A Amazon Web Services (AWS) acaba de disponibilizar o relatório de Controles de Sistema e Organização (SOC) 1 referente ao ciclo Inverno 2025. O documento cobre um período de 12 meses — de 1º de janeiro a 31 de dezembro de 2025 — e contempla 184 serviços dentro do escopo de auditoria.
Essa cobertura anual é importante porque oferece às empresas clientes uma visão contínua e consolidada sobre os controles internos da AWS relacionados a relatórios financeiros, facilitando o processo de conformidade e auditorias externas.
Por que o SOC 1 importa para sua empresa
O relatório SOC 1 é um documento de auditoria independente que atesta a eficácia dos controles internos de um provedor de serviços em nuvem no que diz respeito ao impacto sobre os relatórios financeiros dos clientes. Para empresas brasileiras que operam em setores regulados — como financeiro, saúde e varejo — ter acesso a esse relatório é frequentemente um requisito de compliance ou de auditorias internas.
Com 184 serviços cobertos, a AWS demonstra um compromisso crescente em ampliar o escopo dos seus programas de conformidade, ajudando as organizações a atenderem tanto requisitos arquiteturais quanto regulatórios.
Como acessar o relatório
O relatório SOC 1 Inverno 2025 está disponível para download pelo AWS Artifact, o portal de autoatendimento da AWS para acesso sob demanda a documentos de conformidade. Para obtê-lo, basta acessar o AWS Artifact no Console de Gerenciamento da AWS. Caso ainda não conheça a ferramenta, a AWS disponibiliza um guia introdutório em Primeiros Passos com o AWS Artifact.
Serviços no escopo
A lista completa dos serviços cobertos pelos programas de conformidade da AWS pode ser consultada na página de Serviços no Escopo. A AWS atualiza essa lista continuamente à medida que novos serviços são incluídos nos programas de auditoria.
Dúvidas e suporte
Clientes que tiverem perguntas sobre o relatório SOC 1 ou sobre os programas de conformidade da AWS podem entrar em contato com a equipe de conta AWS. Para uma visão geral de todos os programas de conformidade disponíveis, a AWS mantém uma página dedicada em Programas de Conformidade da AWS. Feedbacks e dúvidas específicas sobre compliance também podem ser enviados diretamente pela página de Contato da equipe de conformidade.
A AWS anunciou suporte ao Amazon S3 Files no Lambda, uma integração que permite às funções montar buckets do Amazon S3 diretamente como sistemas de arquivos — e executar operações de arquivo convencionais sem a necessidade de baixar os dados antes de processá-los.
Construído sobre o Amazon EFS (Elastic File System), o S3 Files combina a simplicidade e a experiência de uso de um sistema de arquivos tradicional com a escalabilidade, durabilidade e o custo-benefício já conhecidos do S3.
Compartilhamento de dados entre funções
Um dos pontos mais relevantes dessa novidade é a possibilidade de múltiplas funções Lambda se conectarem ao mesmo sistema de arquivos S3 Files simultaneamente. Isso significa que diferentes funções podem compartilhar dados por meio de um espaço de trabalho comum, sem que o time precise desenvolver lógica customizada de sincronização.
Na prática, a integração simplifica workloads com estado no Lambda ao eliminar o overhead de baixar objetos, fazer upload de resultados e gerenciar os limites do armazenamento efêmero — um alívio considerável para quem já enfrentou essas restrições.
Valor especial para workloads de IA e machine learning
Esse recurso é especialmente valioso para workloads de Inteligência Artificial (IA) e machine learning, onde agentes precisam persistir memória e compartilhar estado entre as etapas de um pipeline. As funções duráveis do Lambda tornam esses fluxos de trabalho de IA em múltiplas etapas possíveis ao orquestrar a execução paralela com checkpointing automático.
Um exemplo prático: uma função orquestradora pode clonar um repositório para um espaço de trabalho compartilhado enquanto múltiplas funções de agente analisam o código em paralelo. A função durável cuida do checkpointing do estado de execução, enquanto o S3 Files garante o compartilhamento fluido de dados em todas as etapas.
Como configurar
Para usar o S3 Files com o Lambda, basta configurar a função para montar um bucket do S3. Essa configuração pode ser feita pelo console do Lambda, pela AWS CLI (Interface de Linha de Comando), pelos AWS SDKs (Kits de Desenvolvimento de Software), pelo AWS CloudFormation ou pelo AWS SAM (Serverless Application Model). Para mais detalhes sobre como utilizar o recurso, a AWS disponibiliza o guia do desenvolvedor do Lambda.
Disponibilidade e preços
O S3 Files é suportado para funções Lambda que não estejam configuradas com um provedor de capacidade, e está disponível em todas as regiões da AWS onde tanto o Lambda quanto o S3 Files estiverem disponíveis. Não há cobrança adicional pelo uso da integração — os custos seguem os preços padrão do Lambda e do S3.
Acesso ao Athena Spark sem passar pela internet pública
A AWS anunciou que o Amazon Athena Spark agora conta com suporte ao AWS PrivateLink, permitindo que equipes acessem as APIs e endpoints do serviço diretamente a partir de sua Nuvem Privada Virtual da Amazon (VPC — Virtual Private Cloud), sem que o tráfego precise passar pela internet pública.
O que muda na prática
Com essa novidade, é possível criar endpoints de interface do AWS PrivateLink para conectar clientes dentro da sua VPC ao Athena Spark. Todo o tráfego entre a VPC e as APIs e endpoints do Athena Spark passa a ocorrer inteiramente dentro da rede da AWS, estabelecendo um caminho seguro para os dados.
O endpoint de VPC do Athena oferece suporte a todas as APIs e endpoints do Athena Spark, incluindo:
Spark Connect
Spark Live UI
Spark History Server
Por que isso importa para compliance
Um dos benefícios mais relevantes dessa integração é o auxílio no atendimento a requisitos de conformidade (compliance). Ao manter o acesso às APIs e endpoints do Athena Spark completamente dentro da rede da AWS, as organizações conseguem reduzir a exposição de dados sensíveis e reforçar controles de segurança exigidos por regulamentações e políticas internas.
Como começar a usar
Para habilitar essa funcionalidade, basta criar um endpoint de interface de VPC para se conectar ao Amazon Athena Spark. A AWS disponibiliza três formas de fazer isso:
Console de Gerenciamento da AWS (AWS Management Console)
Interface de Linha de Comando da AWS (AWS CLI — Command Line Interface)
AWS CloudFormation
Disponibilidade
O recurso já está disponível em todas as Regiões da AWS onde o Amazon Athena Spark e o AWS PrivateLink estão presentes. Para mais detalhes, a AWS recomenda consultar a documentação do AWS PrivateLink e a documentação do Athena Spark.
O problema de testar agentes de IA que chamam ferramentas externas
Agentes de IA modernos não se limitam a raciocinar: eles chamam APIs, consultam bancos de dados, acionam serviços MCP (Protocolo de Contexto de Modelo) e interagem com sistemas externos para concluir tarefas. O comportamento do agente depende não só do seu raciocínio, mas também do que essas ferramentas retornam — e é exatamente aí que o teste se complica.
Testar contra APIs reais cria três obstáculos sérios. Primeiro, dependências externas atrasam tudo: limites de taxa, instabilidades e necessidade de conectividade tornam impraticável rodar centenas de casos de teste. Segundo, chamadas reais geram efeitos colaterais reais — enviar e-mails de verdade, alterar bancos de produção ou confirmar reservas indesejadas. Terceiro, muitas ferramentas lidam com dados sensíveis, como registros de usuários e informações financeiras, criando riscos de conformidade desnecessários.
A alternativa clássica são os mocks estáticos, mas eles também têm um limite importante: funcionam bem para cenários simples e previsíveis, porém quebram em fluxos multi-etapas com estado. Imagine um agente de reserva de voos que primeiro busca opções e depois verifica o status de uma reserva — a segunda resposta precisa depender do que aconteceu na primeira chamada. Um mock com resposta fixa não consegue capturar essa dinâmica.
O que é o ToolSimulator
A AWS apresentou o ToolSimulator como parte do Kit de Desenvolvimento de Software (SDK) do Strands Evals. Trata-se de um framework de simulação de ferramentas baseado em Modelo de Linguagem de Grande Escala (LLM) que intercepta chamadas às ferramentas registradas e as redireciona para um gerador de respostas inteligente — sem nunca acionar a implementação real.
O gerador usa o esquema da ferramenta, a entrada do agente e o estado atual da simulação para produzir uma resposta realista e contextualmente adequada. Não são necessários fixtures escritos à mão.
Três capacidades centrais sustentam essa proposta:
Geração adaptativa de respostas: as saídas refletem o que o agente realmente solicitou, não um template fixo. Uma busca por voos de Seattle para Nova York retorna opções plausíveis com preços e horários realistas.
Suporte a fluxos com estado: o ToolSimulator mantém um estado compartilhado consistente entre chamadas, permitindo testar interações de banco de dados, fluxos de reserva e processos multi-etapas sem tocar em sistemas de produção.
Validação de esquema: respostas são validadas contra modelos Pydantic definidos pelo desenvolvedor, capturando respostas malformadas antes que cheguem ao agente e quebrem a camada de pós-processamento.
Como o ToolSimulator funciona
O fluxo de trabalho segue três etapas: decorar e registrar as ferramentas, opcionalmente configurar o contexto da simulação e, por fim, deixar o ToolSimulator interceptar as chamadas durante a execução do agente.
Cria-se uma instância do ToolSimulator e envolve-se a função da ferramenta com o decorator @simulator.tool(). O corpo real da função pode ficar vazio — o ToolSimulator intercepta as chamadas antes de chegarem à implementação:
from strands_evals.simulation.tool_simulator import ToolSimulator
tool_simulator = ToolSimulator()
@tool_simulator.tool()
def search_flights(origin: str, destination: str, date: str) -> dict:
"""Search for available flights between two airports on a given date."""
pass # The real implementation is never called during simulation
Etapa 2: Configurar o contexto (opcional)
Por padrão, o ToolSimulator infere o comportamento de cada ferramenta a partir do seu esquema e docstring — nenhuma configuração adicional é necessária para começar. Quando se quer mais controle, três parâmetros opcionais estão disponíveis:
share_state_id: vincula ferramentas que compartilham o mesmo backend sob uma chave de estado comum. Alterações feitas por uma ferramenta ficam visíveis para chamadas subsequentes de outras ferramentas ligadas ao mesmo ID.
initial_state_description: inicializa a simulação com uma descrição em linguagem natural do estado pré-existente. Quanto mais contexto, mais realistas e consistentes serão as respostas geradas.
output_schema: um modelo Pydantic que define a estrutura esperada da resposta. O ToolSimulator gera respostas que obedecem estritamente a esse esquema.
Etapa 3: Simulação em execução
Quando o agente chama uma ferramenta registrada, o wrapper do ToolSimulator intercepta a chamada, valida os parâmetros do agente contra o esquema da ferramenta, produz uma resposta compatível com o output_schema e atualiza o registro de estado para que chamadas subsequentes vejam um ambiente consistente.
O exemplo abaixo mostra uma simulação completa de um assistente de busca de voos:
from strands import Agent
from strands_evals.simulation.tool_simulator import ToolSimulator
# 1. Create a simulator instance
tool_simulator = ToolSimulator()
# 2. Register a tool for simulation with initial state context
@tool_simulator.tool(
initial_state_description="Flight database: SEA->JFK flights available at 8am, 12pm, and 6pm. Prices range from $180 to $420.",
)
def search_flights(origin: str, destination: str, date: str) -> dict:
"""Search for available flights between two airports on a given date."""
pass
# 3. Create an agent with the simulated tool and run it
flight_tool = tool_simulator.get_tool("search_flights")
agent = Agent(
system_prompt="You are a flight search assistant.",
tools=[flight_tool],
)
response = agent("Find me flights from Seattle to New York on March 15.")
print(response)
# Expected output: A structured list of simulated SEA->JFK flights with times
# and prices consistent with the initial_state_description you provided.
Recursos avançados do ToolSimulator
Instâncias independentes para testes paralelos
É possível criar múltiplas instâncias do ToolSimulator lado a lado. Cada instância mantém seu próprio registro de ferramentas e estado, permitindo executar configurações de experimento em paralelo no mesmo código:
simulator_a = ToolSimulator()
simulator_b = ToolSimulator()
# Each instance has an independent tool registry and state --
# ideal for comparing agent behavior across different tool setups.
Estado compartilhado para fluxos multi-etapas
Para ferramentas com estado — como getters e setters de banco de dados — o ToolSimulator mantém consistência entre chamadas. Usa-se share_state_id para vincular ferramentas que operam no mesmo backend e initial_state_description para inicializar o contexto:
@tool_simulator.tool(
share_state_id="flight_booking",
initial_state_description="Flight booking system: SEA->JFK flights available at 8am, 12pm, and 6pm. No bookings currently active.",
)
def search_flights(origin: str, destination: str, date: str) -> dict:
"""Search for available flights between two airports on a given date."""
pass
@tool_simulator.tool(
share_state_id="flight_booking",
)
def get_booking_status(booking_id: str) -> dict:
"""Retrieve the current status of a flight booking by booking ID."""
pass
# Both tools share "flight_booking" state.
# When search_flights is called, get_booking_status sees the same
# flight availability data in subsequent calls.
Também é possível inspecionar o estado antes e depois da execução do agente para validar que as interações com as ferramentas produziram as mudanças esperadas:
initial_state = tool_simulator.get_state("flight_booking")
# ... run the agent ...
final_state = tool_simulator.get_state("flight_booking")
# Verify not just the final output, but the full sequence of tool interactions.
Dica: como o initial_state_description aceita linguagem natural, é possível usar um DataFrame.describe() para gerar resumos estatísticos de dados tabulares e passá-los diretamente como descrição de estado — sem nunca acessar os dados reais.
Validação de esquema de resposta com Pydantic
Para ferramentas que seguem especificações rígidas — como OpenAPI ou MCP — define-se a resposta esperada como um modelo Pydantic e passa-se via output_schema:
from pydantic import BaseModel, Field
class FlightSearchResponse(BaseModel):
flights: list[dict] = Field(
..., description="List of available flights with flight number, departure time, and price"
)
origin: str = Field(..., description="Origin airport code")
destination: str = Field(..., description="Destination airport code")
status: str = Field(default="success", description="Search operation status")
message: str = Field(default="", description="Additional status message")
@tool_simulator.tool(output_schema=FlightSearchResponse)
def search_flights(origin: str, destination: str, date: str) -> dict:
"""Search for available flights between two airports on a given date."""
pass
# ToolSimulator validates parameters strictly and returns only valid JSON
# responses that conform to the FlightSearchResponse schema.
Integração com pipelines de avaliação do Strands Evals
O ToolSimulator se encaixa naturalmente no framework de avaliação do Strands Evals. O exemplo abaixo mostra um pipeline completo — da configuração da simulação ao relatório do experimento — usando o GoalSuccessRateEvaluator para pontuar o desempenho do agente em tarefas de chamada de ferramentas:
from typing import Any
from pydantic import BaseModel, Field
from strands import Agent
from strands_evals import Case, Experiment
from strands_evals.evaluators import GoalSuccessRateEvaluator
from strands_evals.simulation.tool_simulator import ToolSimulator
from strands_evals.mappers import StrandsInMemorySessionMapper
from strands_evals.telemetry import StrandsEvalsTelemetry
# Set up telemetry and tool simulator
telemetry = StrandsEvalsTelemetry().setup_in_memory_exporter()
memory_exporter = telemetry.in_memory_exporter
tool_simulator = ToolSimulator()
# Define the response schema
class FlightSearchResponse(BaseModel):
flights: list[dict] = Field(
..., description="Available flights with number, departure time, and price"
)
origin: str = Field(..., description="Origin airport code")
destination: str = Field(..., description="Destination airport code")
status: str = Field(default="success", description="Search operation status")
message: str = Field(default="", description="Additional status message")
# Register tools for simulation
@tool_simulator.tool(
share_state_id="flight_booking",
initial_state_description="Flight booking system: SEA->JFK flights at 8am, 12pm, and 6pm. No bookings currently active.",
output_schema=FlightSearchResponse,
)
def search_flights(origin: str, destination: str, date: str) -> dict[str, Any]:
"""Search for available flights between two airports on a given date."""
pass
@tool_simulator.tool(share_state_id="flight_booking")
def get_booking_status(booking_id: str) -> dict[str, Any]:
"""Retrieve the current status of a flight booking by booking ID."""
pass
# Define the evaluation task
def user_task_function(case: Case) -> dict:
initial_state = tool_simulator.get_state("flight_booking")
print(f"[State before]: {initial_state.get('initial_state')}")
search_tool = tool_simulator.get_tool("search_flights")
status_tool = tool_simulator.get_tool("get_booking_status")
agent = Agent(
trace_attributes={
"gen_ai.conversation.id": case.session_id,
"session.id": case.session_id
},
system_prompt="You are a flight booking assistant.",
tools=[search_tool, status_tool],
callback_handler=None,
)
agent_response = agent(case.input)
print(f"[User]: {case.input}")
print(f"[Agent]: {agent_response}")
final_state = tool_simulator.get_state("flight_booking")
print(f"[State after]: {final_state.get('previous_calls', [])}")
finished_spans = memory_exporter.get_finished_spans()
mapper = StrandsInMemorySessionMapper()
session = mapper.map_to_session(finished_spans, session_id=case.session_id)
return {"output": str(agent_response), "trajectory": session}
# Define test cases, run the experiment, and display the report
test_cases = [
Case(
name="flight_search",
input="Find me flights from Seattle to New York on March 15.",
metadata={"category": "flight_booking"},
),
]
experiment = Experiment[str, str](
cases=test_cases,
evaluators=[GoalSuccessRateEvaluator()]
)
reports = experiment.run_evaluations(user_task_function)
reports[0].run_display()
A função de tarefa recupera as ferramentas simuladas, cria um agente, executa a interação e retorna tanto a saída do agente quanto a trajetória completa de telemetria. Essa trajetória dá aos avaliadores como o GoalSuccessRateEvaluator acesso à sequência completa de chamadas de ferramentas e invocações do modelo — não apenas à resposta final.
Boas práticas para avaliação baseada em simulação
Comece com a configuração padrão para cobertura ampla. Adicione overrides apenas para os ambientes de ferramentas que você precisa controlar com precisão.
Forneça valores ricos em initial_state_description para ferramentas com estado: inclua faixas de dados, contagens de entidades e contexto de relacionamentos.
Use share_state_id para ferramentas que interagem com o mesmo backend, garantindo que operações de escrita sejam visíveis para leituras subsequentes.
Aplique output_schema para ferramentas que seguem especificações rígidas, como OpenAPI ou MCP.
Valide sequências de interação com ferramentas, não apenas saídas finais — inspecione mudanças de estado antes e depois da execução do agente.
Comece pelos cenários de interação mais comuns e expanda para casos extremos conforme sua prática de avaliação amadurece.
Complemente os testes baseados em simulação com testes pontuais contra APIs reais para caminhos críticos de produção.
Como começar
A instalação é feita com um único comando:
pip install strands-evals
Para continuar explorando o ToolSimulator e o Strands Evals, a AWS recomenda consultar a documentação do Strands Evals para ver todas as opções de configuração, incluindo gerenciamento avançado de estado e avaliadores personalizados. Também é possível experimentar o exemplo oficial para ver o ToolSimulator em ação e estendê-lo com mais ferramentas e fluxos multi-etapas.
Para o backend de LLM que alimenta a geração de respostas do ToolSimulator, a AWS indica o Amazon Bedrock. Para estratégias de implantação serverless de agentes que funcionam bem com testes baseados em ToolSimulator, vale explorar o AWS Lambda.
A AWS disponibilizou o AWS IoT Greengrass v2.17, trazendo duas grandes novidades: suporte à instalação como usuário não-root em sistemas Linux e a introdução de componentes mais leves, projetados para consumir muito menos memória na borda.
Para quem não conhece, o AWS IoT Greengrass é um runtime de borda e serviço de nuvem voltado para a Internet das Coisas (IoT — Internet of Things). Ele ajuda equipes a construir, implantar e gerenciar software diretamente nos dispositivos, sem depender de conectividade constante com a nuvem.
Instalação sem root: mais segurança em ambientes regulados
Uma das mudanças mais relevantes desta versão é justamente a possibilidade de instalar e executar o Greengrass sem precisar de privilégios de superusuário (root). Em ambientes corporativos e setores regulados — como saúde, finanças e indústria —, políticas de segurança frequentemente proíbem o uso de root em sistemas de produção. Com essa atualização, a AWS elimina um obstáculo prático que impedia muitas organizações de adotar o serviço nesses contextos.
Ciclo de vida de desinstalação automática
A versão v2.17 também adiciona uma capacidade de ciclo de vida de desinstalação (uninstall lifecycle) que é ativada automaticamente quando um componente é removido de um dispositivo. Isso simplifica o gerenciamento de dependências, evitando que resíduos de componentes antigos causem conflitos ou ocupem recursos desnecessários.
Novos componentes nucleus lite: menos memória, mesma funcionalidade
Outra frente importante desta versão é a expansão das capacidades do nucleus lite, focado em reduzir o consumo de recursos na borda. As novidades incluem:
Componente Secure Tunneling lite: agora utiliza apenas 4 MB de memória, uma redução expressiva em comparação aos 36 MB do componente padrão — uma queda de mais de 88%.
Componente Fleet Provisioning atualizado: passa a suportar o Módulo de Plataforma Confiável (TPM — Trusted Platform Module) 2.0, viabilizando operações criptográficas e gerenciamento seguro de identidade dos dispositivos.
Interface PKCS#11 (Padrão Criptográfico de Chave Pública — Public Key Cryptographic Standard): permite que o componente nucleus lite do Greengrass se autentique com o AWS IoT Core usando chaves e certificados armazenados em um Módulo de Segurança de Hardware (HSM — Hardware Security Module).
Disponibilidade
O AWS IoT Greengrass v2.17 já está disponível em todas as regiões da AWS onde o serviço é oferecido. Para conhecer todos os detalhes das novidades, a AWS disponibiliza a documentação oficial do AWS IoT Greengrass. Quem quiser dar os primeiros passos com o serviço pode acessar o guia de introdução.
O desafio de construir sistemas de pedidos com voz em múltiplos canais
Criar um sistema de pedidos ativado por voz que funcione ao mesmo tempo em aplicativos móveis, sites e interfaces de voz — o que chamamos de abordagem omnichannel — envolve desafios técnicos reais. É preciso processar fluxos de áudio bidirecionais, manter o contexto da conversa ao longo de múltiplos turnos, integrar serviços de backend sem acoplamento rígido e escalar para suportar picos de tráfego.
A AWS publicou um guia técnico detalhado mostrando como construir um sistema completo de pedidos omnichannel usando o Amazon Bedrock AgentCore — uma plataforma agêntica para construir, implantar e operar agentes de IA de forma segura e escalável — combinado com o Amazon Nova 2 Sonic, modelo de voz em tempo real disponível no Amazon Bedrock.
Visão geral da solução
A arquitetura proposta separa o frontend, o agente de IA e os serviços de backend em componentes distintos, permitindo que cada camada seja desenvolvida e escalada de forma independente. A comunicação entre o agente e os serviços de negócio é feita via Protocolo de Contexto de Modelo (MCP), um padrão aberto para conectar aplicações de IA a fontes de dados externas, ferramentas e fluxos de trabalho.
Os principais serviços utilizados na solução são:
Amazon Cognito — gerencia autenticação de usuários e fornece credenciais temporárias da AWS para acesso seguro à API, compatível com qualquer provedor de identidade OAuth 2.0.
Amazon Bedrock AgentCore Runtime — hospeda o agente de IA com isolamento em microVM. Cada sessão de usuário roda em uma máquina virtual isolada, garantindo segurança e desempenho mesmo sob alta carga.
Amazon Bedrock AgentCore Gateway — oferece uma forma segura de construir, implantar, descobrir e conectar ferramentas em escala, permitindo comunicação padronizada entre o agente e a lógica de negócio sem acoplamento rígido.
A solução é organizada em quatro seções principais. A Seção A cobre a infraestrutura de backend, que provisiona armazenamento de dados para clientes, pedidos, cardápios, carrinhos e localizações, além de funções Lambda, uma camada de API e serviços de autenticação. A Seção B implanta o AgentCore Gateway com as permissões de serviço necessárias e configura a integração de API para expor os endpoints de backend como ferramentas acessíveis pelo agente. A Seção C configura o ambiente de execução do AgentCore Runtime com suporte a protocolo WebSocket, usando Amazon ECR para armazenamento de containers e AWS CodeBuild para automação de build. A Seção D implanta a aplicação frontend via AWS Amplify.
O fluxo de uma requisição funciona da seguinte forma: o usuário acessa a aplicação web hospedada no AWS Amplify pelo navegador ou dispositivo móvel e se autentica no Amazon Cognito com usuário e senha, recebendo tokens JWT (Token de Acesso e Token de ID). O frontend troca o Token de ID pelo Identity Pool do Cognito para obter credenciais temporárias da AWS. Com essas credenciais, o frontend abre uma conexão WebSocket assinada com SigV4 para o AgentCore Runtime e envia o Token de Acesso como primeira mensagem para verificação de identidade. O agente valida o token chamando a API GetUser do Cognito, extrai o nome, e-mail e ID do cliente verificados, e inicializa o modelo Nova 2 Sonic com um prompt de sistema personalizado. A partir daí, o usuário fala seu pedido, o agente processa a entrada de voz, invoca ferramentas de forma assíncrona via MCP pelo AgentCore Gateway, e o Nova 2 Sonic gera uma resposta de voz contextual que é transmitida de volta ao usuário pela conexão WebSocket.
Gerenciamento de dados serverless e serviços de localização
O backend utiliza cinco tabelas no DynamoDB que suportam o fluxo completo de pedidos:
Tabela de Clientes — armazena perfis com nome, e-mail, telefone, nível de fidelidade e pontos para recomendações personalizadas.
Tabela de Pedidos — armazena o histórico de pedidos com dados de localização e usa um Índice Secundário Global para consultas por localização.
Tabela de Cardápio — armazena itens específicos por localização com preços e disponibilidade variável por restaurante.
Tabela de Carrinhos — armazena carrinhos de compras temporários com TTL de 24 horas para limpeza automática.
Tabela de Localizações — armazena dados de restaurantes como coordenadas, horários e taxas para cálculos de pedidos e recomendações.
O AWS Location Services oferece três recursos implantados na solução: um Índice de Lugares (Esri) para geocodificação e busca de endereços, um Calculador de Rotas (Esri) para calcular rotas e tempos de desvio, e um Mapa (estilo VectorEsriNavigation) para visualização interativa. As funções Lambda fornecem três capacidades: busca do local mais próximo por GPS usando a fórmula haversine, busca baseada em rota identificando restaurantes dentro de um tempo de desvio especificado (padrão de 10 minutos), e geocodificação de endereços quando o GPS não está disponível. Isso permite recomendações contextuais como “encontrei um local a 2 minutos da sua rota”.
Processamento de voz com Amazon Bedrock AgentCore
O agente de IA processa interações de voz por meio do Amazon Bedrock AgentCore. Cada sessão de usuário roda em uma microVM isolada, mantendo as sessões seguras e com bom desempenho mesmo sob alta carga. O AgentCore oferece escalabilidade automática, monitoramento integrado e suporte a WebSocket para voz em tempo real. O agente usa o framework Strands para definir prompts de sistema, ferramentas e o fluxo da conversa.
O Amazon Nova 2 Sonic oferece as seguintes capacidades:
Reconhecimento de fala em diferentes sotaques com tolerância a ruído de fundo
Adaptação da resposta de voz ao tom e sentimento do usuário
Streaming bidirecional com baixa latência
Chamada assíncrona de ferramentas que busca dados em paralelo sem bloquear a conversa
Tratamento de interrupções para turnos naturais de conversa
Consciência de contexto ao longo de múltiplos turnos
O fluxo de processamento de voz funciona assim: o áudio é enviado pelo frontend (PCM a 16 kHz) via WebSocket para o AgentCore Runtime. O Nova 2 Sonic transcreve a fala, o agente determina a intenção e seleciona as ferramentas, invoca-as de forma assíncrona via MCP, e o AgentCore Gateway traduz as chamadas MCP em chamadas REST para a API Gateway. As funções Lambda executam a lógica de negócio e retornam os resultados, que o agente incorpora na resposta. O Nova 2 Sonic gera a saída de voz e a transmite de volta ao frontend.
Autenticação e fluxo de conexão WebSocket
A solução usa pools de usuários e pools de identidade do Amazon Cognito para controle de acesso seguro baseado em funções. Os usuários fazem login com usuário e senha no Pool de Usuários do Cognito, recebendo tokens JSON Web Token (JWT) — Token de Acesso e Token de ID. O frontend troca o Token de ID pelo Identity Pool do Cognito para obter credenciais temporárias da AWS (Chave de Acesso, Chave Secreta, Token de Sessão). Essas credenciais assinam a conexão WebSocket com o AgentCore Runtime e as requisições ao API Gateway usando Signature Version 4 (SigV4).
Com as credenciais temporárias, o frontend abre uma conexão WebSocket assinada com SigV4 diretamente para o AgentCore Runtime e envia o Token de Acesso para verificação de identidade. O navegador então transmite áudio PCM a 16 kHz e recebe respostas de voz, transcrições e notificações de invocação de ferramentas pela mesma conexão — sem necessidade de um proxy do lado do servidor.
Interação por voz e pedidos dinâmicos
O diagrama a seguir ilustra como uma consulta de pedido de um cliente é processada por chamada assíncrona de ferramentas. Quando o cliente diz “quero fazer um pedido”, o agente invoca múltiplas ferramentas em paralelo (GetCustomerProfile, GetPreviousOrders, GetMenu) pelo AgentCore Gateway, que as traduz em chamadas REST para o API Gateway. As funções Lambda consultam o DynamoDB e retornam os resultados de volta pelo gateway. O Nova 2 Sonic então gera uma resposta contextual incorporando todos os resultados das ferramentas, criando uma experiência personalizada ao longo da conversa.
git clone https://github.com/aws-samples/sample-omnichannel-ordering-with-amazon-bedrock-agentcore-and-nova-sonic
cd sample-omnichannel-ordering-with-amazon-bedrock-agentcore-and-nova-sonic
Em seguida, execute o script de implantação. Ambos os parâmetros são obrigatórios — o endereço de e-mail receberá uma senha temporária para o usuário de teste inicial no Cognito:
O script executa verificações antes da implantação para validar Node.js, Python, AWS CLI, CDK, credenciais, bootstrap do CDK e acesso ao modelo Nova 2 Sonic no Bedrock. Se alguma verificação falhar, o script reporta o que está faltando e oferece instalar automaticamente o que for possível.
Após as verificações, o script executa cinco etapas. As etapas 1 a 3 são totalmente automatizadas. A etapa 4 (Dados Sintéticos) solicita uma localização como cidade, CEP ou endereço para usar como ponto central na busca de restaurantes próximos, um tipo de comida para buscar (ex: pizza, hambúrguer, café, sanduíche, tacos), se deseja reutilizar o mesmo endereço como residência do cliente, e uma confirmação antes de gravar os dados gerados no DynamoDB. A etapa 5 (Configuração de Senha) oferece a opção de alterar a senha temporária do Cognito enviada por e-mail.
Ao final, o script exibe a URL do frontend (ex: https://main.<app-id>.amplifyapp.com) para acessar a aplicação.
Experiência de pedido por voz
Ao abrir a URL do frontend no navegador e fazer login, o usuário aciona o botão de microfone para iniciar uma conversa por voz com o agente de pedidos. O agente cumprimenta o usuário pelo nome, obtém a localização pelo navegador e carrega os pedidos anteriores em segundo plano. É possível falar naturalmente: repetir um pedido anterior, navegar pelo cardápio, encontrar locais de retirada próximos à rota ou montar um pedido novo do zero. O agente responde por voz em tempo real, trata perguntas sobre o cardápio, adiciona itens ao carrinho e confirma o pedido com total e tempo estimado de retirada. Toda a conversa acontece sem usar as mãos, por uma única conexão WebSocket, e o agente chama as ferramentas de backend de forma assíncrona — sem pausas enquanto os dados são buscados.
Limpeza dos recursos
Para remover a solução e seus recursos associados, basta executar:
./cleanup-all.sh
Conclusão
A solução apresentada pela AWS demonstra como construir um sistema de pedidos omnichannel combinando Amazon Cognito para autenticação, Amazon Bedrock AgentCore para hospedagem do agente, API Gateway para comunicação de dados, DynamoDB para armazenamento e Location Services para otimização de rotas. A arquitetura em três camadas separa frontend, agente e backend para desenvolvimento e escalabilidade independentes.
O Amazon Nova 2 Sonic oferece interações de voz com baixa latência, chamada assíncrona de ferramentas e tratamento de interrupções. A chamada paralela de ferramentas reduz os tempos de espera, o reconhecimento de voz funciona em diferentes sotaques, as recomendações personalizadas usam o histórico de pedidos e os locais de retirada otimizados por rota ajudam os clientes a encontrar pontos convenientes. O modelo de precificação por uso e a escalabilidade automatizada controlam os custos conforme o uso cresce. Com a integração via MCP, é possível adaptar a solução adicionando novas funções Lambda sem modificar o código do agente.
Novas instâncias G7e chegam ao Amazon SageMaker AI
A AWS anunciou a disponibilidade das instâncias G7e no Amazon SageMaker AI, alimentadas pelas GPUs NVIDIA RTX PRO 6000 Blackwell Server Edition. Essa novidade representa um salto relevante para quem precisa executar inferência de Modelos de Fundação (FMs) de grande porte com eficiência de custo.
As instâncias G7e estão disponíveis nas configurações de 1, 2, 4 e 8 GPUs, com cada GPU oferecendo 96 GB de memória GDDR7. O destaque prático é a possibilidade de hospedar modelos de linguagem de grande porte (LLMs) poderosos — como GPT-OSS-120B, Nemotron-3-Super-120B-A12B (variante NVFP4) e Qwen3.5-35B-A3B — em uma única instância de nó, o ml.g7e.2xlarge, sem necessidade de configurações multi-GPU.
O que muda em relação às gerações anteriores
Para entender o salto que as G7e representam, vale comparar as três gerações da família G da AWS na configuração de 8 GPUs:
G5 (g5.48xlarge): 8x NVIDIA A10G, 24 GB GDDR6 por GPU, 192 GB de memória total, 600 GB/s de largura de banda por GPU, rede de 100 Gbps e 7,6 TB de armazenamento NVMe local.
G6e (g6e.48xlarge): 8x NVIDIA L40S, 48 GB GDDR6 por GPU, 384 GB de memória total, 864 GB/s de largura de banda por GPU, rede de 400 Gbps e 7,6 TB de armazenamento NVMe local.
G7e (g7e.48xlarge): 8x NVIDIA RTX PRO 6000 Blackwell, 96 GB GDDR7 por GPU, 768 GB de memória total, 1.597 GB/s de largura de banda por GPU, rede de 1.600 Gbps com EFA e 15,2 TB de armazenamento NVMe local.
Os principais destaques das G7e em relação à geração anterior incluem:
O dobro de memória GPU em comparação com as G6e, permitindo o deployment de LLMs em FP16 com até 35 bilhões de parâmetros em um único nó GPU (g7e.2xlarge), 150 bilhões de parâmetros em 4 GPUs (g7e.24xlarge) e 300 bilhões de parâmetros em 8 GPUs (g7e.48xlarge).
Até 1.600 Gbps de throughput de rede com Elastic Fabric Adapter (EFA) — um aumento de 4x sobre a G6e e 16x sobre a G5.
Até 768 GB de memória GPU agregada na g7e.48xlarge.
Desempenho de inferência até 2,3x superior em relação à G6e.
Com 768 GB de memória GPU agregada em uma única instância, a G7e consegue hospedar modelos que antes exigiam configurações multi-nó nas G5 ou G6e, reduzindo a complexidade operacional e a latência entre nós. Somado ao suporte à precisão FP4 com Tensor Cores de quinta geração e ao NVIDIA GPUDirect RDMA sobre EFAv4, as instâncias G7e se posicionam como a escolha principal para deployment de LLMs, IA multimodal e cargas de trabalho de inferência agêntica na AWS.
Casos de uso ideais para as instâncias G7e
A combinação de densidade de memória, largura de banda e capacidade de rede das G7e as torna adequadas para uma ampla gama de cargas de trabalho de IA generativa:
Chatbots e IA conversacional: baixo Tempo para Primeiro Token (TTFT) e alto throughput mantêm experiências interativas responsivas mesmo sob carga concorrente elevada.
Fluxos de trabalho agênticos e com chamada de ferramentas: a melhoria de 4x na largura de banda CPU-GPU torna a G7e especialmente eficaz para pipelines de Geração Aumentada por Recuperação (RAG) e fluxos agênticos, onde a injeção rápida de contexto a partir de repositórios de recuperação é crítica.
Geração de texto, sumarização e inferência de contexto longo: os 96 GB de memória por GPU acomodam caches KV grandes para contextos de documentos extensos, reduzindo truncamentos e permitindo raciocínio mais rico sobre entradas longas.
Geração de imagens e modelos de visão: onde instâncias anteriores encontravam erros de falta de memória em modelos multimodais maiores, a memória dobrada da G7e resolve essas limitações.
IA física e computação científica: a computação da geração Blackwell, o suporte a FP4 e as capacidades de computação espacial (DLSS 4.0, RT cores de 4ª geração) estendem a aplicabilidade da G7e para gêmeos digitais, simulação 3D e inferência de modelos de IA física.
Como realizar o deployment
Pré-requisitos
Para experimentar a solução usando o SageMaker AI, são necessários os seguintes itens:
Acesso ao Amazon SageMaker Studio ou a uma instância de notebook do SageMaker, ou a um Ambiente de Desenvolvimento Integrado (IDE) como PyCharm ou Visual Studio Code. O SageMaker Studio é a opção recomendada para deployment e inferência simplificados.
Cota para pelo menos uma instância ml.g7e.2xlarge para uso de endpoint do Amazon SageMaker AI. É possível solicitar aumento de cota pelo console de Cotas de Serviço.
Para quantificar a melhoria geracional, a AWS realizou benchmarks do modelo Qwen3-32B (BF16) nas instâncias G6e e G7e com a mesma carga de trabalho: aproximadamente 1.000 tokens de entrada e 560 tokens de saída por requisição — representativo de tarefas de sumarização ou correção de documentos. Ambas as configurações utilizam o contêiner nativo vLLM com cache de prefixo habilitado.
Linha de base G6e: ml.g6e.12xlarge (4x L40S, US$ 13,12/hora)
Com 4 GPUs L40S e grau de paralelismo tensorial 4, a G6e entrega throughput sólido por requisição: 37,1 tok/s em concorrência simples e 21,5 tok/s em C=32. O custo por milhão de tokens de saída nessa configuração vai de US$ 38,09 (C=1) a US$ 2,06 (C=32).
G7e: ml.g7e.2xlarge (1x RTX PRO 6000 Blackwell, US$ 4,20/hora)
A G7e executa o mesmo modelo de 32 bilhões de parâmetros em uma única GPU com grau de paralelismo tensorial 1. Embora o tok/s por requisição seja menor do que a configuração de 4 GPUs da G6e, a história de custo é dramaticamente diferente: o custo por milhão de tokens de saída vai de US$ 21,32 (C=1) a US$ 0,79 (C=32).
Em produção com concorrência C=32, a G7e alcança US$ 0,79 por milhão de tokens de saída, uma redução de custo de 2,6x em relação aos US$ 2,06 da G6e. Isso é impulsionado por dois fatores: a taxa horária significativamente menor da G7e (US$ 4,20 vs. US$ 13,12) e sua capacidade de manter throughput consistente sob carga.
A arquitetura de GPU única da G7e também escala de forma mais previsível. A latência aumenta 22% de C=1 a C=32 (de 27,2s para 33,2s), em comparação com 62% na G6e (de 16,1s para 26,0s). Com grau de paralelismo tensorial 1, não há overhead de sincronização entre GPUs, operações all-reduce a cada camada transformer, fragmentação de cache KV entre GPUs ou gargalos de comunicação NVLink. Para cargas de trabalho sensíveis à latência em baixa concorrência, o paralelismo de 4 GPUs da G6e ainda entrega respostas individuais mais rápidas. Para deployments em produção otimizando custo por token em escala, a G7e é a escolha clara.
As melhorias de hardware das G7e são significativas por si só, mas combiná-las com a decodificação especulativa EAGLE (Algoritmo de Extrapolação para Maior Eficiência de Modelos de Linguagem) produz ganhos compostos. O EAGLE acelera a decodificação de LLMs prevendo múltiplos tokens futuros a partir das próprias representações ocultas do modelo e, em seguida, verificando-os em um único passo forward. Isso produz qualidade de saída idêntica enquanto gera múltiplos tokens por etapa. Para um guia detalhado do EAGLE no SageMaker AI, consulte o post Amazon SageMaker AI apresenta decodificação especulativa adaptativa baseada em EAGLE para acelerar a inferência de IA generativa.
Os benchmarks foram realizados com Qwen3-32B em BF16, com o EAGLE3 habilitado usando um especulador treinado pela comunidade (~1,56 GB) com num_speculative_tokens=4.
G7e + EAGLE3 entrega uma melhoria de throughput de 2,4x e redução de custo de 75% sobre a linha de base da geração anterior. Com US$ 0,41 por milhão de tokens de saída, é também 4x mais barato que G6e + EAGLE3 (US$ 1,72), apesar de oferecer throughput superior.
O gráfico acima mostra como a G7e com GPU única (TP=1) mantém ganhos de speedup do EAGLE3 mais consistentes sob carga crescente em comparação com a G6e com 4 GPUs (TP=4). Enquanto a G6e cai de 2,3x para 1,2x de speedup entre C=1 e C=32, a G7e mantém de 2,6x para 1,9x no mesmo intervalo.
Para deployments em produção com modelos ajustados (fine-tuned), o toolkit de otimização EAGLE do SageMaker AI pode treinar cabeças EAGLE personalizadas com dados próprios, melhorando ainda mais a taxa de aceitação especulativa e o throughput além do que especuladores da comunidade proporcionam.
Preços
As instâncias G7e no Amazon SageMaker AI são cobradas com os preços padrão de inferência do SageMaker AI para o tipo de instância e duração de uso selecionados. Não há taxa adicional por token ou por requisição para servir na G7e.
Os jobs de otimização EAGLE são executados em instâncias de treinamento do SageMaker AI e cobrados pela taxa padrão de instância de treinamento pelo tempo de duração do job. Os artefatos do modelo otimizado resultante são armazenados no Amazon Simple Storage Service (Amazon S3) com as taxas de armazenamento padrão. Não há cobrança adicional pela inferência acelerada pelo EAGLE após o deployment do modelo otimizado — paga-se apenas o custo padrão da instância de endpoint.
A tabela a seguir apresenta os preços sob demanda para os principais tamanhos de instâncias G7e, G6e e G5 no Leste dos EUA (Norte da Virgínia) para referência:
ml.g5.2xlarge: 1 GPU, 24 GB — LLMs pequenos (≤7B FP16); desenvolvimento e testes.
ml.g5.48xlarge: 8 GPUs, 192 GB — Serving de LLMs grandes multi-GPU na G5.
ml.g6e.2xlarge: 1 GPU, 48 GB — LLMs de médio porte (≤14B FP16).
ml.g6e.12xlarge: 2 GPUs, 96 GB — LLMs grandes (≤36B FP16); linha de base da geração anterior.
ml.g6e.48xlarge: 8 GPUs, 384 GB — LLMs muito grandes (≤90B FP16).
ml.g7e.2xlarge: 1 GPU, 96 GB — LLMs grandes (≤70B FP8) em uma única GPU.
ml.g7e.24xlarge: 4 GPUs, 384 GB — LLMs muito grandes; serving de alto throughput.
ml.g7e.48xlarge: 8 GPUs, 768 GB — Throughput máximo; modelos de maior porte.
Também é possível reduzir os custos de inferência com os Amazon SageMaker Savings Plans, que oferecem descontos de até 64% em troca de um compromisso com um volume de uso consistente. Esses planos são adequados para endpoints de inferência em produção com tráfego previsível.
Limpeza de recursos
Para evitar cobranças desnecessárias após concluir os testes, é recomendado excluir os endpoints do SageMaker criados durante o processo. Isso pode ser feito pelo console do SageMaker AI ou com o SDK Python, conforme descrito no Guia do Desenvolvedor do Amazon SageMaker AI. Se um job de otimização EAGLE foi executado, também é recomendado excluir os artefatos de saída do Amazon S3 para evitar cobranças de armazenamento contínuas.
Conclusão
As instâncias G7e no Amazon SageMaker AI representam o próximo salto significativo em inferência de IA generativa com eficiência de custo. A arquitetura de GPU Blackwell entrega 2x de memória por GPU, 1,85x de largura de banda de memória e até 2,3x de desempenho de inferência sobre a G6e. Isso permite que cargas de trabalho que antes exigiam múltiplas GPUs sejam executadas eficientemente em uma única GPU, elevando o teto de throughput para cada configuração.
Combinados com a decodificação especulativa EAGLE do SageMaker AI, os ganhos se compõem ainda mais. A aceleração do EAGLE, limitada pela largura de banda de memória, se beneficia diretamente da maior largura de banda da G7e, enquanto a maior capacidade de memória da G7e permite que as cabeças de rascunho do EAGLE coexistam com modelos maiores sem pressão de memória. Juntas, as melhorias de hardware e software entregam ganhos de throughput que se traduzem diretamente em menor custo por token de saída em escala.
O AWS CloudHSM é o serviço da AWS para geração, armazenamento, importação, exportação e gerenciamento de chaves criptográficas em hardware dedicado. Ele também suporta funções de hash para cálculo de resumos de mensagens e Códigos de Autenticação de Mensagens Baseados em Hash (HMACs), além de assinatura e verificação de dados.
Para garantir redundância e simplificar a recuperação de desastres, a AWS recomenda clonar o cluster CloudHSM para uma Região diferente. Esse processo permite sincronizar chaves entre Regiões — incluindo as chamadas chaves não exportáveis, que nunca saem do dispositivo HSM em texto simples e só podem ser sincronizadas para clusters clonados.
Neste guia, a AWS descreve como usar o recurso CopyBackupToRegion para clonar um cluster da Região 1 para uma Nuvem Privada Virtual (VPC) na Região 2. O processo é feito em dois passos: copiar um backup para a Região de destino e criar um novo cluster a partir desse backup.
Atenção: A partir de 1º de janeiro de 2025, as ferramentas do Client SDK 3 (CMU e KMU) não têm mais suporte. Todo este guia usa exclusivamente comandos do Client SDK 5 (versão 5.17 ou superior).
Como funciona o processo
O CloudHSM cria um backup do cluster e o armazena em um bucket do Amazon Simple Storage Service (Amazon S3) pertencente ao próprio serviço. Em seguida, você usa a Interface de Linha de Comando da AWS (AWS CLI) para copiar esse backup para outra Região. Com o backup disponível na Região de destino, você cria um novo cluster e os módulos de segurança de hardware (HSMs) a partir dele.
Permissões de Gerenciamento de Identidade e Acesso da AWS (IAM) para as APIs do CloudHSM em ambas as Regiões
Client SDK 5 instalado na instância de gerenciamento (versão 5.17 ou superior recomendada)
Observação importante: A sincronização de chaves entre clusters em mais de uma Região só funciona se todos os clusters forem criados a partir do mesmo backup. Isso ocorre porque a sincronização exige a presença da mesma chave secreta — chamada de masking key — no HSM de origem e no de destino. Essa chave é específica de cada cluster, não pode ser exportada e serve exclusivamente para sincronizar chaves entre HSMs de um mesmo cluster.
Passo 1: Criar o primeiro cluster na Região 1
Criar o cluster
Substitua <SUBNET_ID_1> por uma das suas sub-redes privadas e anote o ID do cluster retornado:
Substitua <CLUSTER_ID> pelo ID anotado anteriormente e <AVAILABILITY_ZONE> pela Zona de Disponibilidade correspondente à sua sub-rede privada (por exemplo, us-east-1a):
Antes de inicializar o cluster, crie um certificado autoassinado e use-o para assinar a Requisição de Assinatura de Certificado (CSR) do cluster. Com o certificado assinado em mãos, inicialize o cluster:
Após ativar, saia com quit e faça login novamente com a nova senha usando login --username admin --role admin. Em seguida, crie o primeiro usuário criptográfico (CU) com o comando abaixo. Para mais informações sobre tipos de usuário, consulte os tipos de usuário HSM para o CloudHSM CLI.
user create --username <USERNAME> --role crypto-user
Para copiar o backup da Região 1 para a Região 2, você precisa da Região de destino e do ID do cluster ou do backup. Se informar apenas o ID do cluster, o backup mais recente será utilizado. Para um backup específico, use o ID do backup:
Transferência de certificado e configuração do grupo de segurança
Copie o conteúdo do certificado do cluster original para um novo arquivo no cluster da Região 2. O certificado é necessário para conexões criptografadas entre o cliente e as instâncias HSM.
Em seguida, adicione o Grupo de Segurança do cluster clonado à sua instância EC2 cliente: selecione o Grupo de Segurança da instância EC2 no console, escolha “Adicionar regras” e adicione uma regra que permita tráfego do ID do Grupo de Segurança do cluster na porta 2225.
Recupere o endereço IP da ENI do HSM na Região 2 — você precisará dele no próximo passo:
Para que o CloudHSM CLI se comunique simultaneamente com os dois clusters, adicione o cluster da Região 2 à configuração do cliente usando o endereço IP da ENI obtido anteriormente:
A partir desse ponto, o CloudHSM CLI se comunicará com ambos os clusters simultaneamente, usando os certificados já configurados e a masking key compartilhada entre os clusters clonados.
Passo 6: Sincronizar chaves entre os clusters
Listar usuários e chaves
Antes de replicar, verifique quais usuários e chaves existem:
# Listar todos os usuários
cloudhsm-cli user list
# Listar chaves de um usuário específico
cloudhsm-cli key list --username <username>
Replicar chaves
Para replicar uma chave da Região 1 para a Região 2:
Verifique a replicação listando as chaves novamente. O output deve mostrar referências de chaves idênticas em ambos os clusters. Repita o processo para cada chave adicional que precisar sincronizar.
Pontos de atenção após a clonagem
Usuários criados após o backup inicial precisam ser criados manualmente nos dois clusters.
Alterações de senha em um cluster precisam ser replicadas manualmente para o outro.
Chaves criadas após o backup inicial precisam ser sincronizadas com pelo menos um HSM do cluster clonado — depois disso, a sincronização automática do CloudHSM cuida do restante dentro do segundo cluster.
Mantenha as ferramentas do Client SDK 5 atualizadas para ter acesso aos recursos mais recentes e melhorias de segurança.
O Client SDK 5 oferece suporte à arquitetura ARM64 nas seguintes distribuições Linux: Amazon Linux 2023, Amazon Linux 2, Red Hat Enterprise Linux (RHEL) 8 (8.3+), RHEL 9 (9.2+), RHEL 10 (10.0+), Ubuntu 22.04 LTS, Ubuntu 24.04 LTS, Debian 12 e SUSE Linux Enterprise Server 15.
Conclusão
Seguindo esse processo, é possível configurar um ambiente AWS CloudHSM tolerante a falhas, com chaves sincronizadas entre Regiões usando as ferramentas e práticas recomendadas mais recentes. A configuração de clusters entre Regiões traz melhorias na recuperação de desastres, reduz o risco de perda de dados e garante a continuidade das operações criptográficas — assegurando que as chaves críticas permaneçam disponíveis mesmo diante de uma falha regional. Dúvidas ou comentários podem ser enviados ao AWS re:Post.
A semana foi dominada por IA em produção com foco em três frentes: segurança de agentes, controle de custos e inferência eficiente. O Model Context Protocol trouxe diretrizes concretas para aplicar IAM em sistemas não-determinísticos, enquanto o Bedrock ganhou rastreamento granular de custos por tenant — dois gargalos reais de quem já tem IA rodando. A destilação de modelos com redução de 95% em custos valida uma estratégia que muitos times ainda ignoram. No lado da infraestrutura, Secrets Manager com TLS pós-quântico e Payment Cryptography em São Paulo reforçam que compliance também evoluiu esta semana.
O que muda na prática
Agentes de IA agora têm um padrão de referência para controle de acesso via IAM com MCP — arquiteturas sem isso passam a ser tecnicamente defasadas e auditáveis como risco
Rastreamento de custos por usuário, app ou tenant no Bedrock deixa de ser workaround manual e vira recurso nativo — FinOps de IA generativa em produção muda de patamar
Secrets Manager com TLS pós-quântico híbrido entra em vigor sem mudança de código — organizações com roadmap de compliance precisam registrar isso como controle implementado
Ações da semana
Revise as permissões IAM dos seus agentes de IA e valide se seguem o princípio de menor privilégio conforme o padrão MCP publicado — comece pelos agentes com acesso a dados sensíveis ou produção
Ative o rastreamento de custos por tag no Bedrock para pelo menos um projeto de IA em produção e gere o primeiro relatório de atribuição por aplicação ou time esta semana
Com a explosão de agentes de IA acessando recursos AWS, entender como aplicar IAM determinístico a sistemas não-determinísticos é crítico para qualquer arquitetura segura.
Para quem: Arquitetos de segurança e engenheiros cloud que estão construindo ou revisando sistemas com agentes de IA.
A atribuição de custos por usuário, app ou tenant no Bedrock resolve um dos maiores gargalos de governança financeira em projetos de IA generativa em produção.
Para quem: FinOps, arquitetos de plataforma e líderes técnicos que precisam justificar e controlar gastos com IA.
Proteção automática contra ameaças quânticas sem mudança de código é uma atualização de segurança de alto impacto que toda organização deve registrar em seu roadmap de compliance.
Para quem: Engenheiros de segurança, times de compliance e qualquer equipe que usa Secrets Manager em produção.
Redução de 95% em custos e 50% em latência com manutenção de precisão é um resultado concreto que valida destilação como estratégia de otimização para sistemas de IA em escala.
Para quem: Engenheiros de ML e arquitetos que buscam reduzir custos operacionais de inferência sem sacrificar qualidade.
Padronizar logs de segurança para OCSF é pré-requisito para integração com Security Lake e análise centralizada de ameaças, e ter um acelerador open source reduz semanas de trabalho.
Para quem: Times de segurança e operações que precisam integrar fontes de log heterogêneas ao Amazon Security Lake.
Garantir consistência na coleta de telemetria em múltiplas regiões de forma automática elimina lacunas de observabilidade que frequentemente causam incidentes não detectados.
Para quem: Engenheiros de plataforma e SREs responsáveis por observabilidade em ambientes multi-região.
Sincronizar automaticamente assinaturas e SBOMs junto com imagens de container fortalece a cadeia de suprimentos de software sem adicionar processos manuais ao pipeline.
Para quem: Engenheiros DevSecOps e times de plataforma que gerenciam segurança de imagens de container.
Disponibilidade local elimina dependência cross-region para operações criptográficas de pagamento, reduzindo latência e simplificando compliance com regulações brasileiras.
Para quem: Arquitetos e engenheiros de fintechs e empresas de pagamento que operam no Brasil.
Ter acesso à ferramenta de migração e modernização diretamente no editor reduz a fricção para iniciar transformações de legado, acelerando projetos que costumavam levar anos.
Para quem: Desenvolvedores e arquitetos responsáveis por modernização de aplicações e redução de débito técnico.
Preservar dados originais e rastrear transformações em pipelines de log é requisito crescente de auditorias e regulações, e o fato de ser sem custo adicional aumenta a adoção.
Para quem: Times de compliance, segurança e operações que precisam garantir integridade e rastreabilidade de logs.
A AWS anunciou uma expansão importante na funcionalidade do Amazon Elastic Container Registry (Amazon ECR), especificamente no recurso de Pull Through Cache. A partir de agora, o serviço é capaz de descobrir e sincronizar automaticamente referenciadores OCI (Open Container Initiative) a partir de registros anteriores para seus repositórios privados do Amazon ECR.
Os referenciadores incluem artefatos críticos como assinaturas de imagens, SBOMs (Software Bill of Materials — Lista de Materiais de Software) e atestações. Esses elementos são fundamentais para fluxos de trabalho de segurança, rastreabilidade e conformidade em ambientes cloud nativos.
O problema que era enfrentado antes
Anteriormente, quando você tentava listar referenciadores em um repositório que possuía uma regra de Pull Through Cache configurada, o Amazon ECR não retornava nem sincronizava os referenciadores do repositório anterior. Isso significava que era necessário executar processos manuais para localizar e buscar esses artefatos de forma separada, criando uma desconexão no fluxo de trabalho e aumentando a complexidade operacional.
Essa limitação impedia que workflows inteligentes de verificação de assinatura de imagem, descoberta de SBOM e recuperação de atestações funcionassem sem contornos adicionais no lado do cliente.
Como o Amazon ECR resolveu isso
Com esta atualização, o Pull Through Cache do Amazon ECR agora faz o seguinte automaticamente:
Alcança o registro anterior durante requisições de API de referenciadores
Descobre os referenciadores disponíveis no repositório de origem
Sincroniza e cach os artefatos de referenciador relacionados no seu repositório privado do Amazon ECR
Este comportamento automático elimina a necessidade de intervenção manual e permite que fluxos de trabalho complexos funcionem de forma transparente e integrada.
Implicações práticas para seu ambiente
A mudança torna possível que você implemente workflows end-to-end completos sem necessidade de adaptações ou workarounds no código cliente:
Verificação de assinatura de imagem: valide a integridade e a autenticidade das imagens de container automaticamente
Descoberta de SBOM: acesse listas completas de dependências e componentes das imagens
Recuperação de atestação: obtenha evidências de políticas, scans de segurança e outras comprovações associadas às imagens
Todos esses processos agora funcionam de forma nativa com repositórios que usam Pull Through Cache, sem que você precise implementar soluções alternativas.
Disponibilidade
Este recurso está disponível a partir de hoje em todas as regiões AWS onde o Amazon ECR Pull Through Cache é suportado.
Para compreender melhor como configurar e utilizar este recurso em seu ambiente, consulte a documentação do Amazon ECR.
