S4 Firewall

Wir halten zwei Layer ehrlich getrennt. Layer 1, das Hard Cap, ist deterministisch und präemptiv: Jede Anfrage, deren Reservierung ein konfiguriertes Limit überschreiten würde, wird vor der Weiterleitung blockiert — eine 100% präemptive Blockierung von Anfragen über dem Limit (derselbe Zustand rein, dieselbe Entscheidung raus, validiert durch Chaos-Tests). Layer 2, die Loop-Erkennung, ist Best-Effort: Ein Runaway ist erst nach einigen Aufrufen erkennbar, und diese wenigen sind bereits abgerechnet. Daher wird der Schadensradius auf eine geringe Anzahl von Anfragen oder einen kleinen Dollarbetrag begrenzt, anstatt eine 100%ige Vermeidung zu garantieren. Es wird mit einem Dry-Run-Shadow-Mode ausgeliefert, sodass Sie die False-Block-Rate messen können, bevor Sie das Limit erzwingen.

Es funktioniert nach dem Prinzip Reserve-then-Reconcile, nicht über eine pauschale Schätzung. Vor der Weiterleitung nutzt die Reservierung den Worst Case — Input-Token werden sofort gezählt, der Output wird mit max_tokens mal der Output-Rate berechnet —, um die Hard-Cap-Entscheidung zu treffen. Wenn die Antwort zurückgegeben wird, gilt die gemeldete Nutzung des Providers als Source of Truth und wird mit der Reservierung abgeglichen. Die Token-Zahlen werden über verschiedene Provider hinweg normalisiert und in Input, Output, Cached-Read und Cache-Write aufgeteilt, sodass die Abrechnung die tatsächliche Preisliste des jeweiligen Providers widerspiegelt.

S4 Firewall selbst speichert oder überträgt Ihre Prompts oder Antworten nicht. Der einzige ausgehende Aufruf ist die Provider-Anfrage, die Ihre Anwendung ohnehin gestellt hätte — die Firewall fügt keinen zusätzlichen Egress hinzu. Das Ledger und die Metriken enthalten Token-Anzahlen, keine Inhalte (counts-not-content, validiert durch Property-Tests). Wohin die Prompts gesendet werden, hängt vom gewählten Upstream ab: Das Routing an Amazon Bedrock über einen VPC-Interface-Endpoint (PrivateLink, den dieses AMI optional bereitstellen kann) hält diese Aufrufe innerhalb Ihrer AWS-Grenzen, während das Routing an einen Drittanbieter im öffentlichen Internet Traffic ins Internet leitet und dieser nicht in Ihrer VPC verbleibt.

Nein. Es gibt weder eine separate Control Plane noch eine externe Datenbank. Der Budgetstatus wird pro Instanz in-memory gehalten und bei einem Neustart von Grund auf neu hergeleitet. Die Data Plane ist ein einzelnes statisches Binary, das unter einer gehärteten systemd-Unit ohne jegliche erweiterte Berechtigungen läuft, ausgestattet mit einer Least-Privilege-IAM-Rolle (Upstream-Modellaufruf, CloudWatch PutMetricData beschränkt auf den Namespace S4/Firewall und write-only PutObject auf den Ledger-Bucket). Es gibt keinen Telemetrie-Home-Call und keine Lizenzschlüsselprüfung.

Die Abrechnung erfolgt stündlich über das AMI (abgerechnet pro Instanzstunde) mit einer jährlichen Vertragsoption, ausgeführt auf c6g / c7g (Arm) Instanzen. Die Bereitstellung erfolgt über die mitgelieferten CloudFormation-Templates — cfn-single.yaml für eine einzelne Instanz, cfn-ha.yaml für eine redundante Fleet hinter einem internen Load Balancer —, die optional den Bedrock VPC-Interface-Endpoint erstellen. Danach richten Sie einfach die base_url Ihrer Anwendung auf die Firewall.