S4 Firewall

Mantemos as duas camadas honestamente distintas. A Layer 1, o limite rígido, é determinística e preventiva: qualquer requisição cuja reserva exceda um limite configurado é bloqueada antes do encaminhamento, um bloqueio 100% preventivo de requisições acima do limite (o mesmo estado na entrada gera a mesma decisão na saída, verificado por testes de caos). A Layer 2, a detecção de loop, é de melhor esforço: um comportamento descontrolado só é detectável após algumas chamadas, e essas poucas chamadas já são faturadas, de modo que ela limita o raio de impacto a um pequeno número de requisições ou a um valor baixo em dólares, em vez de garantir 100% de prevenção. Ela acompanha um modo shadow em dry-run para que você possa medir a taxa de falsos bloqueios antes de impor os limites.

É baseado no modelo reserve-then-reconcile, não em uma estimativa simples. Antes do encaminhamento, a reserva utiliza o pior cenário — tokens de entrada contabilizados na hora, saída precificada como max_tokens vezes a taxa de saída — para tomar a decisão de limite rígido (hard cap). Quando a resposta retorna, o uso relatado pelo provedor é considerado a fonte da verdade e reconciliado com a reserva. A contagem de tokens é normalizada entre provedores e dividida em entrada, saída, cached-read e cache-write, de modo que a contabilidade reflita a tabela de preços real de cada provedor.

O próprio S4 Firewall não armazena nem transmite seus prompts ou respostas. Sua única chamada de saída é a requisição ao provedor que sua aplicação faria de qualquer maneira — o firewall não adiciona egress. O registro e as métricas carregam contagens de tokens, não o conteúdo (counts-not-content, garantido por testes de propriedade). Para onde os prompts são enviados depende do upstream escolhido: o roteamento para o Amazon Bedrock por meio de um VPC interface endpoint (PrivateLink, que esta AMI pode provisionar) mantém essas chamadas dentro da sua fronteira AWS, enquanto o roteamento para um provedor de terceiros na internet pública envia o tráfego para a internet e não o mantém na sua VPC.

Não. Não há um plano de controle separado nem banco de dados externo. O estado do orçamento é mantido em memória por instância e recalculado do zero na inicialização. O plano de dados é um único binário estático executado sob uma unidade systemd protegida com zero capacidades elevadas e uma função do IAM de menor privilégio (invocação de modelo upstream, PutMetricData do CloudWatch com escopo restrito ao namespace S4/Firewall e PutObject de gravação exclusiva no bucket do registro de auditoria). Não há chamadas de telemetria externa (home-call) nem validação de chave de licença.

A cobrança é por hora de AMI (tarifada por hora de instância) com uma opção de contrato anual, executada em instâncias c6g / c7g (Arm). A implantação é feita com os modelos do CloudFormation inclusos — cfn-single.yaml para uma única instância, cfn-ha.yaml para uma frota redundante atrás de um balanceador de carga interno —, que opcionalmente criam o VPC interface endpoint do Bedrock. Depois, basta apontar o base_url da sua aplicação para o firewall.