Controle total sobre a criptografia dos dados de identidade
A AWS anunciou uma atualização importante no Amazon Cognito: o serviço agora suporta chaves gerenciadas pelo cliente (CMK) no Serviço de Gerenciamento de Chaves da AWS (AWS KMS) para criptografar dados de user pools em repouso.
Até então, o Cognito utilizava chaves de propriedade da própria AWS por padrão para proteger os dados armazenados. Esse modelo funciona bem para a maioria dos cenários, mas organizações com requisitos mais rígidos de governança de dados precisavam de um nível maior de controle — e é exatamente isso que a nova funcionalidade entrega.
O que muda na prática
Com as chaves gerenciadas pelo cliente, a organização passa a ser responsável por criar, gerenciar e controlar o ciclo de vida das chaves de criptografia diretamente no AWS KMS. Isso traz algumas vantagens concretas:
É possível definir políticas organizacionais sobre quem pode usar as chaves e em quais condições.
O acesso aos dados criptografados pode ser revogado a qualquer momento, bastando desabilitar ou excluir a chave correspondente.
Toda a utilização das chaves pode ser monitorada e auditada via AWS CloudTrail, oferecendo visibilidade completa sobre quando e como os dados de identidade são acessados.
Como configurar
A configuração é flexível: é possível definir uma chave gerenciada pelo cliente tanto na criação de um novo user pool quanto na atualização de um user pool já existente. Para começar, basta acessar o Console de Gerenciamento da AWS, ou utilizar a AWS CLI ou os SDKs da AWS. A documentação oficial para desenvolvedores traz as instruções detalhadas de configuração.
Disponibilidade e custos
O recurso está disponível nos user pools dos planos Essentials e Plus do Amazon Cognito, sem custo adicional pelo uso da funcionalidade em si. Vale lembrar que as tarifas padrão do AWS KMS continuam sendo aplicadas normalmente.
Por que isso importa para equipes brasileiras
Para times que lidam com dados sensíveis de usuários — especialmente em contextos regulatórios como a LGPD — ter controle explícito sobre as chaves de criptografia é um diferencial importante. A possibilidade de revogar acesso programaticamente e auditar cada uso da chave eleva significativamente o nível de rastreabilidade e conformidade que uma organização pode demonstrar.
Disponibilidade geral das instâncias G6e no SageMaker
A AWS anunciou a disponibilidade geral das instâncias Amazon EC2 G6e para uso no SageMaker Notebook Instances. Trata-se de uma atualização relevante para equipes que trabalham com cargas de trabalho intensivas em processamento gráfico e modelos de Inteligência Artificial (IA) generativa diretamente nos notebooks gerenciados do SageMaker.
O que são as instâncias G6e?
As instâncias G6e são equipadas com até 8 GPUs NVIDIA L40s Tensor Core, cada uma com 48 GB de memória, além de processadores AMD EPYC de terceira geração. Essa combinação entrega até 2,5x mais desempenho em comparação com as instâncias EC2 G5, que eram a referência anterior para esse tipo de workload.
Em termos práticos, isso significa mais capacidade de processamento disponível diretamente no ambiente de notebook — sem precisar provisionar infraestrutura adicional para tarefas exploratórias e de desenvolvimento.
Casos de uso suportados
Com as instâncias G6e disponíveis no SageMaker Notebook Instances, os times de dados e engenharia de Machine Learning (ML) podem usar esse poder computacional para:
Testar interativamente o deploy de modelos, validando comportamento antes de ir para produção;
Realizar treinamento interativo de modelos, incluindo fine-tuning de modelos de IA generativa;
Fazer o deploy de Modelos de Linguagem de Grande Escala (LLMs) com até 13 bilhões de parâmetros;
Trabalhar com modelos de difusão para geração de imagens, vídeos e áudio.
Esses casos de uso cobrem desde a fase exploratória até tarefas mais exigentes de ajuste fino de modelos — tudo dentro do ambiente familiar dos notebooks gerenciados.
Regiões disponíveis
As instâncias G6e no SageMaker Notebook Instances estão disponíveis nas seguintes regiões da AWS:
A AWS anunciou o Lambda MicroVMs, uma nova primitiva de computação serverless que combina isolamento em nível de máquina virtual (VM), inicialização quase instantânea e preservação de estado de execução. Com esse lançamento, desenvolvedores podem oferecer a cada usuário ou tarefa um ambiente de computação próprio e seguro — sem precisar gerenciar infraestrutura de virtualização por conta própria.
Por que esse recurso importa?
Cada vez mais equipes estão construindo aplicações multi-tenant que executam código enviado por usuários finais ou gerado por Inteligência Artificial (IA). Casos de uso típicos incluem ambientes interativos de programação, plataformas de análise de dados, assistentes de código e ferramentas de varredura de vulnerabilidades.
Nesse tipo de aplicação, é fundamental isolar cada sessão ou usuário para que um código incorreto ou malicioso não afete outros processos em execução simultânea. Até então, os desenvolvedores precisavam escolher entre três características que raramente coexistiam: isolamento forte, tempo de inicialização rápido e retenção de estado. O Lambda MicroVMs elimina esse compromisso.
Principais capacidades
Isolamento em nível de VM: cada MicroVM roda em um ambiente completamente separado, limitando o impacto de qualquer código problemático.
Inicialização quase instantânea: o tempo de cold start é mínimo, viabilizando experiências responsivas para o usuário final.
Suspensão e retomada de execução: é possível suspender e retomar uma MicroVM por até 8 horas, preservando o estado da execução.
Tecnologia Firecracker: o serviço é construído sobre a virtualização Firecracker, a mesma tecnologia que sustenta mais de 15 trilhões de invocações mensais do Lambda.
Conectividade moderna: cada MicroVM recebe uma URL HTTPS dedicada com suporte a protocolos populares como HTTP/2, gRPC e WebSockets.
Como começar
Para usar o Lambda MicroVMs, o fluxo básico é: criar uma imagem MicroVM a partir de um Dockerfile e, em seguida, inicializar MicroVMs a partir dessa imagem. Cada usuário ou tarefa pode receber sua própria MicroVM com uma URL HTTPS dedicada.
O Lambda MicroVMs já está disponível nas seguintes regiões da AWS: Leste dos EUA (Norte da Virgínia), Leste dos EUA (Ohio), Oeste dos EUA (Oregon), Ásia-Pacífico (Tóquio) e Europa (Irlanda).
O modelo de cobrança considera os recursos de computação de base enquanto a MicroVM está em execução, e cobra apenas pela duração ativa dos recursos adicionais consumidos quando a carga de trabalho ultrapassa o nível base. Para detalhes completos, consulte a página de preços do Lambda MicroVMs.
Quando o assunto é segurança em ambientes Amazon Web Services (AWS), a tendência natural é focar no tráfego de entrada: firewalls, WAFs e políticas de acesso recebem atenção prioritária porque é de lá que vêm as ameaças mais visíveis. O tráfego de saída, por outro lado, costuma ser deixado aberto por padrão — para não quebrar dependências de aplicações — e o risco parece menos imediato.
Mas ignorar o egress significa abrir mão de uma camada essencial de defesa. Sem visibilidade sobre o que está saindo da rede, fica muito mais difícil detectar fluxos de dados não autorizados, sejam eles causados por serviços mal configurados, permissões excessivamente amplas ou workloads comprometidas.
Dois cenários do mundo real ilustram bem esse risco:
Ambientes tradicionais: quando a vulnerabilidade CVE-2025-55182 (React2Shell) foi divulgada em dezembro de 2025, grupos organizados iniciaram tentativas de exploração em questão de horas, visando componentes React Server não atualizados para obter execução remota de código. Após comprometer uma workload, o atacante tipicamente estabelece canais de comando e controle e começa a exfiltrar dados. Sem controles de egress, esse tráfego flui livremente — e o comprometimento pode passar despercebido por meses.
Sistemas de IA agêntica: o OWASP Top 10 para Aplicações Agênticas identifica ameaças como o Sequestro de Objetivo do Agente (ASI01), em que partes não autorizadas manipulam os objetivos de um agente autônomo para exfiltrar dados silenciosamente, e Execução de Código Inesperada (ASI05), em que um agente comprometido gera e executa código que estabelece shells reversos ou transfere dados sensíveis para endpoints externos. Agentes de IA com acesso a ferramentas, APIs e interpretadores de código tornam-se alvos de alto valor — e sua atividade de rede de saída precisa ser controlada com o mesmo rigor de qualquer outra workload.
O denominador comum dos dois cenários é o mesmo: tráfego de saída não autorizado. A AWS publicou um guia detalhando como implementar detecção e proteção de egress em camadas, reduzindo o risco de transferência não autorizada de dados independentemente da origem da ameaça.
Visão geral da arquitetura
A arquitetura proposta adota o padrão hub-and-spoke para ambientes AWS multi-contas. As workloads residem em Nuvens Privadas Virtuais (VPCs) spoke que se conectam ao AWS Transit Gateway, responsável por centralizar o roteamento do tráfego entre VPCs e em direção à internet, aplicando segmentação de rede por meio de tabelas de rotas cuidadosamente definidas.
As VPCs spoke utilizam endpoints de VPC para acessar serviços AWS de forma privada, mantendo o tráfego dentro da rede da AWS sempre que possível. Políticas de endpoint de VPC são aplicadas como controles de perímetro de dados, restringindo quais entidades podem acessar quais serviços e recursos.
O tráfego com destino à internet é roteado através de um AWS Network Firewallacoplado ao Transit Gateway, que inspeciona e filtra os fluxos de saída antes de chegarem à internet. Esse modelo centralizado escala horizontalmente com a adição de novas VPCs spoke, sem necessidade de modificar a infraestrutura de inspeção.
É fundamental entender que o Amazon Route 53 Resolver DNS Firewall precisa ser implantado em todas as VPCs para filtrar consultas DNS resolvidas pelo Route 53 VPC Resolver. Consultas DNS enviadas diretamente a outros resolvers contornam esse firewall, mas podem ser filtradas pelo AWS Network Firewall.
A observabilidade centralizada é alcançada por meio do Amazon CloudWatch Logs e dos dashboards do CloudWatch, coletando logs de fluxo e alertas do Network Firewall para suportar investigações e relatórios de conformidade.
Essa arquitetura se aplica igualmente a workloads tradicionais e a workloads orientadas por IA. Um agente de IA rodando no Amazon Bedrock, por exemplo, normalmente reside dentro de uma VPC spoke. Quando esse agente invoca uma API externa ou tenta acessar a internet, seu tráfego percorre o mesmo caminho pelo Transit Gateway e pelo Network Firewall que qualquer workload no Amazon Elastic Compute Cloud (Amazon EC2) ou em contêineres. O agente não tem um caminho privilegiado de saída — está sujeito às mesmas listas de domínios permitidos, à mesma filtragem DNS e às mesmas políticas de perímetro de dados.
Vale destacar que agentes frequentemente precisam de acesso de saída para invocar ferramentas externas ou APIs de terceiros como parte de sua operação normal. Isso torna o design das listas de permissão (allow-lists) mais delicado: o ideal é restringir os domínios permitidos exatamente aos endpoints que os agentes legitimamente precisam acessar, evitando aberturas genéricas. Complementar os controles de rede com guardrails na camada de aplicação — como o Amazon Bedrock Guardrails, capaz de filtrar conteúdo prejudicial e detectar ataques de prompt antes que cheguem à camada de rede — adiciona mais uma camada de defesa.
Controles preventivos
Os controles preventivos bloqueiam a exfiltração de dados antes que ela ocorra. Por atuarem interrompendo ativamente o tráfego, devem ser reservados para atividades confirmadas ou com alta probabilidade de serem prejudiciais.
AWS Network Firewall
Considere dois cenários: um atacante compromete uma instância EC2 em uma das VPCs spoke e tenta exfiltrar dados para um servidor externo; ou, no cenário de IA agêntica, um atacante usa injeção de prompt para sequestrar o objetivo de um agente (OWASP ASI01) e redirecioná-lo para exfiltrar dados de treinamento para um endpoint externo.
O Network Firewall é projetado para bloquear essa tentativa porque o destino não autorizado não consta na lista de domínios aprovados — o mesmo controle que impede uma instância EC2 comprometida também detém um agente de IA manipulado. Sem inspeção centralizada de egress, esse tráfego fluiria diretamente para a internet através de um NAT gateway.
O Network Firewall oferece inspeção profunda de pacotes nas camadas 3 a 7, com capacidades avançadas de inteligência de ameaças. Suas principais funcionalidades incluem:
Filtragem por nome de domínio: bloqueia tráfego para destinos não autorizados (como servidores de comando e controle em *.dominio-nao-confiavel.com)
Regras de IP e porta: define listas de permissão explícitas para IPs externos que as aplicações realmente precisam
Filtragem por categoria de domínio: bloqueia categorias inteiras de domínios com os quais as workloads nunca deveriam se comunicar
IDS e IPS: detecta e bloqueia padrões de ataque conhecidos no tráfego de saída usando regras compatíveis com Suricata
Aplicação de porta e protocolo: garante que apenas os protocolos esperados utilizem suas portas designadas (por exemplo, apenas HTTPS na porta TCP 443), prevenindo tunelamento de protocolos
Filtragem geográfica de IP: bloqueia tráfego de saída para regiões geográficas onde a organização não possui relacionamentos comerciais
Descriptografia TLS: inspeciona tráfego criptografado para detectar tentativas de exfiltração ocultas em conexões HTTPS
Integração com inteligência de ameaças: utiliza feeds gerenciados (como o sistema de inteligência de ameaças da Amazon, MadPot) ou regras Suricata customizadas para detectar padrões inesperados
Escalabilidade automática: suporta até 100 Gbps por Zona de Disponibilidade
Para ambientes multi-conta, o AWS Firewall Manager permite implantar e gerenciar o Network Firewall de forma centralizada em todas as contas da organização. Adicionalmente, o AWS Network Firewall Proxy (em prévia) oferece capacidades de proxy explícito com filtragem granular de HTTP/HTTPS — incluindo controles no nível de caminho de URL e método HTTP — para workloads que exigem inspeção na camada de aplicação do tráfego web de saída.
Route 53 Resolver DNS Firewall
Consultas DNS feitas pelo Route 53 VPC Resolver não passam pelo caminho de rede inspecionado pelo Network Firewall. Atacantes podem explorar isso codificando dados sensíveis dentro de consultas DNS direcionadas a servidores externos — técnica conhecida como DNS tunneling (tunelamento DNS).
Esse risco se estende a workloads de IA agêntica. Um agente com capacidades de execução de código (OWASP ASI05) pode ser induzido a executar um script que codifica dados sensíveis (como registros de clientes, pesos de modelo, chaves de API) em consultas DNS direcionadas a um servidor de nomes controlado externamente.
O DNS Firewall bloqueia essas consultas independentemente de sua origem — workload tradicional ou agente de IA — porque a filtragem ocorre no nível do resolver, antes que qualquer conexão seja estabelecida. Suas principais capacidades incluem:
Bloqueio de domínios não autorizados: a AWS fornece listas de domínios gerenciadas, incluindo uma Lista Agregada de Ameaças cobrindo malware, ransomware, botnets, spyware e DNS tunneling
Aplicação de listas de permissão: permite apenas consultas a domínios aprovados, bloqueando todo o restante
DNS Firewall Advanced: detecção baseada em IA/ML de DNS tunneling, Algoritmos de Geração de Domínio (DGAs) e DGAs de dicionário
A configuração é direta: crie grupos de regras com listas de correspondência de domínios e ações (bloquear, permitir e alertar), depois associe-os às suas VPCs. Para uma análise mais aprofundada sobre os riscos de exfiltração via DNS e as capacidades avançadas do DNS Firewall, consulte Proteção contra ameaças DNS avançadas com o Amazon Route 53 Resolver DNS Firewall.
Perímetros de dados
Um perímetro de dados é um conjunto de guardrails preventivos que permitem apenas identidades confiáveis acessarem recursos confiáveis a partir de redes esperadas. Enquanto os controles anteriores protegem os caminhos de rede para fora do ambiente, os perímetros de dados protegem os caminhos em nível de API — garantindo que, mesmo que um atacante obtenha credenciais válidas, não consiga usar as APIs de serviços AWS para mover dados para fora da organização.
Essa abordagem utiliza três capacidades principais da AWS trabalhando em conjunto:
Políticas de Controle de Serviço (SCPs): controles preventivos em nível organizacional que restringem o que identidades podem fazer. No contexto de proteção de egress, as SCPs podem impedir usuários de criar recursos que contornem os controles de saída (por exemplo, impedindo a criação de VPCs sem associações ao DNS Firewall ou bloqueando o uso de serviços que possam estabelecer caminhos alternativos de saída).
Políticas de Controle de Recursos (RCPs): controles que restringem o acesso via API aos seus recursos. Embora as RCPs não sejam controles de egress diretamente, atuam como camada complementar. Por exemplo, podem bloquear tentativas de acesso aos buckets do Amazon Simple Storage Service (Amazon S3) de fora da organização, no nível do recurso.
Políticas de endpoint de VPC: endpoints de VPC habilitam comunicação privada com serviços AWS sem que o tráfego passe pela internet. As políticas de endpoint de VPC são políticas de AWS Identity and Access Management (IAM) baseadas em recurso que governam o que pode ser acessado por meio desse endpoint. É aqui que os perímetros de dados funcionam mais diretamente como controle de egress.
O exemplo a seguir mostra uma política de endpoint de VPC que restringe o acesso ao Amazon S3 por meio do endpoint apenas a buckets S3 dentro da organização, impedindo diretamente que uma workload comprometida copie dados para um bucket externo:
Essa política nega qualquer operação do Amazon S3 por meio desse endpoint de VPC, a menos que o bucket S3 de destino pertença à organização. Sem esse controle, uma workload comprometida poderia usar aws s3 cp para copiar dados sensíveis para um bucket controlado externamente em uma conta AWS diferente.
As políticas de perímetro de dados não concedem novas permissões — elas restringem o que é acessível, estabelecendo guardrails e atuando como uma segunda camada de autorização. Ao implementar esses perímetros usando chaves de condição IAM como aws:PrincipalOrgID, aws:ResourceOrgID, aws:SourceVpc e aws:SourceVpce, cria-se guardrails de permissão em camadas que ajudam a prevenir padrões de acesso não intencionais e erros de configuração. Para mais informações sobre a implementação de controles de perímetro, consulte o whitepaper Construindo um Perímetro de Dados na AWS.
Controles detectivos
Os controles detectivos identificam tentativas de exfiltração de dados após sua ocorrência. Por observarem o tráfego sem interrompê-lo, podem ser aplicados amplamente para sinalizar atividades inesperadas para investigação. Os alertas gerados ajudam a identificar padrões recorrentes não autorizados que podem evoluir para controles preventivos.
Amazon GuardDuty
O GuardDuty atua como a camada crítica de detecção para proteção de egress, monitorando continuamente ameaças de saída que escapam ou exploram os controles preventivos. Ele identifica anomalias comportamentais e padrões de ataque que indicam tentativas ativas de exfiltração de dados. Suas capacidades de detecção focadas em egress incluem:
Detecção de exfiltração via DNS: o alerta Trojan:EC2/DNSDataExfiltration é disparado quando instâncias EC2 estão transferindo dados por canais DNS. O GuardDuty também identifica consultas a domínios DGA comumente usados para comunicação de comando e controle.
Detecção de atores maliciosos conhecidos:Exfiltration:S3/MaliciousIPCaller é acionado quando APIs de dados do Amazon S3, como GetObject ou CopyObject, são invocadas a partir de endereços IP presentes nos feeds de inteligência de ameaças da AWS.
Correlação de sequências de ataque em múltiplos estágios: o GuardDuty Extended Threat Detection correlaciona múltiplos eventos inesperados para identificar campanhas de exfiltração em múltiplas etapas. Por exemplo, AttackSequence:S3/CompromisedData detecta quando atacantes modificam políticas de bucket S3 para ampliar o acesso e depois extraem dados sistematicamente usando credenciais roubadas.
Os alertas do GuardDuty servem a dois propósitos na estratégia de egress. Alertas sobre tentativas de exfiltração que falharam confirmam que as camadas preventivas (Network Firewall, DNS Firewall e perímetros de dados) estão funcionando efetivamente. Já alertas indicando exfiltração bem-sucedida acionam fluxos imediatos de resposta a incidentes, permitindo conter incidentes ativos, revogar credenciais roubadas e isolar recursos afetados antes que danos significativos ocorram.
IAM Access Analyzer
O IAM Access Analyzer ajuda a identificar possíveis caminhos de exfiltração de dados detectando recursos acessíveis de fora da conta AWS ou da organização. Ele usa tecnologia de raciocínio automatizado para analisar políticas baseadas em recurso e identificar quais recursos podem ser acessados por entidades externas, monitorando continuamente acessos públicos e entre contas.
Por exemplo, quando um bucket S3 é configurado para permitir acesso fora da zona de confiança por meio de políticas de bucket, ACLs ou pontos de acesso, o IAM Access Analyzer gera um alerta com detalhes sobre o caminho de acesso. As equipes de segurança podem responder removendo imediatamente o acesso não intencional ou configurando notificações automatizadas via EventBridge para envolver as equipes de desenvolvimento na remediação.
AWS Security Hub
O Security Hub fornece uma visão abrangente dos riscos de segurança potenciais, correlacionando dados de múltiplos serviços de segurança da AWS. Seus alertas identificam quando recursos podem estar vulneráveis à exfiltração de dados, integrando inteligência do GuardDuty (detecção de ameaças), do Amazon Inspector (avaliação de vulnerabilidades), do Security Hub CSPM (conformidade de configuração) e do Amazon Macie (descoberta de dados sensíveis).
Por exemplo, o Security Hub pode identificar quando um bucket S3 exposto publicamente contém dados sensíveis e não está criptografado em repouso, sinalizando-o como risco potencial de exfiltração que requer atenção imediata. O AWS Shield network security director (em prévia) complementa o Security Hub descobrindo e analisando a topologia de rede para identificar recursos com acesso irrestrito à internet de saída, ajudando a detectar pontos cegos de egress em todo o ambiente.
Estratégia de segurança de egress em fases
Não é necessário implementar todos esses controles de uma vez. A AWS sugere uma abordagem em fases que permite construir a postura de segurança de egress de forma incremental, em um ritmo compatível com a maturidade operacional e a tolerância a riscos da organização:
Fase 1 – Ganhos rápidos: habilite o Route 53 DNS Firewall em todas as VPCs para eliminar a lacuna de exfiltração via DNS. Habilite o GuardDuty em todas as contas para detecção básica de ameaças.
Fase 2 – Fundação: implante perímetros de dados em nível organizacional (SCPs, RCPs e políticas de endpoint de VPC). Implante o Network Firewall como firewall acoplado ao Transit Gateway.
Fase 3 – Eficiência: habilite o IAM Access Analyzer para detecção contínua de acesso externo. Implemente remediação automatizada via EventBridge e Lambda para atualizar regras de firewall em tempo real. Centralize os alertas no Security Hub com notificações automatizadas.
Conclusão
A segurança de egress não é um controle único — é uma estratégia em camadas. O ponto de partida é avaliar a postura atual em relação a filtragem de rede, segurança DNS, perímetros de dados e controles detectivos. A partir daí, identificam-se as lacunas e adota-se a abordagem em fases para fechá-las incrementalmente. Testes regulares por meio de simulações de tentativas de exfiltração validam que os controles funcionam efetivamente.
Esses controles se aplicam com igual força a workloads de IA agêntica, onde agentes manipulados podem se tornar vetores não intencionais de exfiltração. Colocar o egress sob controle significa transformar pontos cegos de saída em checkpoints monitorados.
A AWS anunciou uma atualização importante no AWS Network Firewall: a ação stateful padrão para novas políticas de firewall agora é “Application drop established (server-directed only)”, substituindo o comportamento anterior chamado “Application drop established (bidirectional)” — que anteriormente era conhecido como “Application layer drop established”.
A mudança vale automaticamente para todas as políticas criadas a partir de agora. Quem está criando novas políticas não precisa fazer nada para aproveitar o comportamento mais seguro e confiável.
Por que a configuração anterior era problemática
O padrão antigo — o modo bidirecional — tinha um comportamento silencioso e perigoso: ele podia descartar pacotes Protocolo de Controle de Transmissão (TCP) legítimos enviados do servidor para o cliente. Entre os pacotes afetados estavam window updates, keep-alives e resets — elementos essenciais para o controle de fluxo de uma conexão TCP saudável.
O resultado prático era a ocorrência de falhas de conexão intermitentes, difíceis de diagnosticar justamente porque o descarte acontecia de forma silenciosa, sem alertas óbvios. Esse tipo de problema é especialmente frustrante para equipes de operações, pois os sintomas aparecem de forma irregular e sem uma causa aparente.
O que muda com o novo padrão
Com o novo padrão “server-directed only” (somente direcionado pelo servidor), as novas políticas de firewall deixam de bloquear indevidamente pacotes de controle de fluxo legítimos originados no servidor. Isso reduz significativamente o risco de quedas de conexão causadas por esse comportamento.
Para quem está criando políticas novas, a melhoria é automática — nenhuma ação é necessária.
Atenção para ambientes com criptografia pós-quântica
Existe um cenário específico que merece atenção: ambientes que utilizam Criptografia Pós-Quântica (PQC) com handshakes TLS fragmentados podem depender do comportamento bidirecional para funcionar corretamente. Para esses casos, a AWS orienta que os times consultem a documentação oficial e avaliem duas opções:
Migrar para o modo “Application drop established (server-directed only)”; ou
Adicionar a flag to_server nas regras de bloqueio TCP, garantindo que pacotes legítimos de controle de fluxo não sejam bloqueados.
Disponibilidade
A atualização está disponível em todas as regiões da AWS onde o Network Firewall é oferecido. Para entender como funciona a ordem de avaliação das regras compatíveis com Suricata, a AWS recomenda consultar a documentação Gerenciamento da ordem de avaliação para regras compatíveis com Suricata.
A AWS anunciou uma atualização importante no IAM Identity Center (antigo AWS SSO): a partir de agora, as cotas para contas AWS e para aplicações passam a ser gerenciadas de forma independente. Isso pode parecer um detalhe técnico pequeno, mas para organizações que gerenciam centenas ou milhares de contas, essa mudança faz uma diferença real no dia a dia.
Como funcionava antes — e o problema que isso gerava
Antes dessa atualização, as cotas de contas AWS e de aplicações compartilhavam o mesmo pool de capacidade dentro de uma instância do IAM Identity Center. Na prática, isso significava que, ao cadastrar muitas contas AWS, você reduzia o espaço disponível para configurar aplicações — e vice-versa. Para grandes organizações, essa limitação podia criar gargalos indesejados na hora de expandir o ambiente.
O que muda com as cotas separadas
Com a nova configuração, cada instância do IAM Identity Center passa a ter dois limites independentes:
Até 7.000 contas AWS configuradas por padrão
Até 7.000 aplicações configuradas por padrão
Esses limites são completamente independentes. Ou seja, utilizar toda a cota de contas não afeta em nada a cota disponível para aplicações, e o contrário também é verdadeiro. Organizações que gerenciam milhares de contas AWS agora podem integrar novas aplicações sem se preocupar em “roubar” capacidade do outro lado.
Preciso fazer alguma coisa para ativar isso?
Para a maioria dos clientes, nenhuma ação é necessária. Quem já tinha limites elevados concedidos anteriormente pela AWS recebe automaticamente o mesmo limite elevado para ambas as categorias — contas e aplicações — sem precisar abrir nenhuma solicitação.
Caso sua organização precise de cotas ainda maiores do que o padrão de 7.000, é possível solicitar um aumento por meio do Console do Serviço de Cotas da AWS (AWS Service Quotas). O processo segue o fluxo padrão de solicitação de aumento de cota da plataforma.
Disponibilidade
A atualização já está disponível em todas as regiões da AWS onde o IAM Identity Center está presente. Não há necessidade de migração, reconfiguração ou janela de manutenção para aproveitar o novo comportamento.
A AWS publicou um tutorial completo sobre como executar workflows do ComfyUI em jobs de processamento do Amazon SageMaker AI para automatizar a criação de conteúdo visual em grande escala. A proposta é direta: transformar o que antes levava dias de trabalho de um time criativo em um processo que termina em menos de uma hora.
Para empresas que dependem de ativos de marketing — posts para redes sociais, peças publicitárias, vídeos curtos —, atrasos na produção criativa se traduzem diretamente em receita perdida. A solução descrita pela AWS permite gerar centenas de imagens prontas para uso em campanhas globais, voiceovers personalizados para múltiplos idiomas e clipes de vídeo com roteiros gerados por IA, tudo dentro das diretrizes de marca da empresa.
Por que combinar ComfyUI com SageMaker AI?
O ComfyUI é um construtor visual de workflows baseado em nós para IA generativa. Ele permite compor, testar e iterar sobre pipelines complexos de imagem, áudio e vídeo sem precisar codificar cada etapa do processo. Os componentes modulares se conectam em um grafo reproduzível que pode ser versionado e compartilhado entre equipes.
Ao trazer o ComfyUI para jobs de processamento do SageMaker AI, a arquitetura ganha vantagens concretas:
Velocidade com GPU: instâncias aceleradas por GPU entregam tempos de inferência rápidos.
Custo sob demanda: cobrança por segundo com encerramento automático do job — você paga apenas pelo que usar.
Escalabilidade natural: a arquitetura baseada em fila processa múltiplas requisições em paralelo sem intervenção manual.
Portabilidade: qualquer workflow do ComfyUI exportado em formato JSON pode ser implantado nessa estrutura.
O modelo Z-Image Turbo
Para a geração de imagens, a solução utiliza o Z-Image Turbo, um modelo de difusão texto-para-imagem que apresenta uma arquitetura chamada Transformador de Fluxo Único Escalável (S3DiT — Scalable Single-Stream Diffusion Transformer).
O diferencial técnico do Z-Image está na sua abordagem de fusão antecipada (Early Fusion): os tokens de texto e de imagem são concatenados em uma única sequência unificada, permitindo interação densa entre as modalidades em cada camada do modelo. Isso significa que o Transformador trata tokens de texto, tokens latentes de imagem e tokens semânticos de imagem de forma uniforme, maximizando o compartilhamento de parâmetros entre as modalidades.
O backbone do modelo é um Transformador decoder-only, inspirado nos decoders de Grandes Modelos de Linguagem (LLMs — Large Language Models), com 30 camadas, dimensão oculta de 3840, 32 cabeças de atenção, dimensões intermediárias de rede feed-forward de 10240 e um total de 6 bilhões de parâmetros. O workflow do ComfyUI para o Z-Image Turbo já vem armazenado no container do job de processamento e pode ser substituído por qualquer outro workflow personalizado — desde que os modelos necessários estejam baixados, os nós customizados instalados no container e a instância tenha VRAM suficiente.
Outros casos de uso
Embora o exemplo central seja geração de imagens, o motor de workflows do ComfyUI pode escalar diferentes tarefas criativas com IA. Alguns casos de uso adicionais citados pela AWS incluem:
Testes A/B de criativos publicitários em escala: produção automática de centenas de variações de anúncios, carrosséis para redes sociais e clipes de vídeo para campanhas globais.
Design de embalagens para lançamentos internacionais: geração de designs específicos por localidade, adaptando cores, imagens e textos para estética, regulamentações ou datas comemorativas regionais.
Narrativas de vídeo interativas para games e entretenimento: criação de narrativas de vídeo ramificadas onde a IA gera cenas dinâmicas que mudam com base nas escolhas do usuário.
Implementa a camada de armazenamento usando buckets do Amazon S3 com criptografia server-side. O bucket de saída armazena as imagens geradas pelos workflows do ComfyUI.
SecurityStack
Estabelece a infraestrutura de segurança para toda a solução. Cria uma Nuvem Privada Virtual da Amazon (Amazon VPC) com sub-redes públicas e privadas em duas Zonas de Disponibilidade para alta disponibilidade e isolamento de rede. A VPC inclui um gateway NAT para acesso seguro à internet a partir das sub-redes privadas onde os jobs do SageMaker AI são executados.
Uma chave gerenciada pelo cliente do Serviço de Gerenciamento de Chaves da AWS (AWS KMS) fornece criptografia em repouso para dados nos buckets do S3, logs do Amazon CloudWatch e variáveis de ambiente — com rotação automática habilitada. Os logs de fluxo da VPC são enviados ao CloudWatch para monitoramento de tráfego de rede.
ComfyUISmStack
Orquestra o pipeline central de processamento por meio de uma função AWS Lambda que dispara os jobs de processamento do SageMaker AI. A função Lambda pode ser invocada manualmente para iniciar o processamento com GPU usando instâncias ml.g5.xlarge rodando um container Docker personalizado. Esse container empacota o ComfyUI com o modelo Z-Image Turbo, oferecendo geração de imagens de alta qualidade com parâmetros configuráveis para prompts, seeds e processamento em batch.
A stack cria um construct reutilizável de job de processamento que cuida de:
Criação de papéis de Gerenciamento de Identidade e Acesso (IAM — Identity and Access Management) com permissões abrangentes para SageMaker AI, S3, ECR, VPC e CloudWatch.
Definição do job de processamento com integração à VPC, criptografia via AWS KMS e isolamento de rede.
Configuração da função Lambda com variáveis de ambiente contendo a configuração completa do job.
Fluxo de processamento
O processo começa quando a função Lambda é acionada. Ela cria o job de processamento e o envia ao SageMaker AI, que provisiona uma instância GPU dentro da rede privada, puxa a imagem do container ComfyUI do registry e a implanta com as configurações de armazenamento e rede necessárias.
Após o container estar em execução, o servidor ComfyUI:
Baixa os componentes do modelo de IA do HuggingFace via conexão segura de saída.
Organiza os componentes nos diretórios correspondentes.
Carrega os modelos na memória GPU e aguarda a inicialização completa.
Com o servidor pronto, o sistema lê os prompts de texto de um arquivo e os processa em batches. Para cada imagem, seleciona um prompt com base em um valor de seed único, preenche o template do workflow com o prompt e o seed, e envia a requisição ao ComfyUI para processamento.
As imagens geradas são gravadas em um diretório de saída e sincronizadas com o Amazon S3 em tempo real — os resultados ficam disponíveis antes mesmo do job terminar. Os logs do container são transmitidos ao CloudWatch para monitoramento. Após todos os batches serem processados, um loop de polling verifica a fila a cada 15 segundos até que todas as requisições sejam concluídas. Quando a fila esvazia, o servidor é encerrado, o container sai e o SageMaker AI termina a instância automaticamente.
Crie o arquivo de ambiente a partir do template de exemplo:
cp .env.example .env
Edite o arquivo .env com os dados da sua conta AWS:
AWS_ACCOUNT_ID=your-account-id
REGION=us-east-1
3. Instalar dependências
O projeto usa uv para gerenciamento de dependências:
# Instale o uv se ainda não tiver
curl -LsSf https://astral.sh/uv/install.sh | sh
# Crie o ambiente
uv venv --python 3.13
# Ative o ambiente
source .venv/bin/activate
# Instale as dependências
uv sync
Alternativamente, usando pip:
pip install -r requirements.txt
4. Bootstrap do AWS CDK
cdk bootstrap aws://YOUR-ACCOUNT-ID/YOUR-REGION
Exemplo:
cdk bootstrap aws://123456789012/us-east-1
5. Solicitar aumento de cota de serviço
Solicite um aumento de cota para seis instâncias ml.g5.xlarge em jobs de processamento do SageMaker AI pelo Console de Gerenciamento da AWS.
6. Configuração
A configuração do job de processamento é definida em config/config.yaml:
Tipo de instância: ml.g5.xlarge (com GPU)
Quantidade de instâncias: 6
Tamanho do volume: 125 GB
Container: imagem Docker personalizada do ComfyUI
7. Implantar as stacks
cdk deploy --all --require-approval never
Atenção: a partir desse comando, custos começam a ser gerados na sua conta AWS.
8. Acionar o job de processamento
Após a implantação, acione os jobs pelo nome da função Lambda criada pelo AWS CDK:
Ao ser invocada, a função Lambda gera um nome único para o job com timestamp, cria o job de processamento no SageMaker AI com a configuração predefinida e provisiona seis instâncias GPU ml.g5.xlarge.
Limpeza de recursos
Para evitar cobranças contínuas, siga os passos abaixo após os testes:
A solução descrita pela AWS demonstra como é possível automatizar a geração de conteúdo com IA em escala combinando o ComfyUI com a infraestrutura gerenciada de GPU do SageMaker AI. O modelo Z-Image Turbo com 6 bilhões de parâmetros entrega imagens fotorrealistas mantendo os custos de inferência baixos, enquanto o AWS CDK implanta toda a infraestrutura com segurança, criptografia e isolamento de rede já integrados desde o início.
Com cobrança por segundo e encerramento automático das instâncias, as empresas pagam apenas pelo processamento efetivamente consumido. O código completo da solução está disponível no repositório no GitHub, e a documentação oficial pode ser consultada na documentação do SageMaker AI.
A semana foi dominada por segurança em camadas e IA operacional na AWS. Do lado da segurança, três frentes se destacam: bloqueio de acesso ao Console por rede via RCPs, alerta ativo sobre sequestro de subdomínios DNS e o novo Console Private Access para ambientes sem internet. Na frente de IA, a AWS avança em agentes autônomos com Kiro CLI para resposta a incidentes, Bedrock Guardrails com verificações granulares e DevOps Agent gerenciando releases. O padrão claro: IA agêntica está chegando à produção, e a infraestrutura de segurança precisa acompanhar esse ritmo.
O que muda na prática
RCPs no AWS Sign-in permitem bloquear acesso ao Console por rede e organização — controle que antes exigia soluções externas agora é nativo e aplicável em toda a org
Agentes de IA ganham controles de segurança programáticos via Bedrock Guardrails InvokeGuardrailChecks, mudando como times de plataforma governam aplicações agênticas em produção
Relatórios SOC 1 e 2 da AWS disponíveis em OSCAL legível por máquina, abrindo caminho para automatizar auditorias e eliminar revisão manual de conformidade
Ações da semana
Audite seus registros DNS na AWS esta semana: identifique CNAMEs apontando para recursos desativados usando o guia do AWS CIRT antes que alguém explore esse vetor
Se sua organização usa AWS Organizations, habilite RCPs no AWS Sign-in para restringir acesso ao Console por rede — é configuração de uma tarde com impacto imediato na postura de segurança
Permite aplicar verificações de segurança em qualquer etapa de um agente sem criar recursos de guardrail, com pontuações numéricas para decisões programáticas.
Para quem: Desenvolvedores e arquitetos construindo aplicações de IA agêntica que precisam de controles de segurança flexíveis.
A AWS anunciou a disponibilidade do Adobe Marketing Agent para o Amazon Quick, uma combinação que promete transformar a forma como equipes de marketing acessam dados de campanha. Em vez de navegar por dashboards complexos, os profissionais de marketing passam a fazer perguntas em linguagem natural — e recebem respostas estruturadas com tabelas, gráficos e recomendações em segundos.
A divisão de responsabilidades é clara: o Amazon Quick cuida da experiência de chat e da orquestração das ações, enquanto o Adobe Marketing Agent fornece a análise especializada em marketing, consultando fontes de dados autorizadas da Adobe. A ponte entre os dois é o Protocolo de Contexto de Modelo (MCP), que permite ao Amazon Quick descobrir as ferramentas expostas pelo servidor Adobe e registrá-las como ações disponíveis para o agente.
O que o Adobe Marketing Agent consegue fazer
As ferramentas expostas pelo Adobe Marketing Agent cobrem cinco grandes áreas de análise para equipes de marketing:
Revisão e monitoramento de campanhas: visualização de métricas que alimentam fluxos de acompanhamento de campanhas ativas.
Planejamento de campanhas: acesso a insights de alcance e histórico de desempenho para embasar decisões futuras.
Insights de audiência: tamanho de perfis, audiências com alta variação, sobreposição entre segmentos e atributos para ampliar o alcance.
Insights de jornada: monitoramento de jornadas existentes e identificação de oportunidades de correção de rota.
Análise de conflitos de jornada: detecção rápida de conflitos entre jornadas antes do lançamento, evitando experiências contraditórias para o cliente.
Como funciona o fluxo de ponta a ponta
O fluxo de uma pergunta até a resposta segue quatro etapas principais. Um profissional de marketing faz uma pergunta no Amazon Quick. O agente de chat seleciona a ação aprovada correspondente na integração com o Adobe Marketing Agent. O servidor MCP valida a requisição e consulta os dados autorizados da Adobe. Por fim, o Amazon Quick renderiza a resposta no formato mais adequado — texto, tabela, gráfico ou recomendação.
Controles de governança são aplicados em todo o fluxo: privilégio mínimo, isolamento de tenant, registro de auditoria, versionamento de esquema e revisão humana para decisões de lançamento.
Pré-requisitos para a configuração
Antes de começar a configuração, é necessário garantir que alguns requisitos estejam atendidos tanto no lado da AWS quanto no lado da Adobe:
Acesso ao Amazon Quick, à organização Adobe, ao provedor de identidade e ao endpoint MCP do Adobe Marketing Agent fornecido pela Adobe.
Assinatura Enterprise do Amazon Quick com permissões para criar, revisar, compartilhar e gerenciar integrações e agentes de chat.
Licença de um ou mais produtos Adobe CX Enterprise: Adobe Real-Time CDP, Adobe Customer Journey Analytics ou Adobe Journey Optimizer.
Um plano de governança para a integração MCP, cobrindo: autenticação de usuário ou serviço, permissões de compartilhamento do agente de chat, controle de acesso ao Adobe Experience Platform por tenant, marca e sandbox, logs de auditoria de invocação de ferramentas MCP, revisão humana para recomendações que impactam lançamentos, e regras de retenção para metadados de requisições MCP e artefatos gerados.
O tempo estimado de configuração é de 45 a 60 minutos após o endpoint MCP, as credenciais e os usuários piloto estarem prontos. Os custos dependem da assinatura do Amazon Quick, do licenciamento Adobe e da infraestrutura que hospeda o servidor MCP.
Implementação passo a passo
Passo 1: Conectar o Adobe Marketing Agent ao Amazon Quick
O Adobe Marketing Agent aparece como um tile de conector com marca própria no console de Integrações do Amazon Quick. Para criar a integração, acesse o console do Amazon Quick, vá em Connectors e escolha Create for your team. Selecione o Adobe Marketing Agent, informe um nome descritivo e, opcionalmente, uma descrição do fluxo de trabalho. Para o tipo de conexão, selecione Public network. Para a configuração de autenticação, selecione Default OAuth app — com o conector de marca própria, o Amazon Quick indica que nenhuma credencial adicional é necessária. Clique em Next.
Na página de gerenciamento de ferramentas e permissões, revise os padrões de nível de acesso. Para o piloto inicial, configure como Always ask para que cada ação exija aprovação explícita do usuário antes de ser executada. Expanda as seções de operações de escrita e leitura para revisar as ações disponíveis. Mantenha as operações de escrita como Always ask durante o piloto e use as operações de leitura para os prompts de validação nas etapas seguintes.
Na página de publicação, defina quem pode acessar a conexão. Mantenha a opção Everyone in your organization desativada até que o conector seja aprovado para uso amplo. Em Specific groups, adicione o time ou grupo que deve usar a conexão e clique em Publish. A janela de autorização da Adobe será aberta automaticamente. Revise os acessos solicitados — que incluem informações básicas de perfil, endereço de e-mail, dados da organização Adobe e dados do Adobe Experience Platform — e clique em Allow Access para concluir. Para detalhes sobre permissões de usuário e acesso a sandboxes no lado da Adobe, consulte a visão geral de controle de acesso.
Passo 2: Criar o agente de chat de planejamento de campanhas
A recomendação é criar um agente focado em vez de um assistente de marketing genérico. Um agente com escopo reduzido é mais fácil de testar, explicar e governar. Navegue até Chat agents, clique em Create chat agent e adicione o nome Adobe Marketing Agent com uma descrição curta para o fluxo piloto. Na seção de ações, escolha Link existing integration e selecione as ações do Adobe Marketing Agent criadas no passo anterior.
As instruções do agente devem orientá-lo a responder de forma concisa e operacional, sem adivinhar respostas e usando apenas a saída das ferramentas como evidência. Se informações estiverem faltando, o agente deve solicitar a campanha, audiência, período, região ou canal. O formato de resposta padrão sugerido inclui: resumo, dados utilizados, observações principais e recomendações para revisão humana. As regras de roteamento de ferramentas devem mapear perguntas sobre tamanho de audiência para o ranking de audiências, sobre segmentos de fidelidade para o resumo de segmentos de lealdade, sobre jornadas para a consulta de uso de jornadas, sobre sobreposições e conflitos de timing para a análise de conflitos de campanha, e sobre desempenho de conteúdo para o resumo de efetividade de conteúdo. O agente não deve criar ou modificar objetos de campanha sem solicitação explícita do usuário, e nunca deve incluir dados pessoais identificáveis ou tokens de acesso nas respostas.
Passo 3 ao 7: Validar o fluxo com prompts de leitura
Com o agente configurado, o processo de validação passa por cinco verificações progressivas usando prompts somente de leitura:
Ranking de audiências: o prompt “Show the top 10 audiences by total profiles” deve retornar um gráfico de barras com as principais audiências e insights gerados automaticamente.
Segmentos de fidelidade: o prompt “Show the top loyalty audiences and group them by attribute type” valida se o agente reutiliza o contexto da conversa e explica premissas de sobreposição quando contagens somadas podem superestimar o alcance único.
Jornadas com audiências de fidelidade: o prompt “Which journeys use loyalty audiences?” deve retornar uma tabela com as jornadas que referenciam audiências de fidelidade, incluindo o atributo de lealdade utilizado e padrões gerados — útil para identificar reutilização de audiências e potenciais interações de campanha antes do lançamento.
Revisão de conflitos pré-lançamento: o prompt “Summarize conflicts I should review before launch” deve retornar um resumo de conflitos com nível de risco, sobreposição de audiência, observações principais e recomendações de coordenação. O resultado deve ser tratado como consultivo — as decisões de lançamento continuam sendo responsabilidade do processo de aprovação da organização.
Após os prompts de validação atenderem aos critérios de aceitação, o agente pode ser lançado e compartilhado com os usuários ou grupos piloto aprovados. Para instruções detalhadas, consulte a documentação de agentes de chat personalizados.
Segurança e governança
Antes de lançar ou compartilhar o agente de chat, é importante revisar os controles que protegem o acesso aos dados da Adobe, o uso das ferramentas e as decisões de lançamento de campanhas.
Durante a configuração inicial, use a página de gerenciamento de ferramentas e permissões para revisar as operações de leitura e escrita descobertas. Para o piloto, ative apenas as ações de leitura necessárias para validação e mantenha as ações de escrita desativadas ou configuradas como Always ask até que os processos de aprovação e reversão estejam testados.
Se a Adobe fornecer um endpoint privado do servidor MCP para a organização, o Amazon Quick oferece suporte a conectividade por Nuvem Privada Virtual (VPC) para conexões MCP. Durante a configuração do MCP, selecione a conexão VPC configurada e confirme que o servidor MCP é acessível a partir da VPC. Se o servidor MCP usar OAuth, os endpoints de OAuth ainda precisam ser acessíveis pela internet pública.
Use as permissões e o controle de acesso por sandbox da Adobe para impor fronteiras por usuário, tenant, marca, região e unidade de negócio. Configure o acesso na Adobe para que o servidor MCP retorne apenas os campos necessários para a tarefa de marketing. Para mais informações, consulte a visão geral de controle de acesso e a visão geral de sandboxes.
Exija aprovação humana para recomendações que afetem lançamento de campanhas, segmentação, supressão de audiência, personalização ou mensagens ao cliente. Para capturar conversas de chat, feedback de usuários, uso de agentes e armazenamento de índice, configure o monitoramento de uso do Amazon Quick com CloudWatch Logs. Os logs podem ser entregues ao Amazon CloudWatch Logs, ao Amazon Simple Storage Service (Amazon S3) ou ao Amazon Data Firehose. Retenha os logs conforme a política da organização e nunca registre identificadores de perfil brutos, dados pessoais identificáveis, tokens de acesso ou metadados restritos da Adobe.
Limpeza de recursos após o piloto
Ao encerrar o piloto, é recomendável remover ou desabilitar os recursos criados para evitar ruído operacional e acesso indevido a ferramentas que não estão mais sob revisão. As etapas incluem: desabilitar ou remover as ações do Adobe Marketing Agent do agente de chat piloto; cancelar o compartilhamento do agente e da integração com os usuários e grupos piloto; excluir a integração MCP se o endpoint do Adobe Marketing Agent não for mais necessário; revogar clientes OAuth, credenciais de serviço, tokens bearer ou credenciais de teste criados para o piloto; remover usuários piloto de funções, marcas, tenants ou unidades de negócio criados exclusivamente para testes; e reter logs apenas pelo período exigido pela política de segurança e conformidade da organização.
Conclusão
A integração entre o Adobe Marketing Agent e o Amazon Quick via MCP representa uma abordagem prática para democratizar o acesso a dados de campanha dentro de equipes de marketing. O Amazon Quick fornece o espaço de trabalho conversacional e a orquestração de ações, enquanto o Adobe Marketing Agent entrega análise especializada em marketing para audiências, jornadas, conflitos de campanha e efetividade de conteúdo. O MCP atua como a camada de integração que permite ao Amazon Quick descobrir as ferramentas da Adobe e chamá-las como ações.
Agentes de Inteligência Artificial (IA) estão transformando a forma como organizações buscam e agem sobre informações. Porém, todos eles compartilham uma limitação estrutural: o conhecimento deles está congelado no momento do treinamento. Se você perguntar a um agente sobre a cotação atual de uma ação, o placar de um jogo de ontem ou o lançamento de uma biblioteca que aconteceu há uma hora, ele simplesmente não consegue responder com precisão.
Para endereçar exatamente essa lacuna, a AWS anunciou a disponibilidade geral do Amazon Bedrock AgentCore Web Search — uma capacidade de busca web totalmente gerenciada e compatível com o Protocolo de Contexto de Modelo (MCP, do inglês Model Context Protocol). Ela permite que agentes obtenham informações atualizadas da web sem qualquer sobrecarga de infraestrutura.
O recurso está disponível como um target ou conector gerenciado que se conecta ao seu AgentCore Gateway. Os agentes o descobrem com uma chamada padrão tools/list e o invocam como qualquer outra ferramenta MCP. Não há APIs de busca para provisionar, credenciais de saída para gerenciar nem lógica de parsing de resultados para manter.
