S4 Firewall

Mantenemos las dos capas claramente diferenciadas. La Capa 1, el límite estricto (hard cap), es determinista y preventiva: cualquier petición cuya reserva supere un límite configurado se bloquea antes de su reenvío, un bloqueo preventivo del 100% de las peticiones que superan el límite (el mismo estado de entrada produce la misma decisión de salida, confirmado por chaos tests). La Capa 2, la detección de bucles, es de tipo best-effort: un comportamiento fuera de control solo se puede conocer tras unas cuantas llamadas, y esas llamadas ya se habrán facturado, por lo que limita el radio de impacto a un número pequeño de peticiones o a una cantidad pequeña de dinero, en lugar de garantizar una prevención del 100%. Se incluye con un modo sombra de tipo dry-run para que pueda medir la tasa de falsos bloqueos antes de aplicarlo.

Se basa en el principio de reserva y conciliación (reserve-then-reconcile), no en una estimación plana. Antes de reenviar, la reserva utiliza el peor de los casos (los tokens de entrada se cuentan ahora, la salida se tarifa como max_tokens por la tasa de salida) para tomar la decisión del límite estricto (hard cap). Al devolverse la respuesta, el uso reportado por el proveedor se toma como fuente de verdad y se concilia con la reserva. Los recuentos de tokens se normalizan entre los diferentes proveedores y se dividen en entrada, salida, cached-read y cache-write, de modo que la contabilidad refleje la lista de tarifas reales de cada proveedor.

S4 Firewall por sí mismo no almacena ni transmite sus prompts ni sus respuestas. Su única llamada saliente es la solicitud al proveedor que su aplicación habría hecho de todos modos; el firewall no añade ningún egress adicional. El registro de auditoría y las métricas reflejan recuentos de tokens, no contenido (counts-not-content, confirmado mediante property tests). El destino de salida de los prompts depende del upstream que elija: el enrutamiento a Amazon Bedrock mediante un VPC interface endpoint (PrivateLink, que esta AMI puede aprovisionar) mantiene las llamadas dentro del límite de AWS, mientras que el enrutamiento a un proveedor externo en la internet pública envía el tráfico a internet y no se queda dentro de su VPC.

No. No requiere un plano de control independiente ni una base de datos externa. El estado del presupuesto se guarda en memoria por instancia y se calcula de nuevo desde cero tras un reinicio. El plano de datos es un único binario estático que se ejecuta en una unidad systemd securizada sin ningún privilegio elevado y con un rol de IAM con privilegios mínimos (invocación de modelos upstream, CloudWatch PutMetricData limitado al namespace S4/Firewall y PutObject de solo escritura en el bucket del registro). No realiza llamadas de telemetría (home-call) ni comprobaciones de clave de licencia.

La facturación es por horas de AMI (con tarifa por hora de instancia) y cuenta con opción de contrato anual, ejecutándose sobre instancias c6g / c7g (Arm). Se despliega con las plantillas de CloudFormation incluidas (cfn-single.yaml para una única instancia y cfn-ha.yaml para una flota redundante detrás de un balanceador de carga interno), que opcionalmente crean el VPC interface endpoint de Bedrock. Luego, solo tiene que dirigir la base_url de su aplicación hacia el firewall.