A AWS anunciou que o AWS Transform agora está dentro do escopo do Programa Federal de Gerenciamento de Risco e Autorização (FedRAMP) — especificamente na classificação Classe C (anteriormente conhecida como baseline Moderada), na região US East (Ohio).
Na prática, isso significa que organizações sujeitas aos requisitos de conformidade do FedRAMP Classe C já podem utilizar o AWS Transform para construir aplicações e executar cargas de trabalho dentro desse padrão regulatório.
O que é o FedRAMP
O FedRAMP é um programa do governo dos Estados Unidos que estabelece uma abordagem padronizada para avaliação de segurança, autorização e monitoramento contínuo de produtos e serviços em nuvem. Ele é exigido para fornecedores de tecnologia que atendem agências federais norte-americanas, funcionando como um selo de conformidade rigoroso no setor público americano.
O AWS Transform é um serviço de migração e modernização com capacidades agênticas — ou seja, ele age de forma autônoma para conduzir processos complexos com menos intervenção manual. O objetivo declarado do serviço é comprimir cronogramas corporativos que normalmente levariam anos para algo na casa de meses.
Entre as capacidades do serviço estão:
Migrações de infraestrutura em larga escala
Redução contínua de débito técnico
Eliminação das transferências manuais e da perda de contexto que costumam travar esses programas
Por que isso importa
A certificação FedRAMP é um requisito crítico para qualquer serviço de nuvem utilizado no setor público americano. Ao atingir o nível Classe C no AWS Transform, a AWS amplia as possibilidades de adoção do serviço por órgãos governamentais e contratados federais nos EUA que precisam garantir conformidade regulatória em seus projetos de modernização.
Para equipes brasileiras que atendem clientes ou parceiros no mercado americano — especialmente no setor público —, essa é uma informação relevante para avaliar o uso do AWS Transform em projetos com requisitos de compliance federal.
Organizações em setores regulados como serviços financeiros, governo, defesa e saúde costumam restringir suas cargas de trabalho a ambientes de rede isolados, sem qualquer acesso à internet pública. Até recentemente, havia uma tensão clara nesse modelo: era possível restringir o acesso ao AWS Management Console a contas e redes corporativas autorizadas, mas o console em si ainda exigia conectividade com a internet para funcionar completamente.
Isso colocava as equipes de segurança diante de uma escolha difícil — permitir alguma saída para a internet para usar o console, ou negar o acesso ao console para operadores que trabalham em ambientes completamente isolados.
A AWS anunciou a disponibilidade geral do AWS Management Console Private Access com suporte a Nuvens Privadas Virtuais (VPCs) sem conectividade com a internet. Agora, todo o tráfego dos consoles de serviço suportados — fluxos de autenticação, assets estáticos (JavaScript, CSS, imagens), APIs exclusivas do console e chamadas às APIs de serviços AWS — pode ser roteado por endpoints de VPC via AWS PrivateLink, eliminando a necessidade de internet gateway, NAT gateway ou qualquer rota para a internet pública. O recurso está disponível em todas as Regiões comerciais da AWS para um conjunto selecionado de consoles de serviço suportados.
O que mudou em relação ao lançamento anterior
Em 2023, a AWS lançou a primeira versão do Console Private Access, que já permitia rotear chamadas de console, sign-in e APIs de serviço por endpoints de VPC. No entanto, os assets estáticos e as APIs exclusivas do console ainda dependiam de conectividade com a internet. Esse gap foi eliminado com este lançamento.
Dois cenários principais atendidos
Tráfego do console em redes sem acesso à internet
Com a atualização, o tráfego dos consoles de serviço suportados flui inteiramente pelos endpoints de VPC — sem listas de domínios permitidos para manter, sem proxies interceptando TLS e sem a necessidade de aceitar fluxos exclusivamente via CLI como solução de contorno. O mesmo caminho funciona a partir do Amazon WorkSpaces, instâncias do Amazon Elastic Compute Cloud (Amazon EC2) e redes on-premises conectadas via AWS Direct Connect ou AWS Site-to-Site VPN.
Combinando com Políticas de Controle de Recursos (RCPs) de sign-in e políticas de recursos de sign-in, é possível garantir que a autenticação no console só seja bem-sucedida a partir de redes esperadas — mesmo que credenciais válidas sejam apresentadas de outro lugar, a sessão é negada.
Prevenção de exfiltração de dados
O Private Access também permite restringir quais contas AWS e identidades organizacionais podem usar o AWS Management Console a partir da VPC. Isso impede o acesso via contas pessoais ou contas fora da organização. Ao anexar uma política de endpoint de VPC com a condição aws:ResourceOrgID, as ações do console ficam automaticamente limitadas a recursos dentro da organização. As RCPs de sign-in adicionam uma segunda camada, garantindo que a autenticação só funcione a partir de redes dentro do perímetro.
Como o tráfego flui em um ambiente sem internet
O Console Private Access utiliza três endpoints de VPC distintos para cobrir todo o tráfego necessário:
Fluxos de autenticação — sign-in, troca de credenciais e requisições de token de sessão
Assets estáticos — JavaScript, CSS e imagens que renderizam a interface do console
Chamadas de API do console de serviço — as requisições de backend feitas quando usuários interagem com os consoles de serviço
O fluxo completo a partir de uma carga de trabalho em uma VPC privada funciona assim: o navegador do operador requisita <região>.console.aws.amazon.com; o encaminhador de DNS corporativo repassa a consulta para um endpoint de entrada do Amazon Route 53 Resolver configurado na VPC, que encaminha o tráfego para o endpoint de VPC do console. O tráfego flui de on-premises via Direct Connect (ou AWS Site-to-Site VPN) até a VPC, e o endpoint de VPC roteia o tráfego para o serviço do console pela rede privada da AWS. O console redireciona para o endpoint de sign-in, que avalia as políticas de endpoint de VPC, políticas baseadas em recursos (RBPs) e RCPs antes de redirecionar de volta ao console. Por fim, o console carrega o conteúdo estático pelo endpoint de VPC do console-static e aplica as restrições de identidade e recurso ao fazer chamadas às APIs dos serviços AWS.
Controles de perímetro de dados aplicados ao console
O Console Private Access e as políticas de recursos de sign-in são uma extensão natural das Políticas de Controle de Serviço (SCPs), RCPs e políticas de endpoint de VPC que as equipes já utilizam para tráfego de API. Agora, os mesmos controles de perímetro de dados para identidade, recurso e rede que protegem o acesso programático também protegem as sessões interativas do navegador.
A tabela de controles cobre quatro objetivos principais:
Identidade: Apenas identidades confiáveis podem acessar recursos — via RCPs e RBPs de sign-in, restringindo quais principals podem autenticar no console usando condições como aws:PrincipalOrgID, aws:PrincipalAccount e aws:PrincipalArn.
Recurso: Identidades só podem acessar recursos confiáveis — via SCP com aws:ResourceOrgID, que segue os principals em cada sessão do console e nega chamadas de API cujo recurso-alvo esteja fora da organização.
Rede (identidade): Identidades só acessam recursos a partir de redes esperadas — via SCPs de perímetro de rede com aws:SourceVpc. Com o Private Access, requisições enviadas pelo console aos serviços suportados carregam aws:SourceVpc definido para a VPC que hospeda os endpoints.
Rede (recurso): Recursos só podem ser acessados a partir de redes esperadas — via RBPs e RCPs de sign-in que negam autenticação no console a partir de redes inesperadas, usando condições como aws:SourceIp, aws:SourceVpc, aws:SourceVpce e aws:VpcSourceIp.
Guia de implantação passo a passo
A AWS recomenda um rollout incremental, validando cada etapa antes de expandir para Regiões e Unidades Organizacionais (OUs) adicionais. Para quem quiser validar a mecânica antes de construir a solução completa, o guia de início rápido com ambiente de teste apresenta uma configuração mínima com uma única VPC, os três endpoints e uma política permissiva.
Pré-requisitos
Uma conta AWS membro de uma organização no AWS Organizations (o exemplo de RCP do Passo 4 requer acesso à conta de gerenciamento)
Antes de qualquer mudança, use o CloudTrail para mapear como os usuários acessam o console hoje. Busque por eventName = ConsoleLogin em uma janela representativa (recomenda-se 30 dias) e revise os campos sourceIPAddress, vpcEndpointId e awsRegion. Identifique quais tipos de identidade estão em uso: usuário root, usuário IAM, federação SAML e AWS IAM Identity Center. Escolha a OU ou conta que será usada no piloto — evite contas de produção ou compartilhadas.
Passo 2: Criar os endpoints de VPC do Private Access
Na Região escolhida, crie ou identifique uma VPC para hospedar os endpoints e, em seguida, crie três endpoints de interface de VPC nessa VPC:
com.amazonaws.<região>.console — para o console
com.amazonaws.<região>.signin — para o AWS Sign-In
com.amazonaws.<região>.console-static — para APIs exclusivas do console (obrigatório apenas se a VPC não tiver caminho para a internet)
Passo 3: Configurar o DNS privado
Para cargas de trabalho dentro da VPC que usam o Amazon Route 53 Resolver padrão, nenhuma configuração adicional de DNS é necessária — basta habilitar o nome de DNS privado em cada endpoint (PrivateDnsEnabled = true). Se você usar um resolver de DNS customizado ou uma zona hospedada privada, é necessário configurá-lo explicitamente para mapear os domínios do console para os endereços dos endpoints. Consulte a documentação de zonas hospedadas privadas e a documentação de endpoints obrigatórios do Console Private Access para a lista completa de domínios.
Para cargas de trabalho fora da VPC — como escritórios corporativos conectados via Direct Connect ou Site-to-Site VPN — garanta que o resolver de DNS corporativo retorne os endereços dos endpoints para esses domínios. O post Simplify DNS management in a multi-account environment with Route 53 Resolver traz orientações detalhadas.
Passo 4: Verificar a conectividade privada
Faça login no console a partir de uma carga de trabalho dentro da VPC. Para confirmar que o tráfego está roteando pelos endpoints de VPC, verifique o ícone de cadeado na barra de navegação do console. Você também pode confirmar no CloudTrail que eventos recentes de ConsoleLogin mostram o campo vpcEndpointId preenchido com um dos seus IDs de endpoint. Veja um exemplo de evento:
Se o console não carregar, verifique: se o DNS privado está habilitado em cada endpoint; se os grupos de segurança dos endpoints permitem HTTPS (TCP 443) das sub-redes das cargas de trabalho; e se, para tráfego externo à VPC, o DNS corporativo retorna os IPs privados dos endpoints. Para validação end-to-end, execute traceroute console.aws.amazon.com a partir da sua estação de trabalho e confirme que o caminho usa apenas hops privados.
Passo 5: Aplicar políticas de endpoint de VPC
Anexe uma política de endpoint nos endpoints do console e do AWS Sign-In que limite o acesso a identidades da sua organização. Comece com uma política permissiva Allow * e confirme que o tráfego está roteando pelos endpoints. Depois, adicione restrições usando as condições aws:PrincipalOrgID e aws:ResourceOrgID. A referência completa está no guia do usuário do Console Private Access. Para políticas além do piloto, consulte Data perimeters on AWS e o repositório de exemplos de políticas de perímetro de dados no GitHub.
Passo 6: Aplicar uma política de Sign-In
As políticas de Sign-In negam requisições de autenticação no console que não correspondam às condições de rede ou de principal definidas. A política é composta por uma instrução de pré-autenticação cobrindo signin:Authenticate e uma instrução de pós-autenticação cobrindo signin:AuthorizeOAuth2Access e signin:CreateOAuth2Token — inclua ambas.
Para o piloto, implante a política como uma RCP a partir da conta de gerenciamento do AWS Organizations. Como a RCP se aplica a todas as contas da organização, recomenda-se pilotar em uma organização de teste dedicada antes de expandir. Ative a aplicação chamando a API signin:PutConsoleAuthorizationConfiguration para a organização na Região us-east-1.
Importante: Configure pelo menos um principal excluído como caminho de acesso emergencial (break-glass) antes de habilitar a RCP. O principal recomendado é uma role IAM dedicada.
Passo 7: Adicionar endpoints de VPC para cada serviço
Os endpoints do Private Access carregam o shell do console, mas não as chamadas de API de serviço que o console faz em nome do usuário. Em uma VPC sem internet gateway, essas chamadas não têm para onde ir. Por isso, é necessário adicionar um endpoint de VPC para cada serviço utilizado.
Para o piloto, crie um endpoint de interface do AWS KMS (com.amazonaws.<região>.kms) na mesma VPC, com DNS privado habilitado, e confirme que a lista de chaves carrega ao acessar o console do AWS Key Management Service (AWS KMS) de dentro da VPC. Repita para cada serviço necessário. A lista atual de serviços que suportam PrivateLink está na documentação do AWS PrivateLink. Consoles de serviços que não suportam PrivateLink não funcionarão em VPCs sem internet e precisam ser tratados separadamente.
Passo 8: Ocultar Regiões e serviços não configurados (opcional)
Links do console para serviços ou Regiões sem endpoints configurados falharão dentro da VPC. Para evitar que usuários naveguem para páginas quebradas, use a Personalização de Experiência do Usuário (UXC) para ocultar Regiões e serviços que não fazem parte da implantação do Private Access. A UXC é configurada no nível da conta e se aplica à navegação, resultados de busca e menus de seleção de serviços.
Passo 9: Validar e expandir
Após aplicar as políticas de endpoint e a RCP de Sign-In a uma conta piloto, valide dois cenários: login de dentro da rede corporativa (deve ter sucesso) e login de fora da rede corporativa (deve ser negado na etapa de Sign-In, antes de chegar ao console). No CloudTrail, confirme que os eventos ConsoleLogin mostram vpcEndpointId preenchido para tráfego de dentro da rede. Para negações inesperadas, procure eventos ConsoleLogin com as mensagens de erro Authorization denied because of a resource-based policy ou Authorization denied because of a resource control policy.
Considerações importantes
IAM Identity Center: O suporte ao sign-in via IAM Identity Center ainda não está disponível por endpoint de VPC. A autenticação inicial de Single Sign-On (SSO) ainda precisa transitar pela internet.
Acesso programático: RBPs e RCPs de Sign-In controlam o sign-in interativo no console. Requisições do AWS SDK e da AWS CLI assinadas com SigV4 não são afetadas. Esse também é o caminho de recuperação: um principal com permissão signin:DeleteConsoleAuthorizationConfiguration pode desabilitar a aplicação programaticamente se a autorização do console estiver mal configurada.
Suporte parcial a consoles: O Console Private Access está disponível em todas as Regiões comerciais da AWS, mas suporta apenas um subconjunto dos consoles de serviço. Consulte a documentação de Regiões, consoles de serviço e funcionalidades suportadas no Private Access. Para serviços não suportados, a conectividade com a internet ainda é necessária.
Custos: São cobrados os preços regulares de endpoint do AWS PrivateLink e processamento de dados para cada endpoint e cada Região implantada. Os três endpoints do Private Access (console, signin e console-static), mais os endpoints de serviço já utilizados, são os itens relevantes de custo.
A AWS anunciou que o Amazon Bedrock AgentCore Memory passou a suportar Controle de Acesso Refinado (FGAC — Fine-Grained Access Control). Com essa novidade, equipes que desenvolvem agentes de Inteligência Artificial (IA) conseguem aplicar isolamento de memória por usuário e por tenant de forma nativa, sem precisar construir lógica de autorização customizada dentro do código da aplicação.
Como funciona o FGAC no AgentCore Memory
Para habilitar o FGAC, a AWS orienta que o recurso de memória seja exposto por meio do AgentCore Gateway, configurado com autenticação OAuth (JWT). A partir daí, é possível anexar políticas Cedar que restringem o acesso com base na identidade do chamador autenticado.
Na prática, isso significa que cada usuário só consegue acessar os dados do seu próprio ator dentro da memória. Além disso, os registros de memória podem ser restritos a namespaces derivados diretamente das claims do token do usuário, e operações específicas de memória podem ser permitidas ou negadas por chamador.
O resultado prático é significativo: o controle de acesso deixa de viver no código da aplicação e passa a ser aplicado na camada de infraestrutura, usando prova criptográfica de identidade.
Arquitetura por trás do recurso
O FGAC para o AgentCore Memory é construído sobre o AgentCore Memory connector, um conector de gateway gerenciado que conecta um alvo de gateway ao plano de dados do Memory. Esse conector expõe 12 operações de memória como ações Cedar, com seus atributos de requisição disponíveis para uso em condições de política.
Essa abordagem torna a configuração de controle de acesso mais declarativa e auditável, já que as políticas Cedar descrevem explicitamente quem pode fazer o quê — sem depender de validações espalhadas pelo código da aplicação.
Por que isso importa para times de IA
Em cenários de agentes de IA com múltiplos usuários ou múltiplos tenants, garantir que cada entidade acesse apenas a sua própria memória é um requisito crítico de segurança e privacidade. Antes desse recurso, essa responsabilidade recaía inteiramente sobre o desenvolvedor, que precisava implementar e manter a lógica de autorização manualmente. Com o FGAC, essa camada passa a ser gerenciada pela própria infraestrutura do AgentCore.
Quem já colocou agentes de IA em produção sabe que o Amazon Bedrock Guardrails protege o que acontece na fronteira do modelo — valida o prompt antes da inferência e a resposta depois. Mas agentes fazem muito mais do que chamar modelos. Eles invocam ferramentas, buscam dados em fontes externas, se comunicam com servidores via Protocolo de Contexto de Modelo (MCP) e retornam resultados para usuários ou sistemas downstream.
Todo esse fluxo acontece fora da fronteira do modelo, onde os guardrails de nível de modelo simplesmente não chegam. A AWS identificou quatro exposições concretas que surgem dessa lacuna:
Parâmetros de ferramentas passam sem verificação. O modelo decide qual ferramenta usar e quais parâmetros enviar. Se esses parâmetros contiverem Informações de Identificação Pessoal (PII) ou conteúdo que viola políticas, a ferramenta executa com esse conteúdo sem nenhuma barreira.
Dados externos entram sem validação. Respostas de ferramentas, saídas de servidores MCP e retornos de APIs chegam ao agente sem passar por nenhum guardrail, podendo influenciar o comportamento do modelo antes de qualquer avaliação.
Conteúdo enganoso afeta o raciocínio. Um agente que consome dados imprecisos de uma fonte externa pode tratá-los como autoritativos, gerando recomendações distorcidas em áreas críticas como crédito, saúde ou assessoria jurídica.
Sistemas multi-agente propagam dados problemáticos. Em arquiteturas com múltiplos agentes, um componente mal configurado pode passar conteúdo que viola políticas para agentes downstream — e os guardrails de cada agente individualmente não inspecionam o que trafega entre eles na camada de ferramentas.
A solução: três pontos de validação com lifecycle hooks
Para fechar essas lacunas, a abordagem proposta pela AWS adiciona três pontos de validação em cada fronteira de confiança onde dados entram ou saem do agente. Esses pontos são implementados com os lifecycle hooks do Strands Agents SDK, sem exigir nenhuma alteração nas ferramentas existentes ou na lógica do agente.
Figura 1: Os três pontos de validação estendem o Amazon Bedrock Guardrails da fronteira do modelo até a fronteira das ferramentas. Imagem original — fonte: Aws
Ponto 1 — Validação de dados de entrada (BeforeInvocationEvent)
O primeiro ponto verifica os dados antes de chegarem ao modelo: entrada do usuário, dados vindos de outros agentes, servidores MCP e pipelines de Geração Aumentada por Recuperação (RAG). O hook BeforeInvocationEvent dispara antes da inferência ou da execução de qualquer ferramenta. Se o conteúdo violar políticas, a requisição é bloqueada e o modelo nunca vê esse conteúdo.
Ponto 2 — Supervisão de interação com ferramentas (BeforeToolCallEvent)
O segundo ponto age antes de o agente chamar uma ferramenta, verificando os parâmetros que seriam enviados. É exatamente a lacuna que os guardrails de nível de modelo não cobrem: o modelo já decidiu o que enviar, mas nada verificou se esse conteúdo é seguro para ser executado. O hook BeforeToolCallEvent cancela a chamada se os parâmetros forem problemáticos, antes que qualquer ação real aconteça.
Ponto 3 — Validação de dados de saída (AfterToolCallEvent)
O terceiro ponto valida os resultados antes de retorná-los ao usuário ou repassá-los a sistemas downstream. É especialmente importante para ferramentas que consomem conteúdo externo, como uma ferramenta de busca na web que traz páginas de sites fora do seu controle. O hook AfterToolCallEvent valida o retorno da ferramenta e o substitui por uma mensagem de bloqueio se o conteúdo violar políticas.
A intensidade de validação de cada ponto pode ser ajustada de forma independente. No Ponto 1, faz sentido usar um guardrail completo com detecção de PII, filtragem de conteúdo e aplicação de tópicos. O Ponto 2 pode ser mais leve — um guardrail separado com regras específicas para a ferramenta em questão, ou verificações locais como validação de expressão regular ou de schema. O Ponto 3 deve focar na detecção de conteúdo indesejado nas saídas que trazem dados externos. Combinar verificações determinísticas rápidas (regex, validação de schema, listas de permissão) com avaliações baseadas em IA mantém a latência baixa.
Implementação passo a passo
A implementação usa o boto3, o SDK da AWS para Python, para chamar a API ApplyGuardrail. O Strands Agents SDK expõe um evento de lifecycle por ponto de validação.
Pré-requisitos
Antes de implementar a abordagem com múltiplos pontos de validação, você precisará de:
A classe GuardrailHook é um HookProvider do Strands. Ela registra três callbacks, um para cada evento de lifecycle. Quando o Strands dispara um evento, o callback correspondente executa: validate_inbound verifica mensagens do usuário, validate_input verifica parâmetros de ferramentas antes da execução e validate_output verifica os resultados das ferramentas. Os três usam o método compartilhado _check, que chama a API ApplyGuardrail do Amazon Bedrock.
Crie um arquivo guardrail_hook.py e adicione a implementação abaixo. Use o parâmetro opcional tool_names para restringir o hook a ferramentas específicas, ou passe None para aplicar em todas:
import boto3
from strands.hooks import HookProvider, HookRegistry
from strands.hooks.events import (
BeforeInvocationEvent,
BeforeToolCallEvent,
AfterToolCallEvent,
)
class GuardrailHook(HookProvider):
def __init__(self, guardrail_id, guardrail_version, region_name, tool_names=None):
self.client = boto3.client("bedrock-runtime", region_name=region_name)
self.guardrail_id = guardrail_id
self.guardrail_version = guardrail_version
self.tool_names = tool_names # None = apply to all tools
def register_hooks(self, registry: HookRegistry, **kwargs):
registry.add_callback(BeforeInvocationEvent, self.validate_inbound)
registry.add_callback(BeforeToolCallEvent, self.validate_input)
registry.add_callback(AfterToolCallEvent, self.validate_output)
def _check(self, content, source="INPUT"):
"""Call Bedrock ApplyGuardrail. Returns True if content is safe."""
response = self.client.apply_guardrail(
guardrailIdentifier=self.guardrail_id,
guardrailVersion=self.guardrail_version,
source=source, # "INPUT" applies input policies; "OUTPUT" applies output policies
content=[{"text": {"text": content}}],
)
return response["action"] != "GUARDRAIL_INTERVENED"
# Checkpoint 1 — BeforeInvocationEvent
# Validates user input before model inference or tool execution occurs.
# The model does not see blocked content.
async def validate_inbound(self, event: BeforeInvocationEvent):
for msg in reversed(event.messages):
if msg.get("role") == "user":
for block in msg.get("content", []):
text = block.get("text", "")
if text and not self._check(text):
event.messages.clear()
event.messages.append({
"role": "user",
"content": [{"text": "Request blocked by safety guardrail."}],
})
return
break
# Checkpoint 2 — BeforeToolCallEvent
# Validates tool input parameters before the tool executes.
# Skips tools not in tool_names (if a filter is set).
async def validate_input(self, event: BeforeToolCallEvent):
if self.tool_names and event.tool_use.get("name") not in self.tool_names:
return
tool_input = event.tool_use.get("input", {})
for param_value in tool_input.values():
if isinstance(param_value, str) and not self._check(param_value):
event.cancel_tool = "This request was blocked by a safety guardrail."
return
# Checkpoint 3 — AfterToolCallEvent
# Validates tool output before it reaches the agent.
# Skips tools not in tool_names (if a filter is set).
async def validate_output(self, event: AfterToolCallEvent):
if self.tool_names and event.tool_use.get("name") not in self.tool_names:
return
content_parts = [
block["text"]
for block in event.result.get("content", [])
if "text" in block
]
content = "\n".join(content_parts)
if content and not self._check(content, source="OUTPUT"):
event.result = {
"toolUseId": event.result["toolUseId"],
"status": "error",
"content": [{"text": "Content blocked by safety guardrail."}],
}
Definindo ferramentas
O Strands descobre ferramentas pelo decorator @tool, que transforma uma função Python comum em uma ferramenta que o modelo pode chamar, usando a docstring e as type hints como contrato da ferramenta. Abaixo estão dois exemplos simples usados nas seções de registro:
from strands import tool
@tool
def web_search(query: str) -> str:
"""Search the web and return a result snippet."""
# Replace with your actual search implementation
return f"Search results for: {query}"
@tool
def get_customer_data(customer_id: str) -> str:
"""Retrieve customer record by ID."""
# Replace with your actual data lookup implementation
return f"Customer record for: {customer_id}"
Registrando o hook
O Strands ativa hooks pelo parâmetro hooks no construtor do Agent. Após o registro, os callbacks do hook executam automaticamente em cada evento de lifecycle correspondente, sem nenhuma alteração nas ferramentas ou na lógica do agente.
Para um único guardrail aplicado a todas as ferramentas, crie uma instância do hook e passe-a ao agente:
from strands import Agent
from strands.models import BedrockModel
from guardrail_hook import GuardrailHook
from tools import web_search, get_customer_data # Example tools - replace with your tools
# Example model and region selection
model = BedrockModel(
model_id="us.anthropic.claude-sonnet-4-5",
region_name="us-east-1",
)
guardrail_hook = GuardrailHook(
guardrail_id="your-guardrail-id", # Copy it from the Amazon Bedrock console > Guardrails
guardrail_version="1", # Use "DRAFT" for testing
region_name="us-east-1", # Region where the guardrails are defined
)
agent = Agent(
model=model,
tools=[web_search, get_customer_data], # Example tools
system_prompt="You are a helpful assistant.", # Example system prompt
hooks=[guardrail_hook], # Applied to all tool calls
)
Usando guardrails diferentes por ferramenta
Ferramentas diferentes carregam riscos diferentes. Uma ferramenta de busca na web traz conteúdo externo de sites não confiáveis e precisa de filtragem de saída rigorosa. Uma ferramenta de dados de clientes retorna registros internos e pode precisar de detecção de PII configurada de forma diferente.
O parâmetro tool_names restringe um hook a ferramentas específicas. O Strands ainda executa todos os hooks registrados em cada evento, mas os hooks ignoram a chamada quando o nome da ferramenta não corresponde. Registre um hook por guardrail:
from strands import Agent
from strands.models import BedrockModel
from guardrail_hook import GuardrailHook
from tools import web_search, get_customer_data # Example tools - replace with your tools
# Example model and region selection
model = BedrockModel(
model_id="us.anthropic.claude-sonnet-4-5",
region_name="us-east-1",
)
# Strict content filtering and PII detection for web search results
web_search_hook = GuardrailHook(
guardrail_id="gr-websearch-id", # Guardrail ID with content filtering + PII detection
guardrail_version="1", # Or set to DRAFT
region_name="us-east-1", # Change to your region
tool_names={"web_search"}, # Only applies to the web_search tool
)
# PII detection for customer data — prevents sensitive records from leaking into tool parameters
customer_data_hook = GuardrailHook(
guardrail_id="gr-customerdata-id", # Guardrail ID with PII detection
guardrail_version="1", # Or set to DRAFT
region_name="us-east-1", # Change to your region
tool_names={"get_customer_data"}, # Only applies to the get_customer_data tool
)
agent = Agent(
model=model,
tools=[web_search, get_customer_data], # Example tools
system_prompt="You are a helpful assistant.", # Example system prompt
hooks=[web_search_hook, customer_data_hook], # Each hook runs only for its assigned tools
)
Cada guardrail é configurado de forma independente no console do Amazon Bedrock, permitindo ajustar a rigidez da validação ao nível de risco de cada ferramenta, em vez de aplicar uma política única para todo o agente.
Testando a implementação
Para validar o funcionamento, crie uma pasta de projeto com os seguintes arquivos:
guardrail_hook.py — a classe GuardrailHook
tools.py — as definições das ferramentas web_search e get_customer_data
agent.py — a configuração do agente da seção de registro do hook
Em agent.py, adicione um prompt de teste ao final:
# Send a test prompt
response = agent("Search the web for the latest news on AI security.")
print(response)
Atualize os IDs de guardrail, a região AWS e o ID do modelo em agent.py para corresponder à sua configuração. Execute o agente a partir da pasta do projeto:
python agent.py
O hook de guardrail executa em cada ponto de validação. Se o prompt ou qualquer saída de ferramenta for sinalizado, você verá a mensagem de bloqueio na resposta em vez do resultado da ferramenta.
Reutilizando o hook em toda a organização
A classe GuardrailHook é um HookProvider independente. Construída uma vez, ela pode ser anexada a agentes Strands passando-a no parâmetro hooks. O mesmo pacote de hook pode ser publicado como uma biblioteca interna e consumido por:
Times em toda a organização, com IDs de guardrail específicos por ambiente injetados via configuração (por exemplo, dev, staging, prod)
É possível trocar configurações de guardrail ou adicionar verificações como regex ou validação de schema sem tocar no código do agente ou das ferramentas.
Conclusão
O Amazon Bedrock Guardrails protege a fronteira do modelo, mas agentes também chamam ferramentas, consomem dados externos e retornam resultados que nunca passam pelas verificações de nível de modelo. Os três pontos de validação apresentados neste guia fecham essa lacuna usando os lifecycle hooks do Strands Agents SDK: BeforeInvocationEvent valida a entrada do usuário, BeforeToolCallEvent valida os parâmetros das ferramentas e AfterToolCallEvent valida a saída das ferramentas.
A mesma classe GuardrailHook suporta tanto um guardrail compartilhado quanto guardrails diferentes com escopo por ferramenta, e pode ser implantada sem alterações desde o teste local até o Amazon Bedrock Agent Core Runtime.
Para se aprofundar no tema, a AWS recomenda consultar também o OWASP Top 10 para Aplicações Agênticas, que traz as principais vulnerabilidades a considerar nesse tipo de arquitetura.
Novas versões menores disponíveis no Amazon RDS para PostgreSQL
A AWS anunciou que o Amazon Serviço de Banco de Dados Relacional (RDS) para PostgreSQL agora oferece suporte às versões menores mais recentes do PostgreSQL: 18.6, 17.11, 16.15, 15.19 e 14.24. A recomendação oficial é que todos os usuários realizem o upgrade para essas versões o quanto antes.
Por que atualizar?
O principal motivo para realizar o upgrade é a correção de Vulnerabilidades e Exposições Comuns (CVEs) presentes nas versões anteriores do PostgreSQL. Além da segurança, as novas versões menores incorporam correções de bugs e melhorias desenvolvidas pela comunidade PostgreSQL, tornando os bancos de dados mais estáveis e confiáveis.
Como realizar o upgrade
A AWS oferece algumas formas práticas de executar a atualização com o mínimo de impacto nas operações:
Janelas de manutenção programadas: é possível configurar upgrades automáticos de versões menores para que sejam aplicados durante as janelas de manutenção agendadas, sem necessidade de intervenção manual.
AWS Organizations com Política de Rollout de Upgrade: para equipes que gerenciam múltiplos ambientes em escala, esse recurso permite orquestrar os upgrades em fases — validando primeiro nos ambientes de menor prioridade antes de aplicar nas cargas de trabalho mais críticas.
Implantações Blue/Green do Amazon RDS: para quem precisa minimizar ao máximo o tempo de inatividade durante o processo de atualização, as implantações Blue/Green são uma alternativa eficiente.
O Amazon RDS para PostgreSQL é um serviço gerenciado que simplifica a configuração, operação e escalabilidade de implantações PostgreSQL na nuvem. Para criar ou atualizar um banco de dados, é possível utilizar o Console de Gerenciamento do Amazon RDS ou a Interface de Linha de Comando (CLI) da AWS. Informações sobre preços e disponibilidade por região estão disponíveis na página de Preços do Amazon RDS para PostgreSQL.
A AWS anunciou que o Lambda MicroVMs agora conta com suporte ao AWS PrivateLink, possibilitando conectividade privada diretamente a partir de recursos de uma Nuvem Privada Virtual (VPC — Virtual Private Cloud) sem que o tráfego precise passar pela internet pública.
A novidade é especialmente relevante para equipes que trabalham com cargas de trabalho reguladas — como as dos setores financeiro, de saúde e governamental —, que precisam cumprir requisitos rigorosos de isolamento de rede ao construir soluções com o Lambda MicroVMs.
O que são os Endpoints de VPC do PrivateLink?
Os Endpoints de VPC do PrivateLink (PrivateLink VPC Endpoints) entregam conectividade privada entre uma VPC e os serviços da AWS, garantindo que o tráfego não trafegue pela internet pública durante a comunicação com esses serviços. Com este lançamento, essa capacidade é estendida ao Lambda MicroVMs.
O que muda na prática para desenvolvedores e times de TI
Desenvolvedores e equipes de TI que precisam de conectividade privada com o Lambda MicroVMs agora podem criar Endpoints de VPC do PrivateLink dentro de sua VPC para:
Chamar as APIs do MicroVM — por exemplo, para criar imagens de MicroVM ou inicializar MicroVMs;
Conectar-se ao endpoint HTTP de cada MicroVM individualmente.
Os Endpoints de VPC do PrivateLink para o Lambda MicroVMs podem ser criados por meio do Console de Gerenciamento da AWS (AWS Management Console), da Interface de Linha de Comando da AWS (AWS CLI), do AWS CloudFormation ou dos SDKs da AWS.
Disponibilidade e recursos adicionais
O recurso está disponível em todas as regiões onde o Lambda MicroVMs já é oferecido. Para verificar a disponibilidade mais atualizada por região, a AWS disponibiliza a página de Capacidades da AWS por Região.
Para aprofundar o conhecimento sobre o uso do PrivateLink com o Lambda MicroVMs, a AWS disponibiliza um guia do desenvolvedor dedicado ao tema. Informações sobre preços podem ser consultadas na página de preços do AWS PrivateLink. Para entender melhor como configurar conectividade privada para serviços da AWS de forma geral, o guia do desenvolvedor do AWS PrivateLink é o ponto de partida recomendado.
Além do relatório em si, a AWS apresenta informações sobre a aplicabilidade do ISM ao LZA e um novo mecanismo de teste para medir desvios de configuração — recursos que, em conjunto, oferecem às organizações australianas uma base documentada e validada para acelerar a preparação para avaliações IRAP (Programa de Avaliadores Registrados de Segurança da Informação).
Contexto: por que isso importa para o setor público australiano
Organizações australianas do setor público, defesa e infraestrutura crítica precisam construir ambientes de nuvem que atendam aos requisitos do ISM. Esse manual define 1.081 requisitos de controle de segurança distribuídos em 22 capítulos de diretrizes. Demonstrar conformidade é parte central para obter um resultado positivo em uma avaliação IRAP — mas essas avaliações normalmente exigem meses de preparação, coleta de evidências e testes.
O LZA é uma solução adequada para clientes com obrigações de segurança e conformidade — tanto existentes quanto previstas — porque os controles que ele implanta são aplicados automaticamente a novas contas à medida que os ambientes crescem.
O que o relatório cobre
Para avaliar como o LZA pode ajudar clientes na Austrália, a AWS trabalhou em conjunto com o parceiro gwi.digital para executar o LZA da mesma forma que um cliente faria. A equipe conduziu uma análise e avaliação independente da Configuração Universal do LZA contra os 1.081 controles do ISM.
A avaliação foi realizada em um ambiente AWS totalmente novo (greenfield), hospedado na região AWS ap-southeast-2 (Sydney), posicionado dentro da Fase 2 do Framework de Avaliação e Autorização de Segurança em Nuvem da ASD (Diretoria Australiana de Sinais). O foco foi em consumidores de nuvem que constroem sobre serviços AWS já autorizados. A iniciativa se apoia nas fundações IRAP existentes da AWS: os serviços subjacentes da AWS foram avaliados de forma independente no nível PROTECTED pela CyberCX.
É importante destacar: o relatório não constitui uma autorização, certificação ou credenciamento IRAP oficial. Ele fornece uma avaliação profissional de evidências com base no que o LZA entrega por padrão — e no que ele não entrega —, permitindo que as organizações tomem decisões informadas.
O que a avaliação encontrou
Dos 1.081 controles do ISM, 256 estão dentro do escopo endereçável pelo LZA — ou seja, são os controles de infraestrutura técnica que uma solução como o LZA pode efetivamente tratar. Desses 256, o LZA alcança cobertura Total ou Parcial em 234, o que representa 91% dos controles aplicáveis.
Os 825 controles restantes estão fora do escopo do LZA: segurança física, pessoal, governança organizacional e exclusões por nível de classificação.
Uma contribuição relevante da avaliação foi a análise do modelo de responsabilidade compartilhada que vai além da visão binária tradicional entre AWS e cliente. O relatório considera uma visão em três camadas — AWS (fornecido), LZA (habilitado) e Cliente (responsabilidade) — e categoriza os 825 controles fora do escopo em subcategorias, permitindo que as organizações identifiquem rapidamente quais controles ainda exigem atenção delas, em comparação com os que já estão cobertos no nível de infraestrutura.
Validação contínua com o CATS
Confirmar que os controles estão implementados e operando de forma eficaz em todo o ambiente é uma tarefa complexa e frequentemente sem cobertura completa. Para simplificar esse processo, a AWS desenvolveu o CATS (Suíte de Testes de Aceitação de Controles).
O CATS é um mecanismo automatizado de validação de conformidade que executa testes específicos contra a linha de base de configuração de segurança implantada pela Configuração Universal do LZA. Para a avaliação do ISM, o CATS executou mais de 3.600 testes individuais em seis contas AWS, avaliando estrutura de contas, identidade e acesso, configuração de rede, logging, criptografia e backup.
Para clientes australianos, o CATS oferece os seguintes benefícios:
Geração automatizada de evidências: resultados legíveis por máquina podem substituir semanas de coleta manual de evidências
Relatórios enriquecidos com ISM: a gwi.digital desenvolveu um script de conversão que mapeia a saída do CATS para referências de controle do ISM, permitindo que auditores interpretem os resultados sob a perspectiva do ISM
Detecção contínua de desvios: a execução repetível identifica quando as configurações se afastam da linha de base validada entre os ciclos de avaliação
Atenção: a disponibilidade do CATS é limitada e atualmente acessível apenas por meio do AWS Professional Services como solução em beta privado, podendo estar sujeita a alterações. Disponibilidade, funcionalidades e preços podem mudar sem aviso prévio.
Ajustes de configuração otimizados para o ISM
Durante a avaliação, a gwi.digital identificou ajustes de configuração que elevam classificações específicas de controles de Parcial para Total, com esforço mínimo. Como exemplo, aumentar o comprimento mínimo de senha padrão de 14 para 15 caracteres, ou ajustar a retenção de logs para se alinhar aos padrões australianos de descarte de registros federais. Essas recomendações foram comunicadas à equipe de Configuração Universal do LZA para inclusão em uma futura seção de orientações específicas para o ISM na documentação do GitHub do LZA.
Como começar
Para quem deseja explorar esses recursos, a AWS recomenda os seguintes passos:
Utilize o Guia de Implementação do LZA para conhecer os casos de uso, revisar as considerações de pré-implantação e seguir os passos de implantação
Considere criar uma base de conhecimento com o Amazon Bedrock usando o LZA Compliance Workbook, o Guia de Implementação do LZA, rastreadores web para o GitHub do LZA e seus recursos personalizados para configurar um agente de chat de conformidade de segurança
A combinação dos mapeamentos ISM no LZA Compliance Workbook, do relatório de análise da gwi.digital e das evidências geradas pelo CATS oferece às organizações australianas uma vantagem significativa na preparação para avaliações IRAP. Entre os principais ganhos práticos estão:
Semanas economizadas no escopo: a aplicabilidade pré-determinada dos controles reduz significativamente o esforço inicial de definição de escopo
Documentação pronta: os statements de implementação e o alinhamento de requisitos de controle reduzem a carga de documentação
Garantia independente: um relatório de terceiros que clientes e seus avaliadores podem referenciar diretamente
Evidência contínua: o CATS gera evidências de segurança repetíveis entre os ciclos de avaliação, substituindo auditorias manuais periódicas por garantia contínua
Novas versões do PostgreSQL disponíveis no Amazon Aurora
A AWS anunciou que o Amazon Aurora PostgreSQL-Compatible Edition passa a suportar as versões 18.4, 17.10, 16.14, 15.18 e 14.23 do PostgreSQL. As atualizações trazem correções de bugs da comunidade PostgreSQL, além de melhorias específicas da plataforma Aurora.
Por que atualizar?
A AWS recomenda que os usuários migrem para as versões minor mais recentes assim que possível. O principal motivo é a correção de Vulnerabilidades e Exposições Comuns (CVEs) conhecidas — falhas de segurança documentadas publicamente que podem representar risco para os ambientes de banco de dados. Além da segurança, as novas versões também entregam melhorias de estabilidade e desempenho. Os detalhes completos de cada atualização estão disponíveis nas notas de lançamento.
Como realizar o upgrade
A atualização pode ser feita de forma simples, sem necessidade de intervenção manual. O Aurora permite que os upgrades de versões minor sejam executados automaticamente durante as janelas de manutenção programadas. Para isso, basta habilitar a opção de upgrades automáticos de versão minor no cluster.
Para equipes que gerenciam múltiplos bancos de dados em escala, a AWS disponibiliza um recurso adicional bastante útil: a Política de Rollout de Upgrade do AWS Organizations. Com ela, é possível orquestrar os upgrades em fases — começando pelos ambientes de menor criticidade para validar o processo antes de atualizar os ambientes mais críticos do negócio.
O Amazon Aurora é o serviço de banco de dados relacional gerenciado da AWS, projetado para oferecer alta performance e disponibilidade em escala global, com compatibilidade total com o PostgreSQL. Entre seus principais recursos estão:
Computação serverless com escala até zero, reduzindo custos quando o banco não está em uso
Aurora Global Database, para resiliência multi-região
Aurora I/O-Optimized, com melhor relação custo-benefício para cargas de trabalho intensivas em operações de entrada e saída (I/O)
Segurança integrada e backups contínuos
Para quem ainda não utiliza o serviço e quer dar os primeiros passos, a AWS disponibiliza uma página de introdução ao Aurora com os recursos necessários para começar.
A AWS anunciou uma atualização importante no Amazon Elastic Kubernetes Service (Amazon EKS): agora é possível associar múltiplos provedores de identidade externos baseados em OpenID Connect (OIDC) a um único cluster. Com essa novidade, cada cluster pode ter até 10 provedores OIDC configurados simultaneamente, ampliando consideravelmente a flexibilidade na autenticação de usuários e cargas de trabalho.
Por que isso importa na prática
Muitas organizações trabalham com diferentes grupos de usuários — funcionários internos, prestadores de serviço, sistemas de Integração Contínua e Entrega Contínua (CI/CD), entre outros. Cada um desses grupos costuma ter seu próprio provedor de identidade, e até então o EKS exigia que tudo fosse consolidado em um único provedor ou que se usasse um broker de identidade intermediário para contornar essa limitação.
Com a atualização, cada grupo pode se autenticar diretamente pelo seu próprio provedor, sem a necessidade de centralização forçada ou de soluções de contorno. Cada provedor é configurado e gerenciado de forma independente, com seu próprio mapeamento de identidade.
Compatibilidade com a autenticação IAM existente
Um ponto relevante destacado pela AWS é que a autenticação via IAM (Gerenciamento de Identidade e Acesso) continua funcionando normalmente em paralelo com todos os provedores OIDC configurados. Ou seja, não é necessário abrir mão da configuração atual para aproveitar a nova capacidade.
Como configurar
A forma de adicionar provedores segue o mesmo processo já conhecido: via AWS Management Console ou por meio da API AssociateIdentityProviderConfig, acessível pelo AWS CLI e pelos AWS SDKs. Não há mudança no fluxo de configuração — apenas a possibilidade de repetir o processo para cada novo provedor que precise ser associado ao cluster.
Disponibilidade e custo
A funcionalidade está disponível em todas as regiões da AWS onde o Amazon EKS é oferecido e não tem custo adicional.
Imagine um engenheiro de infraestrutura abrindo o laptop de um colega para depurar uma build. Na pasta de configuração, um arquivo chamado mcp.json contém uma senha de banco de dados de produção em texto puro, ao lado de um comentário TODO: rotate this. A equipe de segurança não tem visibilidade de quais agentes de IA estão acessando ferramentas internas, quem concedeu esse acesso, nem qual seria o impacto se aquela credencial vazasse.
Esse cenário representa um padrão recorrente em empresas que adotam assistentes habilitados com o Protocolo de Contexto de Modelo (MCP) — como Kiro, Claude Code e Amazon Quick — sem uma camada centralizada de governança. A AWS identificou cinco padrões de falha estrutural nesse cenário: espalhamento de credenciais em configs locais, divergência silenciosa de políticas, lacunas de auditoria, opacidade de custos e Shadow IT.
Para endereçar isso, a AWS documentou uma abordagem progressiva usando o AgentCore Gateway, uma capacidade do Amazon Bedrock AgentCore que fornece um ponto de entrada único, seguro e auditável para o tráfego de agentes em direção às ferramentas corporativas.
A jornada de maturidade em quatro escopos
A proposta da AWS não é construir tudo de uma vez — é avançar conforme as dores reais aparecem. Cada escopo entrega valor independente e preserva o caminho para o próximo.
Indicado para pilotos com 1 a 20 usuários e ferramentas de baixo risco. O objetivo é simples: criar um único ponto de entrada para que os agentes de IA cheguem aos recursos organizacionais, com autenticação via SSO (Entrada Única), credenciais centralizadas e auditoria pelo AWS CloudTrail.
Na prática, o gateway é provisionado com um autorizador JWT (Token Web JSON) apontando para um pool do Amazon Cognito. Uma função AWS Lambda de baixo risco — como uma busca de tickets somente leitura — é registrada como alvo MCP. O arquivo mcp.json dos assistentes passa a apontar para o endpoint do gateway em vez de servidores locais. As credenciais de backend nunca saem da AWS, e toda invocação aparece nos logs do Amazon CloudWatch.
O comando para criar o gateway com autorizador JWT é:
O resultado: o caminho fim a fim funciona, o mcp.json agora contém um endpoint que alcança recursos organizacionais, e produtividade e controles chegam juntos.
Escopo 2 — Control: autorização por identidade e guardrails
Com a porta aberta, o Escopo 2 identifica quem está chamando e filtra o que passa. É indicado quando a base de usuários cresce e a conformidade começa a perguntar “quem fez o quê, sob qual política?”
A mudança central é migrar de confiança no nível de máquina para confiança no nível de usuário. Os clientes passam a ser registrados dinamicamente via Registro Dinâmico de Clientes (DCR) — um shim Lambda que cria um app client no Cognito e o adiciona à lista de clientes permitidos do gateway. O usuário se autentica via SSO com fluxo de Código de Autorização (Authorization Code), e a partir daí cada requisição carrega a identidade real do usuário.
O AgentCore Policy aplica regras Cedar com controle de acesso baseado em papéis (RBAC) e atributos (ABAC). Por exemplo, a política abaixo restringe deploys de CI ao ambiente de staging para membros do grupo de pagamentos, enquanto mantém ferramentas de leitura abertas para qualquer principal autenticado:
// Payments deployers can deploy, but only to staging
permit (
principal,
action == AgentCore::Action::"DeployCI___invoke",
resource
)
when {
principal.hasTag("groups") &&
principal.getTag("groups").contains("repo-payments-service")
/* Note: for Cognito, the claim is cognito:groups, not groups.
Refer to your deployed Gateway Cedar schema for the precise tag names. */
&& context.input.environment == "staging"
};
// Read-only tools are open to any authenticated principal with a group
permit (
principal,
action in [
AgentCore::Action::"TicketSearch___invoke",
AgentCore::Action::"DocsSearch___invoke"
],
resource
)
when {
principal.hasTag("groups")
};
O Amazon Bedrock Guardrails é integrado nativamente ao AgentCore Policy para aplicar filtros de Informações de Identificação Pessoal (PII), políticas de conteúdo e detecção de ataques de prompt na camada do gateway, sem código customizado. A configuração abaixo, por exemplo, bloqueia números de CPF/SSN e cartões de crédito, e anonimiza e-mails:
A recomendação é implantar o AgentCore Policy primeiro em modo LOG_ONLY para monitorar quais decisões mudariam antes de ativar o modo ENFORCE. Quando um recurso downstream precisa da identidade do usuário em um sistema SaaS (como GitHub ou Slack), o AgentCore Identity gerencia o fluxo de três pernas (3LO), emitindo um erro de elicitação -32042 para que o assistente conduza o usuário pelo consentimento no navegador. Para recursos que compartilham a mesma cadeia de identidade, o On-Behalf-Of (OBO) token exchange substitui o redirecionamento pelo navegador, sem fluxo adicional de consentimento.
Escopo 3 — Catalog: autoatendimento, registro e alcance multi-ambiente
Quando os tickets de “adicione esta ferramenta” se acumulam ou é preciso alcançar sistemas fora da AWS, é hora do Escopo 3. Indicado para mais de 100 usuários, esse escopo elimina o gargalo de cadastro manual de ferramentas.
Os donos de ferramentas passam a criar um manifesto YAML e abrir um pull request. O pipeline de CI valida, escaneia e, no merge, chama create-gateway-target e atualiza a política Cedar automaticamente. Um exemplo de manifesto:
O AWS Agent Registry centraliza a descoberta de ferramentas e habilidades. Um servidor Resources MCP distribui automaticamente para todos os assistentes contextos organizacionais como padrões de código, runbooks de plantão e checklists de release — sem configuração por desenvolvedor.
Para sistemas fora da AWS, o gateway alcança bancos de dados on-premises via AWS Direct Connect ou VPN, e APIs SaaS via OAuth de saída. O Open Policy Agent (OPA) complementa o Cedar com regras que ele não expressa nativamente, como janelas de tempo e verificação de ticket de mudança. A política Rego abaixo, por exemplo, permite escrita em banco de dados somente em dias úteis, das 9h às 17h UTC, com ticket de mudança anexado:
Para FinOps, tags por ferramenta no AWS Cost Explorer permitem que o financeiro atribua gastos ao time responsável. Um alerta de AWS Budgets pode ser configurado por ferramenta com um limite mensal de custo de invocação.
Escopo 4 — Harden: resiliência e governança de borda
Para workloads com mais de 1.000 usuários, indústrias reguladas ou requisitos de alta disponibilidade global, o Escopo 4 endurece o perímetro e prepara o gateway para falhas.
O tráfego passa a fluir pela rede corporativa: Amazon CloudFront na borda → Application Load Balancer restrito ao CloudFront via header secreto → VPC Endpoint em subnet privada → PrivateLink → gateway. O DNS público é eliminado. Para agentes hospedados em Runtime, a AWS recomenda ativar enforcement de entrada exclusiva, de modo que o Runtime rejeite qualquer invocação que não venha pelo gateway, impedindo contornos à política e à auditoria.
O failover multi-região é configurado via Amazon Route 53 com health checks. O registro de failover abaixo alterna para a região secundária quando o health check primário falha, dentro de um TTL de 30 segundos:
Uma Lambda noturna de deprecação lê métricas do CloudWatch e abre pull requests automaticamente para ferramentas com zero invocações nos últimos 30 dias. Após 90 dias sem uso, o alvo é removido — eliminando ferramentas zumbi do registry.
Para responder perguntas de conformidade como “quais principals tiveram maior taxa de negação na última semana?”, o Amazon Athena consulta os logs do CloudTrail:
SELECT
attributes.`aws.agentcore.policy.determining_policies` as policies,
COUNT(*) AS denies,
DATE_TRUNC('day', from_iso8601_timestamp(event_time)) AS day
FROM aws_spans_export
WHERE
attributes.`aws.agentcore.policy.authorization_decision` = 'DENY'
AND from_iso8601_timestamp(event_time) > current_date - INTERVAL '7' DAY
GROUP BY principal, matched_policy, DATE_TRUNC('day', from_iso8601_timestamp(event_time))
ORDER BY denies DESC
LIMIT 25;
Referência de implantação: caso de serviços financeiros
A AWS documentou como uma organização de serviços financeiros percorreu os quatro escopos em seis meses: começou no Escopo 1 com dois analistas e uma ferramenta SQL de staging; evoluiu para o Escopo 2 em três semanas com 30 analistas, RBAC por mesa de operação e auditoria completa; chegou ao Escopo 3 no terceiro mês com 200 usuários e queda de ~40% na fila de tickets; e completou o Escopo 4 no sexto mês com 1.000 usuários, isolamento de rede exigido pela MiFID II e RTO de 4 horas via Route 53 failover. O gatilho para avançar cada escopo foi sempre uma pergunta organizacional concreta, não um prazo predefinido.
Considerações operacionais e de custos
A AWS recomenda tratar o gateway com as mesmas práticas operacionais de serviços de produção desde o primeiro dia. Ambientes de dev, staging e produção devem rodar em contas AWS separadas, promovidos via Infraestrutura como Código (IaC).
Em segurança, credenciais devem ser armazenadas no AWS Secrets Manager com rotação, ou eliminadas com autenticação por Chave Privada JWT (private key no AWS KMS). Nunca em variáveis de ambiente. O mcp.json deve ser distribuído centralmente via MDM. Políticas de Controle de Serviço (SCPs) do AWS IAM com a condição aws:ViaAWSMCPService bloqueiam operações destrutivas invocadas por servidores MCP gerenciados pela AWS.
Em custos, a referência da AWS aponta que ~50 desenvolvedores executando 572.000 operações mensais custam aproximadamente US$ 17 combinando Gateway e Policy (Gateway InvokeTool a US$ 5 por milhão + Policy authorization a US$ 25 por milhão; Identity custa US$ 0 quando consumido pelo Gateway). Consulte a página de preços do Amazon Bedrock AgentCore para valores atualizados.
Limpeza de recursos
Para evitar cobranças contínuas após testes, a AWS recomenda remover os recursos na ordem inversa da criação. Os comandos principais incluem deletar targets com DeleteGatewayTarget e o gateway em si:
