Novas versões do PostgreSQL disponíveis no Amazon Aurora
A AWS anunciou que o Amazon Aurora PostgreSQL-Compatible Edition passa a suportar as versões 18.4, 17.10, 16.14, 15.18 e 14.23 do PostgreSQL. As atualizações trazem correções de bugs da comunidade PostgreSQL, além de melhorias específicas da plataforma Aurora.
Por que atualizar?
A AWS recomenda que os usuários migrem para as versões minor mais recentes assim que possível. O principal motivo é a correção de Vulnerabilidades e Exposições Comuns (CVEs) conhecidas — falhas de segurança documentadas publicamente que podem representar risco para os ambientes de banco de dados. Além da segurança, as novas versões também entregam melhorias de estabilidade e desempenho. Os detalhes completos de cada atualização estão disponíveis nas notas de lançamento.
Como realizar o upgrade
A atualização pode ser feita de forma simples, sem necessidade de intervenção manual. O Aurora permite que os upgrades de versões minor sejam executados automaticamente durante as janelas de manutenção programadas. Para isso, basta habilitar a opção de upgrades automáticos de versão minor no cluster.
Para equipes que gerenciam múltiplos bancos de dados em escala, a AWS disponibiliza um recurso adicional bastante útil: a Política de Rollout de Upgrade do AWS Organizations. Com ela, é possível orquestrar os upgrades em fases — começando pelos ambientes de menor criticidade para validar o processo antes de atualizar os ambientes mais críticos do negócio.
O Amazon Aurora é o serviço de banco de dados relacional gerenciado da AWS, projetado para oferecer alta performance e disponibilidade em escala global, com compatibilidade total com o PostgreSQL. Entre seus principais recursos estão:
Computação serverless com escala até zero, reduzindo custos quando o banco não está em uso
Aurora Global Database, para resiliência multi-região
Aurora I/O-Optimized, com melhor relação custo-benefício para cargas de trabalho intensivas em operações de entrada e saída (I/O)
Segurança integrada e backups contínuos
Para quem ainda não utiliza o serviço e quer dar os primeiros passos, a AWS disponibiliza uma página de introdução ao Aurora com os recursos necessários para começar.
Imagine um engenheiro de infraestrutura abrindo o laptop de um colega para depurar uma build. Na pasta de configuração, um arquivo chamado mcp.json contém uma senha de banco de dados de produção em texto puro, ao lado de um comentário TODO: rotate this. A equipe de segurança não tem visibilidade de quais agentes de IA estão acessando ferramentas internas, quem concedeu esse acesso, nem qual seria o impacto se aquela credencial vazasse.
Esse cenário representa um padrão recorrente em empresas que adotam assistentes habilitados com o Protocolo de Contexto de Modelo (MCP) — como Kiro, Claude Code e Amazon Quick — sem uma camada centralizada de governança. A AWS identificou cinco padrões de falha estrutural nesse cenário: espalhamento de credenciais em configs locais, divergência silenciosa de políticas, lacunas de auditoria, opacidade de custos e Shadow IT.
Para endereçar isso, a AWS documentou uma abordagem progressiva usando o AgentCore Gateway, uma capacidade do Amazon Bedrock AgentCore que fornece um ponto de entrada único, seguro e auditável para o tráfego de agentes em direção às ferramentas corporativas.
A jornada de maturidade em quatro escopos
A proposta da AWS não é construir tudo de uma vez — é avançar conforme as dores reais aparecem. Cada escopo entrega valor independente e preserva o caminho para o próximo.
Indicado para pilotos com 1 a 20 usuários e ferramentas de baixo risco. O objetivo é simples: criar um único ponto de entrada para que os agentes de IA cheguem aos recursos organizacionais, com autenticação via SSO (Entrada Única), credenciais centralizadas e auditoria pelo AWS CloudTrail.
Na prática, o gateway é provisionado com um autorizador JWT (Token Web JSON) apontando para um pool do Amazon Cognito. Uma função AWS Lambda de baixo risco — como uma busca de tickets somente leitura — é registrada como alvo MCP. O arquivo mcp.json dos assistentes passa a apontar para o endpoint do gateway em vez de servidores locais. As credenciais de backend nunca saem da AWS, e toda invocação aparece nos logs do Amazon CloudWatch.
O comando para criar o gateway com autorizador JWT é:
O resultado: o caminho fim a fim funciona, o mcp.json agora contém um endpoint que alcança recursos organizacionais, e produtividade e controles chegam juntos.
Escopo 2 — Control: autorização por identidade e guardrails
Com a porta aberta, o Escopo 2 identifica quem está chamando e filtra o que passa. É indicado quando a base de usuários cresce e a conformidade começa a perguntar “quem fez o quê, sob qual política?”
A mudança central é migrar de confiança no nível de máquina para confiança no nível de usuário. Os clientes passam a ser registrados dinamicamente via Registro Dinâmico de Clientes (DCR) — um shim Lambda que cria um app client no Cognito e o adiciona à lista de clientes permitidos do gateway. O usuário se autentica via SSO com fluxo de Código de Autorização (Authorization Code), e a partir daí cada requisição carrega a identidade real do usuário.
O AgentCore Policy aplica regras Cedar com controle de acesso baseado em papéis (RBAC) e atributos (ABAC). Por exemplo, a política abaixo restringe deploys de CI ao ambiente de staging para membros do grupo de pagamentos, enquanto mantém ferramentas de leitura abertas para qualquer principal autenticado:
// Payments deployers can deploy, but only to staging
permit (
principal,
action == AgentCore::Action::"DeployCI___invoke",
resource
)
when {
principal.hasTag("groups") &&
principal.getTag("groups").contains("repo-payments-service")
/* Note: for Cognito, the claim is cognito:groups, not groups.
Refer to your deployed Gateway Cedar schema for the precise tag names. */
&& context.input.environment == "staging"
};
// Read-only tools are open to any authenticated principal with a group
permit (
principal,
action in [
AgentCore::Action::"TicketSearch___invoke",
AgentCore::Action::"DocsSearch___invoke"
],
resource
)
when {
principal.hasTag("groups")
};
O Amazon Bedrock Guardrails é integrado nativamente ao AgentCore Policy para aplicar filtros de Informações de Identificação Pessoal (PII), políticas de conteúdo e detecção de ataques de prompt na camada do gateway, sem código customizado. A configuração abaixo, por exemplo, bloqueia números de CPF/SSN e cartões de crédito, e anonimiza e-mails:
A recomendação é implantar o AgentCore Policy primeiro em modo LOG_ONLY para monitorar quais decisões mudariam antes de ativar o modo ENFORCE. Quando um recurso downstream precisa da identidade do usuário em um sistema SaaS (como GitHub ou Slack), o AgentCore Identity gerencia o fluxo de três pernas (3LO), emitindo um erro de elicitação -32042 para que o assistente conduza o usuário pelo consentimento no navegador. Para recursos que compartilham a mesma cadeia de identidade, o On-Behalf-Of (OBO) token exchange substitui o redirecionamento pelo navegador, sem fluxo adicional de consentimento.
Escopo 3 — Catalog: autoatendimento, registro e alcance multi-ambiente
Quando os tickets de “adicione esta ferramenta” se acumulam ou é preciso alcançar sistemas fora da AWS, é hora do Escopo 3. Indicado para mais de 100 usuários, esse escopo elimina o gargalo de cadastro manual de ferramentas.
Os donos de ferramentas passam a criar um manifesto YAML e abrir um pull request. O pipeline de CI valida, escaneia e, no merge, chama create-gateway-target e atualiza a política Cedar automaticamente. Um exemplo de manifesto:
O AWS Agent Registry centraliza a descoberta de ferramentas e habilidades. Um servidor Resources MCP distribui automaticamente para todos os assistentes contextos organizacionais como padrões de código, runbooks de plantão e checklists de release — sem configuração por desenvolvedor.
Para sistemas fora da AWS, o gateway alcança bancos de dados on-premises via AWS Direct Connect ou VPN, e APIs SaaS via OAuth de saída. O Open Policy Agent (OPA) complementa o Cedar com regras que ele não expressa nativamente, como janelas de tempo e verificação de ticket de mudança. A política Rego abaixo, por exemplo, permite escrita em banco de dados somente em dias úteis, das 9h às 17h UTC, com ticket de mudança anexado:
Para FinOps, tags por ferramenta no AWS Cost Explorer permitem que o financeiro atribua gastos ao time responsável. Um alerta de AWS Budgets pode ser configurado por ferramenta com um limite mensal de custo de invocação.
Escopo 4 — Harden: resiliência e governança de borda
Para workloads com mais de 1.000 usuários, indústrias reguladas ou requisitos de alta disponibilidade global, o Escopo 4 endurece o perímetro e prepara o gateway para falhas.
O tráfego passa a fluir pela rede corporativa: Amazon CloudFront na borda → Application Load Balancer restrito ao CloudFront via header secreto → VPC Endpoint em subnet privada → PrivateLink → gateway. O DNS público é eliminado. Para agentes hospedados em Runtime, a AWS recomenda ativar enforcement de entrada exclusiva, de modo que o Runtime rejeite qualquer invocação que não venha pelo gateway, impedindo contornos à política e à auditoria.
O failover multi-região é configurado via Amazon Route 53 com health checks. O registro de failover abaixo alterna para a região secundária quando o health check primário falha, dentro de um TTL de 30 segundos:
Uma Lambda noturna de deprecação lê métricas do CloudWatch e abre pull requests automaticamente para ferramentas com zero invocações nos últimos 30 dias. Após 90 dias sem uso, o alvo é removido — eliminando ferramentas zumbi do registry.
Para responder perguntas de conformidade como “quais principals tiveram maior taxa de negação na última semana?”, o Amazon Athena consulta os logs do CloudTrail:
SELECT
attributes.`aws.agentcore.policy.determining_policies` as policies,
COUNT(*) AS denies,
DATE_TRUNC('day', from_iso8601_timestamp(event_time)) AS day
FROM aws_spans_export
WHERE
attributes.`aws.agentcore.policy.authorization_decision` = 'DENY'
AND from_iso8601_timestamp(event_time) > current_date - INTERVAL '7' DAY
GROUP BY principal, matched_policy, DATE_TRUNC('day', from_iso8601_timestamp(event_time))
ORDER BY denies DESC
LIMIT 25;
Referência de implantação: caso de serviços financeiros
A AWS documentou como uma organização de serviços financeiros percorreu os quatro escopos em seis meses: começou no Escopo 1 com dois analistas e uma ferramenta SQL de staging; evoluiu para o Escopo 2 em três semanas com 30 analistas, RBAC por mesa de operação e auditoria completa; chegou ao Escopo 3 no terceiro mês com 200 usuários e queda de ~40% na fila de tickets; e completou o Escopo 4 no sexto mês com 1.000 usuários, isolamento de rede exigido pela MiFID II e RTO de 4 horas via Route 53 failover. O gatilho para avançar cada escopo foi sempre uma pergunta organizacional concreta, não um prazo predefinido.
Considerações operacionais e de custos
A AWS recomenda tratar o gateway com as mesmas práticas operacionais de serviços de produção desde o primeiro dia. Ambientes de dev, staging e produção devem rodar em contas AWS separadas, promovidos via Infraestrutura como Código (IaC).
Em segurança, credenciais devem ser armazenadas no AWS Secrets Manager com rotação, ou eliminadas com autenticação por Chave Privada JWT (private key no AWS KMS). Nunca em variáveis de ambiente. O mcp.json deve ser distribuído centralmente via MDM. Políticas de Controle de Serviço (SCPs) do AWS IAM com a condição aws:ViaAWSMCPService bloqueiam operações destrutivas invocadas por servidores MCP gerenciados pela AWS.
Em custos, a referência da AWS aponta que ~50 desenvolvedores executando 572.000 operações mensais custam aproximadamente US$ 17 combinando Gateway e Policy (Gateway InvokeTool a US$ 5 por milhão + Policy authorization a US$ 25 por milhão; Identity custa US$ 0 quando consumido pelo Gateway). Consulte a página de preços do Amazon Bedrock AgentCore para valores atualizados.
Limpeza de recursos
Para evitar cobranças contínuas após testes, a AWS recomenda remover os recursos na ordem inversa da criação. Os comandos principais incluem deletar targets com DeleteGatewayTarget e o gateway em si:
Agentes de IA são capazes de automatizar fluxos de trabalho complexos, mas sem os controles certos, eles podem tomar ações que conflitam com as políticas internas da organização ou com obrigações regulatórias. Para endereçar esse desafio, a AWS desenvolveu o recurso de Política no Amazon Bedrock AgentCore, que permite às equipes aplicar controles de forma centralizada sobre os agentes que rodam no Amazon Bedrock AgentCore.
Recentemente, a AWS expandiu esse recurso com novas capacidades que permitem impor restrições ao longo do tempo — como limites de taxa, pré-requisitos de chamadas, ordenação sequencial de ferramentas e controle de efeitos cumulativos. Essas políticas são expressas em Dogwood, uma linguagem de governança de código aberto, e aplicadas em tempo real pelo monitor Dogwood embutido no AgentCore Gateway.
O que é o Policy Authoring
Como parte desse lançamento, a AWS também expandiu as capacidades do Policy Authoring, uma ferramenta baseada em IA que converte documentos de especificação de políticas escritos em linguagem natural em especificações formais Dogwood — sintaticamente e semanticamente corretas.
Com essa funcionalidade, é possível gerar políticas que:
Impõem restrições temporais e de trajetória de ações;
Restringem os parâmetros de entrada das ferramentas disponíveis para o agente.
O ponto central é que qualquer pessoa, independentemente do nível técnico, pode importar um documento de políticas escrito em prosa diretamente no Amazon Bedrock AgentCore para proteger os sistemas agênticos em produção.
Como o Policy Authoring funciona na prática
O Policy Authoring funciona melhor quando as regras já existem em prosa — quando o trabalho é de transcrição, não de design. Você pode fornecer um documento com um conjunto de regras: uma lista de políticas, a seção de regras de um procedimento operacional ou um parágrafo descrevendo ações permitidas ou restritas.
A ferramenta atua como um tradutor, não como um resumidor. Documentos que misturam regras com justificativas e comentários funcionam melhor quando pré-processados para isolar apenas as regras em si.
O cenário de exemplo: banco de varejo
Para ilustrar as traduções, o artigo da AWS usa o exemplo de um agente de atendimento ao cliente em um banco de varejo. Esse agente verifica identidades, abre disputas, emite reembolsos, move fundos entre contas e solicita aprovação de supervisores. Suas ferramentas são acessadas via AgentCore Gateway e incluem:
verify_identity — verificação de identidade do chamador;
initiate_transfer — transferência de fundos entre contas do cliente;
issue_refund — reversão de uma cobrança disputada;
file_dispute — abertura de caso de disputa;
request_approval — solicitação de aprovação de um supervisor.
O Policy Authoring recebe junto ao documento um esquema com os nomes das ferramentas, seus argumentos e retornos — gerado a partir do manifesto de ferramentas MCP (Model Context Protocol) do agente. Isso garante que as políticas geradas referenciem exatamente os mesmos nomes que o agente usa.
Exemplos de tradução de políticas
Restrição em argumentos de uma ferramenta
Regra em linguagem natural: Reembolsos só podem ser emitidos durante o horário comercial (9h–17h UTC) e apenas para valores de até US$ 2.500.
Uma única frase com dois requisitos independentes se torna uma política com duas condições. Para mais detalhes sobre funções baseadas em tempo como duration, consulte o suporte a políticas baseadas em tempo.
Pré-requisito obrigatório
Regra: Não inicie uma transferência a menos que a identidade do chamador tenha sido verificada para a mesma conta nos últimos 15 minutos.
Aqui a condição não pode ser resolvida apenas com a requisição de transferência — ela consulta o histórico da sessão. O operador formerly within 15m verifica se o evento descrito ocorreu nos últimos 15 minutos. A correlação por account garante que uma verificação de outra conta não satisfaça a regra.
Limite cumulativo
Regra: Bloqueie uma transferência se o total transferido nas últimas 12 horas ultrapassar US$ 50.000.
forbid (
principal,
action == AgentCore::Action::"initiate_transfer",
resource
)
when temporal {
exists (total: Long). (
(sum a for (a: Long), (t: Timepoint).
where (
formerly within 12h (
AgentCore::Action::"initiate_transfer"::request{
input.amount: a
} && tp(t)
)
)
) == total &&
total > 50000
)
};
Aqui o histórico não é apenas consultado — ele é somado. A política soma o argumento amount de todas as transferências nas últimas 12 horas e bloqueia a chamada atual se o total ultrapassar US$ 50.000. Cada transferência individual pode ser pequena, mas a condição restringe o agregado.
Limite de taxa
Regra: O agente não pode tentar mais de três reembolsos para a mesma conta em uma hora.
forbid (
principal,
action == AgentCore::Action::"issue_refund",
resource
)
when temporal {
exists (n: Long). (
(count for (t: Timepoint).
where (
formerly within 1h (
AgentCore::Action::"issue_refund"::request{
input.account: context.input.account
} && tp(t)
)
)
) == n &&
n > 3
)
};
Estrutura semelhante ao exemplo anterior, mas contando eventos em vez de somar valores. A contagem inclui a tentativa atual, portanto a quarta tentativa na mesma hora é bloqueada. Como a regra diz "tentativa", reembolsos negados ou com falha também contam.
Verificação de texto livre
Regra: Rejeite qualquer abertura de disputa cuja descrição contenha um número de Seguro Social americano.
Algumas regras dizem respeito ao significado de texto livre, não a valores estruturados. Para esses casos, a política gerada invoca uma verificação do Amazon Bedrock Guardrails diretamente no campo indicado. Como a regra original não especifica um limiar de confiança, a tradução usa o valor padrão para essa verificação.
Regra que combina múltiplos tipos de condição
Regra: Um reembolso acima de US$ 500 exige aprovação de supervisor para aquela cobrança, registrada nos últimos 30 minutos.
A sentença tem duas partes verificadas de formas distintas: um limite no argumento da chamada atual e uma condição sobre o histórico da sessão. A cláusula unless levanta a negação quando uma aprovação correspondente está registrada. A correlação por charge_id impede que uma aprovação para uma cobrança autorize o reembolso de outra.
Boas práticas para escrever políticas em linguagem natural
Políticas claras e sem ambiguidade geram comportamentos mais previsíveis — tanto para humanos quanto para o autoformalizador. A AWS destaca as seguintes orientações:
Diga se você quer a tentativa ou o resultado. "Após uma transferência" é ambíguo. "Após uma transferência ser concluída com sucesso" não é. Limites de taxa e caps cumulativos geralmente se aplicam a tentativas; pré-requisitos e regras de ordenação, a resultados.
Declare a janela de tempo. "Recentemente" não tem tradução. "Nos últimos 30 minutos" sim. Se a regra deve resetar em um limite de calendário (e não deslizar com o relógio), declare isso explicitamente.
Nomeie o sujeito da regra. "Não mais que três transferências por hora" não diz de quem: três pelo mesmo chamador ou três contra a mesma conta? Ambas são expressáveis, mas são políticas diferentes.
Forneça o limiar e seu limite. "Mais de três" e "pelo menos três" diferem por uma ação — geralmente a que a regra existe para impedir. O mesmo vale para níveis de confiança em verificações de conteúdo.
Revise as políticas Dogwood geradas. Cada política é retornada junto com a frase que a originou para leitura lado a lado. A validação verifica se a política é bem formada, mas não confirma se ela expressa exatamente o que o autor pretendia. Esse julgamento fica com quem é dono do documento.
O que não pode ser aplicado por políticas
O serviço de authoring consegue identificar e sinalizar políticas incompatíveis com o mecanismo de execução. Há quatro categorias comuns de regras que não podem ser traduzidas para Dogwood:
Não é uma regra sobre uma ação. Exemplo: "Agentes devem sempre agir no melhor interesse financeiro do cliente." Não há condição sobre nenhuma ação, campo ou principal. Essa é uma exigência legítima, mas pertence às instruções do agente, às avaliações e ao treinamento — não a um mecanismo de autorização.
Pede uma ação, não um veredicto. Exemplo: "Quando uma descrição de disputa contiver um número de Seguro Social, remova-o antes de salvar." Um mecanismo de políticas permite ou nega uma chamada — ele não a modifica. Redação é um controle diferente, aplicado em outro ponto do pipeline.
Usa construtos não suportados pela linguagem. Exemplo: "Negue transferências em fins de semana e feriados federais americanos." O suporte a data e hora no Dogwood cobre pontos no tempo, offsets e diferenças, mas não há acesso ao dia da semana nem a calendários de feriados. O guia da linguagem Dogwood detalha quais construtos estão disponíveis.
Está fora do escopo de execução. Exemplo: "Um cliente pode iniciar no máximo dez transferências por dia, contadas em todas as sessões simultâneas." A execução avalia trajetórias dentro de uma sessão; um cap que agrega entre sessões não pode ser recuperado com uma formulação diferente.
Em cada um desses casos, o resultado útil não é uma política, mas um rótulo indicando que a regra não pode ser traduzida para Dogwood — o que sinaliza a necessidade de considerar alternativas: reescrever, mover para outro controle ou aceitar que permanece como processo humano.
Como funciona o pipeline de autoformação
O processo de autoformação roda em quatro etapas:
Decomposição: O documento é quebrado em regras atômicas. Uma cláusula numerada frequentemente carrega várias obrigações independentes, e cada uma se torna uma instrução sobre uma ferramenta específica que pode ser aplicada de forma isolada.
Roteamento: Cada regra é classificada como expressável ou não em Dogwood. As inexpressáveis são separadas antes da tradução, evitando que se tornem políticas que validam corretamente mas aplicam a coisa errada.
Autoformação: As regras restantes são convertidas em Dogwood, ancoradas no esquema de ferramentas fornecido junto ao documento.
Validação: Cada política candidata é validada usando as mesmas ferramentas de linha de comando Dogwood que acompanham a linguagem open source. O compilador é uma autoridade precisa e determinística sobre se uma política pode ser analisada e se todos os nomes existem no esquema. Quando uma candidata é rejeitada, seus diagnósticos são retornados e a regra é traduzida novamente com esses erros em vista, por um número limitado de rodadas.
O resultado final são duas coleções: as políticas que validaram para sintaxe e compatibilidade com o esquema do ambiente (junto com as regras atômicas que as geraram) e as regras atômicas que foram separadas por não serem expressáveis.
Conclusão
O Policy Authoring no Amazon Bedrock AgentCore representa um avanço importante para equipes que precisam aplicar governança sobre agentes de IA sem precisar dominar uma linguagem formal de especificação. A abordagem reconhece que as regras geralmente já existem em prosa — em procedimentos operacionais, documentos de conformidade ou políticas internas — e encurta o caminho entre esse documento e um conjunto de políticas revisável e implantável.
O Dogwood pode ser escrito diretamente por quem preferir trabalhar na linguagem. O Policy Authoring existe para o caso mais comum: quando as regras já estão em prosa e o trabalho é de transcrição.
O Amazon Elastic Kubernetes Service (Amazon EKS) anunciou suporte à rotação de Autoridade Certificadora (CA), permitindo que os clientes rotem a CA do cluster por meio de um ciclo de vida gerenciado com salvaguardas automatizadas.
Cada cluster do Amazon EKS possui sua própria CA, responsável por habilitar conexões criptografadas com a Interface de Programação de Aplicações (API) do Kubernetes. Com esse novo recurso, é possível realizar a rotação da CA antes de sua expiração, garantindo que o cluster continue operacional e seguro.
Por que isso é relevante agora
Os clusters do Amazon EKS criados desde o lançamento do serviço em 2018 possuem CAs com validade de 10 anos — ou seja, muitos desses clusters estão se aproximando do momento em que a rotação deve ser iniciada. É exatamente para esse cenário que a AWS desenvolveu esse mecanismo gerenciado.
Responsabilidade compartilhada na rotação
A rotação de CA no Amazon EKS segue um modelo de responsabilidade compartilhada:
A AWS gerencia o ciclo de vida da rotação e atualiza automaticamente os componentes gerenciados pela própria AWS para que passem a confiar na CA sucessora. Instâncias no EKS Auto Mode e nós do AWS Fargate são atualizados automaticamente.
Os clientes são responsáveis por substituir os worker nodes e atualizar clientes externos para que confiem na CA sucessora antes de sua ativação — inclusive quando utilizam EKS Auto Mode ou Fargate, no que diz respeito aos clientes externos que se conectam ao servidor de API do cluster.
Salvaguardas automatizadas
Para apoiar os clientes durante o processo, o Amazon EKS oferece um conjunto de proteções automáticas:
Notificações antecipadas antes da expiração da CA;
Adição automática de uma CA sucessora, caso o cliente não crie uma por conta própria;
Ativação automática da CA sucessora, caso o cliente não realize a ativação dentro do prazo;
Capacidade de rollback, permitindo reverter para a CA anterior caso algum problema surja durante a transição.
Disponibilidade e como começar
A rotação de CA no Amazon EKS está disponível sem custo adicional em todas as regiões comerciais da AWS. Para iniciar o processo, é possível utilizar o AWS CLI, as APIs do EKS, o CloudFormation ou o console da AWS.
A AWS anunciou que o Amazon CloudFront agora oferece suporte nativo ao Controle de Acesso de Origem (OAC — Origin Access Control) para os Pontos de Acesso Multi-Região (MRAP — Multi-Region Access Points) do Amazon S3. A novidade simplifica bastante a forma como equipes protegem seus conteúdos distribuídos globalmente.
Como funciona essa combinação
Quando times de engenharia utilizam o Amazon S3 MRAP junto ao CloudFront, o objetivo é servir conteúdo a partir de um único endpoint global. Esse endpoint roteia automaticamente as requisições para o bucket replicado mais próximo do usuário, sempre que ocorre um cache miss — ou seja, quando o conteúdo solicitado ainda não está em cache na borda. Esse modelo melhora tanto a performance quanto a resiliência para usuários distribuídos ao redor do mundo.
Qual era o problema antes
Até então, para proteger adequadamente os origens MRAP, as equipes precisavam calcular e encaminhar manualmente o cabeçalho de autorização SigV4a (Versão de Assinatura Assimétrica 4) usando uma função personalizada de Lambda@Edge. Esse processo adicionava complexidade operacional: era necessário manter código customizado apenas para lidar com a assinatura das requisições.
O que muda com o novo suporte
Com o suporte nativo ao OAC, o CloudFront passa a assinar automaticamente as requisições direcionadas às origens S3 MRAP — sem nenhuma função Lambda@Edge adicional. Na prática, isso traz dois ganhos diretos:
Preenchimento de cache mais rápido: as requisições de cache miss são resolvidas a partir da região mais próxima disponível.
Acesso restrito e seguro via OAC: o MRAP fica protegido sem a necessidade de computação personalizada do cabeçalho de autorização.
Disponibilidade e como começar
O suporte ao OAC do CloudFront para origens S3 MRAP está disponível mundialmente, com exceção da região CloudFront China. Para habilitar o recurso, basta acessar o Console do CloudFront, o SDK, a CLI ou o CloudFormation e ativar o OAC ao configurar o endpoint S3 MRAP desejado.
Não há cobrança adicional associada a essa funcionalidade. Para mais detalhes técnicos, a AWS disponibiliza o Guia do Desenvolvedor do CloudFront com todas as instruções necessárias.
Quem gerencia firewalls em ambientes corporativos sabe bem como conjuntos de regras crescem com o tempo. Novas regras são adicionadas para atender a requisitos de segurança, auditorias ou incidentes pontuais — e poucas são removidas. O resultado é um conjunto de regras cada vez mais extenso, com muitas entradas que podem nunca ser acionadas na prática.
Até então, a única forma de descobrir quais regras do AWS Network Firewall estavam realmente correspondendo ao tráfego era analisar logs manualmente. Isso cria dois problemas sérios: operacional e de conformidade. Do ponto de vista operacional, equipes não conseguem identificar regras dormentes que consomem capacidade sem servir a nenhum propósito. Do ponto de vista de conformidade, frameworks como o Padrão de Segurança de Dados da Indústria de Cartões de Pagamento (PCI) 4.0 e a Lei de Resiliência Operacional Digital (DORA) exigem evidências de que controles específicos estão ativamente funcionando — e sem dados de ativação de regras, essa evidência simplesmente não existe.
Para resolver esse cenário, a AWS anunciou o suporte a rule hit count (contagem de hits por regra) no Network Firewall, uma funcionalidade que entrega exatamente essa visibilidade de forma nativa e automática.
Como funciona o rule hit count
O rule hit count registra quantas vezes cada regra stateful corresponde ao tráfego de rede. O contador é incrementado sempre que uma regra gera um log de alerta — ou seja, regras com ações de alert, drop ou reject são contabilizadas automaticamente, pois essas ações produzem logs de alerta por padrão.
Regras configuradas com a ação pass, por outro lado, não geram logs de alerta por padrão e, portanto, não aparecem na métrica de hit count. Para incluir esse tipo de regra na contagem, basta adicionar a palavra-chave alert dentro da própria regra de pass. Isso faz com que o tráfego continue sendo permitido normalmente, mas um log de alerta também seja gerado, tornando a regra visível na métrica. O exemplo abaixo, em sintaxe Suricata, ilustra esse padrão:
pass tls $HOME_NET any -> $EXTERNAL_NET 443 (msg:"Pass and Log HTTPS traffic"; alert; sid:1000001; rev:1;)
Essa regra permite o tráfego HTTPS ao destino pretendido e, ao mesmo tempo, gera um log de alerta para que a regra apareça no hit count.
Metadados adicionados nos logs de alerta
A funcionalidade também enriquece cada log de alerta com um bloco de metadados que identifica o grupo de regras responsável pelo match. Esse enriquecimento é automático e não requer configuração adicional:
O Network Firewall envia esses logs de alerta para o Amazon CloudWatch Logs ou para o Amazon Simple Storage Service (Amazon S3). Para identificar qual regra específica gerou um alerta, basta combinar os campos sid (identificador de assinatura) e resource_arn na consulta. O dashboard de monitoramento do firewall usa exatamente esses campos para calcular e exibir os hit counts por regra, dispensando a necessidade de consultar os logs diretamente. Mas caso prefira análise customizada, é possível usar o CloudWatch Logs Insights para logs armazenados no CloudWatch, ou o Amazon Athena para logs no S3.
Como começar a usar
O rule hit count já vem habilitado por padrão no Network Firewall — não é necessária nenhuma configuração adicional. Assim que as regras do firewall estão em operação, o rastreamento de hits começa automaticamente.
Pré-requisitos
Para aproveitar o recurso, alguns pontos precisam estar configurados:
Entrega de logs de alerta configurada: O firewall precisa ter o log de alertas habilitado. Os metadados de hit count são capturados independentemente do destino dos logs, mas o dashboard nativo exige que os logs sejam enviados ao CloudWatch Logs ou ao Amazon S3.
Monitoramento detalhado habilitado: Para visualizar o painel de Top Rule Hits no console, é necessário habilitar o monitoramento detalhado nas configurações de log do firewall ou pela aba de Monitoramento no Console de Gerenciamento da AWS. Se você tiver uma solução de dashboard própria, os metadados necessários já estão presentes nos logs automaticamente — independentemente de o monitoramento detalhado estar ativo ou não.
Regras pass com a palavra-chave alert: Regras com ação pass não geram logs de alerta por padrão. Para que apareçam na métrica de hit count, inclua a palavra-chave alert nessas regras, conforme demonstrado anteriormente.
Visualizando os dados no console
Para acessar as métricas de hit count, abra o console do Network Firewall, selecione o firewall desejado e navegue até a seção Monitoring and observability. Em Top analysis, o painel Top Rule Hits exibe as regras stateful mais acionadas. É possível selecionar um período de lookback para filtrar a atividade dentro de um intervalo de tempo específico.
O painel apresenta colunas para contagem de hits (com gráfico de barras e fração), percentual do total de hits, Resource ARN (Nome de Recurso da Amazon), Signature ID (identificador de assinatura), descrição da regra (campo msg da regra Suricata) e última ocorrência em UTC.
Vale notar que os IDs de assinatura 2, 4, 6 e 8 são assinaturas geradas automaticamente pelo sistema, correspondentes às ações padrão da política de firewall em modo de ordem estrita. Como essas assinaturas têm origem na política — e não em um grupo de regras —, o campo resource_arn exibe o ARN da política de firewall em vez do ARN de um grupo de regras. Elas aparecem no Top Rule Hits quando a política tem ações padrão como Drop established, Alert established ou suas variantes de camada de aplicação configuradas. Essas assinaturas disparam em pacotes de conexão estabelecida que não correspondem a nenhuma regra explícita, aplicando a postura de negação padrão da política.
Casos de uso práticos
Identificando regras inativas
Qualquer regra cujo Signature ID não apareça no painel de Top Rule Hits durante o período selecionado não correspondeu a nenhum tráfego naquele intervalo. Isso indica que a regra pode estar obsoleta ou posicionada incorretamente dentro do grupo de regras.
Acelerando a resposta a incidentes
Filtrando o painel pelo período de um incidente suspeito, a equipe consegue identificar rapidamente quais regras foram acionadas naquele intervalo — sem precisar percorrer manualmente milhares de entradas de log. Por exemplo: uma regra com a descrição traffic_to_oast [oast[.]fun] com seis hits pode indicar que um atacante está tentando exfiltrar dados ou validar uma vulnerabilidade no ambiente.
Validando regras recém-adicionadas
Após adicionar uma nova regra para monitorar ou restringir tráfego — como uma regra de geofencing para bloquear conexões a países fora dos Estados Unidos, ou uma regra para categorizar tráfego a domínios de Inteligência Artificial e Aprendizado de Máquina (IA/ML) —, o hit count confirma se a regra está sendo acionada conforme esperado. Isso fornece evidência concreta de que os controles implantados estão funcionando.
Preços
O rule hit count está incluído no Network Firewall sem custo adicional. No entanto, as tarifas padrão se aplicam ao armazenamento e à consulta dos dados de log. Se os logs forem enviados ao CloudWatch Logs, aplicam-se os preços do CloudWatch. Se forem armazenados no Amazon S3 e consultados via Athena, aplicam-se as tarifas padrão de armazenamento do S3 e de consulta do Athena. Para detalhes completos, consulte a página de preços do AWS Network Firewall.
Considerações importantes
Para gerenciar custos, revise a utilização dos logs e configure políticas de filtragem ou retenção.
O rule hit count se aplica apenas a regras stateful. Regras stateless não suportam rastreamento de hit count no momento.
O recurso está disponível em todas as regiões AWS onde o Network Firewall é suportado, exceto Oriente Médio (Emirados Árabes Unidos) e Oriente Médio (Bahrein).
Conclusão
O rule hit count é uma adição relevante para equipes que precisam de mais visibilidade sobre a efetividade das suas políticas de firewall. A funcionalidade resolve um problema concreto e recorrente: saber quais regras realmente fazem alguma coisa. Com ela, é possível limpar conjuntos de regras obsoletos, demonstrar conformidade com evidências reais e reagir mais rápido durante investigações de segurança.
A AWS anunciou uma novidade importante para quem utiliza o Amazon Timestream para InfluxDB: o serviço agora suporta Chaves Gerenciadas pelo Cliente (CMK — Customer Managed Keys) por meio do Serviço de Gerenciamento de Chaves da AWS (AWS KMS — AWS Key Management Service). Com isso, os clientes ganham controle direto sobre as chaves usadas para criptografar dados em repouso.
O suporte abrange três tipos de recursos: instâncias de banco de dados InfluxDB 2, Read Replicas do InfluxDB 2 e clusters InfluxDB 3. Em todos os casos, a chave selecionada é utilizada para criptografar o armazenamento subjacente do banco de dados.
Como funciona na prática
A configuração é feita no momento da criação do recurso: o cliente seleciona uma chave simétrica do AWS KMS e o Timestream para InfluxDB passa a utilizá-la automaticamente para proteger os dados armazenados. É importante destacar dois pontos de atenção:
A chave deve estar na mesma conta AWS e na mesma região do recurso de banco de dados.
A chave é definida apenas durante a criação do recurso — não é possível alterá-la depois.
Como habilitar o recurso
O suporte a CMK está disponível por três canais:
Console de Gerenciamento da AWS (AWS Management Console)
Interface de Linha de Comando da AWS (AWS CLI — AWS Command Line Interface)
Interface de Programação de Aplicações (API) do Timestream para InfluxDB
O recurso está disponível em todas as regiões da AWS onde o Amazon Timestream para InfluxDB é oferecido. Do ponto de vista financeiro, a AWS não cobra nenhuma taxa adicional do Timestream para InfluxDB pelo uso de CMK — as cobranças que se aplicam são apenas as tarifas padrão do AWS KMS.
O problema: agentes de IA sem consciência de quem está perguntando
Times de engenharia que implantam agentes de IA frequentemente conectam esses agentes a tabelas do Amazon DynamoDB, repositórios de documentos, plataformas de Software como Serviço (SaaS) e bases de conhecimento internas. O risco central nesse cenário é que o agente, por padrão, não sabe quem está fazendo a pergunta — e pode acabar retornando dados que o usuário não deveria ver.
Para endereçar esse problema, a AWS publicou um guia técnico detalhado sobre como usar o Amazon Bedrock AgentCore para propagar o contexto de autorização do usuário por toda a cadeia de acesso a dados. A abordagem segue a boa prática AGENTSEC03 do AWS Well-Architected Agentic AI Lens.
O princípio central é direto: o agente atua como orquestrador, não como guardião. Ele coordena chamadas e raciocínio, mas quem decide o que cada usuário pode acessar são os serviços de infraestrutura subjacentes — não o código do agente.
Caso de uso: CRM com departamentos isolados
O guia usa como exemplo uma aplicação de chat para Gestão de Relacionamento com o Cliente (CRM), onde funcionários de Vendas e Financeiro interagem com o mesmo agente de IA para acessar informações de clientes. Embora a interface seja a mesma, cada departamento precisa de acesso isolado:
Vendas acessa contratos de clientes, estratégias de precificação e dados do pipeline de vendas.
Financeiro acessa faturas, registros de pagamento e relatórios financeiros.
A regra é clara: quando um funcionário de Vendas pergunta “Mostre os contratos de clientes”, o agente deve retornar apenas contratos de Vendas — nunca faturas do Financeiro. E esse controle precisa acontecer fora do agente, para que mesmo em caso de comprometimento por injeção de prompt ou bugs, o acesso não autorizado seja bloqueado.
Visão geral da arquitetura
O fluxo de dados da arquitetura proposta funciona da seguinte forma:
O usuário abre a aplicação web e se autentica com o Amazon Cognito user pool, que atua como Provedor de Identidade (IdP).
Um gatilho Lambda de pré-geração de token (V2) enriquece os Tokens Web JSON (JWTs) com uma claim personalizada e metadados de session tag do AWS STS antes de retorná-los ao usuário.
A aplicação web encaminha a requisição do usuário junto com o token de acesso para o agente implantado no Bedrock AgentCore Runtime.
O AgentCore Runtime valida o JWT de entrada e, por meio do Bedrock AgentCore Identity, emite um token de acesso de workload que vincula as identidades do usuário e do agente.
Para consultas que exigem documentos internos, o agente usa sua função do AWS Identity and Access Management (IAM) para consultar o Amazon Bedrock Knowledge Bases com filtragem de metadados, e o DynamoDB com credenciais temporárias com escopo de usuário via session tags.
Quando o funcionário abre a aplicação, ele se autentica com suas credenciais corporativas usando o Amazon Cognito user pools como IdP. O gatilho Lambda de pré-geração de token (V2) captura o contexto de departamento do usuário e o adiciona tanto ao token de identidade (ID token) quanto ao token de acesso.
O token de acesso é usado pelo autorizador JWT personalizado do AgentCore Runtime para autorização de entrada. O ID token recebe a claim https://aws.amazon.com/tags, que é o formato específico exigido pelo AWS Security Token Service (AWS STS) para extrair session tags durante o AssumeRoleWithWebIdentity. Para mais detalhes, a AWS disponibiliza o guia Como personalizar tokens de acesso no Amazon Cognito user pools.
O código a seguir mostra a lógica principal dentro de uma função Lambda handler configurada como gatilho no Amazon Cognito user pool. Esse código roda automaticamente quando o usuário se autentica, extraindo o atributo de departamento e adicionando-o como uma claim personalizada em ambos os tokens:
Quando a requisição chega ao AgentCore Runtime, o autorizador JWT de entrada realiza duas verificações: valida o token JWT com o Amazon Cognito (verificando assinatura criptográfica, expiração e emissor confiável) e extrai a claim de departamento do token validado, comparando-a com o valor esperado na configuração do autorizador. Qualquer token sem uma claim correspondente é rejeitado antes mesmo de o código do agente ser invocado.
O exemplo abaixo mostra a configuração do autorizador JWT de entrada. O campo inboundTokenClaimName é department, o inboundTokenClaimValueType declara o tipo como STRING_ARRAY, e o authorizingClaimMatchValue especifica os valores permitidos (["Sales", "Finance"]) com o operador CONTAINS_ANY:
Vale destacar que o AgentCore Runtime cria automaticamente uma identidade de workload para cada agente implantado. Essa identidade representa a identidade digital do agente no ambiente AWS, permitindo que ele mantenha identidade consistente ao usar funções IAM para acesso a recursos AWS, tokens OAuth 2.0 para integração com serviços externos, ou chaves de API para acesso a ferramentas de terceiros.
Padrão 1: Escopo de acesso ao DynamoDB por usuário
Para o acesso ao DynamoDB, a abordagem usa o AssumeRoleWithWebIdentity com session tags para criar credenciais com escopo de usuário por requisição. O agente passa o ID token assinado do usuário para o AWS STS, que extrai a tag de departamento da claim https://aws.amazon.com/tags e retorna credenciais temporárias restritas à partição de dados daquele departamento.
Isso move o controle de acesso do código do agente para a avaliação de políticas IAM. O STS também valida a claim de audiência (aud) do token contra a configuração do provedor OIDC do IAM, impedindo que tokens emitidos para outros clientes de aplicação sejam usados para assumir a função.
Como pré-requisito de configuração única, é necessário registrar o Amazon Cognito como um provedor OIDC no IAM e configurar a política de confiança da UserScopedDynamoDBRole para incluir as permissões sts:AssumeRoleWithWebIdentity e sts:TagSession:
Por padrão, o AgentCore Runtime descarta cabeçalhos personalizados por segurança. Para permitir que o cabeçalho X-Id-Token chegue ao container do agente, é preciso configurá-lo no requestHeaderAllowlist do runtime:
O AWS STS extrai a claim https://aws.amazon.com/tags e cria uma sessão com aws:PrincipalTag/department definido. A política de permissão na função usa a condição dynamodb:LeadingKeys vinculada a essa tag, garantindo que apenas a partição do departamento do usuário seja acessível — e esse controle acontece na camada de política IAM, não no código do agente:
Padrão 2: Autorização com escopo de usuário no Amazon Bedrock Knowledge Bases
Para documentos armazenados no Amazon Bedrock Knowledge Bases, o agente aplica filtragem de metadados no momento da consulta. Cada documento é marcado com um atributo de metadados Department durante a ingestão. Os arquivos de metadados ficam no Amazon S3 com o mesmo nome do arquivo-fonte e sufixo .metadata.json:
{"metadataAttributes": {"Department": "Sales"}}
Quando o agente consulta o Amazon Bedrock Knowledge Bases, ele chama a ação bedrock:Retrieve e adiciona o filtro de configuração de recuperação com escopo para o departamento do usuário. O valor do departamento é extraído do token de acesso JWT recebido durante a autorização de entrada:
Importante: a filtragem de metadados é um controle na camada de aplicação. A API bedrock:Retrieve não expõe o conteúdo do filtro de metadados como uma chave de condição IAM. Para isolamento mais rigoroso, a AWS recomenda considerar bases de conhecimento separadas por departamento com políticas IAM em nível de recurso.
Padrão 3: Acesso a serviços externos via troca de token on-behalf-of
Para serviços externos como o Salesforce, que não suportam controle de acesso baseado em IAM, é necessário um mecanismo diferente para propagar a identidade do usuário. A troca de token On-Behalf-Of (OBO) do AgentCore Identity (RFC 8693) resolve isso trocando a identidade autenticada do usuário por um token com escopo de usuário que o serviço externo reconhece e aplica nativamente.
O guia compara três padrões OAuth suportados pelo AgentCore Identity para acesso a serviços externos:
Client Credentials — OAuth de Duas Pernas (2LO) ou máquina a máquina (M2M): o agente autentica como conta de serviço e recebe um token com acesso amplo. Adequado para dados organizacionais não vinculados a um usuário individual. Veja mais em Empower AI agents with user context using Amazon Cognito.
Authorization Code — OAuth de Três Pernas (3LO): o usuário consente explicitamente via redirecionamento no navegador. Funciona quando é necessário consentimento por serviço, mas exige interação do usuário, o que é impraticável para operações em segundo plano. Veja mais em Secure AI agents with Amazon Bedrock AgentCore Identity on Amazon ECS.
Troca de token OBO: a identidade já autenticada do usuário é trocada por um token com escopo de serviço sem interação adicional do usuário, e o serviço externo aplica o controle de acesso. É o padrão mais adequado para este caso de uso.
O OBO propaga a identidade do usuário de ponta a ponta sem que o agente armazene credenciais, escala automaticamente sem armazenamento de token por usuário, e permite que serviços downstream apliquem sua própria autorização (regras de compartilhamento, Controle de Acesso Baseado em Função — RBAC).
No Salesforce, é necessário registrar o Amazon Cognito como provedor de autenticação OpenID Connect, configurar um handler de troca de token (classe Apex estendendo Auth.Oauth2TokenExchangeHandler) que resolve usuários pelo FederationIdentifier, e configurar regras de compartilhamento para acesso com escopo de departamento. O ID de federação (sub) é imutável e não pode ser forjado pelo agente, pois origina do token de identidade assinado criptograficamente.
Como resultado, nenhum filtro de departamento é necessário na consulta Salesforce Object Query Language (SOQL) — as regras de compartilhamento do Salesforce aplicam o controle de acesso nativamente:
@tool
def query_salesforce_opportunities(query_text: str) -> str:
access_token = _get_salesforce_token_sync()
# No department filter needed. Salesforce sharing rules enforce access.
soql = "SELECT Id, Name, Amount, StageName, CloseDate FROM Opportunity ORDER BY CloseDate DESC LIMIT 10"
response = requests.get(
f"{SALESFORCE_URL}/services/data/v59.0/query?q={urllib.parse.quote(soql)}",
headers={"Authorization": f"Bearer {access_token}"},
timeout=30,
)
return json.dumps(response.json().get("records", []))
Conclusão e próximos passos
A arquitetura apresentada pela AWS demonstra como implementar autorização consistente de ponta a ponta em aplicações de IA agêntica, propagando o contexto do usuário do Amazon Cognito pelo Amazon Bedrock AgentCore até os recursos downstream. Os três padrões cobertos são:
Credenciais temporárias com escopo de usuário por requisição usando AssumeRoleWithWebIdentity com session tags, avaliadas por políticas IAM de Controle de Acesso Baseado em Atributos (ABAC) para acesso ao Amazon DynamoDB.
Filtragem de metadados com escopo de departamento na camada de aplicação para acesso ao Amazon Bedrock Knowledge Bases.
Troca de token on-behalf-of (RFC 8693) usando o AgentCore Identity, com regras de compartilhamento nativas do Salesforce governando o acesso a dados externos de CRM.
O ponto central é que o agente coordena o trabalho, mas não decide quem pode acessar o quê. As decisões de acesso são tomadas por controles de infraestrutura e pelo modelo de autorização dos serviços downstream. Essa abordagem em camadas garante que, mesmo que o agente se comporte de forma inesperada, o acesso não autorizado a dados ainda seja bloqueado.
Para explorar mais, a AWS disponibiliza os seguintes recursos:
A AWS anunciou que os notebooks do Amazon SageMaker agora suportam a Propagação de Identidade Confiável (TIP — Trusted Identity Propagation), com integração aos serviços Amazon Athena, Amazon Redshift e Amazon EMR Serverless. O objetivo é habilitar controle de acesso granular por usuário em fluxos de análise de dados.
Como funciona na prática
Quando um notebook está conectado a um ambiente de computação habilitado para TIP, dentro de um Projeto também habilitado para TIP, a identidade de cada usuário no Centro de Identidade do IAM (IAM Identity Center) é automaticamente propagada até o AWS Lake Formation. Isso significa que cada pessoa enxerga somente as tabelas, colunas e linhas que suas permissões individuais permitem — sem que seja necessário compartilhar uma única função de execução ampla entre todos os usuários do ambiente.
Em outras palavras, o controle de acesso deixa de ser genérico e passa a ser individual: quem executa a consulta define o que pode ser visto.
Principais benefícios
Fronteiras de dados por usuário: o acesso é aplicado com base em quem está executando a consulta, não em uma função de serviço compartilhada.
Auditoria completa: o AWS CloudTrail registra qual usuário acessou quais dados, garantindo rastreabilidade total das operações.
Menos atrito administrativo: a identidade é propagada automaticamente pela conexão de computação existente, sem necessidade de login adicional, gerenciamento de tokens ou configuração de funções extras.
Novos processadores chegam ao CloudWatch Pipelines
A AWS anunciou a adição de três novos processadores ao Amazon CloudWatch Pipelines: um parser de logs do Amazon RDS, um parser de XML e um processador de enriquecimento por GeoIP. A novidade amplia as capacidades de transformação de dados de telemetria diretamente na ingestão, sem a necessidade de gerenciar infraestrutura adicional.
Para quem ainda não conhece o serviço: o CloudWatch Pipelines é um serviço totalmente gerenciado que ingere, transforma e roteia dados de telemetria para o CloudWatch. A proposta é eliminar a necessidade de pipelines customizados e servidores dedicados para esse tipo de processamento.
O problema que esses processadores resolvem
Fontes de log comuns produzem dados em formatos que não são consultáveis diretamente — é preciso reprocessá-los antes de qualquer análise. Três cenários clássicos ilustram bem o desafio:
Logs do RDS Aurora chegam no formato nativo do mecanismo de banco de dados, sem estrutura padronizada;
Logs de aplicação frequentemente carregam payloads em XML embutidos em campos de texto;
Endereços IP presentes nos logs não trazem nenhum contexto geográfico por padrão.
Os três novos processadores foram criados exatamente para endereçar cada um desses casos.
O que cada processador faz
Parser de logs do Amazon RDS
Converte logs de auditoria e de erros do Aurora em campos estruturados. Isso facilita, por exemplo, a geração de relatórios de conformidade a partir de logs de auditoria do banco de dados, sem precisar de etapas extras de transformação.
Parser de XML
Converte um campo que contém uma string XML em JSON. Um caso de uso prático é a extração do payload XML presente em logs do Windows Event Log, tornando os dados consultáveis de forma mais simples e eficiente.
Processador de GeoIP
Enriquece qualquer campo de endereço IP com contexto geográfico, incluindo cidade, país e coordenadas. Combinado com o parser de XML, por exemplo, é possível identificar a origem geográfica de eventos de segurança diretamente no pipeline.
Como usar na prática
Os processadores podem ser utilizados de forma independente ou combinados em um único pipeline. A AWS exemplifica dois cenários:
Fazer o parse de um log de auditoria do Aurora em campos estruturados para relatórios de conformidade;
Extrair o payload XML de um Windows Event Log em JSON e resolver o IP de origem para cidade e país, tudo em um único pipeline voltado à análise de segurança.
Disponibilidade e custos
Os três processadores estão disponíveis sem custo adicional em todas as regiões da AWS onde o CloudWatch Pipelines já está em disponibilidade geral. As taxas normais de ingestão e armazenamento de logs do CloudWatch continuam se aplicando.
A configuração pode ser feita pelo Console de Gerenciamento da AWS, pela AWS CLI ou pelos AWS SDKs. Para começar, a AWS disponibiliza a documentação oficial do CloudWatch Pipelines com todos os detalhes sobre os novos processadores.
