A AWS anunciou que o Serviço de Contêiner Elástico da Amazon (Amazon ECS) passou a suportar agendamento fracionado de GPU com as instâncias Amazon EC2 G6f. Com isso, é possível executar cargas de trabalho em frações de uma GPU NVIDIA L4 Tensor Core — chegando a apenas um oitavo da GPU, com 3 GB de memória dedicada.
Por que isso importa
Nem toda carga de trabalho precisa de uma GPU inteira. Inferência de modelos de IA de menor porte, experimentação de modelos, renderização gráfica e outros cenários similares frequentemente não justificam o custo de provisionar uma instância GPU completa. Com o suporte a GPUs fracionadas, equipes podem dimensionar os contêineres de forma mais precisa, reduzindo custos de infraestrutura sem abrir mão do poder de processamento acelerado.
Como configurar
A configuração é feita diretamente na definição de tarefa do Amazon ECS. Para solicitar uma fração de GPU, basta definir um dos seguintes valores no campo correspondente da definição de contêiner:
GPU=0.125 — um oitavo da GPU
GPU=0.25 — um quarto da GPU
GPU=0.5 — metade da GPU
O Amazon ECS se encarrega de posicionar a tarefa em uma instância G6f que atenda à solicitação. O recurso é compatível tanto com o Amazon ECS em EC2 quanto com as ECS Managed Instances.
Vantagens das ECS Managed Instances
Para quem opta pelas ECS Managed Instances, a experiência é totalmente gerenciada: o ECS cuida automaticamente do provisionamento, escalabilidade, aplicação de patches e gerenciamento do ciclo de vida das instâncias. Isso permite que as equipes se concentrem nas cargas de trabalho de GPU, sem se preocupar com operações de infraestrutura.
Além disso, as ECS Managed Instances oferecem funcionalidades específicas para cargas de trabalho aceleradas, como métricas de GPU via Amazon CloudWatch Container Insights e monitoramento automático de saúde capaz de detectar falhas de hardware na GPU e substituir instâncias com problema — minimizando interrupções nas cargas de trabalho.
Disponibilidade
O recurso está disponível em todas as regiões da AWS onde as instâncias Amazon EC2 G6f já estão presentes. Para começar, é possível usar o Console de Gerenciamento da AWS, AWS CLI, AWS SDKs, AWS CloudFormation ou outras ferramentas de infraestrutura como código para configurar um provedor de capacidade com instâncias G6f e especificar o valor fracionado de GPU na definição de contêiner da task definition do ECS.
Gerenciar certificados TLS em escala é uma das maiores dores operacionais de times de infraestrutura. E esse cenário está prestes a ficar ainda mais exigente: o Fórum CA/Browser (CA/Browser Forum) determinou uma redução progressiva na validade máxima dos certificados públicos. Em março de 2027, o limite cai para 100 dias. Em março de 2029, chega a apenas 47 dias.
Para ter uma ideia do impacto: uma organização que gerencia 1.000 certificados precisará lidar com cerca de 30 eventos de renovação por dia quando a janela de 47 dias entrar em vigor. Processos manuais ou fluxos baseados em tickets simplesmente não são capazes de sustentar essa cadência.
Foi nesse contexto que a AWS anunciou o suporte ao protocolo ACME (Ambiente de Gerenciamento Automatizado de Certificados) no AWS Certificate Manager (ACM). A novidade permite que equipes utilizem clientes ACME já conhecidos — como certbot, cert-manager, acme.sh e win-acme — para automatizar a emissão e renovação de certificados públicos em qualquer infraestrutura.
O que é o ACME e por que ele importa
O ACME é um protocolo de código aberto que automatiza a verificação de propriedade de domínio e a emissão de certificados. Ele se tornou o mecanismo padrão para automação de certificados no setor.
O ACM já oferecia emissão e renovação gerenciadas de certificados para serviços integrados da AWS, como Elastic Load Balancing (ELB), Amazon CloudFront e Amazon API Gateway. Mas muitos clientes também precisam automatizar certificados para infraestruturas próprias — servidores em data centers, clusters Kubernetes, frotas de Internet das Coisas (IoT) e ambientes híbridos. Até agora, esses cenários exigiam recorrer a provedores externos. Com o suporte ACME, o ACM passa a atender também essa demanda, usando o protocolo padrão com endpoints gerenciados pela AWS.
Como a arquitetura funciona
O recurso introduz um novo tipo de recurso gerenciado centralmente: o endpoint ACME. Cada endpoint é um recurso AWS com uma URL de diretório ACME exclusiva e controles de acesso baseados no AWS Identity and Access Management (IAM). Os endpoints são criados e gerenciados via API do ACM ou pelo Console de Gerenciamento da AWS.
A arquitetura se divide em dois planos:
Plano de controle: administradores de Infraestrutura de Chave Pública (PKI) usam as APIs do ACM para criar endpoints ACME, pré-aprovar os domínios que cada endpoint pode emitir certificados e gerar credenciais de Vinculação de Conta Externa (EAB).
Plano de dados: clientes ACME se registram em um endpoint usando credenciais EAB e solicitam certificados para domínios que o administrador já validou. Assim, os proprietários de aplicações não precisam de credenciais DNS para obter um certificado.
As credenciais EAB controlam o acesso dos clientes aos endpoints. Cada EAB está vinculado a uma função (role) do IAM que define quais operações o cliente ACME pode realizar. Um cliente autorizado para um endpoint de desenvolvimento, por exemplo, não consegue obter certificados do endpoint de produção — o que cria fronteiras de segurança claras entre ambientes.
Os certificados emitidos por ACME são automaticamente registrados no inventário do ACM, aparecendo junto com certificados criados pelas APIs RequestCertificate e ImportCertificate. O Amazon EventBridge e o AWS CloudTrail fornecem alertas de expiração e logs de auditoria.
Antes que os clientes ACME possam solicitar certificados, o administrador valida o domínio via DNS uma única vez, no nível do endpoint. O parâmetro DomainScope controla exatamente quais padrões de certificado são permitidos:
ExactDomain habilitado: restringe ao nome exato do domínio
Subdomains habilitado: permite nomes como api.example.com
Wildcards habilitado: permite *.example.com
Para um endpoint de produção, a recomendação é habilitar apenas ExactDomain e Subdomains, deixando Wildcards desabilitado para uma postura mais restritiva.
Se o domínio estiver hospedado no Route 53, o parâmetro HostedZoneId permite que o ACM crie o registro CNAME automaticamente. Para outros provedores de DNS, omita esse parâmetro e crie o registro manualmente. A validação normalmente é concluída em poucos segundos após o registro estar no lugar.
Passo 3: Gerar credenciais EAB
As credenciais EAB autenticam os clientes ACME no endpoint. O ideal é gerar um conjunto exclusivo de credenciais para cada cliente ou ambiente.
Após o registro inicial, o cliente ACME passa a gerenciar as renovações automaticamente.
Controles empresariais e boas práticas
Validação de domínio granular
Para cada domínio validado, é possível definir exatamente quais padrões de certificado são permitidos — ExactDomain, Subdomains ou Wildcards. Essa aplicação acontece no nível do endpoint, antes que as requisições cheguem à autoridade certificadora do ACM. Múltiplos domínios podem ser validados em um único endpoint, cada um com seu próprio escopo.
Visibilidade centralizada de certificados
Todos os certificados emitidos pelos endpoints ACME são registrados no ACM. O comando aws acm list-certificates exibe o inventário completo. As operações de gerenciamento de endpoints são autorizadas via IAM e registradas no CloudTrail, permitindo auditoria detalhada de quem criou endpoints, gerou credenciais EAB e gerenciou restrições de domínio.
Segmentação de endpoints por ambiente
A recomendação da AWS é segmentar endpoints por fronteiras organizacionais ou de ambiente. Um ponto de partida razoável é criar um endpoint por ambiente (dev, staging e produção) dentro de uma unidade de negócio, expandindo para endpoints por unidade de negócio apenas quando requisitos de conformidade ou organizacionais exigirem. Credenciais comprometidas em um ambiente não têm caminho para certificados de outro.
Gerenciamento seguro de credenciais EAB
Qualquer pessoa que possua um KeyId e MacKey válidos pode obter certificados para qualquer domínio pré-aprovado no endpoint — portanto, essas credenciais merecem o mesmo cuidado dado a chaves de acesso. A AWS recomenda evitar codificar o MacKey diretamente no código, usando um cofre de segredos como o AWS Secrets Manager. Também é importante criar uma função (role) IAM por EAB, em vez de compartilhar uma única role entre todos os bindings, e configurar o tempo de expiração do EAB de acordo com o perfil de risco da organização.
No CloudTrail, vale monitorar separadamente as chamadas CreateAcmeExternalAccountBinding e GetAcmeExternalAccountBindingCredentials — alertar sobre eventos de recuperação das credenciais é um sinal mais forte de distribuição real do que apenas a criação do binding.
Automação do ciclo de vida dos EABs
Para escalar com múltiplos endpoints, algumas práticas ajudam a reduzir o esforço operacional:
Nomeie cada EAB e sua role IAM vinculada com o nome do cliente ao qual pertence (time, aplicação, ambiente)
Armazene o KeyId e o MacKey de cada cliente em um caminho de segredos específico (por exemplo, um caminho no Secrets Manager por time e ambiente)
No Kubernetes, use um ClusterIssuer ou Issuer com escopo de namespace por EAB, em vez de um issuer compartilhado entre times
Para infraestrutura efêmera (agentes de build, frotas com autoescalamento), provisione credenciais EAB como parte do pipeline de Integração e Entrega Contínuas (CI/CD), para que o ciclo de vida das credenciais acompanhe o da infraestrutura
Monitoramento contínuo
Com certificados de 47 dias de validade, uma falha silenciosa de renovação deixa muito menos tempo de reação do que as janelas longas às quais os times estavam acostumados. Por isso, a AWS recomenda configurar alarmes para falhas de emissão — não apenas para sucessos — e testar a automação de renovação em um endpoint de não-produção antes de depender dela em produção.
Disponibilidade e preços
O suporte ao ACME no AWS Certificate Manager está disponível hoje em todas as regiões comerciais da AWS. A disponibilidade para AWS GovCloud (EUA), Regiões da China e AWS European Sovereign Cloud será anunciada em momento posterior. Consulte a página de preços do ACM para informações sobre os valores cobrados pelo recurso ACME.
Conclusão
A redução progressiva na validade dos certificados é um problema que não tem solução sem automação. O suporte ao ACME no ACM oferece essa automação por meio de um protocolo e ferramentas já padronizados no mercado, mantendo a visibilidade e os controles de governança que os times de segurança esperam do ACM. Para começar, consulte a documentação do AWS Certificate Manager ou siga o guia de introdução.
A AWS anunciou a disponibilidade das instâncias Amazon EC2 G7 na região Europa (Espanha). Equipadas com GPUs NVIDIA RTX PRO 4500 Blackwell Server Edition, essas instâncias chegam com ganhos expressivos de desempenho em relação à geração anterior — até 4,6x mais performance em inferência de Inteligência Artificial (IA) e até 2,1x mais desempenho gráfico em comparação com as instâncias G6.
Para que servem as instâncias G7?
As instâncias G7 são projetadas para cobrir uma ampla gama de cargas de trabalho modernas que exigem poder computacional de GPU. Entre os principais casos de uso destacados pela AWS estão:
Inferência de modelos de IA: tradução de idiomas, análise de vídeo e imagem, e reconhecimento de fala.
Workloads gráficos: criação e renderização de gráficos em tempo real com qualidade cinematográfica, além de streaming de jogos.
Computação espacial e transcodificação de vídeo.
Análise de dados acelerada por GPU: sistemas de recomendação, inferência com Geração Aumentada por Recuperação (RAG) e pipelines de dados em tempo real.
Especificações técnicas
Do ponto de vista de hardware, as instâncias G7 entregam uma configuração robusta:
Até 8 GPUs NVIDIA RTX PRO 4500 Blackwell Server Edition, com 32 GB de memória por GPU.
Processadores Intel Xeon 6 customizados.
Suporte a até 192 CPUs virtuais (vCPUs).
Até 700 Gbps de largura de banda de rede com Adaptador de Malha Elástica (EFA — Elastic Fabric Adapter).
Até 768 GiB de memória de sistema.
Até 7,6 TB de armazenamento local NVMe SSD.
Disponibilidade e formas de aquisição
As instâncias EC2 G7 já estão disponíveis em quatro regiões AWS:
Os modelos de IA estão evoluindo em ritmo acelerado. Cada nova geração traz janelas de contexto maiores, raciocínio mais sofisticado e custos menores por token. Nesse cenário, a AWS entende que a segurança mais eficaz virá de ferramentas que combinem os modelos mais avançados com um conhecimento profundo do ambiente específico de cada cliente.
É com essa premissa que a AWS anunciou a AWS Continuum para vulnerabilidades de código (Preview) — e agora vai além, revelando parcerias com a Anthropic e a OpenAI para levar o Continuum diretamente para dentro dos ambientes onde o código está sendo escrito: Claude Code, OpenAI Codex e Kiro.
O desafio por trás da evolução dos modelos
Os modelos de fronteira mais recentes já conseguem identificar vulnerabilidades e rastrear caminhos de ataque em múltiplas etapas — algo que levaria semanas para uma equipe de segurança humana fazer manualmente. Isso representa um avanço real na detecção. Mas cria um novo problema: mais achados, mais complexidade e a necessidade de determinar quais realmente importam para aquele ambiente específico.
O próximo desafio é construir a orquestração correta para transformar esses modelos em uma interface única que vá da detecção até a correção. Foi exatamente isso que a AWS se propôs a fazer ao criar o Continuum: reunir diferentes modelos e usar o mais eficaz para cada etapa do processo.
A AWS também participa do Frontier Model Forum, um consórcio da indústria que desenvolve padrões de segurança compartilhados, métodos de avaliação e benchmarks para garantir que os modelos possam ser avaliados de forma eficaz. Além disso, a empresa trabalha com os provedores de modelos em benchmarks de desempenho de segurança para assegurar que o melhor modelo seja usado para cada tarefa dentro do Continuum e de outros produtos de segurança da AWS.
O conceito de “harness”: o motor e tudo ao redor
Para entender o Continuum, é importante compreender o que a AWS chama de harness — a camada de orquestração que envolve um modelo para conectá-lo a ferramentas, guardrails, memória e fluxos de trabalho, transformando-o em resultados concretos. A analogia usada pela própria AWS é direta: o modelo é o motor; o harness é tudo ao redor. Você precisa dos dois para ter um carro de alto desempenho.
Esses harnesses estão ficando cada vez mais complexos. As equipes estão costurando múltiplos modelos, agentes que chamam outros agentes e fluxos de trabalho dinâmicos — tudo isso em um cenário de mudanças constantes. Esse nível de complexidade faz com que muitas organizações criem infraestruturas paralelas e não oficiais para gerenciar as camadas de integração entre modelos e ferramentas. Cada vez que o ecossistema muda, os controles de segurança e governança potencialmente quebram, forçando as equipes a revisitá-los.
A AWS posiciona o gerenciamento dessa complexidade como um peso que ela mesma deve resolver. A empresa trata o harness como infraestrutura, aplicando o mesmo rigor usado em identidade, descoberta, aplicação de políticas, observabilidade e conformidade na infraestrutura central da AWS.
Como o AWS Continuum funciona na prática
O AWS Continuum para vulnerabilidades de código descobre vulnerabilidades, prioriza-as dentro do contexto do negócio do cliente, valida-as em um ambiente isolado (sandbox) e oferece correção em velocidade de máquina.
Por baixo dos panos, o Continuum opera com uma arquitetura de loop de equipe de agentes — um harness sofisticado que orquestra tudo: seleção do modelo adequado, conexão com o ambiente do cliente e entrega de código seguro validado em contexto. O desenvolvedor não precisa se preocupar com como a orquestração funciona ou o que mudou na última versão.
A integração com Anthropic e OpenAI
A AWS está trabalhando com a Anthropic e a OpenAI para trazer o Continuum para os ambientes de desenvolvimento onde o código está sendo escrito. O funcionamento será o seguinte:
Dentro dos ambientes Claude Code, Codex e Kiro, varreduras de vulnerabilidades sob demanda identificam possíveis problemas e enviam os achados ao Continuum.
O Continuum prioriza esses achados dentro do contexto do ambiente AWS do cliente — considerando configurações, políticas do Gerenciamento de Identidade e Acesso da AWS (IAM), topologia de rede e superfícies de exposição.
Em seguida, valida os achados em um sandbox e retorna inteligência priorizada e contextualizada de volta ao assistente de código, que ajusta suas recomendações de acordo.
Isso colapsa o que era tradicionalmente um processo de múltiplas etapas e múltiplas equipes — escrever, escanear, triar, priorizar, corrigir, reescanear — em um único resultado: a própria sugestão de código.
Dois modos, um objetivo
A solução opera em dois modos complementares:
Para código existente: use o Continuum para vulnerabilidades de código da AWS para descobrir, priorizar, validar e corrigir em todo o ambiente.
Para código novo (greenfield): use o plugin do Continuum dentro do Codex, Claude Code ou Kiro para receber sugestões com validação de segurança diretamente no ambiente de desenvolvimento.
Parceiros de design que já testaram a solução relatam resultados concretos. Mike Johnson, CISO da Rivian, destacou que o AWS Continuum conecta o código-fonte ao conhecimento corporativo, permitindo que as equipes identifiquem com precisão vulnerabilidades de segurança e verifiquem se os problemas sinalizados são realmente relevantes — reduzindo o tempo até a correção de vulnerabilidades críticas.
Disponibilidade
O AWS Continuum para vulnerabilidades de código já está disponível em preview. É possível solicitar acesso diretamente pelo formulário de interesse do AWS Continuum. A integração do Continuum com os fluxos de trabalho do Claude Code, Codex e Kiro está prevista para breve.
Quem já usou o n8n para automatizar fluxos de trabalho sabe que o nó de AI Agent embutido resolve bem o caso mais básico: uma chamada a um modelo de linguagem dentro de um workflow. Mas um agente de produção exige muito mais do que isso. Ele precisa de memória que sobreviva entre execuções, ferramentas reais como navegador e sandbox de código, e capacidade de lidar com tarefas mais longas e complexas. Montar essa estrutura do zero é exatamente onde a maioria das equipes perde tempo.
É nesse contexto que a AWS posiciona o Amazon Bedrock AgentCore — uma plataforma para construir, conectar e otimizar agentes em escala, compatível com qualquer framework ou modelo. O AgentCore Harness, uma das capacidades do Amazon Bedrock AgentCore, passou a ser disponibilizado em disponibilidade geral (GA) e entrega exatamente essa camada de infraestrutura gerenciada. Um novo nó comunitário de código aberto traz essa capacidade para o editor visual do n8n.
O nó, publicado como @aws/n8n-nodes-agentcore, não prende o usuário a um único provedor. Ele funciona com Amazon Bedrock, OpenAI, Google Gemini e provedores suportados pelo LiteLLM — e é possível até trocar de provedor entre turnos de uma mesma conversa. O harness é construído sobre o Strands Agents, o framework de agentes de código aberto da AWS, e o nó é licenciado sob MIT.
O que o harness faz por você
Um agente não é apenas um modelo. O modelo raciocina, mas é o harness que executa o trabalho ao redor: ele roda o loop de orquestração, chama ferramentas, gerencia a janela de contexto, mantém o estado entre turnos, se recupera de falhas e isola cada sessão. Construir essa camada é onde a maioria das equipes concentra esforço.
Com o AgentCore Harness, você define o agente em configuração — modelo, ferramentas, habilidades e instruções — e o AgentCore monta e executa o loop por você. Cada sessão roda em um ambiente isolado com sistema de arquivos próprio, memória entre sessões e navegação web. Quando a configuração não for suficiente, é possível exportar o harness para código Strands e continuar rodando no mesmo sistema.
O nó comunitário expõe o harness completo no editor do n8n com uma única operação controlada pelo campo Harness ARN: deixe-o em branco e o nó cria o agente na primeira execução, reutiliza nas seguintes e atualiza quando a configuração muda. Cole um ARN existente e o nó invoca diretamente um agente criado fora do n8n. O padrão de credenciais é o mesmo já usado pelos nós de AWS Lambda e Amazon S3 no n8n.
Pré-requisitos
Antes de começar, é necessário ter:
Uma instância do n8n (self-hosted ou n8n Cloud). Consulte a documentação de deploy do n8n para escolher a opção adequada.
O nó instalado. Como nó comunitário verificado, basta pesquisar por Amazon Bedrock AgentCore no painel de nós do n8n e selecioná-lo. Também é possível instalar via Settings > Community Nodes informando @aws/n8n-nodes-agentcore. O guia usa a versão 0.3 do nó.
Importante: sempre que possível, use credenciais temporárias do AWS IAM Identity Center ou do AWS Security Token Service (AWS STS) e siga o princípio do menor privilégio ao configurar permissões IAM. Não armazene credenciais em controle de versão.
Sobre custos: o AgentCore Harness, o armazenamento de memória gerenciada provisionado e, se utilizado, os endpoints de VPC são recursos faturáveis na AWS. Consulte a documentação do AgentCore para detalhes de preço e lembre-se de remover os recursos criados ao final.
Configurando a credencial
A credencial AWS é configurada uma única vez, da mesma forma que outros nós AWS no n8n. Em Credentials, crie uma nova credencial do tipo Amazon Bedrock AgentCore API. Informe o Access Key ID, o Secret Access Key e, se usar credenciais temporárias, o Session Token. Selecione a região, informe o ARN da função de execução que o harness assumirá em runtime e teste a conexão antes de salvar.
Construindo o primeiro agente com memória persistente
O primeiro cenário demonstrado pela AWS é um agente que lembra detalhes ao longo de turnos de conversa. A memória é ativada por padrão — o nó provisiona automaticamente um armazenamento de memória gerenciada sem configuração adicional.
O fluxo básico é: adicionar um trigger manual, conectar o nó do Amazon Bedrock AgentCore com a credencial configurada, deixar o campo Harness ARN em branco, definir um nome para o agente (por exemplo, travel_concierge), escolher o provedor e o modelo (como um modelo Claude via Amazon Bedrock), escrever um System Prompt, definir um Session ID e inserir o prompt do primeiro turno.
A primeira execução leva cerca de 30 a 60 segundos enquanto a AWS provisiona o agente. A saída inclui a resposta do agente, o uso de tokens e um resumo do que foi provisionado, incluindo o ARN do armazenamento de memória criado automaticamente. Nos turnos seguintes, mantendo o mesmo Session ID, o agente recupera o contexto anterior — o contador de tokens de entrada sobe porque o nó carrega a conversa prévia antes de o agente raciocinar. Deixar o Session ID em branco inicia uma nova conversa a cada execução.
Isolando memória por usuário com Actor ID
Quando um único agente atende múltiplas pessoas, é possível manter o histórico de cada uma separado usando o campo Actor ID, disponível nas opções adicionais do nó. A hierarquia de escopo é: o agente guarda a configuração compartilhada, o Actor ID isola a memória de um usuário de outro, e o Session ID isola conversas individuais dentro de um mesmo ator. Um ator diferente com o mesmo Session ID ainda terá sua própria memória separada.
Na prática: configure um agente como team_assistant com memória gerenciada, defina o Actor ID como um valor por usuário (por exemplo, user-alice) e um Session ID para esse usuário. No primeiro turno, armazene uma informação. No segundo, recupere-a com o mesmo actor e session. Trocando o Actor ID, o agente não terá acesso ao histórico do usuário anterior.
Adicionando ferramentas: interpretador de código em sandbox
Agentes se tornam muito mais capazes quando podem usar ferramentas. O segundo cenário demonstrado é um agente com acesso a um interpretador de código que executa scripts em um ambiente isolado.
Configure um agente como data_analyst com um modelo Claude. No System Prompt, instrua o agente a escrever e executar código para responder e reportar o resultado. Ative Add Tools, adicione uma ferramenta do tipo AgentCore Code Interpreter e insira um prompt que exija computação — por exemplo, gerar 500 notas aleatórias entre 0 e 100 e calcular média, mediana e desvio padrão.
O agente escreve e executa o código no sandbox e retorna os resultados computados, em vez de estimá-los. O resumo do harness na saída confirma uma ferramenta configurada. Da mesma forma, é possível adicionar outras ferramentas: navegador em nuvem, AgentCore Gateway e servidores MCP remotos.
Skills são pacotes de instruções e scripts que fornecem conhecimento de domínio ao agente sob demanda. Elas podem ser carregadas do catálogo curado da AWS, de um repositório Git, do Amazon S3 ou de um caminho no sistema de arquivos — e o harness as carrega apenas quando a tarefa exige.
Configure um agente como aws_architect com um modelo Claude. Ative Add Skills, adicione uma skill e defina a fonte. Para o catálogo curado, escolha AWS Skills e informe um padrão glob como core-skills/*. É possível adicionar mais skills de outras fontes. Insira um prompt que se beneficie da skill, como solicitar um esboço de pipeline serverless para upload de imagens na AWS. O agente aplica as habilidades carregadas para produzir orientações, e o resumo do harness mostra o número de skills configuradas.
Executando o agente dentro da sua VPC
Para agentes que precisam de acesso a redes privadas, o harness pode ser executado dentro de uma Nuvem Privada Virtual (VPC). A configuração de rede é feita na credencial, então todos os agentes provisionados com aquela credencial rodarão de forma privada.
Edite a credencial Amazon Bedrock AgentCore API, defina o Network Mode como VPC, informe os IDs de sub-redes e grupos de segurança e salve. As sub-redes não precisam de acesso à internet: o harness busca sua imagem de contêiner gerenciada em um repositório privado do Amazon ECR na mesma região, então são necessários endpoints de VPC para o Amazon ECR e o Amazon S3 — não um NAT gateway. Consulte a documentação de segurança do AgentCore Harness para os endpoints necessários e as permissões da função de execução.
Em um workflow, use um agente como private_vpc_agent com a credencial configurada para VPC. A saída do nó confirmará que o modo de rede é VPC no resumo do harness.
Limpeza dos recursos
Cada agente criado é um recurso de harness na conta AWS e pode provisionar um armazenamento de memória gerenciada. Para evitar cobranças contínuas, remova os agentes que não forem mais necessários.
Liste os harnesses com a Interface de Linha de Comando da AWS (AWS CLI):
Se você habilitou VPC, remova também os endpoints de interface criados, pois eles geram cobranças enquanto existem. Consulte a documentação do AgentCore para detalhes de preço.
O que explorar a seguir
O nó já suporta um conjunto mais amplo de funcionalidades do AgentCore Harness. Confira o que é possível explorar com a mesma abordagem de configuração apresentada acima:
Troca de provedor de modelo mid-session: use OpenAI, Google Gemini ou provedores LiteLLM ao lado do Amazon Bedrock e troque entre turnos da mesma sessão sem perder contexto. Provedores não-Bedrock usam uma chave de API armazenada no AgentCore Identity.
Mais ferramentas: adicione navegador em nuvem, AgentCore Gateway com autenticação OAuth de saída opcional e servidores MCP remotos junto ao interpretador de código.
Funções inline: permita que o agente chame de volta o workflow do n8n para uma etapa de revisão humana (human-in-the-loop) e retorne o resultado ao agente.
Contêineres customizados: traga sua própria imagem de contêiner Linux/arm64 para o agente rodar com suas próprias dependências.
Montagem de sistemas de arquivos: use armazenamento de sessão gerenciada ou monte Amazon EFS ou Amazon S3 para dados que sobrevivam a uma sessão.
Invocação autenticada com OAuth: invoque agentes protegidos por um autorizador JSON Web Token (JWT) de entrada com um token do seu provedor de identidade.
Versões e endpoints: cada mudança de configuração gera uma versão imutável, e endpoints nomeados permitem fixar staging e produção em versões específicas.
A pasta examples no repositório GitHub inclui workflows importáveis para muitos desses cenários. Para casos de uso completos, a pasta examples/templates traz automações mais completas mostrando o agente funcionando junto a outros nós do n8n.
Conclusão
O AgentCore Harness entrega a camada de infraestrutura que faltava para quem quer rodar agentes de IA em produção a partir do editor visual do n8n. Com memória persistente, isolamento por usuário, ferramentas como interpretador de código, habilidades de domínio e suporte a execução privada em VPC — tudo configurável sem escrever código de infraestrutura — a AWS reduz significativamente a barreira de entrada para agentes robustos.
O nó está disponível como nó comunitário verificado no n8n. Para começar, adicione o nó Amazon Bedrock AgentCore pelo painel de nós (ou instale @aws/n8n-nodes-agentcore via Settings > Community Nodes), importe um workflow de exemplo e construa seu primeiro agente. O nó é de código aberto sob licença MIT, construído sobre o framework Strands Agents, e contribuições são bem-vindas no repositório GitHub. Para aprofundar no funcionamento da capacidade subjacente, consulte a documentação do AgentCore.
Busca vetorial nativa chega ao DynamoDB em disponibilidade geral
A AWS anunciou, em agosto de 2026, a disponibilidade geral da busca vetorial nativa no Amazon DynamoDB. Trata-se de um novo recurso que permite indexar e pesquisar vetores em tempo real, diretamente dentro do banco de dados NoSQL já consolidado no mercado.
O problema que essa novidade resolve
À medida que conjuntos de dados vetoriais crescem para bilhões ou até trilhões de entradas, a busca vetorial em escala enfrenta um dilema clássico: ou você aceita maior latência, ou abre mão de precisão e throughput. Até então, escalar buscas vetoriais sem comprometer a qualidade dos resultados era um desafio significativo de infraestrutura.
Com essa atualização, o DynamoDB passa a oferecer busca vetorial nativa com latência de milissegundos de um único dígito, mantendo 99%+ de recall — e tudo isso projetado para funcionar em qualquer escala, inclusive com trilhões de vetores.
Como funciona na prática
A proposta é simples e integrada ao modelo já conhecido do DynamoDB. Os vetores são armazenados junto com os demais atributos do item, e podem ser gerados por qualquer modelo de sua escolha — incluindo os modelos disponíveis no Amazon Bedrock. A partir daí, o fluxo envolve:
Criação de um índice vetorial;
Execução de buscas por vizinhos mais próximos aproximados (Approximate Nearest Neighbor — ANN);
Escolha da chave de partição do índice vetorial para escalar a solução;
Filtragem por atributos para refinar os resultados.
E o modelo serverless segue intacto: sem gerenciamento de infraestrutura, sem janelas de manutenção, sem downtime, e com cobrança apenas pelo que for utilizado.
Casos de uso habilitados pelo recurso
O DynamoDB já era utilizado para armazenar memória de agentes de IA. Com a busca vetorial, agora é possível adicionar recuperação semântica sobre essa memória — o que abre caminho para uma série de aplicações práticas:
Grounding de agentes de IA com recuperação semântica;
Busca por similaridade de produtos em e-commerce;
Publicidade personalizada;
Geração Aumentada por Recuperação (RAG — Retrieval Augmented Generation);
Sistemas de recomendação com desempenho previsível.
Disponibilidade
A busca vetorial no DynamoDB já está disponível em todas as regiões comerciais da AWS e também nas regiões AWS GovCloud (EUA), sem necessidade de configuração adicional de infraestrutura.
Existe um desafio bastante concreto no uso de agentes de IA hospedados na nuvem: e quando as ferramentas que o agente precisa usar estão na máquina local do usuário? Planilhas Excel, repositórios Git, arquivos de configuração — tudo isso vive no computador de quem trabalha, não em um servidor remoto.
Foi exatamente esse problema que a equipe da AWS se propôs a resolver. Em um post técnico detalhado, a AWS descreve como construiu uma ponte entre um agente hospedado no Amazon Bedrock AgentCore e servidores MCP (Model Context Protocol) rodando localmente na máquina do usuário final.
O resultado prático? Um assistente de IA para finanças que, segundo a AWS, acumulou mais de 41.000 conversas em um ano desde o lançamento interno — lendo planilhas diretamente do computador do analista, sem expor credenciais ao navegador.
O que é o MCP e qual é a lacuna que a ponte resolve
O Model Context Protocol (MCP) é um padrão aberto lançado pela Anthropic em novembro de 2024 para padronizar como modelos de IA se conectam a dados externos e ferramentas. Ele segue uma arquitetura cliente-servidor: o host MCP (uma aplicação de IA, como o Amazon Quick ou o Claude Code) estabelece conexões com um ou mais servidores MCP.
O protocolo suporta dois mecanismos de transporte: stdio (para comunicação entre processos na mesma máquina) e HTTP com streaming (para comunicação entre cliente remoto e servidor remoto). O que faltava era justamente o cenário inverso: servidor MCP local, cliente MCP remoto. A ponte MCP da AWS resolve exatamente essa lacuna.
Esse padrão é o mesmo que alimenta produtos como o Claude Cowork — um agente na nuvem chamando ferramentas locais via MCP — mas, neste caso, totalmente auto-hospedado na AWS com modelo e servidores de ferramentas próprios.
Arquitetura da solução: quatro componentes em conjunto
A arquitetura descrita pela AWS tem quatro componentes principais que trabalham em conjunto:
AgentCore Runtime: hospeda o agente Strands na nuvem. O agente atua como cliente MCP, emitindo requisições de descoberta e invocação de ferramentas.
Extensão de navegador: fornece a interface de chat e age como retransmissora bidirecional, encaminhando mensagens MCP entre o AgentCore Runtime (via WebSocket) e a MCP Bridge (via native messaging).
MCP Bridge: um proxy FastMCP rodando na máquina local do usuário, iniciado pelo navegador através do registro de host de native messaging. Ele traduz entre o formato de envelope do native messaging e o JSON-RPC bruto do MCP.
Servidor MCP: um servidor MCP padrão rodando localmente. Como a bridge está co-localizada, a comunicação usa transporte stdio.
O fluxo completo funciona assim: o usuário envia uma mensagem pela extensão, que se conecta ao AgentCore Runtime via WebSocket pré-assinado. Quando o agente Strands precisa chamar uma ferramenta, ele envia uma requisição JSON-RPC MCP encapsulada em um envelope JSON de volta pela WebSocket para a extensão. A extensão repassa a mensagem para a bridge via native messaging. A bridge desencapsula o envelope, extrai o conteúdo JSON-RPC e o encaminha para o servidor MCP via stdio. A resposta percorre o caminho inverso.
A tabela abaixo mostra como uma única chamada de ferramenta percorre os saltos entre o agente e o servidor MCP, com cada salto removendo uma camada de encapsulamento:
Como o agente Strands funciona no AgentCore Runtime
Conexão WebSocket
A extensão de navegador se conecta ao AgentCore Runtime via uma URL WebSocket pré-assinada. Na inicialização, o painel lateral envia uma requisição de pré-assinatura pelo script de background para a bridge nativa, que usa as credenciais AWS locais do usuário e o SDK do bedrock-agentcore para gerar uma URL wss:// assinada com SigV4, com escopo para o ARN do runtime implantado (válida por 5 minutos). Nenhuma credencial sai da máquina do usuário ou entra no navegador.
Inicialização MCP e descoberta de ferramentas
Antes de descobrir ferramentas, o agente realiza o handshake de inicialização MCP padrão: envia uma requisição initialize com a versão do protocolo, aguarda a resposta de capacidades do servidor e envia a notificação notifications/initialized. Somente após esse handshake o servidor aceita requisições tools/list e tools/call.
A cada mensagem do usuário, o agente chama tools/list e recebe um array de esquemas de ferramentas. Ele encapsula cada esquema em um Strands AgentTool cujo método stream() envia uma requisição tools/call pela bridge. Ferramentas adicionadas ao servidor MCP ficam automaticamente disponíveis na próxima requisição, sem nenhuma alteração no código do agente.
Correlação de requisição e resposta
Cada requisição JSON-RPC de saída do agente recebe um ID único e é registrada em um asyncio.Future indexado por (session_id, jsonrpc_id). Quando a resposta chega de volta pela WebSocket, ela é associada ao Future correspondente e resolvida. Isso permite que múltiplas chamadas de ferramentas estejam em andamento simultaneamente sem ambiguidade.
Como funciona o native messaging
Para que a extensão se comunique com um processo local de longa duração sem permissões de rede ou prompts por mensagem, a solução usa o native messaging — suportado tanto pelo Chrome quanto pelo Firefox. O navegador procura um arquivo de manifesto em um local conhecido na máquina do usuário que especifica qual binário iniciar.
O arquivo de manifesto do native messaging para Chrome no macOS tem o seguinte formato:
# Stored at ~/Library/Application\ Support/Google/Chrome/NativeMessagingHosts/com.example.mcp_bridge.json
{
"name": "com.example.mcp_bridge",
"description": "MCP Bridge - Routes MCP messages to local servers",
"path": "/path/to/mcp-bridge-demo/bridge/run_bridge.sh",
"type": "stdio",
"allowed_origins": [
"chrome-extension:///"
]
}
Na inicialização da extensão, o script de background chama chrome.runtime.connectNative("com.example.mcp_bridge") para iniciar o aplicativo nativo localmente. O script run_bridge.sh referenciado no manifesto ativa o ambiente Python e inicia a bridge:
#!/bin/bash
cd "/path/to/mcp-bridge-demo/bridge"
source .venv/bin/activate
exec python3 bridge.py
Cada mensagem é serializada como JSON, codificada em UTF-8 e precedida por um comprimento de mensagem de 32 bits em ordem little-endian. O tamanho máximo de uma mensagem do host de native messaging é 1 MB; o tamanho máximo de uma mensagem enviada ao host é 64 MiB.
Como a MCP Bridge funciona internamente
A MCP Bridge age como tradutora de protocolo entre dois mundos: o protocolo de native messaging do Chrome de um lado, e o padrão MCP (JSON-RPC 2.0 sobre stdio) do outro.
No caminho de entrada, ela remove o cabeçalho de 4 bytes do stdin, analisa o corpo JSON e desencapsula o envelope para extrair a mensagem JSON-RPC bruta. No caminho de saída, faz o inverso: encapsula a resposta JSON-RPC em um envelope e a escreve de volta com o cabeçalho de comprimento.
Internamente, a bridge executa dois loops concorrentes conectados por um proxy FastMCP. O loop principal lê mensagens do navegador, as desencapsula e coloca o conteúdo JSON-RPC em uma fila de entrada. O proxy FastMCP, iniciado uma vez e mantido ativo pelo tempo de vida da bridge, pega mensagens dessa fila, as encaminha para o subprocesso do servidor MCP via stdin e coloca as respostas do stdout do servidor em uma fila de saída. Um segundo loop em background lê da fila de saída, encapsula cada resposta de volta em um envelope e a escreve no stdout para o navegador receber.
O servidor MCP em si é um processo filho iniciado pela bridge na inicialização, configurado por um arquivo mcp.json. Adicionar um novo servidor MCP é uma mudança de uma linha nesse arquivo:
Permissões de Gerenciamento de Identidade e Acesso (IAM) para Bedrock AgentCore (bedrock-agentcore:*), AWS CloudFormation, criação de roles IAM e S3.
Interface de Linha de Comando da AWS (AWS CLI) configurada com credenciais.
Kit de Desenvolvimento em Nuvem da AWS (AWS CDK) inicializado na região alvo.
Python 3.10+, Node.js 20+, Google Chrome e Git.
O processo de implantação consiste em clonar o repositório, instalar dependências Python, criar e implantar o agente no AgentCore via CLI, configurar o arquivo bridge_config.json com o ARN do runtime, carregar a extensão no Chrome e registrar a bridge de native messaging. O código completo está disponível no GitHub.
git clone https://github.com/aws-samples/sample-mcp-bridge-agentcore.git
cd mcp-bridge-demo
A AWS destaca que a solução demonstrada prioriza a funcionalidade da bridge MCP e, portanto, inclui apenas medidas básicas de segurança: restrição de origem do native messaging (o Chrome verifica o ID da extensão contra a lista allowed_origins), expiração de URL pré-assinada (URLs WebSocket são assinadas com SigV4 e expiram em 5 minutos) e isolamento de processos.
A principal superfície de exposição única dessa arquitetura é a própria bridge: ela aceita instruções de um agente hospedado na nuvem e as executa localmente com as permissões do sistema de arquivos do usuário. Para um sistema em produção, além de implementar o Amazon Bedrock Guardrails para filtragem de conteúdo, a AWS recomenda medidas adicionais:
Autenticação: exigir um handshake com Token Web JSON (JWT) como primeiro frame WebSocket, verificado via Amazon Cognito ou segredo HMAC no AWS Systems Manager.
Assinatura de payload: assinar cada mensagem MCP com Ed25519 (chave privada no agente, chave pública na bridge) para garantir que mensagens não foram modificadas em trânsito.
Escopo do sistema de arquivos: configurar uma lista explícita de diretórios que o servidor MCP pode acessar, rejeitando caminhos fora do limite — prevenindo que uma injeção de prompt engane o agente para ler arquivos sensíveis.
Registro de auditoria: registrar cada invocação de ferramenta (nome, argumentos, timestamp, status do resultado) em um arquivo local para rastreabilidade.
O que vem a seguir: extensões da arquitetura
A AWS aponta que a arquitetura atual pode ser estendida para suportar mais casos de uso:
Ações no navegador: a extensão pode implementar suas próprias ferramentas de navegador modeladas nas definições de ferramentas do Playwright MCP e expô-las ao agente para realizar ações como clicar em elementos, preencher formulários, navegar em páginas e tirar screenshots.
Automação de ferramentas locais: a bridge fala JSON-RPC MCP padrão sobre stdio, então servidores MCP compatíveis com transporte stdio funcionam sem modificação. Exemplos incluem acesso ao sistema de arquivos para leitura/escrita em sandbox, Git para operações em repositórios e memory para grafos de conhecimento local persistentes. O diretório awesome-mcp-servers lista servidores disponíveis.
Empacotamento como binário standalone: para distribuição em produção, a AWS usa o PyInstaller para empacotar a bridge em um binário standalone que inclui o runtime Python, dependências e configuração em um único executável.
Conclusão
A solução descrita pela AWS demonstra como é possível manter um agente de IA centralmente implantado e gerenciado enquanto se dá a ele acesso a ferramentas que precisam rodar localmente — planilhas Excel, repositórios Git ou outros servidores MCP locais. O padrão usa uma extensão de navegador como camada de retransmissão e o native messaging do Chrome como transporte local, tunelando mensagens JSON-RPC MCP padrão entre a nuvem e o sistema de arquivos do usuário sem expor credenciais ao navegador ou modificar o próprio protocolo MCP.
A AWS anunciou duas novidades relevantes para quem trabalha com qualidade de dados no AWS Glue Data Quality: a detecção de anomalias em jobs de Extração, Transformação e Carga (ETL) passou a ser gratuita, e um novo modo de observação foi introduzido para tornar as detecções mais precisas e com menos ruído.
Novo modo de observação: menos falsos positivos
Um dos problemas clássicos em sistemas de detecção de anomalias é o excesso de alertas que não representam problemas reais — os chamados falsos positivos. Para endereçar isso, a AWS introduziu um novo modo de observação de anomalias que utiliza uma linha de base constante no lugar de uma tendência linear para analisar os dados.
Na prática, isso significa que o serviço para de extrapolar tendências de forma exagerada, entregando alertas mais precisos e reduzindo o ruído. Com isso, as equipes conseguem focar nas anomalias genuínas, sem perder tempo investigando falsos alarmes.
Quando esse novo modo é mais útil
A AWS destaca que o novo modo de observação é particularmente indicado para os seguintes cenários:
Análises exploratórias de dados (EDA — Exploratory Data Analysis), como as realizadas em notebooks interativos;
Datasets com padrões planos ou aleatórios, sem tendências previsíveis;
Cargas de trabalho com intervalos irregulares de chegada de dados;
Verificações de qualidade executadas em horários variados ou em ambientes interativos.
Em resumo, qualquer cenário onde os dados não seguem um ritmo previsível se beneficia diretamente dessa melhoria.
Detecção de anomalias em ETL agora sem custo adicional
Além da melhoria técnica, a AWS removeu a cobrança pela detecção de anomalias em jobs ETL do Glue. Isso significa que é possível monitorar a qualidade dos dados em todos os pipelines do Glue sem preocupação com custos adicionais por essa funcionalidade específica.
Para quem já utilizava o serviço com restrições por conta do preço, essa mudança abre espaço para ampliar o monitoramento sem impacto no orçamento.
O problema que todo time de identidade já enfrentou
Imagine que sua empresa está se preparando para o maior evento de vendas do ano — uma Black Friday, uma virada de exercício fiscal, ou o pico de declarações de imposto de renda. Você precisa garantir que o serviço de autenticação vai aguentar o tranco. Aí você descobre que aumentar os limites de taxa do Amazon Cognito exige abrir um ticket de suporte e esperar entre 10 e 14 dias para a aprovação.
Esse cenário foi realidade por muito tempo para equipes de segurança, arquitetos de identidade e times de engenharia que dependem do Cognito em produção. A necessidade de planejar com semanas de antecedência — ou correr para escalar uma solicitação urgente — criava um gargalo operacional considerável, especialmente para negócios com tráfego sazonal intenso.
A AWS identificou esse problema e respondeu com uma mudança significativa: a partir de 6 de julho de 2026, o Amazon Cognito passou a oferecer os chamados limites provisionados (provisioned limits), um mecanismo de autoatendimento que permite ajustar a capacidade de autenticação em minutos, diretamente pelo console.
O que são os limites provisionados
Os limites provisionados são uma nova camada de controle de capacidade disponível na aba Provisioned limits dentro do console do Amazon Cognito, no nível de conta (por Região AWS, por conta). Com esse recurso, é possível aumentar ou reduzir a capacidade provisionada sob demanda, com efeito imediato.
O modelo funciona com dois mecanismos complementares:
Limite provisionado (console do Amazon Cognito): controla a capacidade que você reserva ativamente. Alterações entram em vigor imediatamente. A cobrança ocorre sobre a capacidade provisionada acima do limite padrão, independentemente do quanto é efetivamente consumido.
Limite máximo de conta (console do AWS Service Quotas): define o teto máximo de Requisições por Segundo (RPS) que sua conta pode provisionar. Elevar esse teto não gera cobrança adicional — ele apenas desbloqueia a possibilidade de provisionar mais capacidade.
Juntos, esses dois controles oferecem precisão tanto na gestão de custos quanto na gestão de capacidade. Você pode subir o teto com antecedência, sem custo, e só ativar a capacidade extra quando realmente precisar.
Para entender a lógica do modelo, vale usar o exemplo da API UserCreation, que tem limite padrão de 50 RPS. No estado inicial, você tem três valores:
Limite padrão: 50 RPS (incluso sem custo adicional)
Limite provisionado: 50 RPS (igual ao padrão — capacidade faturada é 0)
Limite máximo de conta: 50 RPS (teto atual da conta)
Se você tentar provisionar 55 RPS diretamente, o console bloqueará a ação, pois o valor excede o teto máximo de 50 RPS. Para avançar, é necessário primeiro solicitar um aumento do limite máximo de conta via Service Quotas. Aproximadamente 90% dessas solicitações são aprovadas automaticamente em minutos. Para aumentos maiores, dependendo da categoria de API e da Região, pode ser necessária revisão manual pelo suporte da AWS.
Após a aprovação do novo teto (digamos, 55 RPS), você retorna ao console do Cognito e ajusta o limite provisionado para 55 RPS. A partir daí, a capacidade faturada passa a ser de 5 RPS (55 menos os 50 do padrão). Quando o evento de pico termina, basta reduzir o limite provisionado de volta ao padrão — a cobrança extra cessa imediatamente.
Um detalhe importante sobre o modelo de cobrança: você é cobrado pela capacidade que provisiona acima do padrão, e não pelo que efetivamente usa. Se você provisionar 80 RPS (com padrão de 50), será cobrado por 30 RPS mesmo que o uso real seja de apenas 60 RPS. Isso reforça a importância de dimensionar a capacidade com precisão, alinhada à demanda esperada.
Categorias ajustáveis e não ajustáveis
Nem todas as categorias de API do Cognito podem ter seus limites ajustados. A aba de limites provisionados exibe cada categoria com seu status de ajustabilidade. Por exemplo, UserCreation é marcada como Adjustable (ajustável) e pode ser modificada. Já UserList aparece como Not adjustable (não ajustável) — você consegue visualizar os valores de limite padrão e provisionado, mas não pode alterá-los.
Para as categorias ajustáveis, a visão consolidada mostra o limite padrão, o limite provisionado atual e a capacidade faturada de forma direta, facilitando o acompanhamento e a tomada de decisão.
Casos de uso práticos
A flexibilidade do novo modelo atende a cenários bem variados. Serviços de declaração de imposto de renda, por exemplo, concentram cerca de 90% do volume anual de autenticação em poucos meses. Plataformas de e-commerce enfrentam picos intensos em datas comemorativas. Antes, essas equipes precisavam solicitar aumentos de capacidade semanas antes do evento e torcer para que a aprovação chegasse a tempo.
Agora, o fluxo muda completamente: eleve o teto máximo de conta com antecedência (sem custo), e quando o pico se aproximar, aumente o limite provisionado para o valor necessário. Após o evento, reduza a capacidade e pare de ser cobrado pela capacidade extra. Tudo isso sem abrir um único ticket de suporte.
O mesmo vale para testes de carga planejados ou para crescimento viral inesperado — qualquer ajuste é feito em autoatendimento, em minutos.
Considerações para SaaS multi-tenant
Para provedores de Software como Serviço (SaaS) que gerenciam múltiplos tenants com requisitos de throughput diferentes, a AWS disponibilizou também a API UpdateProvisionedLimit, que permite o gerenciamento programático dos limites provisionados.
Equipes que utilizam user pools dedicados por tenant, por exemplo, podem integrar essa API em seus pipelines de infraestrutura como código para ajustar os limites por tier de serviço. Isso abre a possibilidade de provisionar maior capacidade para tenants enterprise e menor capacidade para tenants em plano gratuito, com ajustes independentes por tenant conforme a demanda de cada um.
Como começar
O recurso de limites provisionados para user pools do Amazon Cognito está disponível desde 6 de julho de 2026, em todas as Regiões AWS onde o Cognito é suportado. Para colocar em prática, a AWS recomenda o seguinte fluxo:
Revise os padrões atuais de tráfego de autenticação usando métricas do Amazon CloudWatch para entender sua linha de base
Configure alarmes no CloudWatch em 70% e 85% dos seus limites de taxa atuais
Verifique se sua equipe tem as permissões adequadas de Gerenciamento de Identidade e Acesso da AWS (IAM) tanto para o Service Quotas quanto para a aba de limites provisionados no console do Cognito
Eleve o limite máximo de conta no Service Quotas com base nas suas expectativas de demanda
Use a aba Provisioned limits no console do Amazon Cognito para ajustar a capacidade conforme necessário
AWS renova certificações PCI e expande escopo de serviços e regiões
A Amazon Web Services (AWS) anunciou a conclusão bem-sucedida da renovação de suas certificações de Padrão de Segurança de Dados da Indústria de Cartões de Pagamento (PCI DSS) e de Segurança em Três Domínios (PCI 3DS). Além da renovação em si, a AWS ampliou o escopo desta certificação, incluindo três novos serviços e uma nova região.
Com essa expansão, clientes que utilizam esses serviços podem continuar operando dentro dos requisitos de conformidade PCI DSS e PCI 3DS, sem precisar abrir mão de inovação por conta de restrições regulatórias. A lista completa de serviços cobertos pode ser consultada na página de serviços no escopo por programa de conformidade da AWS.
O que compõe os pacotes de conformidade
Os pacotes de conformidade PCI DSS e PCI 3DS disponibilizados pela AWS incluem dois componentes principais para cada certificação:
Atestado de Conformidade (AOC) – documento que comprova que a AWS foi validada com sucesso em relação aos padrões PCI DSS e PCI 3DS.
Resumo de Responsabilidades da AWS – material que orienta os clientes a entenderem suas próprias responsabilidades ao desenvolver e operar ambientes seguros na AWS para o tratamento de dados de cartões de pagamento.
A avaliação foi conduzida pela Coalfire, empresa terceirizada credenciada como Avaliadora de Segurança Qualificada (QSA).
Como acessar os relatórios
Os pacotes de relatórios PCI DSS e PCI 3DS estão disponíveis pelo AWS Artifact, portal de autoatendimento da AWS que oferece acesso sob demanda a relatórios de conformidade, facilitando processos de auditoria.
