O objetivo principal é ajudar organizações que utilizam a AWS a planejar, implementar e evidenciar os controles relevantes para o escopo da CCM — especialmente aquelas que estão buscando ou precisam manter a certificação CSA STAR.
O que é a Cloud Controls Matrix?
Antes de entender o guia em si, vale contextualizar o framework por trás dele. A Cloud Security Alliance é uma organização sem fins lucrativos dedicada a definir e disseminar boas práticas de segurança em nuvem.
A Matriz de Controles de Nuvem (CCM) é um framework de controles de cibersegurança desenvolvido pela CSA. Ela oferece um conjunto detalhado de controles de segurança distribuídos em múltiplos domínios — como auditoria e garantia, gestão de identidade e acesso, e criptografia e gestão de chaves — projetados especificamente para avaliar e gerenciar riscos de segurança em ambientes de computação em nuvem.
Um ponto importante: a CCM é agnóstica em relação ao provedor de nuvem. Isso significa que ela foi desenvolvida para ser aplicável a qualquer provedor de serviços em nuvem ou modelo de implantação — seja Infraestrutura como Serviço (IaaS), Plataforma como Serviço (PaaS) ou Software como Serviço (SaaS) — independentemente da tecnologia ou fornecedor subjacente. Ou seja, os controles universais que ela define podem ser aplicados em diferentes plataformas de nuvem.
A AWS, por sua vez, mantém a certificação CSA STAR Nível 2, que combina os requisitos da ISO/IEC 27001:2022 com a CCM. A documentação CSA e o Questionário de Iniciativa de Avaliações de Consenso da AWS (CAIQ) estão disponíveis para clientes AWS por meio do AWS Artifact.
Responsabilidade do provedor de serviços em nuvem (CSP)
Responsabilidade do cliente
Responsabilidade compartilhada (independente ou dependente)
O guia recomenda usar o SSRM em conjunto com o Modelo de Responsabilidade Compartilhada da AWS. Para os controles que são de responsabilidade da AWS, o guia aponta para os atestados da AWS disponíveis no AWS Artifact — como relatórios SOC, certificados ISO e o atestado CSA STAR — como evidências herdadas. Para os controles que são de responsabilidade do cliente ou compartilhados, o guia descreve como implementá-los e evidenciá-los usando serviços AWS.
Aqui vale um alerta importante que o próprio guia destaca: utilizar um serviço AWS com certificação CSA STAR não torna automaticamente a carga de trabalho do cliente em conformidade. Os clientes continuam sendo responsáveis por configurar os serviços, gerenciar acessos, proteger dados e implementar controles adicionais com base em seu ambiente, avaliações de risco e obrigações regulatórias.
O que está dentro do guia
Para cada controle da CCM, o guia apresenta:
Aplicabilidade: indica se o controle é aplicável ao contexto AWS
Implementação: descreve como as organizações podem implementar o controle na AWS
Armadilhas comuns: identifica erros frequentes que devem ser evitados
Exemplos de evidência: lista exemplos que podem ser utilizados durante uma avaliação de conformidade
O guia tem caráter informativo e não substitui a documentação oficial de conformidade e as certificações da AWS disponíveis no AWS Artifact.
Recursos relacionados e como acessar
Para quem quiser se aprofundar no tema, a AWS disponibilizou os seguintes recursos:
Para times de segurança, compliance e arquitetura de nuvem no Brasil, esse guia representa um material de referência valioso. A CCM é amplamente reconhecida como um framework robusto para gestão de segurança em nuvem, e ter um mapeamento direto para os serviços AWS facilita bastante o trabalho de quem precisa demonstrar conformidade — seja para auditorias internas, clientes ou órgãos reguladores.
O fato de o guia apontar armadilhas comuns e exemplos de evidências para cada controle é especialmente útil na prática: não basta saber o que implementar, é preciso saber como provar que foi implementado corretamente. Esse tipo de orientação costuma fazer diferença real no dia a dia de quem trabalha com certificações e auditorias.
Se você já usou Geração Aumentada por Recuperação (RAG) para analisar centenas de documentos ao mesmo tempo — como em processos de due diligence financeira ou revisões de conformidade regulatória — provavelmente já esbarrou nas suas limitações. A busca por similaridade consegue recuperar fragmentos relevantes, mas frequentemente perde as conexões que existem entre documentos diferentes.
Para ilustrar o problema, imagine uma firma de private equity avaliando uma aquisição de R$ 500 milhões. A equipe de due diligence precisa analisar demonstrações financeiras de 12 subsidiárias ao longo de 5 anos, mais de 200 contratos com fornecedores, relatórios de conformidade ambiental de 8 instalações e mais de 50 casos jurídicos. Quando um analista pergunta sobre os riscos financeiros consolidados considerando os termos atuais com fornecedores e os litígios pendentes, a busca por similaridade do RAG simplesmente não consegue montar essa resposta — as informações relevantes estão espalhadas por centenas de documentos sem nenhuma similaridade lexical entre elas.
É exatamente esse tipo de problema que a técnica TAKC (Task-Aware Knowledge Compression — Compressão de Conhecimento Orientada a Tarefas) se propõe a resolver.
O que é TAKC e como funciona
A ideia central do TAKC é usar um LLM (Modelo de Linguagem de Grande Escala) para produzir resumos mais curtos e focados em tarefas específicas — com resumos diferentes para tarefas diferentes. O ponto-chave é que documentos diferentes exigem informações diferentes dependendo do contexto de uso.
Um relatório anual comprimido para análise financeira precisa preservar receitas, margens e dados de fluxo de caixa. O mesmo relatório comprimido para uma revisão de conformidade precisa reter citações regulatórias e históricos de violações. Uma sumarização genérica tenta cobrir tudo e acaba diluindo a densidade de informação para qualquer caso de uso específico.
O TAKC comprime os documentos pela lente de uma tarefa específica: mantém o que importa e descarta o resto. Essa compressão acontece offline, uma vez por documento por tipo de tarefa. No momento da consulta, o sistema recupera a representação já comprimida em vez do documento original e responde com base nessa versão. Se a representação comprimida não tiver detalhes suficientes, um analisador de complexidade de consulta redireciona a pergunta para um nível de compressão menor, que retém mais contexto.
Diferente do RAG, o TAKC dá acesso a toda a base de conhecimento em forma comprimida — não apenas aos top-k fragmentos retornados por uma busca por similaridade. Isso preserva as conexões entre documentos, porque a compressão processa os documentos de forma integrada. A redução de tokens varia de 8x a 64x, sempre priorizando as informações relevantes para a tarefa.
Compressão em múltiplos níveis
Nem toda consulta exige o mesmo nível de detalhe. Uma pergunta como “Qual foi a receita do terceiro trimestre?” precisa de muito menos contexto do que um pedido para analisar as relações entre prazos de pagamento a fornecedores e o fluxo de caixa trimestral entre subsidiárias.
O TAKC resolve isso mantendo quatro níveis de compressão para cada tipo de tarefa:
Leve (8x): reduz aproximadamente 87,5% do contexto. Preserva detalhes suficientes para raciocínio em múltiplas etapas e síntese entre documentos.
Médio (16x): redução de aproximadamente 93,8%. Adequado para consultas analíticas de complexidade moderada.
Alto (32x): redução de aproximadamente 96,9%. Atende buscas factuais e perguntas bem definidas.
Ultra (64x): redução de aproximadamente 98,4%. Indicado para tarefas de classificação e buscas por palavras-chave.
Um analisador de complexidade de consulta roteia automaticamente cada pergunta para o nível adequado, com base em sinais como o comprimento da consulta, o tipo de pergunta e a presença de linguagem analítica. Perguntas factuais simples chegam ao cache mais comprimido; consultas analíticas complexas usam o cache menos comprimido. Tudo isso acontece de forma transparente para o usuário.
Na prática, a maioria das consultas empresariais são buscas simples que podem ser atendidas pelos níveis de maior compressão com custo mínimo. As consultas complexas, menos frequentes, consomem orçamentos maiores de contexto apenas quando necessário.
Arquitetura na AWS
A implementação roda na AWS como dois pipelines serverless desacoplados: um para ingestão e outro para consultas.
O AWS Lambda foi escolhido para computação porque cada invocação é de curta duração e orientada a eventos. O Amazon API Gateway expõe a interface de consulta como um endpoint REST. O Amazon ElastiCache Serverless cuida do cache com leituras em chaves compostas (takc:{task}:{rate}) sem necessidade de gerenciamento de shards. O Amazon Cognito gerencia emissão e renovação de tokens JWT sem código de autenticação customizado.
Pipeline de ingestão
Quando um documento chega ao Amazon S3 sob um prefixo de tipo de tarefa (por exemplo, raw-data/financial/), uma notificação de evento S3 aciona uma função AWS Lambda. Essa função divide o documento em segmentos de 256 tokens com sobreposição de 50 tokens para evitar perda de informação nas bordas. Em seguida, invoca de forma assíncrona uma função Lambda de compressão para cada segmento, permitindo processamento paralelo.
A segunda função chama o Amazon Bedrock para comprimir os segmentos nos quatro níveis de compressão. Cada chamada de compressão inclui um prompt orientado à tarefa que instrui o modelo sobre quais informações preservar. Veja um exemplo de prompt para análise financeira:
TASK: Financial analysis. Preserve revenue metrics, margins, cash flow, debt obligations, and financial risk indicators.
COMPRESSION TARGET: Reduce to approximately 1/16 of original length.
INSTRUCTIONS:
- Focus on facts and relationships relevant to the task
- Preserve numerical data and metrics
- Maintain entities and their attributes
- Keep causal relationships and dependencies
- Remove redundant or irrelevant information
O modelo sabe o que preservar porque o prompt especifica exatamente o que importa para aquela tarefa — é isso que torna a abordagem orientada à tarefa, em vez de uma compressão genérica.
As saídas comprimidas são armazenadas no Amazon ElastiCache Serverless com chaves como takc:financial:medium e têm backup no S3 para durabilidade. As entradas de cache usam TTL de 24 horas. Se uma entrada for removida ou expirar, a função de consulta recorre ao backup no S3 e repovoа o cache na leitura.
Pipeline de consulta
O usuário se autentica pelo Amazon Cognito, recebe um JWT (JSON Web Token) e envia a consulta pelo Amazon API Gateway. O AWS WAF (Firewall de Aplicação Web) fica na frente da API para limitação de taxa e proteção contra ameaças. Uma função Lambda analisa a complexidade da consulta por heurísticas, recupera o cache comprimido adequado do ElastiCache e envia o contexto comprimido junto com a consulta ao Amazon Bedrock para inferência.
As chamadas de compressão ao Bedrock — que são mais custosas — acontecem apenas uma vez durante a ingestão. O caminho de consulta é apenas uma busca no cache mais a inferência sobre o contexto comprimido.
Stack completo de serviços
O stack utiliza o Amazon Bedrock (Anthropic Claude 3 Haiku, Claude 3 Sonnet e Amazon Titan Text) para compressão e inferência. A seleção de modelo é configurável via valores de contexto do CDK sem alterações de código. O AWS Lambda (Python 3.12+) trata o processamento de dados e a lógica de consulta. O Amazon ElastiCache Serverless armazena o cache comprimido, enquanto o Amazon S3 guarda dados brutos, segmentos e backups do cache (criptografados com KMS). O Amazon API Gateway expõe os endpoints REST, e o Amazon Cognito fornece autenticação baseada em JWT. O AWS WAF protege a API com limitação de taxa e regras de segurança gerenciadas. O Amazon CloudWatch oferece monitoramento e métricas, e o AWS Key Management Service (AWS KMS) gerencia as chaves de criptografia.
A tabela abaixo mostra o consumo de tokens de entrada para uma base de conhecimento de 100.000 tokens consultada 1.000 vezes por dia (tokens de saída são excluídos porque o tamanho da resposta é independente do tamanho do contexto):
Contexto completo: 100.000 tokens por consulta → 100.000.000 tokens/dia → 100% do custo
O TAKC exige um custo inicial de compressão — chamadas únicas ao Bedrock durante a ingestão. Esse custo se amortiza em bases de conhecimento que mudam com pouca frequência e são consultadas repetidamente. Para bases de conhecimento que mudam a cada hora, o modelo de recuperação por consulta do RAG pode ser mais prático.
Quando escolher TAKC, RAG ou ambos
Cada abordagem tem seu cenário ideal:
TAKC é mais indicado quando: as consultas exigem raciocínio entre documentos e síntese; a base de conhecimento muda diariamente ou menos; os tipos de tarefa são bem definidos; é necessário considerar o corpus completo; e a rastreabilidade da fonte não é obrigatória.
RAG é mais indicado quando: as consultas são buscas factuais pontuais; a base de conhecimento muda a cada hora ou mais; os padrões de consulta são imprevisíveis; apenas alguns documentos são relevantes; e o usuário precisa rastrear a resposta até o documento-fonte.
Na prática, sistemas em produção frequentemente se beneficiam das duas abordagens. O RAG trata buscas rápidas com eficiência. O TAKC trata consultas analíticas onde abordagens baseadas em recuperação perdem conexões importantes. Um analisador de complexidade de consulta pode rotear entre eles. Para cargas de trabalho reguladas que exigem tanto raciocínio entre documentos quanto auditabilidade, é possível combinar TAKC para a resposta analítica e RAG para recuperar os documentos-fonte de suporte na trilha de auditoria.
Como implantar a implementação de referência
Para implantar a implementação de referência, são necessários: uma conta AWS com acesso a modelos do Amazon Bedrock, a CLI do AWS CDK, Python 3.12 ou superior e Node.js 18 ou superior.
Tarefas analíticas complexas que abrangem centenas de documentos exigem mais do que recuperação de fragmentos. O TAKC oferece uma abordagem construída para esse cenário: comprima a base de conhecimento completa offline pela lente de tarefas específicas, armazene essas representações em múltiplos níveis de fidelidade e direcione o nível de compressão adequado para a complexidade de cada consulta.
A implementação na AWS usa o Amazon Bedrock para compressão e inferência, o Amazon ElastiCache Serverless para cache e uma arquitetura totalmente serverless que escala conforme a demanda. O código de referência, a infraestrutura CDK e os scripts de implantação estão disponíveis em aws-samples/sample-bedrock-takc-compression.
A AWS anunciou que o Amazon Neptune Database passou a suportar controle de acesso baseado em tags — conhecido pela sigla TBAC (Tag-Based Access Control) — para o Gerenciamento de Identidade e Acesso (IAM). Com isso, administradores agora podem usar tags de recursos AWS e tags de principais IAM como condições em políticas IAM e em Políticas de Controle de Serviço (SCPs) para governar o acesso a operações no plano de dados do Neptune.
Por que esse recurso foi criado
O Neptune já oferecia uma base sólida de segurança: isolamento via VPC, criptografia TLS e autenticação IAM. No entanto, equipes que gerenciam múltiplos clusters em escala enfrentavam um desafio prático — precisavam de um mecanismo dinâmico e baseado em atributos para impor fronteiras de acesso organizacionais sem ter que listar manualmente o ARN (Amazon Resource Name) de cada cluster em cada política criada.
O TBAC resolve exatamente esse problema. Com ele, o acesso passa a ser governado por correspondência de tags, e não por enumeração de recursos.
Como o TBAC funciona na prática
Com o TBAC habilitado, um principal IAM só consegue executar ações neptune-db:* nos clusters do Neptune cujas tags coincidam com as suas próprias tags. Um exemplo direto: um principal com a tag Project=FraudDetection fica automaticamente restrito a clusters que também carregam essa mesma tag — sem nenhuma regra adicional explícita.
Esse modelo traz benefícios concretos para times que trabalham em ambientes compartilhados:
Elimina o risco de acesso lateral dentro de ambientes VPC compartilhados
Impõe isolamento por time e por ambiente entre projetos diferentes
Suporta fluxos de identidade federada usando tags de sessão SAML ou OIDC vindas de provedores de identidade externos
Para cenários que exigem ainda mais granularidade, é possível combinar o TBAC com permissões específicas, como neptune-db:QueryLanguage, para um controle de acesso ainda mais refinado.
Disponibilidade e requisitos
O recurso está disponível em todas as regiões AWS onde o Amazon Neptune opera. Para utilizá-lo, é necessário que o cluster esteja rodando a versão de engine 1.2.0.0 ou superior e com a autenticação IAM habilitada.
Para saber como configurar o TBAC no Amazon Neptune — incluindo como aplicar tags nos clusters de banco de dados e nos principais IAM, além de como implantar proteções em nível organizacional usando SCPs — a AWS disponibiliza orientações detalhadas na documentação oficial do Amazon Neptune.
A AWS colocou em preview o Security Hub MCP App, um servidor local baseado no Protocolo de Contexto de Modelo (MCP) que conecta os findings de exposição do Security Hub diretamente ao Claude Desktop. Na prática, isso significa que profissionais de segurança podem investigar problemas e agir sobre exposições sem precisar alternar entre ferramentas — tudo dentro do próprio ambiente de IA.
Por que isso importa
Um dos maiores gargalos no trabalho de segurança em nuvem é a troca constante de contexto: você identifica um alerta no painel, abre outra ferramenta para investigar o caminho de ataque, vai para uma terceira para verificar a configuração do recurso afetado, e assim por diante. O Security Hub MCP App foi criado justamente para reduzir esse atrito, centralizando a investigação dentro do fluxo assistido por IA.
O que você consegue fazer com o Security Hub MCP App
Com o app configurado, é possível interagir com os dados de segurança usando linguagem natural. Entre as capacidades disponíveis:
Visualizar os principais findings de exposição da sua conta
Detalhar o caminho de ataque e o caminho de rede expandido de um finding específico
Examinar findings correlacionados e as configurações dos recursos afetados
Obter recomendações de remediação diretamente na conversa
Cada chamada de ferramenta retorna dois elementos: um resumo em texto para que o agente de IA possa raciocinar sobre o problema, e uma visualização interativa para que você possa verificar os dados na mesma conversa.
Como o servidor funciona na prática
O servidor MCP roda localmente na sua máquina, utilizando as credenciais AWS que você já possui. Um ponto importante: todas as ferramentas disponíveis são somente leitura — nenhuma alteração é feita no seu ambiente. Isso garante que a investigação seja segura por padrão, sem risco de modificações acidentais.
Disponibilidade e custo
O Security Hub MCP App está disponível sem custo adicional para clientes do Security Hub. O recurso se encontra em preview em todas as regiões comerciais da AWS que já suportam o Security Hub.
A AWS anunciou duas novas capacidades para o AWS Glue Data Quality: suporte à detecção de anomalias em avaliações baseadas no Catálogo (GDC) e a possibilidade de gravar os resultados das avaliações diretamente em tabelas do AWS Glue Data Catalog. Ambas as funcionalidades funcionam tanto em jobs de ETL (Extração, Transformação e Carga) quanto em avaliações diretas no Catálogo, garantindo uma experiência consistente de qualidade de dados independentemente do tipo de fluxo de trabalho utilizado.
Detecção de anomalias com Machine Learning
Com o suporte à detecção de anomalias para tabelas do GDC, a AWS permite identificar mudanças inesperadas nas estatísticas dos dados — como quedas repentinas em valores distintos ou picos no número de linhas — sem a necessidade de escrever regras com limites explícitos. O mecanismo usa previsão de séries temporais com ML (Machine Learning) para detectar esses desvios automaticamente.
Essa capacidade é especialmente útil para engenheiros de dados que monitoram centenas de tabelas no GDC e precisam que problemas sejam identificados de forma automática, sem intervenção manual constante.
Gravação de resultados no Glue Data Catalog
A segunda novidade é a capacidade de armazenar os resultados das avaliações diretamente em tabelas do GDC. Isso inclui:
Resultados das regras de qualidade de dados
Métricas de profiling (perfilamento dos dados)
Previsões de anomalias com intervalos de confiança
Com isso, cria-se um histórico consultável de todas as avaliações de qualidade realizadas. Independentemente de a avaliação ter sido executada em um job ETL ou diretamente em uma tabela do Catálogo, os resultados podem ser consultados a qualquer momento usando SQL padrão.
Disponibilidade
As funcionalidades de detecção de anomalias e armazenamento de resultados no GDC estão disponíveis em todas as regiões comerciais da AWS e nas regiões do AWS GovCloud (US). Para começar a usar, a AWS disponibiliza a documentação oficial do AWS Glue Data Quality.
O problema com ataques DDoS na camada de aplicação
Ataques de Negação de Serviço Distribuído (DDoS) na camada de aplicação são especialmente difíceis de combater porque imitam tráfego legítimo. Inundações de requisições HTTP — os chamados request floods — estão entre os vetores mais comuns contra aplicações web, e o desafio é justamente que essas requisições parecem normais à primeira vista.
O que é o grupo de regras Anti-DDoS do WAF e por que é melhor
O novo grupo de regras gerenciadas Anti-DDoS (AWSManagedRulesAntiDDoSRuleSet) representa uma evolução significativa em relação à mitigação automática atual do Shield Advanced. Veja os principais diferenciais:
Baseline em minutos, não horas: o sistema aprende o perfil de tráfego normal da aplicação e estabelece uma linha de base muito mais rapidamente do que a proteção anterior.
Reação em segundos: quando um ataque começa, a resposta é quase imediata — sem necessidade de configurar verificações de integridade.
Nova ação Challenge: além de Count e Block, o grupo adiciona a ação Challenge, que apresenta um desafio silencioso de navegador em segundo plano. Usuários legítimos não percebem nada; tráfego automatizado malicioso é filtrado.
Sensibilidade configurável: é possível definir níveis Baixo, Médio ou Alto separadamente para as ações Block e Challenge. Por exemplo, você pode usar Challenge em alta sensibilidade para capturar mais tráfego suspeito e manter Block em baixa sensibilidade para evitar falsos positivos.
Menor consumo de capacidade: o grupo consome 50 Unidades de Capacidade de Lista de Controle de Acesso Web (WCUs), contra 150 da proteção anterior — sobrando mais espaço para suas outras regras.
Visibilidade granular: cada requisição inspecionada recebe rótulos (labels) indicando nível de suspeita, eventos detectados e regras aplicadas. Esses rótulos ficam disponíveis para uso nas suas próprias regras do AWS WAF.
Sem cobrança pelo tráfego de ataque: durante mitigação ativa (Block ou Challenge), as requisições DDoS bloqueadas saem da contagem mensal, isentando você de cobranças do WAF, do grupo Anti-DDoS e do Shield Advanced por esse tráfego.
Vale reforçar: o Shield Advanced não é obrigatório para usar o grupo de regras Anti-DDoS. Assinantes do Shield Advanced recebem o grupo incluído no WAF, mas qualquer cliente pode ativá-lo de forma independente. Consulte a tabela de preços do AWS WAF para mais detalhes.
O cronograma de migração em 5 fases
A AWS estruturou a transição em cinco fases. As datas abaixo representam quando a AWS age automaticamente — você pode agir antes em qualquer fase.
Fase 1 — Implantação em modo Count (27 de julho a 7 de agosto de 2026)
A AWS adicionará o grupo de regras Anti-DDoS em modo Count a todas as Listas de Controle de Acesso Web (ACLs) elegíveis — ou seja, ACLs do Shield Advanced com pelo menos um recurso usando mitigação automática de camada de aplicação que ainda não execute o grupo Anti-DDoS. Nessa fase, o grupo apenas observa e rotula as requisições, sem agir sobre elas. Sua mitigação automática atual continua funcionando normalmente.
Fase 2 — Período de avaliação gratuita (27 de julho a 30 de setembro de 2026)
Os dois sistemas rodam em paralelo e detectam ataques de forma independente. Durante esse período, todas as cobranças do grupo Anti-DDoS são isentas para as ACLs elegíveis da Fase 1 — incluindo taxa de assinatura, cobranças por requisição e consumo de WCU. Use esse tempo para comparar os resultados de detecção usando a métrica DDoSAttackRequests, os rótulos do WAF e o painel Anti-DDoS.
Fase 3 — Atualização automática (a partir de 1º de outubro de 2026)
Para ACLs elegíveis, a AWS realiza a migração automaticamente, herdando a configuração atual: uma ACL em modo Block continua em Block; uma em modo Count continua em Count. A operação é atômica — a mitigação automática é desativada no mesmo passo em que o grupo Anti-DDoS assume, sem nenhuma janela de exposição. Se preferir não migrar automaticamente, é possível optar por não participar entrando em contato com o Suporte da AWS antes dessa data.
Fase 4 — Migração guiada (27 de julho a 31 de dezembro de 2026)
Você não precisa esperar pela atualização automática de outubro. Assim que o grupo de regras for implantado em modo Count (entre 27 de julho e 7 de agosto), é possível migrar no seu próprio ritmo. Essa fase é especialmente importante para ACLs em modo misto ou com recursos sem mitigação automática habilitada — que não são elegíveis para a Fase 3. Trabalhe com a equipe de conta da AWS e o Suporte nesse período.
Fase 5 — Descontinuação da mitigação automática do Shield Advanced (1º de janeiro de 2027)
A partir de 1º de janeiro de 2027, a mitigação automática de camada de aplicação do Shield Advanced deixará de existir. Recursos que não tiverem sido migrados para o grupo Anti-DDoS perderão a proteção automática de L7. O prazo é definitivo.
Observabilidade: três camadas de visibilidade
O grupo Anti-DDoS oferece um modelo de observabilidade em três camadas, mais rico do que a proteção atual:
Camada 1 — Detecção de eventos
Dois métricas do Amazon CloudWatch indicam eventos DDoS ativos. A métrica DDoSDetected (namespace AWS/DDoSProtection) continua existindo para eventos de camadas 3 e 4 após a migração — seus alarmes de rede permanecem válidos. Para camada de aplicação, a nova métrica é DDoSAttackRequests (namespace AWS/WAFV2), que conta requisições durante eventos L7. Configure o alarme com Sum >= 1 para detectar qualquer evento, ou defina um limite de volume para alertas por severidade. Como essa métrica fica ausente fora de eventos ativos, configure o tratamento de dados ausentes como missing ou notBreaching.
Camada 2 — Rótulos de detecção para monitoramento customizado
Cada requisição avaliada recebe rótulos no namespace awswaf:managed:aws:anti-ddos:. Os principais são: event-detected (requisição durante evento detectado), ddos-request (parte do ataque), low-suspicion-ddos-request, medium-suspicion-ddos-request, high-suspicion-ddos-request (níveis graduados de suspeita) e challengeable-request (elegível para desafio de navegador). Use esses rótulos nas suas próprias regras WAF ou analise-os nos logs via CloudWatch Logs Insights ou Amazon Athena.
Camada 3 — Métricas de ação de mitigação
Durante um evento ativo, métricas como ChallengeAllDuringEvent, ChallengeDDoSRequests e DDoSRequests mostram o que o grupo de regras está fazendo com o tráfego suspeito. Se você estiver desafiando muito mais requisições do que bloqueando, pode ser sinal de que a configuração está conservadora demais — e que vale aumentar o nível de sensibilidade.
Considerações de cobrança
A assinatura do Shield Advanced inclui o grupo Anti-DDoS para até 50 bilhões de requisições por mês, contabilizadas em toda a organização no nível da conta pagadora. Para a maioria dos clientes, esse limite está bem acima do tráfego normal. Consulte a tabela de preços do AWS WAF e a tabela de preços do Shield Advanced para os valores exatos.
Um ponto importante: manter o grupo em modo Count além do período de avaliação significa ter a proteção sem o benefício da isenção de cobranças por tráfego de ataque. Evite permanecer em Count mais tempo do que o necessário para validar a detecção.
Também vale atenção ao nível da ACL: como o grupo opera por web ACL, todos os recursos associados a ela compartilham a cobertura. Uma ACL protegendo 20 recursos tem uma dinâmica de cobrança diferente de uma com 2 recursos.
Atualize sua infraestrutura como código
Se você gerencia ACLs com AWS CloudFormation, AWS Cloud Development Kit (AWS CDK), Terraform ou outra ferramenta de Infraestrutura como Código (IaC), a atualização automática da Fase 3 alterará sua infraestrutura fora dos seus templates. Você precisará fazer duas coisas:
Mover a declaração de proteção: hoje, a mitigação automática é habilitada via API do Shield (EnableApplicationLayerAutomaticResponse), por recurso. O grupo Anti-DDoS é configurado via API do WAF (CreateWebACL / UpdateWebACL), como um managed rule group statement dentro da ACL. Em termos de IaC, você remove o bloco de resposta automática do Shield (ex: aws_shield_application_layer_automatic_response no Terraform) e adiciona o statement do grupo gerenciado na ACL.
Sincronizar o estado: após a atualização automática, importe o estado atual para sua ferramenta antes do próximo deploy (terraform plan, detecção de drift no CloudFormation, cdk diff), para evitar que o pipeline reverta a mudança.
Quem usa o AWS Firewall Manager com uma política do Shield Advanced precisa adicionar o grupo Anti-DDoS a uma política do WAF no Firewall Manager. A política do Shield continua cuidando de L3 e L4; a proteção de camada de aplicação migra para a política WAF.
O processo é direto: adicione ou reutilize uma política WAF no Firewall Manager, inclua o grupo Anti-DDoS (AWS AntiDDoS Protection for Layer 7 attacks) nos First rule groups — abaixo de qualquer regra Allow customizada que você use para liberar tráfego conhecido — e aplique ao mesmo escopo de contas e recursos da sua política Shield. O Firewall Manager propagará a mudança para todas as contas no escopo.
A AWS recomenda os seguintes passos após o grupo ser implantado em modo Count (entre 27 de julho e 7 de agosto de 2026):
Acesse o painel Anti-DDoS no console do AWS WAF para visualizar eventos em tempo real, métricas e principais fontes de tráfego.
Compare a detecção dos dois sistemas lado a lado: métrica DDoSDetected no namespace AWS/DDoSProtection versus DDoSAttackRequests no AWS/WAFV2. Você pode usar o painel de comparação do CloudWatch disponível no repositório AWS Samples para visualizar ambos em um único lugar.
Habilite os logs do WAF e explore os rótulos no namespace awswaf:managed:aws:anti-ddos: para ter visibilidade por requisição.
Comece com sensibilidade Baixa para ações de Block durante a avaliação, minimizando o risco de falsos positivos. Ajuste conforme ganha confiança nos dados.
Planeje a configuração: revise níveis de sensibilidade, isenções de URI para caminhos não-HTML e a prioridade do grupo na ACL (deve ser a mais alta, ou logo abaixo de regras Allow customizadas).
Sincronize seus templates de IaC após a atualização automática, antes do próximo deploy.
Conclusão
A mudança que a AWS está promovendo é substancial: o grupo de regras Anti-DDoS do WAF estabelece baseline em minutos, reage em segundos e oferece visibilidade granular que a mitigação automática atual simplesmente não entrega. O período de avaliação gratuita existe justamente para que você possa observar os dois sistemas rodando no seu próprio tráfego antes de qualquer mudança efetiva.
A recomendação prática é aproveitar as semanas em modo Count para confirmar que a nova detecção está alinhada com o que você vê hoje, migrar seus alarmes e escolher um nível de sensibilidade com o qual se sinta confortável. Se você opera ACLs com muitos recursos ou gerencia regras via Firewall Manager, envolva o time de conta da AWS e o Suporte antes de começar.
O prazo final é 1º de janeiro de 2027. Qualquer recurso que ainda depender da mitigação automática do Shield Advanced após essa data ficará sem proteção automática de camada de aplicação.
A semana consolidou uma tendência clara: IA agêntica e segurança cloud deixaram de ser disciplinas separadas. O GuardDuty ganhou um agente de IA que comprime investigações de ameaças de horas para minutos, enquanto o DevOps Agent já resolve falhas de rede com correlação automática de logs. No Bedrock, chegaram Claude Opus 5 e três modelos GPT-5.6 da OpenAI, ampliando as opções para quem constrói aplicações em produção. No lado de segurança e compliance, WAF com regras dinâmicas, filtros IAM no CloudTrail e criptografia CMK no Lambda Durable Functions entregam controle mais granular sem aumentar complexidade operacional.
O que muda na prática
Investigação de incidentes na AWS muda de processo manual para fluxo assistido por IA: GuardDuty e DevOps Agent já correlacionam achados, mapeiam MITRE ATT&CK e sugerem remediação automaticamente — times de SOC precisam revisar seus runbooks.
A escolha de modelo de LLM no Bedrock ficou mais complexa e mais poderosa: com Claude Opus 5 e os três modelos GPT-5.6 disponíveis, arquitetos precisam avaliar custo-benefício por caso de uso antes de subir para produção.
Políticas de WAF e auditoria de logs ficam mais baratas de manter: interpolação dinâmica de labels reduz centenas de regras estáticas a uma, e filtros IAM no CloudTrail cortam ruído e custo de ingestão de eventos de rede.
Ações da semana
Ative o agente de investigação do GuardDuty no seu ambiente de staging e rode um achado real para medir o ganho de tempo antes de liberar em produção.
Acesse o Bedrock e compare latência e custo entre Claude Opus 5 e GPT-5.6 Sol no seu caso de uso principal — use o Bedrock Playground com seus próprios prompts de produção para ter dados concretos.
Três novos modelos OpenAI acessíveis via Bedrock ampliam drasticamente as opções de inferência, agentes de código e raciocínio de longa duração na AWS.
Para quem: Arquitetos de soluções e engenheiros de IA que precisam escolher o modelo certo para cada caso de uso.
O problema: correlacionar dados manualmente custa tempo
Quando um administrador altera uma regra no AWS Network Firewall e a conectividade cai, identificar a causa exige inspecionar vários pontos ao longo do caminho do tráfego. O firewall oferece motores de regras stateless e stateful, regras de domínio e roteamento até o endpoint do firewall dentro da Rede Virtual Privada da Amazon (Amazon VPC). Para a carga de trabalho, uma queda de pacotes parece idêntica independentemente de onde se originou. Isolar a causa significa cruzar logs de alertas e de fluxo com a configuração do firewall, tabelas de rotas e chamadas de API recentes no AWS CloudTrail que possam ter modificado algum desses recursos.
É exatamente nessa correlação manual que o AWS DevOps Agent entra. Funcionando como um parceiro de operações sempre disponível, ele resolve e previne proativamente problemas operacionais em ambientes AWS, multicloud e on-premises. Quando um alarme do Amazon CloudWatch dispara, ele chega ao agente via webhook. O agente lê a configuração e os logs do firewall pelas APIs da AWS, associa a queda à atividade recente de API e devolve uma causa raiz acompanhada de um plano de mitigação — que você revisa antes de aplicar.
A arquitetura do ambiente de demonstração
A AWS disponibilizou um aplicativo AWS Cloud Development Kit (AWS CDK) que implanta todo o ambiente na sua própria conta, permitindo reproduzir cada falha e acompanhar o passo a passo. A carga de trabalho consiste em uma instância t3.micro em uma sub-rede protegida que verifica conectividade com um endpoint de teste em loop contínuo e publica os resultados no CloudWatch. O tráfego percorre o caminho de saída pela internet através do Network Firewall, do gateway NAT e do gateway de internet.
O endpoint de teste roda em uma VPC separada implantada pelo mesmo aplicativo CDK, servindo HTTPS na porta 443 e TCP na porta 9142. O pipeline de alarmes corre do CloudWatch pelo Amazon Simple Notification Service (Amazon SNS) e por uma função AWS Lambda de webhook até o DevOps Agent.
Para usar o mesmo padrão com sua própria carga de trabalho, você precisa de um alarme no CloudWatch que detecte o problema de conectividade e do pipeline de webhook (tópico SNS e função Lambda) que o entrega ao DevOps Agent. O agente lê configuração do firewall, logs e CloudTrail pelas APIs da AWS — sem necessidade de instrumentação adicional no lado do firewall.
O deploy é feito clonando o repositório e executando o script abaixo, que verifica pré-requisitos, instala dependências, compila, testa, faz o bootstrap do CDK se necessário e implanta todas as stacks:
git clone https://github.com/aws-samples/sample-accelerating-aws-network-firewall-troubleshooting-with-aws-devops-agent.git
cd sample-accelerating-aws-network-firewall-troubleshooting-with-aws-devops-agent
bash scripts/deploy.sh
Após o deploy, abra o link da página de status (um endereço https://<random-id>.cloudfront.net) e confirme que os três cards mostram o status Healthy (saudável) em verde.
Como o pipeline de alarmes funciona
Todos os cenários chegam ao DevOps Agent pelo mesmo caminho: um alarme do CloudWatch muda para o estado ALARM e notifica o tópico SNS. O SNS invoca a função Lambda, que lê a URL do webhook e o segredo de assinatura do AWS Secrets Manager, assina o payload do alarme e faz um POST para o webhook do DevOps Agent.
Há dois tipos de alarme no ambiente de demonstração:
Alarm-1 — usa a métrica nativa AWS/NetworkFirewall DroppedPackets, somada nos fluxos stateful. Não exige nenhuma instrumentação adicional na carga de trabalho, mas só informa que o firewall está descartando pacotes, sem identificar qual regra é responsável.
Alarm-2 e Alarm-3 — usam uma métrica customizada de verificação de conectividade. São úteis para alarmes vinculados ao impacto real no usuário ou para distinguir um caminho de tráfego de outro.
Cenário 1: lista de negação de domínio bloqueando um endpoint legítimo
Na baseline, o grupo de regras Suricata rg-domain nega apenas um placeholder não utilizado, mantendo o endpoint de teste acessível. O grupo inspeciona o Indicador de Nome do Servidor TLS (TLS SNI) em cada conexão de saída e descarta as que correspondem a um domínio negado.
Para introduzir a falha, adiciona-se uma regra drop no grupo rg-domain que corresponde ao nome DNS do endpoint de teste no SNI do TLS:
drop tls $HOME_NET any -> $EXTERNAL_NET any (ssl_state:client_hello; tls.sni; content:"<app-endpoint-dns>"; startswith; nocase; endswith; msg:"S1 domain denylist"; flow:to_server, established; sid:2000002; rev:1;)
Após salvar, a verificação HTTPS da carga de trabalho para o endpoint expira, a métrica DroppedPackets sobe acima da baseline e o Alarm-1 entra em ALARM. Os cenários 2 e 3 permanecem saudáveis.
O DevOps Agent executa várias linhas de investigação em paralelo:
Lê a métrica DroppedPackets e correlaciona o pico com uma queda simultânea em pacotes passados, confirmando que o firewall está bloqueando tráfego ativamente.
Lê o log de ALERTA e encontra as conexões TLS da carga de trabalho bloqueadas pela regra S1 domain denylist.
Compara o estado atual com uma janela de baseline onde o mesmo endpoint era acessível sem alertas.
Busca no CloudTrail e identifica a chamada UpdateRuleGroup que adicionou a regra de negação, com usuário, papel assumido e timestamp — aproximadamente um minuto antes do início dos descartes.
Reporta a causa raiz como aquela alteração manual no grupo de regras e recomenda remover a entrada de negação ou adicionar uma exceção de permissão, além de habilitar FirewallPolicyChangeProtection para evitar alterações não autorizadas.
Atenção: em um ambiente real, esse tipo de regra normalmente existe por um motivo. Antes de removê-la, verifique se foi intencional mas com escopo muito amplo. Se for o caso, refine a regra para bloquear apenas endpoints não autorizados em vez de removê-la inteiramente.
Cenário 2: inversão de prioridade em regra stateless
Na baseline, o grupo de regras stateless rg-stateless-priority mantém a regra de permissão na prioridade 100 e a regra de descarte na prioridade 200 para a classe de tráfego TCP na porta de destino 9142. Como o Network Firewall avalia os números de prioridade menores primeiro, a regra de permissão vence.
Para introduzir a falha, inverte-se as duas prioridades: a regra de permissão passa para a prioridade 300 e a regra de descarte permanece em 200. Isso faz com que a regra de descarte seja avaliada primeiro — exatamente o tipo de erro que uma edição apressada pode introduzir.
Como um descarte stateless ocorre antes de o tráfego alcançar o motor de inspeção stateful, não há entradas de ALERTA nos logs. O agente recorre à configuração e aos logs de fluxo:
Lê o estado do grupo de regras stateless e encontra a regra de descarte com número de prioridade menor, à frente da regra de permissão.
Lê os logs de fluxo e observa os pacotes passados caírem a zero dentro de um minuto após a mudança.
Busca no CloudTrail e identifica a chamada UpdateRuleGroup que inverteu as prioridades.
Reporta a causa raiz como essa inversão de prioridade e recomenda remover a regra de descarte redundante e gerenciar o grupo de regras por infraestrutura como código (IaC) para evitar erros manuais.
Cenário 3: descarte por roteamento assimétrico entre Zonas de Disponibilidade
Na baseline, a sub-rede protegida em cada Zona de Disponibilidade (AZ) roteia sua saída pelo endpoint do firewall na mesma AZ. Assim, um endpoint vê as duas direções do fluxo e o motor stateful completa o handshake.
Para criar a falha, são necessárias duas edições de tabela de rotas: a saída da sub-rede protegida em us-east-1a é apontada para o endpoint do firewall em us-east-1b, e a rota de retorno na sub-rede pública de us-east-1b é apontada para o endpoint do firewall em us-east-1a. Com isso, a saída de um fluxo passa por um endpoint enquanto o retorno chega ao outro — nenhum endpoint vê o fluxo completo e o handshake falha.
Diferente dos cenários anteriores, esse problema afeta toda a sub-rede e faz com que o Alarm-2 e o Alarm-3 disparem ao mesmo tempo. O Alarm-1 (baseado em DroppedPackets) permanece silencioso, pois nenhum endpoint toma uma decisão de descarte — o fluxo simplesmente se perde pelo roteamento assimétrico. Isso ilustra por que monitorar a conectividade da aplicação é fundamental: uma falha de roteamento é invisível para o contador de descartes do próprio firewall.
O DevOps Agent reconhece os dois alarmes como relacionados e os une em uma única investigação:
Lê os logs de fluxo e observa as conexões TLS bidirecionais parando abruptamente, com apenas tráfego unidirecional restante e nenhum fluxo atingindo o estado estabelecido.
Lê as métricas do firewall e percebe que os pacotes recebidos e passados mudam de uma AZ para a outra no momento da alteração.
Chama DescribeRouteTables e encontra a rota de saída apontando para o endpoint do firewall em uma AZ enquanto a rota de retorno aponta para a outra.
Busca no CloudTrail e identifica as chamadas ReplaceRoute e CreateRoute pelo mesmo usuário, cerca de um minuto antes dos dois alarmes.
Reporta a causa raiz como a mudança de roteamento assimétrico e recomenda restaurar o roteamento simétrico na mesma AZ.
Atenção: o plano de mitigação é uma recomendação para você revisar, não uma mudança automática. A correção correta depende do design pretendido. O agente infere um destino plausível com base no que pode observar — revise a rota específica proposta em relação à sua topologia pretendida antes de aplicar.
Considerações adicionais
Em produção, uma única mudança pode disparar vários alarmes ao mesmo tempo, como o Cenário 3 demonstra. O DevOps Agent vincula investigações relacionadas e as trabalha como uma só, permitindo que você valide os achados ou desvincule um alarme para investigá-lo de forma independente. Também é possível adicionar lógica de correlação na função Lambda de ponte, agrupando alarmes por firewall antes que cheguem ao agente.
O agente pode trabalhar com mais contexto quando conectado a repositórios de código-fonte e pipelines de CI/CD, integrando-se com GitHub (incluindo GitHub Enterprise Server e GitLab Self-Managed via conexão privada). Ele pode associar recursos AWS a implantações de AWS CloudFormation, AWS CDK, imagens do Amazon Elastic Container Registry (Amazon ECR) e Terraform. Com configuração implantada e eventos recentes de deploy em mãos, o agente correlaciona a interrupção com a mudança que a introduziu e recomenda uma correção alinhada ao design pretendido.
O DevOps Agent também suporta prevenção proativa de incidentes: analisa padrões em investigações anteriores e entrega recomendações para evitar problemas similares, incluindo sugestões de governança que fortalecem processos de deploy e controles de pipeline. Para mudanças em regras do Network Firewall, isso significa que o agente pode recomendar guardrails para o pipeline de CI/CD com base nas classes de erros que já resolveu. Essas recomendações ficam acessíveis na página de Melhorias (Improvements) no Operator Web App do DevOps Agent.
O padrão descrito não é exclusivo do Network Firewall. O mesmo fluxo se aplica a qualquer serviço que emita métricas e logs no CloudWatch, como AWS WAF, security groups e listas de controle de acesso à rede (NACLs).
Limpeza do ambiente
Para remover todos os recursos implantados, basta executar:
bash scripts/destroy.sh
O script reverte qualquer cenário ativo, executa cdk destroy para todas as stacks e busca recursos remanescentes pela tag Project = nf-devops-agent. Os principais geradores de custo são os dois endpoints do Network Firewall, os gateways NAT e os load balancers do endpoint de teste — todos cobrados por hora enquanto provisionados, independentemente de haver tráfego. Executar os cenários e destruir a stack no mesmo dia limita o custo a poucas horas ativas.
Conclusão
A AWS demonstrou como o DevOps Agent acelera o troubleshooting de três problemas comuns de conectividade no Network Firewall: lista de negação de domínio, inversão de prioridade stateless e descarte por roteamento assimétrico entre AZs. Em cada caso, o agente investigou a queda e retornou uma causa raiz com um plano de mitigação para aprovação antes da aplicação.
O primeiro cenário disparou com base em uma métrica nativa do Network Firewall; os outros dois, com base em métricas de saúde da aplicação — mostrando as duas formas de alarmar sobre um problema de firewall pelo mesmo pipeline.
Amazon MWAA adiciona suporte ao Apache Airflow 2.11.2
A AWS anunciou que o Amazon MWAA — Fluxos de Trabalho Gerenciados para Apache Airflow (MWAA) — passou a oferecer suporte ao Apache Airflow versão 2.11.2. Para quem não conhece o serviço, o Amazon MWAA é uma solução gerenciada que executa o Apache Airflow em escala, eliminando a necessidade de gerenciar manualmente a infraestrutura subjacente.
O que muda com o Apache Airflow 2.11.2
O Apache Airflow 2.11.2 é uma versão de manutenção, ou seja, seu foco está em estabilidade, segurança e correções — e não em grandes funcionalidades novas. Ainda assim, as mudanças são relevantes para quem opera pipelines de dados em produção. Confira o que foi atualizado:
Dependências principais atualizadas com patches de segurança e melhorias de estabilidade nas camadas do servidor web e de execução de tarefas do Airflow.
Correções no gerenciamento do ciclo de vida de tarefas para tarefas em estado de fila (queued tasks).
Mascaramento aprimorado de segredos nos logs, reduzindo o risco de exposição acidental de informações sensíveis.
Correções na interface do usuário na visualização de lista de Instâncias de Tarefas (Task Instances list view).
Atualizações nos pacotes de provedores para entrega de logs via S3 e CloudWatch.
Como migrar ou criar um novo ambiente
A AWS facilita a adoção da nova versão: é possível tanto criar um novo ambiente com o Apache Airflow 2.11.2 quanto atualizar ambientes existentes, tudo com poucos cliques diretamente no Console de Gerenciamento da AWS. A atualização está disponível em todas as regiões onde o Amazon MWAA já está disponível.
Para saber mais, a AWS disponibiliza os seguintes recursos:
GPT-5.6 no Amazon Bedrock: três modelos, um endpoint
A AWS anunciou a disponibilidade geral dos modelos GPT-5.6 Sol, Terra e Luna no Amazon Bedrock. A proposta é direta: desenvolvedores que precisam de modelos de fronteira para workloads de codificação agêntica, raciocínio de longa duração e inferência de alto volume agora podem acessá-los pela API familiar da OpenAI, sem precisar operar infraestrutura de modelos separada.
O GPT-5.6 introduz um sistema de nomenclatura onde o número identifica a geração e os nomes Sol, Terra e Luna identificam camadas de capacidade duráveis que podem evoluir de forma independente. A tabela abaixo resume as especificações de cada modelo:
Sol (openai.gpt-5.6-sol): ideal para codificação autônoma, pesquisa de segurança, análise científica e raciocínio profundo em múltiplos passos. Disponível em US East (N. Virginia) e US East (Ohio).
Terra (openai.gpt-5.6-terra): equilibra raciocínio, desempenho e custo para workloads de produção de uso geral. Disponível em US East (N. Virginia), US East (Ohio) e US West (Oregon).
Luna (openai.gpt-5.6-luna): otimizado para workloads de alto volume e baixa latência, como classificação, sumarização e roteamento. Disponível nas mesmas regiões do Terra.
Os três modelos suportam entrada de texto e imagem, saída de texto, uma janela de contexto de 272 mil tokens e a Responses API. Todos também suportam os níveis de esforço de raciocínio: none, low, medium, high, xhigh e max. O preço corresponde às tarifas de primeira parte da OpenAI, e o uso conta para os compromissos existentes da AWS.
Acessando o GPT-5.6 pelo endpoint bedrock-mantle
O acesso aos modelos GPT-5.6 é feito pela Responses API da OpenAI no endpoint bedrock-mantle. A URL base é https://bedrock-mantle.{region}.api.aws, e a Responses API fica em /openai/v1/responses. Basta substituir {region} pela região AWS desejada, como us-east-1.
O endpoint funciona com os SDKs Python e TypeScript da OpenAI. Para migrar uma aplicação existente, basta substituir a URL base da OpenAI pelo endpoint bedrock-mantle, usar o ID do modelo correspondente no Amazon Bedrock e autenticar com uma chave de API do Amazon Bedrock ou credenciais AWS.
Segurança e controle de dados
Cada chamada de modelo é executada sob as políticas do AWS Identity and Access Management (IAM), dentro da sua nuvem privada virtual (VPC) e registrada no AWS CloudTrail. A inferência em região mantém as requisições dentro da região AWS especificada, o que ajuda equipes a atender requisitos de residência de dados.
Por serem modelos de terceiros, o GPT-5.6 Sol, Terra e Luna estão sujeitos a os termos da OpenAI. Para esses modelos, tráfego sinalizado por classificadores é retido por até 30 dias para detecção de abuso automatizada offline. As entradas e saídas retidas são armazenadas e processadas pela AWS e não são compartilhadas com o provedor do modelo, a menos que você opte por isso. O controle da configuração de retenção é feito pelo modo de retenção de dados. Vale destacar que seus prompts e respostas não são usados para treinar modelos.
Primeiros passos: pré-requisitos e autenticação
Para usar os modelos GPT-5.6, é necessário uma conta AWS com permissões para executar inferências no endpoint bedrock-mantle. Uma forma de conceder essas permissões é anexar a política gerenciada AmazonBedrockMantleInferenceAccess ao seu principal do IAM. Ela concede acesso de leitura e criação de inferências, incluindo bedrock-mantle:CreateInference e bedrock-mantle:CallWithBearerToken.
Instale o SDK Python da OpenAI, versão 2.45.0 ou superior:
pip install "openai>=2.45.0"
A autenticação pode ser feita de duas formas:
Chave de curta duração com atualização automática: o cliente nativo BedrockOpenAI do SDK usa um provedor de token que gera uma chave de curta duração a partir das credenciais AWS e a atualiza antes de cada requisição. Os exemplos deste artigo usam esse cliente.
from aws_bedrock_token_generator import provide_token
from openai import BedrockOpenAI
region = "us-east-1"
client = BedrockOpenAI(
aws_region=region,
bedrock_token_provider=lambda: provide_token(region=region),
)
Chave de curta duração via variável de ambiente: defina a chave em AWS_BEARER_TOKEN_BEDROCK e passe-a ao cliente. Como essa chave não é atualizada automaticamente, ela expira em no máximo 12 horas. Para produção, prefira a opção com atualização automática ou armazene a chave no AWS Secrets Manager.
import os
from openai import OpenAI
client = OpenAI(
base_url="https://bedrock-mantle.us-east-1.api.aws/openai/v1",
api_key=os.environ["AWS_BEARER_TOKEN_BEDROCK"],
)
Executando a primeira inferência com a Responses API
Com o cliente configurado, é possível chamar o GPT-5.6 Terra pela Responses API. A API usa um único campo input e retorna o texto gerado em output_text.
response = client.responses.create(
model="openai.gpt-5.6-terra",
input="Explain the benefits of prompt caching for agentic workloads.",
max_output_tokens=512,
store=False,
)
print(response.output_text)
Controlando o esforço de raciocínio
Os modelos GPT-5.6 podem gastar tokens adicionais de raciocínio em tarefas complexas de múltiplos passos antes de responder, o que melhora os resultados mas aumenta a latência e o custo. O nível é definido com o parâmetro reasoning.
response = client.responses.create(
model="openai.gpt-5.6-sol",
input="A train leaves at 3 PM at 60 km/h. Another leaves an hour later at "
"90 km/h from the same station. When does the second catch up?",
reasoning={"effort": "high"},
)
print(response.output_text)
Chamando ferramentas (tool calling)
O GPT-5.6 suporta chamada de ferramentas, permitindo que o modelo solicite ferramentas definidas pela aplicação e use seus resultados para completar uma requisição. O exemplo abaixo demonstra a chamada de ferramenta no lado do cliente, onde a aplicação executa a ferramenta e retorna o resultado ao modelo.
import json
tools = [
{
"type": "function",
"name": "get_weather",
"description": "Get the current weather for a given location",
"parameters": {
"type": "object",
"properties": {
"location": {
"type": "string",
"description": "City and country (for example, Seattle, US)",
},
"unit": {
"type": "string",
"enum": ["celsius", "fahrenheit"],
"description": "Temperature unit",
},
},
"required": ["location"],
},
}
]
# Step 1: Send the user request with the tool definition.
input_list = [{"role": "user", "content": "What's the weather like in Seattle?"}]
response = client.responses.create(
model="openai.gpt-5.6-terra",
input=input_list,
tools=tools,
)
# Step 2: Carry the model's output (including any reasoning items) into the next turn.
input_list += response.output
# Step 3: Run each requested function and append its result.
for item in response.output:
if item.type == "function_call":
args = json.loads(item.arguments)
result = {
"location": args["location"],
"temperature": 64,
"condition": "Partly cloudy",
}
input_list.append(
{
"type": "function_call_output",
"call_id": item.call_id,
"output": json.dumps(result),
}
)
# Step 4: Ask the model for the final response, incorporating the tool result.
final_response = client.responses.create(
model="openai.gpt-5.6-terra",
input=input_list,
tools=tools,
)
print(final_response.output_text)
Como os modelos GPT-5.6 raciocinam antes de responder, é importante passar os itens de saída do modelo (que podem incluir raciocínio) de volta na próxima requisição, como o exemplo acima faz ao acrescentar response.output à lista de entrada. Para implantações em produção, a AWS recomenda usar o Amazon Bedrock Guardrails para implementar salvaguardas personalizadas às suas políticas de IA responsável.
Reduzindo custos com cache de prompts
Workloads agênticos e de múltiplos passos repetem grande parte do contexto entre chamadas — instruções de sistema, definições de ferramentas e arquivos de referência costumam permanecer iguais enquanto apenas a entrada mais recente muda. O GPT-5.6 suporta cache de prompts em dois modos no Amazon Bedrock.
Cache implícito: ativado por padrão. Requisições elegíveis são cacheadas automaticamente sem alterações no código.
Cache explícito: permite marcar pontos de quebra de cache para controle preciso sobre quais partes do prompt são cacheadas.
Em ambos os modos, o cache reduz o custo de processar repetidamente contextos compartilhados conforme o volume de requisições cresce. Tokens de entrada cacheados são cobrados com 90% de desconto em relação a tokens não cacheados, e tokens gravados no cache são cobrados a 1,25 vezes a taxa de entrada não cacheada. Consulte a página de preços do Amazon Bedrock para valores atualizados. O conteúdo cacheado fica disponível por pelo menos 30 minutos.
Cache explícito com pontos de quebra
Para cachear um prefixo, adicione um prompt_cache_breakpoint ao bloco de conteúdo que encerra a seção reutilizável e defina prompt_cache_options para o modo explícito. Definir um prompt_cache_key consistente entre requisições direciona-as ao mesmo cache e melhora a confiabilidade de correspondência. Cada ponto de quebra requer um prefixo de pelo menos 1.024 tokens, e é possível definir até quatro pontos de quebra de cache por requisição.
# Replace with your real system instructions and reference content.
# The cached prefix must be at least 1,024 tokens, or nothing is cached.
system_prompt = "You are a technical support agent for Example Corp. ...(1,024+ tokens)..."
def ask(question):
return client.responses.create(
model="openai.gpt-5.6-terra",
prompt_cache_key="support-agent:system-prompt-v1",
prompt_cache_options={"mode": "explicit"},
input=[
{
"type": "message",
"role": "developer",
"content": [
{
"type": "input_text",
"text": system_prompt,
# Cache everything up to this breakpoint (the system instruction).
"prompt_cache_breakpoint": {"mode": "explicit"},
}
],
},
{
"type": "message",
"role": "user",
"content": [{"type": "input_text", "text": question}],
},
],
)
# First call: writes the prefix to cache.
first = ask("How do I configure single sign-on?")
print("write:", first.usage.input_tokens_details.cache_write_tokens)
# Second call with the same prefix and cache key: read the prefix from cache.
second = ask("How do I reset a password?")
print("read: ", second.usage.input_tokens_details.cached_tokens)
print(second.output_text)
Cache implícito
Se prompt_cache_options não for definido, o GPT-5.6 usa o cache implícito. O Amazon Bedrock coloca automaticamente um ponto de quebra de cache na mensagem mais recente e respeita quaisquer pontos de quebra explícitos adicionados. A recomendação é manter o conteúdo estático (instruções de sistema, definições de ferramentas, documentos de referência) no início do prompt e o conteúdo variável no final, além de definir um prompt_cache_key consistente para requisições relacionadas.
response = client.responses.create(
model="openai.gpt-5.6-terra",
prompt_cache_key="support-agent:kb-v1",
input=[
{
"type": "message",
"role": "developer",
# Static content first so it forms a stable, cacheable prefix.
"content": [{"type": "input_text", "text": system_prompt}],
},
{
"type": "message",
"role": "user",
"content": [{"type": "input_text", "text": "How do I configure single sign-on?"}],
},
],
)
print(response.output_text)
O cache explícito é mais adequado para loops agênticos com um prefixo grande e estável, onde se deseja controle total sobre o que é cacheado. O cache implícito é mais simples e se adapta bem a workloads de chat e RAG (Geração Aumentada por Recuperação) com um prefixo naturalmente estável. A cobrança é a mesma nos dois modos. Para desativar o cache em uma requisição, defina prompt_cache_options para o modo explícito sem adicionar nenhum ponto de quebra.
Monitorando a taxa de acerto do cache
Cada resposta reporta a atividade de cache no objeto usage. O campo input_tokens_details.cached_tokens indica o número de tokens lidos do cache, e cache_write_tokens indica os gravados. Como cached_tokens já faz parte do total de input_tokens, a taxa de acerto do cache pode ser calculada dividindo cached_tokens por input_tokens.
O endpoint bedrock-mantle publica métricas de tokens de conta, projeto e modelo no Amazon CloudWatch sob o namespace AWS/BedrockMantle, mas não publica uma métrica específica de cache — portanto, o objeto de uso da resposta é a fonte oficial para medir o desempenho do cache.
Usando o GPT-5.6 com o Codex
O Codex é o agente de codificação da OpenAI para desenvolvedores. Ele trabalha com arquivos locais, repositórios, terminais e ambientes de desenvolvimento para escrever funcionalidades, corrigir bugs, executar testes e abrir pull requests. É possível executá-lo pela linha de comando (Codex CLI), como extensão de IDE para Visual Studio Code e JetBrains, ou no aplicativo desktop do ChatGPT.
Para apontar o Codex para o Amazon Bedrock, basta definir o modelo e o provedor no arquivo ~/.codex/config.toml:
model = "openai.gpt-5.6-sol"
model_provider = "amazon-bedrock"
[model_providers.amazon-bedrock.aws]
region = "us-east-1"
O Codex autentica com uma chave de API ou com as credenciais do SDK AWS. Se AWS_BEARER_TOKEN_BEDROCK estiver definido, o Codex o usa primeiro; caso contrário, recorre à cadeia de credenciais do SDK AWS. O aplicativo desktop do ChatGPT e a extensão de IDE podem não herdar o ambiente do shell, então é recomendável colocar as variáveis necessárias em ~/.codex/.env:
AWS_BEARER_TOKEN_BEDROCK=<your-api-key>
Reinicie o aplicativo ou a extensão após alterar ~/.codex/config.toml ou ~/.codex/.env. Para tarefas de codificação, esforços de raciocínio mais altos são adequados para refatorações e depurações complexas, enquanto níveis mais baixos mantêm edições rotineiras rápidas. No aplicativo desktop do ChatGPT, é possível escolher entre Light, Medium, High e Extra High para cada tarefa.
As requisições aos modelos GPT-5.6 usam inferência sob demanda no nível de serviço Standard, onde se paga por token sem reservar capacidade. A inferência no endpoint bedrock-mantle é governada por duas cotas por modelo e por região: uma para tokens de entrada por minuto e outra para tokens de saída por minuto. Não há cota de requisições por minuto.
Tokens de entrada cacheados lidos pelo cache de prompts não contam para a cota de tokens de entrada por minuto — mais um motivo pelo qual o cache ajuda em escala. Se uma cota de tokens por minuto for excedida, o endpoint retorna uma resposta HTTP 429. A recomendação é tratar throttling transitório com backoff exponencial e um contador limitado de tentativas, que o SDK da OpenAI suporta pela configuração max_retries:
from aws_bedrock_token_generator import provide_token
from openai import BedrockOpenAI
region = "us-east-1"
client = BedrockOpenAI(
aws_region=region,
bedrock_token_provider=lambda: provide_token(region=region),
max_retries=6,
)
Para reduzir o throttling em alto volume sustentado, distribua workloads grandes ao longo de vários minutos em vez de disparar em rajadas rápidas. Para mais detalhes, consulte as cotas para o endpoint bedrock-mantle.
Limpeza e custos
A inferência sob demanda gera cobranças apenas quando um modelo é invocado, portanto não há infraestrutura para desativar. Se uma chave de API de curta duração foi gerada, ela expira automaticamente em até 12 horas. Para revogar uma chave antes disso, exclua-a no novo console do Amazon Bedrock. Cada invocação de modelo gera cobranças por token — consulte a tabela de preços do Amazon Bedrock para valores atualizados.
Próximos passos
Para quem quer explorar os modelos GPT-5.6 no Amazon Bedrock, a AWS sugere os seguintes passos iniciais:
