S4 Firewall
Budget de tokens LLM et contrôle des boucles runaway
Un proxy de forwarding dans le VPC qui place un spend firewall préemptif devant votre trafic LLM. Votre app ne change que son base_url (compatible OpenAI, compatible Anthropic Messages ou compatible Bedrock) ; chaque requête passe par un pipeline synchrone attribute → reserve → budget/anomaly → forward → reconcile. Sa fonction principale est le circuit breaker de boucle runaway : il bloque de façon déterministe une requête avant qu’elle soit relayée dès qu’un budget serait dépassé.
S4 Firewall est un proxy de forwarding qui place un budget et un circuit breaker devant vos dépenses en tokens LLM, avec deux couches honnêtement distinctes. La couche 1, le hard cap, est déterministe et préemptive : la dépense cumulée est connue, donc toute requête dont la réservation ferait passer le total courant au-delà d’un hard cap configuré est bloquée avant d’être relayée — un blocage préemptif à 100% des requêtes au-dessus du cap, fixé par des chaos tests. La couche 2, le blocage de boucle, est best-effort et comportementale : elle détecte les boucles d’agents, les chaînes d’appels quasi dupliquées et l’amplification intra-session pour limiter le blast radius. La dépense est attribuée par feature / tenant / customer, et les réponses en streaming passent chunk par chunk afin de préserver le time-to-first-token.
Le problème
Les dépenses en tokens LLM sont particulièrement sujettes aux emballements : une boucle d'agent, une chaîne d'appels quasi-identiques ou une amplification au sein d'une session peuvent consommer le budget d'un mois avant que quiconque ne s'en aperçoive. Étant donné que le nombre de tokens de sortie est imprévisible avant le retour de la réponse, sans un mécanisme qui interrompt les dépenses avant que la facture ne soit engagée, vous devez reconstituer après coup quelle fonctionnalité, quel tenant ou quel client a fait grimper les coûts. Vos dépenses suivent une boucle incontrôlée plutôt que le travail que vous aviez réellement prévu.
Fonctionnement
- 1
Pointez simplement votre base_url vers lui
S4 Firewall est un proxy de transfert que vous exécutez au sein de votre propre Amazon VPC. Votre application change uniquement son base_url : le pare-feu accepte un flux compatible OpenAI, Anthropic Messages ou Bedrock, et relaye chaque requête vers le fournisseur amont que vous utilisez déjà. Les réponses en streaming sont transmises chunk par chunk sans mise en mémoire tampon, préservant ainsi le time-to-first-token.
- 2
Attribuer, réserver et décider dans un seul pipeline synchrone
Avant le transfert, chaque requête passe par un pipeline synchrone attribute -> reserve -> budget/anomaly -> forward -> reconcile. Il associe la requête à une fonctionnalité, un tenant et un client, réserve le coût dans le pire des cas (les tokens d'entrée sont comptabilisés immédiatement, la sortie est valorisée à max_tokens fois le tarif de sortie), compare la réservation à la hiérarchie des budgets, puis la transfère ou la bloque.
- 3
Deux couches d'arrêt, puis réconciliation avec l'utilisation réelle
La Layer 1, le hard cap, est déterministe et préemptive : toute requête dont la réservation dépasserait un plafond configuré est bloquée avant transfert (un blocage 100 % préemptif des requêtes dépassant la limite, le même état en entrée produisant la même décision en sortie, validé par des chaos tests). La Layer 2, le loop block, est de type best-effort et comportementale : elle détecte les boucles d'agent, les chaînes d'appels quasi-identiques et l'amplification au sein de la session pour limiter le blast radius. Lorsque la réponse est renvoyée, l'utilisation déclarée par le fournisseur sert de source de vérité et est réconciliée avec la réservation.
Points forts
Hard cap déterministe : bloque une requête hors budget avant qu’elle soit relayée (hiérarchie de budgets tenant / feature / customer).
Circuit breaker contre les boucles incontrôlées : détecte les boucles d’agents et les chaînes d’appels quasi dupliquées afin de limiter le blast radius.
Drop-in : base_url compatible OpenAI / Anthropic / Bedrock, streaming passthrough (TTFT préservé), s’exécute dans votre propre VPC.
Ce qui est inclus
- AMI Amazon Linux 2023 arm64 (s'exécute sur les instances Graviton c6g / c7g, facturée à l'heure d'instance)
- Proxy de transfert avec flux d'entrée compatible OpenAI, Anthropic Messages et Bedrock (les applications changent uniquement leur base_url ; le streaming passe chunk par chunk, préservant le TTFT)
- Hard cap Layer 1 — un circuit breaker déterministe et préemptif qui bloque toute requête hors budget avant transfert (blocage 100 % préemptif des requêtes hors limite, validé par des chaos tests)
- Loop block Layer 2 — une couche comportementale de type best-effort qui détecte les boucles d'agent, les chaînes d'appels quasi-identiques et l'amplification au sein de la session pour limiter le blast radius (sans garantie à 100 % ; livré avec un mode shadow dry-run)
- Comptabilité de tokens de type reserve-then-reconcile — la réservation se base sur le pire des cas (les tokens d'entrée sont comptabilisés immédiatement, la sortie est valorisée à max_tokens fois le tarif de sortie), puis est réconciliée avec l'utilisation signalée par le fournisseur comme source de vérité
- Attribution des dépenses de tokens par fonctionnalité/tenant/client, envoyée à Amazon CloudWatch (namespace S4/Firewall) et un registre d'audit de comptage seul (sans jamais enregistrer les corps de prompt ou de réponse)
- Modèles CloudFormation en un clic (cfn-single.yaml pour une instance unique, cfn-ha.yaml pour une flotte redondante derrière un load balancer interne), avec un rôle IAM de moindre privilège, sans control plane ni base de données séparés
Cas d'usage
Arrêt d'un agent en fuite avec un hard cap déterministe avant qu'il ne consomme le budget du mois
Équipes ayant besoin d'attribuer les dépenses de tokens par fonctionnalité, tenant ou client — avec une granularité plus fine que le principal IAM — et d'allouer les budgets en conséquence
Gouvernance du trafic LLM sans transmettre les prompts ni les corps de réponse à un tiers — un registre qui enregistre le nombre de tokens, et non le contenu
Placer un budget unique au sein du VPC devant le trafic compatible OpenAI, Anthropic et Bedrock en pointant le base_url de l'application vers le proxy
FAQ
Peut-il arrêter un agent en fuite dans 100 % des cas ?
Nous gardons les deux couches honnêtement distinctes. La Layer 1, le hard cap, est déterministe et préemptive : toute requête dont la réservation dépasserait un plafond configuré est bloquée avant le transfert, soit un blocage 100 % préemptif des requêtes hors limite (même état en entrée, même décision en sortie, validé par des chaos tests). La Layer 2, la détection de boucle, est de type best-effort : un emballement n'est détectable qu'après quelques appels, et ces quelques appels sont déjà facturés, elle limite donc le blast radius à un petit nombre de requêtes ou à un faible montant en dollars plutôt que de garantir une prévention à 100 %. Elle est livrée avec un mode shadow dry-run pour vous permettre de mesurer le taux de faux blocages avant l'application des règles.
Si les tokens de sortie sont inconnus à l'avance, comment les dépenses sont-elles arrêtées avant la facturation ?
Il s'agit d'un mécanisme de type reserve-then-reconcile, et non d'une estimation forfaitaire. Avant le transfert, la réservation utilise le pire des cas — les tokens d'entrée étant comptabilisés immédiatement, et la sortie tarifée à max_tokens fois le tarif de sortie — pour prendre la décision de type hard-cap. Lorsque la réponse est renvoyée, l'utilisation signalée par le fournisseur est prise comme source de vérité et réconciliée avec la réservation. Le nombre de tokens est normalisé entre les fournisseurs et réparti en entrée, sortie, cached-read et cache-write, de sorte que la comptabilité reflète la grille tarifaire réelle de chaque fournisseur.
Où mes prompts sont-ils stockés ou envoyés ?
S4 Firewall lui-même ne conserve ni ne transmet vos prompts ou vos réponses. Son seul appel sortant est la requête vers le fournisseur que votre application aurait passée de toute façon — le pare-feu n'ajoute aucun trafic sortant (egress). Le registre et les métriques contiennent le nombre de tokens, pas le contenu (counts-not-content, validé par des property tests). La destination des prompts dépend du fournisseur amont choisi : le routage vers Amazon Bedrock via un VPC interface endpoint (PrivateLink, que cette AMI peut provisionner) maintient ces appels à l'intérieur de votre frontière AWS, tandis que le routage vers un fournisseur tiers sur l'internet public sort vers internet et ne reste pas dans votre VPC.
Nécessite-t-il un control plane ou une base de données séparés ?
Non. Il n'y a pas de control plane séparé ni de base de données externe. L'état du budget est conservé en mémoire par instance et recalculé à partir de zéro au redémarrage. Le data plane est un binaire statique unique fonctionnant sous une unité systemd sécurisée sans privilèges élevés et doté d'un rôle IAM de moindre privilège (vocation de modèle amont, CloudWatch PutMetricData restreint au namespace S4/Firewall, et PutObject en écriture seule sur le bucket du registre). Il n'y a aucun appel télémétrique vers l'extérieur (home-call) ni de vérification de clé de licence.
Comment est-il facturé et comment le déployer ?
La facturation se fait au tarif horaire de l'AMI (mesurée par heure d'instance) avec une option de contrat annuel, le tout fonctionnant sur des instances c6g / c7g (Arm). Vous effectuez le déploiement à l'aide des modèles CloudFormation fournis — cfn-single.yaml pour une instance unique, cfn-ha.yaml pour une flotte redondante derrière un load balancer interne — qui peuvent également créer le VPC interface endpoint de Bedrock. Ensuite, il vous suffit de diriger le base_url de votre application vers le pare-feu.
Modèle de tarification
Frais logiciel horaires + EC2 (classe c6g, Arm). Facturation à l’usage par type d’instance.
Autres produits S4
S4 — Squished S3
Gateway transparent de compression S3 par GPU
S4 Logs
Archiver CloudWatch Logs vers S3 zstd
S4 Metrics
Gouverner la cardinalité des métriques CloudWatch