Com esse novo suporte, quem utiliza o Amazon ECS Managed Instances pode acompanhar diretamente no CloudWatch as seguintes dimensões das GPUs:
Capacidade de GPU — quanto do recurso está disponível no pool
Utilização — percentual de uso em tempo real
Memória — consumo de memória da GPU
Saúde do hardware — estado operacional dos dispositivos físicos
Condições térmicas — temperatura e alertas relacionados ao superaquecimento
O Container Insights com observabilidade aprimorada vai além do nível de cluster ou serviço: ele entrega visibilidade granular até o nível do dispositivo GPU individual, o que facilita muito a identificação de gargalos e falhas pontuais.
Por que isso importa para cargas de IA/ML
Workloads de treinamento e inferência de modelos de Inteligência Artificial e Aprendizado de Máquina (IA/ML) são altamente sensíveis ao desempenho da GPU. Um dispositivo operando abaixo do esperado — seja por limitação de memória, superaquecimento ou degradação de hardware — pode comprometer toda uma pipeline de treinamento sem que a equipe perceba rapidamente.
Com as novas métricas, as equipes conseguem identificar esses problemas de forma proativa, antes que eles impactem as cargas em produção. Além disso, a visibilidade sobre capacidade e utilização ajuda no right-sizing da frota de instâncias GPU, evitando tanto o desperdício de recursos quanto o subdimensionamento.
Como começar a usar
Para acessar as métricas de GPU NVIDIA no ECS, o processo envolve dois passos principais:
Habilitar o Container Insights com observabilidade aprimorada no cluster do Amazon ECS
Provisionar instâncias Amazon EC2 com aceleração por GPU por meio de um capacity provider do Amazon ECS Managed Instances
O problema de alinhamento dos modelos de linguagem
Grandes Modelos de Linguagem (LLMs) já estão no centro de agentes conversacionais, ferramentas criativas e sistemas de apoio a decisões. Mas o output bruto desses modelos frequentemente carrega imprecisões, desalinhamentos de política ou respostas pouco úteis — problemas que comprometem a confiança e limitam o uso real em produção.
Para resolver isso, o Ajuste Fino por Reforço (RFT) se consolidou como o método preferido de alinhamento eficiente. Em vez de depender de rotulagem manual cara e demorada, o RFT usa sinais de recompensa automatizados para guiar o comportamento do modelo.
No centro do RFT moderno estão as funções de recompensa, construídas de duas formas principais:
Aprendizado por Reforço com Recompensas Verificáveis (RLVR): usa código para avaliar as respostas geradas pelo modelo com critérios verificáveis.
Aprendizado por Reforço com Feedback de IA (RLAIF): usa um segundo modelo de linguagem como “juiz” para avaliar as respostas candidatas — a técnica conhecida como LLM-as-a-judge.
A AWS publicou um post técnico detalhando como o RLAIF funciona na prática com os modelos Amazon Nova, incluindo um caso de uso real no setor jurídico.
Por que usar LLM-as-a-judge em vez de recompensas genéricas?
Recompensas genéricas baseadas em regras simples — como correspondência de substrings — funcionam para casos bem definidos, mas falham quando os critérios de qualidade são subjetivos ou multidimensionais.
Um juiz baseado em LLM raciocina sobre múltiplas dimensões ao mesmo tempo: correção, tom, segurança, relevância. Ele captura nuances e especificidades de domínio sem precisar de retreinamento específico por tarefa. Além disso, oferece explicabilidade embutida por meio de justificativas — algo que funções de recompensa estáticas simplesmente não conseguem fornecer.
Seis passos para implementar o LLM-as-a-judge
1. Escolha a arquitetura do juiz
Existem dois modos principais de avaliação:
Julgamento baseado em rubrica (pontuação absoluta): atribui uma nota numérica a uma única resposta com base em critérios predefinidos. Recomendado quando não há dados de preferência disponíveis e o RLVR não é adequado. Funciona melhor para dados fora da distribuição e evita viés de dados.
Julgamento baseado em preferência (comparação relativa): compara duas respostas candidatas lado a lado e seleciona a superior. Recomendado quando há dados comparativos disponíveis e o modelo deve explorar livremente sem restrições de dados de referência.
2. Defina os critérios de avaliação
Critérios claros são a base de um treinamento RLAIF eficaz. Para juízes baseados em rubrica, a AWS recomenda usar pontuação booleana (aprovado/reprovado) em vez de escalas de 1 a 10 — isso reduz a variabilidade do juiz e torna a avaliação mais confiável.
3. Selecione e configure o modelo juiz
A escolha do modelo depende da complexidade do domínio e do equilíbrio entre custo e confiabilidade:
Modelos grandes/pesados (Amazon Nova Pro, Claude Opus, Claude Sonnet): indicados para raciocínio complexo, avaliação com nuances e pontuação multidimensional. Alto custo, altíssima confiabilidade.
Modelos médios/leves (Amazon Nova 2 Lite, Claude Haiku): adequados para domínios gerais como matemática ou programação. Custo baixo a médio, confiabilidade moderada a alta.
O juiz é configurado via Amazon Bedrock e chamado por uma função AWS Lambda de recompensa.
4. Refine o prompt do modelo juiz
O prompt do juiz é o alicerce da qualidade do alinhamento. Ele deve produzir saídas estruturadas e facilmente parseáveis, com regras de pontuação claras, tratamento de casos extremos e comportamentos desejados explicitamente definidos.
5. Alinhe os critérios do juiz com as métricas de produção
A função de recompensa deve espelhar as métricas que serão usadas para avaliar o modelo final em produção. O fluxo recomendado é: definir critérios de sucesso em produção, mapear cada critério para dimensões de pontuação do juiz, validar a correlação entre as notas do juiz e as métricas de avaliação, e testar em amostras representativas e casos extremos.
6. Construa uma função Lambda de recompensa robusta
Sistemas RFT em produção processam milhares de avaliações de recompensa por etapa de treinamento. A AWS recomenda combinar o juiz LLM com componentes de recompensa determinísticos rápidos para capturar falhas óbvias antes de acionar avaliações mais custosas:
Validação de formato: verifica estrutura JSON, campos obrigatórios e conformidade com o schema — sempre, pois é barato e instantâneo.
Penalidades de tamanho: desencoraja respostas excessivamente longas ou curtas, quando o comprimento importa.
Consistência de idioma: verifica se as respostas correspondem ao idioma de entrada — crítico para aplicações multilíngues.
Filtros de segurança: verificações baseadas em regras para conteúdo proibido — sempre, para evitar que conteúdo inseguro chegue à produção.
Do ponto de vista de infraestrutura, a AWS recomenda: implementar backoff exponencial para lidar com limites de taxa da API do Amazon Bedrock, usar ThreadPoolExecutor ou padrões assíncronos para paralelizar chamadas ao juiz, configurar o timeout da Lambda para 15 minutos e usar concorrência provisionada de aproximadamente 100 para configurações típicas. Erros devem retornar recompensas neutras (0.5) em vez de interromper toda a etapa de treinamento.
Fluxo de treinamento RFT com LLM-as-a-judge
O processo completo de ponta a ponta passa por três fases principais: configuração e validação, treinamento e implantação. O diagrama abaixo ilustra esse fluxo, mostrando como cada etapa se apoia na anterior para criar um pipeline resiliente que equilibra qualidade de alinhamento com eficiência computacional.
Fase 1 — Configuração e Validação: avaliação do modelo juiz, avaliação de baseline e design do dataset e das funções de recompensa.
Fase 2 — Treinamento: treinamento iterativo com monitoramento contínuo de distribuições de recompensa, scores de vantagem, taxa de concordância do juiz e detecção de reward hacking.
Fase 3 — Implantação: verificação de diversidade de rollouts, calibração do juiz, alinhamento recompensa-avaliação e ausência de reward hacking antes do deploy.
Caso de uso real: revisão automatizada de contratos jurídicos
O post da AWS descreve uma aplicação prática com um parceiro do setor jurídico. O desafio era automatizar a revisão, avaliação e identificação de riscos em documentos de contratos, comparando-os com diretrizes internas, regulamentações, contratos anteriores e legislação aplicável.
O problema foi formulado da seguinte forma: dado um documento-alvo (o contrato a ser avaliado) e um documento de referência (as diretrizes e contexto), o LLM deve gerar um JSON com comentários, tipos de comentário e ações recomendadas baseadas na avaliação.
O dataset original era relativamente pequeno, contendo contratos completos com anotações e comentários de especialistas jurídicos. Foi utilizado um modelo GPT OSS 120b como juiz, com um system prompt personalizado durante o RFT.
Estrutura do prompt do juiz para revisão de contratos
O prompt do juiz foi construído em camadas bem definidas:
a) Objetivo de alto nível:
# Contract Review Evaluation - Unweighted Scoring
You are an expert contract reviewer evaluating AI-generated comments. Your PRIMARY objective is to assess how well each predicted comment identifies issues in the TargetDocument contract clauses and whether those issues are justified by the Reference guidelines.
b) Abordagem de avaliação: define o que o modelo recebe (TargetDocument, Reference, Prediction) e instrui o juiz a avaliar cada comentário de forma independente, verificando se o campo text_excerpt cita texto do contrato-alvo — não das diretrizes de referência.
c) Dimensões de pontuação: três dimensões avaliadas em sequência obrigatória — TargetDocument_Grounding, Reference_Consistency e Actionability — cada uma com escala de 1 a 5 e critérios explícitos para cada nota.
d) Formato de saída: JSON estruturado com pontuação por comentário, justificativas e score agregado.
e) Handler Lambda com multithreading:
def lambda_handler(event, context):
scores: List[RewardOutput] = []
samples = event
max_workers = len(samples)
print(f"Evaluating {len(samples)} items with {max_workers} threads...")
with ThreadPoolExecutor(max_workers=max_workers) as executor:
futures = [executor.submit(judge_answer, sample) for sample in samples]
scores = [future.result() for future in futures]
print(f"Completed {len(scores)} evaluations")
return [asdict(score) for score in scores]
Configuração de permissões e IAM
A função de execução do Amazon SageMaker AI precisa de permissão para invocar a Lambda de recompensa:
A AWS reforça que o nome da função Lambda deve conter “SageMaker” (por exemplo, arn:aws:lambda:us-east-1:123456789012:function:MyRewardFunctionSageMaker) e que o treinamento RFT pode falhar se as permissões estiverem ausentes. O princípio do menor privilégio deve ser aplicado, limitando as permissões a ARNs de recursos específicos. Para mais detalhes, consulte a documentação de Segurança no AWS Lambda e a Segurança no Amazon SageMaker AI.
Personalização do treinamento com o Nova Forge SDK
A AWS disponibilizou o Nova Forge SDK para gerenciar todo o ciclo de personalização de modelos — da preparação dos dados ao deploy e monitoramento. O SDK elimina a necessidade de buscar receitas ou URIs de container para técnicas específicas. No caso de uso jurídico, os parâmetros de treinamento foram ajustados via overrides:
Os resultados foram avaliados em um cenário “best of k” com comentário único, onde cada modelo gerou múltiplos comentários por amostra e o de maior qualidade foi pontuado. Essa abordagem estabelece um limite superior de desempenho e permite comparação justa entre modelos.
Figura 1 — Pontuações de Validação de Schema JSON (escala 0–1, quanto maior melhor) — fonte: AwsFigura 2 — Pontuações agregadas do juiz LLM (escala 1–5, quanto maior melhor) — fonte: Aws
O Amazon Nova 2 Lite com RFT alcançou score agregado de 4.33 — o maior entre todos os modelos avaliados — além de validação perfeita do schema JSON. Isso representa uma melhoria significativa sobre o Nova 2 Lite base (3.05), o Nova 2 Lite com Ajuste Fino Supervisionado — SFT (3.16), o Claude Haiku 4.5 (3.54) e o Claude Sonnet 4.5 (3.89).
Outros destaques dos resultados:
Eliminação de artefatos indesejados: durante iterações de SFT, foram observados comportamentos problemáticos como geração repetitiva de comentários e predições anômalas de caracteres Unicode. Esses problemas não apareceram nos checkpoints de RFT, pois o mecanismo de recompensa desencoraja naturalmente tais artefatos.
Boa generalização para novos critérios de avaliação: quando os modelos RFT foram avaliados com um prompt de juiz modificado (alinhado, mas não idêntico ao usado no treinamento), o desempenho se manteve forte — evidência de que o RFT aprende padrões de qualidade generalizáveis, não apenas decora critérios específicos.
Custo computacional maior: o RFT exigiu de 4 a 8 rollouts por amostra de treinamento, aumentando os custos em relação ao SFT. Para aplicações de missão crítica — como revisão jurídica, conformidade financeira ou documentação de saúde — os ganhos de desempenho justificam esse custo adicional.
Conclusão
O RFT com LLM-as-a-judge representa uma abordagem poderosa para alinhar LLMs a aplicações específicas de domínio. Como demonstrado no caso de revisão de contratos jurídicos, a metodologia entrega melhorias significativas sobre modelos base e sobre o ajuste fino supervisionado tradicional.
Para equipes que constroem sistemas de IA de missão crítica, a recomendação da AWS é começar pequeno: validar o design do juiz em benchmarks curados, verificar a resiliência da infraestrutura e escalar gradualmente monitorando sinais de reward hacking.
A AWS anunciou o Neuron Agentic Development, uma coleção open-source de agentes e habilidades projetada para equipar assistentes de codificação com IA e acelerar o desenvolvimento sobre o AWS Trainium e o AWS Inferentia. Em termos práticos, a novidade traz capacidades agênticas diretamente para o fluxo de trabalho do desenvolvedor, cobrindo desde a criação de kernels até a análise de desempenho.
O lançamento inicial foca no desenvolvimento de kernels pela Interface de Kernel Neuron (NKI) — a camada de programação de baixo nível que dá acesso direto ao hardware Trainium, permitindo escrever kernels de computação personalizados para extrair o máximo de desempenho da plataforma.
Como funciona na prática
O Neuron Agentic Development leva o conhecimento especializado de NKI para dentro da IDE agêntica do desenvolvedor — como Claude Code e Kiro — por meio de linguagem natural. Ou seja, em vez de consultar documentação extensa ou depurar manualmente, o desenvolvedor pode simplesmente descrever o que precisa e o agente executa a tarefa.
Alguns exemplos do que já é possível fazer com essa abordagem:
Descrever uma operação PyTorch e receber um kernel NKI funcional como resposta;
Pedir ao agente que corrija um erro de compilação — ele identifica o problema automaticamente e aplica a correção;
Solicitar uma análise de desempenho e receber um relatório apontando quais linhas do código do kernel estão causando gargalos.
Capacidades cobertas
O conjunto de capacidades disponíveis nesta versão inicial abrange:
Autoria de kernels — criação de kernels NKI a partir de descrições em linguagem natural;
Depuração — identificação e correção automática de erros de compilação;
Consulta à documentação — busca contextual na documentação do Neuron;
Captura de perfil — coleta de dados de profiling durante a execução;
Análise de perfil — interpretação dos dados coletados para identificar pontos de melhoria.
Visão de longo prazo
A AWS posiciona o Neuron Agentic Development como um framework amplo para capacidades agênticas em toda a pilha Neuron, sendo o desenvolvimento de kernels NKI apenas o ponto de partida. A expectativa é que novas capacidades sejam incorporadas ao longo do tempo, expandindo o escopo além do NKI.
Três novos modelos disponíveis no SageMaker JumpStart
A AWS anunciou a chegada de três novos modelos ao Amazon SageMaker JumpStart: o Paraphrase-multilingual-MiniLM-L12-v2, o Microsoft Table Transformer Detection e o Bielik-11B-v3.0-Instruct. Cada um atende a casos de uso bastante distintos, o que torna essa atualização relevante para equipes que trabalham com processamento de linguagem natural (PLN), extração de dados em documentos e aplicações em idiomas europeus.
Paraphrase-multilingual-MiniLM-L12-v2
Desenvolvido pela Sentence Transformers, esse é um modelo leve de similaridade semântica que converte sentenças e parágrafos em vetores densos de 384 dimensões — e faz isso em mais de 50 idiomas simultaneamente.
A proposta é simples e poderosa: encontrar conteúdos semanticamente parecidos dentro de um mesmo idioma ou entre idiomas diferentes, sem precisar de configurações específicas por língua. Isso o torna especialmente útil para:
Busca semântica multilíngue (Recuperação de Informação Cross-lingual)
Agrupamento de documentos em múltiplos idiomas
Pontuação de similaridade entre sentenças
Para equipes brasileiras que lidam com conteúdo em português e precisam cruzar informações com documentos em outros idiomas, esse modelo pode ser um recurso bastante prático.
Microsoft Table Transformer Detection
Este modelo é baseado na arquitetura Detecção de Objetos por Transformers (DETR) e foi treinado no conjunto de dados PubTables-1M, com foco exclusivo em detectar tabelas dentro de documentos não estruturados — como PDFs e imagens digitalizadas.
A ideia é resolver um problema clássico em pipelines de digitalização de documentos: localizar automaticamente onde estão as tabelas em relatórios financeiros, artigos científicos e outros tipos de documentos, antes de extrair os dados que elas contêm. Isso é especialmente valioso em fluxos de trabalho de extração automatizada de dados em larga escala.
Bielik-11B-v3.0-Instruct
Desenvolvido pela SpeakLeash em parceria com o ACK Cyfronet AGH, o Bielik é um modelo de linguagem generativa com 11 bilhões de parâmetros, treinado em corpora multilíngues que cobrem 32 idiomas europeus, com ênfase especial no polonês.
Entre suas principais capacidades estão:
Diálogo em polonês e outros idiomas europeus
Raciocínio em Ciência, Tecnologia, Engenharia e Matemática (STEM) e matemático
Tarefas de lógica e uso de ferramentas
Aplicações empresariais que exigem compreensão linguística profunda em idiomas europeus
Para organizações que atendem mercados europeus ou precisam de um modelo generativo com forte cobertura de idiomas do continente, o Bielik representa uma opção robusta agora acessível diretamente pelo JumpStart.
Como acessar os modelos
Os três modelos podem ser implantados com poucos cliques pela seção Modelos do SageMaker Studio, ou programaticamente via SDK Python do SageMaker, diretamente na conta AWS do usuário. Para mais detalhes sobre como implantar e utilizar modelos de fundação no SageMaker JumpStart, a AWS disponibiliza a documentação oficial do Amazon SageMaker JumpStart.
Novos modelos de IA disponíveis no SageMaker JumpStart
A AWS anunciou a disponibilidade dos modelos Gemma 4 E4B, Gemma 4 26B-A4B e Gemma 4 31B no Amazon SageMaker JumpStart, ampliando o portfólio de modelos de fundação acessíveis aos clientes da plataforma. Os três modelos são desenvolvidos pelo Google DeepMind e chegam com ajuste de instrução (instruction-tuned), capacidades multimodais, raciocínio configurável, chamada nativa de funções e suporte multilíngue para mais de 140 idiomas.
O que esses modelos são capazes de fazer
Os três modelos compartilham um conjunto robusto de capacidades voltadas para casos de uso empresariais. Veja o que cada funcionalidade oferece:
Thinking (Raciocínio): modo de raciocínio integrado que permite ao modelo pensar passo a passo antes de responder.
Compreensão de imagens: detecção de objetos, análise de documentos e PDFs, entendimento de interfaces gráficas (UI), interpretação de gráficos, Reconhecimento Óptico de Caracteres (OCR) multilíngue e reconhecimento de escrita à mão.
Compreensão de vídeo: análise de conteúdo em vídeo por meio do processamento de sequências de frames.
Entrada multimodal intercalada: possibilidade de combinar texto e imagens em qualquer ordem dentro de um único prompt.
Function Calling (Chamada de funções): suporte nativo para uso estruturado de ferramentas externas, viabilizando fluxos de trabalho agênticos.
Programação: geração, complementação e correção de código.
Multilíngue: suporte nativo a mais de 35 idiomas, com pré-treinamento em mais de 140 idiomas.
Diferencial do Gemma 4 E4B
Entre os três modelos disponibilizados, o Gemma 4 E4B se destaca por oferecer uma capacidade adicional: suporte a entrada de áudio para Reconhecimento Automático de Fala (ASR) e tradução de fala para texto em múltiplos idiomas. Esse diferencial o torna uma opção interessante para aplicações que envolvem processamento de voz.
Como começar a usar
Com o SageMaker JumpStart, a AWS permite que os clientes façam o deploy de qualquer um desses modelos com poucos cliques, sem a necessidade de configurações complexas. Para começar, basta acessar a seção Models do SageMaker Studio ou utilizar o SageMaker Python SDK para realizar o deploy direto na conta AWS. Mais detalhes sobre como implantar e utilizar modelos de fundação estão disponíveis na documentação oficial do Amazon SageMaker JumpStart.
O problema central: memória sem organização é memória inútil
Quem já trabalhou com agentes de IA sabe que persistir contexto entre sessões é um dos desafios mais práticos do desenvolvimento. Não basta armazenar informações — é preciso organizá-las de forma que possam ser recuperadas com precisão, no momento certo, pela entidade certa. Sem isso, o agente traz contexto irrelevante, mistura dados de usuários diferentes ou expõe informações que não deveriam ser acessíveis.
Para endereçar exatamente esse problema, a AWS publicou um guia técnico detalhado sobre o design de namespaces no Amazon Bedrock AgentCore Memory. Se você ainda não conhece o serviço, vale começar pela introdução ao AgentCore Memory antes de mergulhar nos padrões avançados.
O que são namespaces no AgentCore Memory?
Namespaces são caminhos hierárquicos que organizam os registros de memória de longo prazo dentro de um recurso de memória do AgentCore. A analogia mais direta é com estruturas de diretórios em um sistema de arquivos: cada registro fica armazenado em um caminho específico, e esse caminho determina como ele será recuperado e quem poderá acessá-lo.
Por exemplo, as preferências de um usuário podem ficar em /actor/customer-123/preferences/, enquanto o resumo de uma sessão específica fica em /actor/customer-123/session/session-789/summary/. Com essa estrutura, é possível recuperar memórias com exatamente o nível de granularidade necessário.
Se você já trabalhou com chaves de partição no Amazon DynamoDB ou com estruturas de prefixo no Amazon Simple Storage Service (Amazon S3), o raciocínio é o mesmo: antes de definir a estrutura, você precisa pensar nos padrões de acesso. As perguntas fundamentais são:
Quem precisa acessar essas memórias — um único usuário ou todos os usuários de um agente?
Qual granularidade de recuperação é necessária — resumos por sessão ou preferências acumuladas ao longo do tempo?
Quais são os limites de isolamento — a memória de um usuário pode ser visível para outro?
A principal diferença em relação a uma chave de partição é que namespaces suportam recuperação hierárquica além do match exato. É possível consultar em qualquer nível da hierarquia, não apenas na folha.
Templates de namespace e resolução dinâmica
Ao criar um recurso de memória, o namespace é definido por meio do campo namespaceTemplate dentro de cada configuração de estratégia. Três variáveis pré-definidas estão disponíveis para composição dinâmica:
{actorId} — resolve para o identificador do ator nos eventos processados
{sessionId} — resolve para o identificador da sessão
{memoryStrategyId} — resolve para o identificador da estratégia
Veja um exemplo de criação de recurso de memória com templates de namespace:
Quando eventos chegam com actorId=customer-456 e sessionId=session-789, os namespaces resolvidos ficam:
/actor/customer-456/facts/
/actor/customer-456/session/session-789/summary/
Padrões de design por estratégia de memória
Cada tipo de estratégia de memória tem necessidades de escopo diferentes. A AWS detalha os padrões recomendados para cada caso.
1. Memória semântica e preferências: escopo por ator
A memória semântica captura fatos e conhecimentos extraídos de conversas — por exemplo, “a empresa do cliente tem 500 funcionários”. A memória de preferências captura escolhas e estilos — por exemplo, “o usuário prefere Python para desenvolvimento”. Ambas acumulam valor ao longo do tempo e são relevantes em qualquer sessão futura.
Para esses casos, o namespace deve ser escopado ao ator:
/actor/{actorId}/facts/
/actor/{actorId}/preferences/
Com esse design, fatos e preferências de um usuário ficam consolidados em um único namespace, independentemente de qual sessão os originou. O motor de consolidação do AgentCore Memory mescla memórias relacionadas dentro do mesmo namespace.
Vale notar que quando o namespace inclui o sessionId no caminho dos fatos (como /actor/{actorId}/{sessionId}/facts/), o motor de consolidação não consegue enxergar registros de sessões diferentes — e os fatos nunca são mesclados. Por isso, para memórias que devem persistir entre sessões, o escopo por ator é o padrão correto.
Em alguns casos, um administrador pode precisar recuperar informações de múltiplos atores. Para isso, a AWS sugere inverter a estrutura, colocando o identificador do ator como filho do tipo de memória:
/customer-issues/{actorId}/
/sales/{actorId}/
Com essa estrutura invertida, uma consulta com namespacePath="/customer-issues/" retorna problemas reportados por todos os clientes, enquanto uma consulta com namespace="/customer-issues/customer-123/" retorna apenas os dados daquele ator específico.
2. Memória de resumo: escopo por sessão
A memória de resumo cria narrativas das conversas, capturando pontos principais e decisões. Em vez de alimentar todo o histórico de uma conversa na janela de contexto do modelo de linguagem (LLM), o agente pode recuperar um resumo compacto que preserva as informações essenciais com muito menos tokens.
Como resumos estão intrinsecamente ligados a uma conversa específica, o namespace deve incluir o identificador da sessão: /actor/{actorId}/session/{sessionId}/summary/. Assim, cada sessão tem seu próprio resumo, mas todos ficam organizados sob o ator para recuperação cruzada quando necessário.
3. Memória episódica: escopo por sessão com hierarquia de reflexão
A memória episódica captura rastros completos de raciocínio — o objetivo, os passos executados, os resultados e as reflexões. Como cada episódio representa o que aconteceu em uma interação específica, ele deve ser escopado à sessão, de forma similar aos resumos.
Reflexões são insights transversais, armazenados em um nível pai. Elas generalizam aprendizados entre sessões — por exemplo, “quando uma restrição de classe tarifária bloqueia uma modificação, busque voos alternativos imediatamente em vez de apenas explicar a política”. O namespace das reflexões deve ser um subcaminho do namespace dos episódios:
O AgentCore Memory oferece três APIs principais para recuperação de memória de longo prazo.
Busca semântica com RetrieveMemoryRecords
Esse é o método primário durante interações do agente. Ele retorna as memórias semanticamente relevantes para uma consulta, com base em significado — não em correspondência exata de texto.
# Retrieve memories relevant to the current user query
memories = agentcore_client.retrieve_memory_records(
memoryId="mem-12345abcdef",
namespace="/actor/customer-123/facts/",
searchCriteria={
"searchQuery": "What cloud migration approach is the customer using?",
"topK": 5
}
)
A consulta de busca pode vir diretamente da pergunta do usuário ou ser gerada pelo próprio LLM do agente para cenários mais complexos. No segundo caso, há um custo adicional de latência.
Listagem direta com ListMemoryRecords
Usado quando é necessário enumerar memórias dentro de um namespace específico — por exemplo, exibir as preferências armazenadas de um usuário em uma interface, auditar o que existe ou executar operações em lote.
# List all memories in a specific namespace
records = agentcore_client.list_memory_records(
memoryId="mem-12345abcdef",
namespace="/actor/customer-123/preferences/"
)
Acesso e exclusão diretos com GetMemoryRecord e DeleteMemoryRecord
Quando o ID específico de um registro é conhecido (por exemplo, a partir de uma listagem anterior), é possível acessá-lo ou removê-lo diretamente. Esses métodos são úteis para fluxos de gerenciamento de memória que permitem aos usuários visualizar, corrigir ou excluir registros específicos pela interface da aplicação.
# Get a specific memory record
record = agentcore_client.get_memory_record(
memoryId="mem-12345abcdef",
memoryRecordId="rec-abc123"
)
# Delete a specific memory record
agentcore_client.delete_memory_record(
memoryId="mem-12345abcdef",
memoryRecordId="rec-abc123"
)
namespace vs. namespacePath: match exato versus recuperação hierárquica
O AgentCore Memory oferece dois campos distintos para escopar a recuperação, e entender a diferença é crítico para o comportamento correto do sistema.
O campo namespace realiza correspondência exata — retorna apenas os registros armazenados naquele caminho preciso. Já o campo namespacePath realiza correspondência hierárquica, retornando todos os registros cujo namespace esteja sob o caminho especificado.
A tabela abaixo, extraída do guia original, resume quando usar cada abordagem:
Recuperar preferências semanticamente relevantes:RetrieveMemoryRecords com namespace → /actor/customer-123/preferences/
Recuperar um resumo de sessão específica:ListMemoryRecords com namespace → /actor/customer-123/session/session-001/summary/
Listar todas as preferências de um usuário:ListMemoryRecords com namespace → /actor/customer-123/preferences/
Buscar em todas as memórias de um usuário:RetrieveMemoryRecords com namespacePath → /actor/customer-123/
Listar resumos de todas as sessões de um usuário:ListMemoryRecords com namespacePath → /actor/customer-123/session/
É importante pensar bem nos padrões de isolamento ao usar namespacePath, pois a travessia em árvore pode expor dados não intencionais se a hierarquia não estiver bem planejada.
Controle de acesso via IAM
Os namespaces se integram ao Gerenciamento de Identidade e Acesso (IAM) da AWS por meio de condition keys que restringem quais namespaces uma entidade pode incluir nas requisições à API de memória.
Políticas de match exato
Para restringir o acesso a um namespace específico, usa-se StringEquals com a condition key bedrock-agentcore:namespace:
Essa política garante que um usuário só consiga recuperar memórias do seu próprio namespace de preferências, usando a tag de principal userId para escopo dinâmico.
Políticas de recuperação hierárquica
Para acesso hierárquico, usa-se StringLike com a condition key bedrock-agentcore:namespacePath:
Com essa configuração, o usuário pode realizar recuperação hierárquica em seus próprios namespaces (fatos, preferências, resumos), enquanto o acesso aos dados de outros usuários é bloqueado.
Conclusão: design de namespace é fundação, não detalhe
O guia publicado pela AWS deixa claro que o design de namespaces é tão fundamental quanto o design de esquemas em um banco de dados. Pensar nos padrões de acesso e nos limites de isolamento antes de definir os templates de namespace é o que separa um sistema de memória eficaz de um que traz contexto errado ou expõe dados indevidamente.
Os pontos-chave do guia são:
Pense nos padrões de acesso e isolamento antes de criar os templates de namespace
Escope memórias semânticas e de preferências ao ator (/actor/{actorId}/) para consolidação entre sessões
Escope resumos e episódios à sessão (/actor/{actorId}/session/{sessionId}/), pois são específicos de cada conversa
Use namespace para match exato quando souber o caminho preciso, e namespacePath para recuperação hierárquica quando precisar buscar em uma subárvore
Use barras no início e no fim dos caminhos para manter consistência e evitar colisões de prefixo
Use as condition keys do IAM (bedrock-agentcore:namespace e bedrock-agentcore:namespacePath) para controlar quais namespaces podem ser acessados
A IA generativa está transformando rapidamente a forma como empresas operam — de atendimento ao cliente a criação de conteúdo, as possibilidades parecem crescer a cada semana. Mas junto com essa expansão vem uma responsabilidade que muitas equipes ainda estão aprendendo a lidar: como garantir que essas aplicações sejam seguras, confiáveis e eticamente construídas?
A AWS publicou um material aprofundado sobre como projetar confiança e segurança em aplicações baseadas no Amazon Bedrock, e os números apresentados no documento deixam claro que isso não é apenas uma questão técnica — é um diferencial competitivo real. Uma pesquisa da Accenture em parceria com a AWS mostra que organizações com uma abordagem madura de IA responsável registram 82% de melhoria na confiança dos colaboradores em relação à adoção de IA. Além disso, empresas que oferecem produtos com IA responsável experimentam um aumento de 25% na fidelidade e satisfação dos clientes.
Esses dados reforçam que investir em segurança e responsabilidade no desenvolvimento de IA não é custo — é construção de valor.
As dimensões centrais da IA responsável segundo a AWS
Para estruturar esse trabalho, a AWS identifica oito dimensões que formam a espinha dorsal de uma implementação responsável de IA. Entender cada uma delas ajuda as equipes a não deixar pontos cegos no desenvolvimento:
Segurança: foca em prevenir saídas prejudiciais do sistema e evitar uso indevido, direcionando os sistemas de IA para priorizar a proteção de usuários e da própria aplicação.
Controlabilidade: diz respeito aos mecanismos que monitoram e orientam o comportamento do sistema de IA, garantindo que ele opere dentro de parâmetros definidos.
Equidade (Fairness): considera os impactos da IA sobre diferentes grupos de usuários, evitando discriminação ou tratamento desigual.
Explicabilidade (Explainability): foca em compreender e avaliar as saídas do sistema, tornando os resultados interpretáveis.
Segurança e privacidade: garante que dados e modelos sejam obtidos, utilizados e protegidos de forma adequada.
Veracidade e robustez: busca resultados corretos mesmo diante de entradas inesperadas ou adversariais.
Governança: assegura que o desenvolvimento, a implantação e o gerenciamento dos sistemas de IA estejam alinhados com padrões éticos, exigências legais e valores sociais.
Transparência: foca em entender como os sistemas de IA tomam decisões, por que produzem determinados resultados e quais dados utilizam.
Além de entender as dimensões, é fundamental saber quando aplicar cada consideração de segurança. A AWS estrutura isso em três fases distintas do ciclo de vida da IA responsável:
Fase 1: Design e Desenvolvimento
Nesta fase, a orientação é avaliar minuciosamente os riscos potenciais de segurança antes de escrever qualquer linha de código. A equipe precisa ter clareza sobre o que a aplicação de IA deve fazer, o que ela não deve fazer e o que precisa ser ativamente impedido. As proteções (guardrails) devem ser incorporadas desde o início — não adicionadas depois como um remendo. Também é essencial que todos na equipe de desenvolvimento compreendam as capacidades e os limites da aplicação.
Fase 2: Implantação
É aqui que a teoria encontra a realidade. Na fase de implantação, medidas robustas de segurança devem ser implementadas em múltiplas camadas: desde treinamento abrangente dos usuários até processos proativos de monitoramento e revisão. Cada aplicação, produto e funcionalidade precisa ter protocolos claros de segurança e diretrizes para o usuário final. A AWS recomenda pensar além do lançamento — é necessário construir um framework de segurança holístico, que pode incluir etapas como testes de red team, para proteger a marca, os usuários e as partes interessadas.
Fase 3: Operações
Segurança não é algo que se configura uma vez e esquece. Na fase operacional, a vigilância contínua é indispensável. Mecanismos de feedback em tempo real ajudam a identificar problemas de segurança cedo, e avaliações periódicas de desempenho são fundamentais. A equipe também deve monitorar mudanças na forma como a aplicação é utilizada, já que os riscos evoluem conforme a tecnologia avança. Para mais detalhes, a AWS disponibiliza o Guia de Uso Responsável de IA.
Detecção de abusos: camadas de proteção
Os modelos de fundação disponíveis no Amazon Bedrock já são construídos com mecanismos de segurança para prevenir saídas prejudiciais. Mas em ambientes de produção, a AWS recomenda implementar sistemas adicionais de segurança nas entradas para criar capacidades de detecção precoce de conteúdos problemáticos, usuários suspeitos ou padrões de uso indevido.
Para manter a confiança nos serviços de IA, a ação preventiva é o caminho mais eficiente — e a AWS oferece ferramentas específicas para isso. O ponto de partida é definir claramente o escopo do caso de uso de IA, o que envolve:
Entender quem são os usuários da aplicação
Antecipar cenários potenciais de uso indevido
Definir a tolerância a riscos do negócio
Esse escopo orienta o desenvolvimento de um framework de segurança preciso, que endereça os riscos específicos da implementação sem comprometer o desempenho esperado.
Monitoramento com Amazon CloudWatch
O Amazon CloudWatch oferece visibilidade essencial sobre o comportamento e o desempenho dos sistemas de IA. Com o logging configurado de forma abrangente, é possível capturar informações importantes em diferentes segmentos de usuários e tipos de interação, como:
Volumes de requisições
Latências de resposta
Taxas de rejeição
Acionamentos de filtros de conteúdo
Esses dados permitem identificar padrões de abuso ou comportamentos inesperados antes que afetem as operações. Dashboards do CloudWatch visualizam as métricas conforme as prioridades de monitoramento, e alertas automatizados notificam a equipe quando limites são ultrapassados. Um ponto de atenção importante: por padrão, o logging do Amazon Bedrock está desativado. É necessário ativá-lo para a aplicação — para configurar isso, a AWS orienta entrar em contato com o gerente de conta.
Proteção personalizada com Amazon Bedrock Guardrails
O Amazon Bedrock Guardrails oferece mecanismos de proteção configuráveis, adaptados a perfis de risco e políticas de conteúdo específicos. É possível personalizar o Bedrock Guardrails para atender aos requisitos da aplicação, incluindo:
Definir tópicos indesejáveis relevantes para o domínio da aplicação
Configurar limites apropriados de filtragem de conteúdo
Configurar parâmetros de detecção e redação de informações sensíveis alinhados às políticas de dados
Também é possível configurar controles que priorizam a precisão e previnem alucinações, mantendo a flexibilidade criativa conforme as necessidades da aplicação. Uma configuração cuidadosa do Guardrails permite equilibrar desempenho e segurança de acordo com os requisitos e fatores de risco de cada caso de uso.
O processo de resposta a abusos
Mesmo com todos os mecanismos de segurança implementados, abusos ainda podem ocorrer à medida que novos riscos surgem. Caso a equipe receba um relatório de abuso da equipe de Confiança e Segurança da AWS (AWS Trust & Safety), a AWS orienta seguir estas etapas:
Confirmar o recebimento: acusar o recebimento do relatório de abuso em até 24 horas. Se a investigação ainda estiver em andamento, informar à AWS e indicar o prazo estimado para conclusão.
Investigar o problema: conduzir uma investigação completa, incluindo análise dos logs (se habilitados), revisão dos inputs do Amazon Bedrock e verificação de acessos não autorizados. Embora os relatórios de abuso da AWS incluam uma amostra de IDs de prompts, a recomendação é investigar o uso geral da aplicação para identificar padrões e possíveis problemas sistêmicos.
Tomar as medidas adequadas: se necessário, implementar correções, atualizar as proteções, tratar usuários em violação ou redesenhar funcionalidades. É importante avaliar se são necessárias correções sistêmicas ou de causa raiz, e não apenas ações pontuais sobre um usuário abusivo. Um incidente por um único usuário pode indicar vulnerabilidades nos mecanismos de segurança que permitem abusos contínuos.
Reportar à AWS Trust & Safety: após a investigação e implementação de correções, fornecer um relatório à equipe com os achados e as etapas de remediação. Ser transparente sobre o que aconteceu e como foi endereçado. Se a conclusão for de que não houve violação, explicar o raciocínio e incluir exemplos dos prompts e do caso de uso do negócio sempre que possível.
Conclusão
Construir aplicações de IA generativa com segurança e responsabilidade não é uma tarefa opcional — é parte fundamental do desenvolvimento de produtos que as pessoas e as organizações possam confiar. A AWS estruturou um conjunto robusto de dimensões, fases do ciclo de vida e ferramentas práticas para ajudar as equipes a fazer isso de forma sistemática.
Para equipes brasileiras que trabalham com o Amazon Bedrock, o recado é claro: incorporar segurança desde o design, monitorar continuamente em produção e ter um processo definido para responder a incidentes são práticas que protegem tanto os usuários quanto o negócio.
Por que um proxy MCP serverless importa em produção
Quando agentes de IA se conectam a ferramentas por meio do Protocolo de Contexto de Modelo (MCP), eles ganham acesso a capacidades que vão de consultas a bancos de dados e chamadas de API até operações em arquivos e integrações com serviços de terceiros. Em produção, essas interações precisam de governança adequada, controles e observabilidade alinhados às políticas de segurança da organização.
Isso inclui sanitizar entradas de ferramentas antes que cheguem aos sistemas de backend, gerar trilhas de auditoria em formatos específicos ou redigir dados sensíveis na camada de protocolo. Esses requisitos são moldados por padrões internos de governança, regulamentações do setor e as especificidades de cada ambiente de produção.
A AWS publicou um guia mostrando como implantar um proxy MCP serverless no Amazon Bedrock AgentCore Runtime que fornece exatamente essa camada programável.
O contexto: Gateway, interceptores Lambda e quando o proxy faz mais sentido
O Amazon Bedrock AgentCore Gateway já oferece governança centralizada para integração entre agentes e ferramentas, incluindo descoberta semântica de ferramentas, credenciais gerenciadas e aplicação de políticas. Para organizações que precisam embutir lógica personalizada no caminho de requisição do Gateway, o serviço suporta interceptores Lambda — que permitem executar código de validação, transformação ou filtragem como funções AWS Lambda em cada invocação de ferramenta.
Porém, algumas organizações já investiram em lógica de filtragem MCP personalizada fortemente acoplada a bibliotecas internas ou sistemas de conformidade on-premises. Elas querem reutilizar essa lógica no AgentCore Runtime sem refatorá-la em funções Lambda. Outras operam em ambientes híbridos onde executar controles como um servidor MCP independente oferece mais portabilidade. Nesses casos, um proxy MCP serverless rodando no AgentCore Runtime é um padrão complementar e mais adequado.
O que é o AgentCore Runtime e por que ele serve de base para o proxy
O AgentCore Runtime é um ambiente de computação totalmente gerenciado para implantar agentes de IA e servidores MCP. Ele oferece infraestrutura serverless com escalonamento automático, observabilidade integrada via Amazon CloudWatch e OpenTelemetry, além do AgentCore Identity para autenticação e autorização.
Como o Runtime suporta nativamente o protocolo MCP, ele permite hospedar servidores MCP — incluindo proxies MCP que adicionam controles personalizados ao tráfego. O proxy apresentado no guia é stateless, roda como uma carga de trabalho serverless no Runtime, descobre ferramentas de um servidor MCP upstream na inicialização, re-expõe essas ferramentas com sua lógica personalizada aplicada e encaminha requisições de forma transparente.
Visão geral da arquitetura
A solução envolve três camadas lógicas que trabalham juntas via MCP: o cliente MCP, o proxy MCP no AgentCore Runtime e o servidor MCP upstream. O fluxo de requisições percorre essas camadas em sequência: o cliente envia requisições MCP ao proxy, o proxy aplica a lógica personalizada e encaminha a requisição ao servidor MCP upstream, e o servidor upstream processa a requisição e retorna a resposta pelo mesmo caminho.
O servidor MCP upstream pode ser hospedado em qualquer lugar — no próprio AgentCore Runtime, na infraestrutura da organização ou como serviço de terceiros. No guia publicado pela AWS, o AgentCore Gateway é usado como servidor upstream porque já fornece um endpoint compatível com MCP com alvos registrados, permitindo seguir o passo a passo sem precisar configurar um servidor MCP separado.
Como o proxy MCP funciona internamente
A implementação usa o FastMCP para descobrir ferramentas do servidor MCP upstream na inicialização e encaminhar cada requisição do cliente em tempo de execução. O proxy não define ferramentas próprias e não tem conhecimento prévio do que o servidor upstream expõe.
Quando o processo do proxy inicia, ele envia uma requisição padrão tools/list ao servidor upstream. O servidor retorna o catálogo completo de ferramentas disponíveis. Para cada ferramenta, o proxy registra dinamicamente uma ferramenta FastMCP local com o mesmo nome e descrição. Cada ferramenta é suportada por uma função handler que encaminha requisições tools/call ao servidor upstream e retorna a resposta.
Clientes MCP que se conectam ao proxy veem o mesmo catálogo de ferramentas e obtêm os mesmos resultados como se estivessem se conectando diretamente ao servidor upstream. Como o proxy é um servidor MCP Python padrão que você possui e implanta, é possível inserir lógica personalizada antes de encaminhar uma chamada de ferramenta ou após receber a resposta.
Autorização entre os componentes
A autorização é aplicada de forma independente em cada camada da arquitetura, criando fronteiras de confiança distintas ao longo do fluxo.
Do agente ao proxy MCP
Quando um agente se conecta ao proxy MCP, ele usa o AgentCore Identity para autenticação e autorização. O proxy utiliza as capacidades que o AgentCore Identity oferece, incluindo gerenciamento centralizado de identidades de agentes e armazenamento seguro de credenciais.
Do proxy ao servidor MCP upstream
O proxy precisa se autenticar no servidor MCP upstream ao qual se conecta. O método de autenticação depende dos requisitos do servidor upstream. O AgentCore Identity oferece autorização de entrada para cargas de trabalho hospedadas no AgentCore Runtime por meio de Gerenciamento de Identidade e Acesso da AWS (IAM) usando AWS Signature Version 4 (SigV4) e autorização baseada em Token Web JSON (JWT) usando credenciais de cliente OAuth 2.0.
Para autorização baseada em IAM, o proxy assina requisições usando SigV4 com a função de execução IAM que herda do AgentCore Runtime. O script de implantação concede a essa função permissões bedrock-agentcore:InvokeGateway, com o campo Resource com escopo para o Gateway. O proxy usa a sessão boto3 do runtime para assinar requisições automaticamente.
Para autorização OAuth, o proxy substitui a assinatura SigV4 por um token bearer obtido via concessão de credenciais de cliente OAuth 2.0. O token é armazenado em cache na memória e atualizado automaticamente quando se aproxima da expiração. Cada requisição de saída ao servidor MCP upstream inclui o token como cabeçalho Authorization: Bearer. O projeto no GitHub usa autorização baseada em IAM como método padrão, mas o script de implantação também suporta autorização baseada em JWT.
Do servidor upstream para as ferramentas
O servidor MCP upstream se autentica nas ferramentas downstream usando provedores de credenciais do AgentCore Identity, que gerenciam tokens OAuth 2.0, chaves de API e rotação de credenciais de forma transparente. A autorização de saída opera da mesma forma independentemente de as requisições se originarem do proxy ou de um cliente direto.
Pré-requisitos para a implantação
Ambiente de desenvolvimento Linux ou macOS com Python 3.12 ou posterior instalado
(Opcional, para OAuth) Um pool de usuários do Amazon Cognito com domínio configurado e um cliente de aplicativo que usa concessão de credenciais de cliente com segredo de cliente
Implantando a solução
O processo começa clonando o repositório do GitHub e revisando a estrutura do projeto. Em seguida, o arquivo deploy_config.json deve ser configurado com os valores do ambiente: o endpoint do servidor MCP upstream em gateway_endpoint, a região AWS em region, e opcionalmente o Nome de Recurso Amazon (ARN) do Gateway em gateway_api_id para restringir as permissões IAM a esse recurso específico.
O campo auth_mode determina como o proxy se autentica no servidor upstream — o padrão é "iam" para autenticação baseada em IAM. Para autenticação OAuth, define-se auth_mode como "jwt" e configuram-se os campos do Cognito.
O script automatizado setup_and_deploy.py executa o fluxo completo de implantação em sequência:
Valida pré-requisitos — verifica se AWS CLI, Python e Docker estão disponíveis e se as credenciais AWS estão configuradas
Cria uma função de execução IAM com política de confiança que permite ao bedrock-agentcore.amazonaws.com assumir a função, incluindo permissões para invocar o Gateway, gravar no Amazon CloudWatch Logs e extrair imagens do Amazon ECR
Configura o agente com a CLI do AgentCore executando agentcore configure com o protocolo MCP, apontando para o entrypoint do proxy em mcp_proxy/main.py
Lança o agente no AgentCore Runtime via agentcore launch, passando o endpoint do servidor upstream como variável de ambiente (GATEWAY_ENDPOINT)
Após a implantação, o status do agente proxy MCP pode ser verificado com agentcore status --agent mcp_proxy. O ARN do agente exibido na saída é usado no cliente de teste para invocar o proxy.
Oportunidades de personalização
Tokenização de dados sensíveis
Argumentos de chamadas de ferramentas podem conter Informações de Identificação Pessoal (PII) que não devem chegar aos sistemas de backend em texto claro. O fluxo de encaminhamento do proxy oferece um ponto de interceptação natural para adicionar tokenização. O código relevante fica na função _make_tool_handler em main.py:
def _make_tool_handler(tool_name: str):
"""Create a tool handler function that forwards calls to the gateway."""
def handler(**kwargs) -> str:
# --- Tokenize: scan kwargs for PII and replace with tokens ---
result = _send_gateway_request(
"tools/call",
{"name": tool_name, "arguments": kwargs}
)
content = result.get("content", [])
# --- Detokenize: reverse tokens in content before returning ---
if content and isinstance(content, list):
texts = [c.get("text", str(c)) for c in content if isinstance(c, dict)]
return "\n".join(texts) if texts else json.dumps(result)
return json.dumps(result)
return handler
A tokenização pode ser adicionada em dois pontos dentro do closure do handler: antes da chamada a _send_gateway_request, para escanear os valores de kwargs em busca de padrões de PII e substituí-los por tokens reversíveis (consulte o Guia de Tokenização para Melhorar a Segurança de Dados e Reduzir o Escopo de Auditoria na AWS); e após o retorno de _send_gateway_request, para reverter os tokens no conteúdo da resposta antes de devolvê-la ao cliente.
Controle de acesso por ferramenta
É possível restringir quais ferramentas um determinado chamador pode invocar, mesmo que o servidor upstream exponha o catálogo completo. Isso é implementado adicionando uma verificação de política no início da função handler criada por _make_tool_handler. Antes de encaminhar a requisição tools/call ao servidor upstream, o handler avalia a identidade do chamador em relação a uma política de acesso. Se o chamador não estiver autorizado para aquela ferramenta, o handler retorna uma resposta de erro sem contatar o servidor upstream. Também é possível filtrar a resposta de tools/list na função register_gateway_tools para expor apenas as ferramentas que correspondem a uma determinada política.
Limpeza dos recursos
Para evitar cobranças recorrentes, os recursos criados devem ser removidos após os testes. A CLI do AgentCore fornece um comando destroy que remove o agente e seus recursos associados:
O padrão de proxy MCP serverless no AgentCore Runtime oferece uma camada programável onde é possível aplicar lógica personalizada como validação de entrada, logging, limitação de taxa ou enriquecimento de resposta. O proxy é stateless, roda como um contêiner padrão no Runtime e pode ser conectado a qualquer servidor MCP upstream compatível, encadeando múltiplos endpoints ou adicionando lógica de middleware específica para a carga de trabalho.
O problema de escala no gerenciamento de acesso AWS
À medida que as organizações expandem sua presença na Amazon Web Services (AWS), gerenciar o acesso de forma segura, escalável e eficiente em múltiplas contas se torna um desafio crescente. A abordagem tradicional — criar usuários IAM individuais e atribuir permissões manualmente — não sustenta ambientes corporativos complexos.
Para endereçar esse problema, a AWS oferece o AWS IAM Identity Center, uma solução centralizada para gerenciar o acesso de colaboradores a contas AWS. Ele simplifica a autenticação, reforça a segurança e proporciona uma experiência de login consistente em diferentes ambientes.
O ponto mais poderoso dessa solução, no entanto, está na combinação entre permission sets e session tags — uma dupla que abre caminho para controle de acesso granular e otimização de custos sem aumentar a complexidade operacional.
O que são session tags e por que elas importam
Session tags são atributos dinâmicos que podem ser passados de um provedor de identidade externo para a AWS durante o processo de autenticação. Em vez de definir permissões estáticas por usuário, é possível usar informações contextuais — como departamento, projeto ou perfil de custo — para determinar o que cada sessão pode fazer.
Essa abordagem viabiliza o que a AWS chama de controle de acesso baseado em atributos (ABAC): as permissões são determinadas pelos atributos do usuário, não por regras fixas atribuídas individualmente. O resultado é um modelo mais flexível, onde adicionar um novo colaborador ao grupo correto no provedor de identidade já é suficiente para garantir o acesso adequado — sem necessidade de reconfigurar políticas IAM.
A arquitetura: Microsoft Entra ID + IAM Identity Center
O artigo publicado pela AWS demonstra como session tags derivadas de atributos de grupos no Microsoft Entra ID podem entregar uma funcionalidade equivalente às tags de roles do AWS Identity and Access Management (IAM). A integração usa dois protocolos complementares:
SAML 2.0 — para autenticação federada entre o Entra ID e o IAM Identity Center
SCIM — para sincronização automática de usuários e grupos do Entra ID para a AWS
O fluxo de autenticação funciona da seguinte forma: o usuário acessa a aplicação corporativa configurada no Azure, o Microsoft Entra ID realiza o login, e durante a autenticação SAML, atributos do usuário (como departamento, função, centro de custo ou ID de projeto) são enviados como session tags para o IAM Identity Center. A partir daí, esses atributos são usados para aplicar permissões granulares dentro da AWS.
Vale destacar que o exemplo usa políticas com permissões amplas por simplicidade didática. Em ambientes de produção, a AWS orienta seguir o princípio do menor privilégio e escopar as permissões adequadamente.
Após criar o permission set, é necessário provisioná-lo em uma conta AWS atribuindo acesso a usuários ou grupos no IAM Identity Center. Mais detalhes estão disponíveis em Atribuir acesso de usuário ou grupo a contas AWS.
3. Configurar atributos de usuário no Microsoft Entra ID
No portal do Azure, dentro da aplicação corporativa criada, acesse a seção Single sign-on e depois Attributes & Claims. Em seguida, adicione uma nova claim com as seguintes configurações:
Name:AccessControl:<NomeDoAtributo> — para o exemplo, use AccessControl:glue:UsageProfile
Claim conditions:
User type: Members
Source: Attribute
Value: developer
O ponto central aqui é que as tags são atribuídas com base na associação de grupo no Entra ID. Isso significa que qualquer usuário que faça login no IAM Identity Center e pertença ao grupo configurado receberá automaticamente o valor da tag aplicado à sua sessão — sem necessidade de configurar tags individualmente por usuário.
Quando o AWS Glue recebe chamadas de API para criação de recursos, o sistema verifica se o usuário ou role está marcado com a chave glue:UsageProfile e o nome do perfil como valor.
Testando e validando a configuração
Com tudo configurado, o teste consiste em fazer login como usuário pelo Microsoft Entra ID acessando https://myapps.microsoft.com/ e verificar a criação de jobs no AWS Glue usando o perfil developer. Um job criado com sucesso dentro das configurações do perfil confirma que as session tags estão sendo aplicadas corretamente.
Validação via AWS CloudTrail
Para confirmar que as tags de sessão estão sendo transmitidas corretamente durante a autenticação, a AWS recomenda verificar o evento AssumeRoleWithSAML no AWS CloudTrail. O caminho é:
Acessar o console do CloudTrail
Selecionar Event history
Filtrar pelo nome de evento AssumeRoleWithSAML
Abrir um evento relevante e inspecionar a seção requestParameters
Confirmar que as session tags esperadas aparecem em PrincipalTags
Outros casos de uso: AWS Systems Manager Session Manager
Por padrão, o Session Manager inicia sessões usando uma conta de sistema gerada automaticamente chamada ssm-user. Para instâncias Linux, é possível configurar sessões para serem executadas como um usuário específico do sistema operacional. Nesse cenário, basta configurar o provedor de identidade para passar o atributo AccessControl:SSMSessionRunAs com o nome de um usuário do SO como valor durante a federação — e a sessão será iniciada com esse usuário automaticamente.
Limpeza dos recursos
Para evitar cobranças desnecessárias após os testes, a AWS orienta remover os recursos criados:
Remover a instância do IAM Identity Center e limpar a aplicação corporativa no Microsoft Entra
Excluir o perfil de uso do AWS Glue
Remover quaisquer outros recursos AWS provisionados durante os testes
Por que essa abordagem importa
A combinação de IAM Identity Center, SAML 2.0 e session tags representa uma evolução significativa na forma como organizações gerenciam acesso em ambientes AWS multi-conta. Ao usar ABAC com atributos vindos de um provedor de identidade externo, as equipes de segurança conseguem manter controle granular sem a complexidade de gerenciar usuários IAM individuais ou roles estáticas.
À medida que os ambientes de nuvem crescem em complexidade, adotar federação de identidade moderna e ABAC via IAM Identity Center é uma das formas mais eficazes de equilibrar segurança rigorosa com agilidade operacional.
A AWS anunciou a disponibilidade geral do AWS Glue 5.1 em todas as regiões comerciais e nas regiões AWS GovCloud (US). Com essa expansão, as regiões Ásia-Pacífico (Nova Zelândia), AWS GovCloud (US-West) e AWS GovCloud (US-East) passam a contar com a versão mais recente do serviço.
Para quem não conhece, o AWS Glue é um serviço serverless e escalável de integração de dados. Ele simplifica as tarefas de descoberta, preparação, movimentação e integração de dados provenientes de múltiplas fontes — sem a necessidade de gerenciar infraestrutura.
O que muda na versão 5.1
Atualização dos motores principais
O AWS Glue 5.1 atualiza os principais componentes de execução do serviço. Os destaques são:
Apache Spark 3.5.6 — motor de processamento distribuído de dados
Python 3.11 — linguagem de programação amplamente usada em pipelines de dados
Scala 2.12.18 — linguagem alternativa para desenvolvimento de jobs no Glue
Essas atualizações trazem melhorias de desempenho e segurança para os jobs existentes.
Suporte atualizado a formatos de tabela abertos
A versão 5.1 também atualiza as bibliotecas de formatos de tabela abertos (open table formats), que são fundamentais para arquiteturas de Data Lakehouse modernas:
Apache Hudi 1.0.2
Apache Iceberg 1.10.0
Delta Lake 3.3.2
Novidades do Apache Iceberg formato versão 3.0
O Glue 5.1 introduz suporte ao Apache Iceberg no formato versão 3.0, que adiciona capacidades relevantes para quem trabalha com grandes volumes de dados:
Valores padrão para colunas (default column values)
Vetores de exclusão para tabelas merge-on-read (deletion vectors)
Transformações com múltiplos argumentos (multi-argument transforms)
Rastreamento de linhagem de linhas (row lineage tracking)
Controle de acesso mais granular com o Lake Formation
Uma das mudanças mais significativas desta versão está na integração com o AWS Lake Formation. O controle de acesso refinado (fine-grained access control) do Lake Formation foi estendido para operações de escrita — tanto Linguagem de Manipulação de Dados (DML) quanto Linguagem de Definição de Dados (DDL) — para Spark DataFrames e Spark SQL.
Anteriormente, esse controle estava disponível apenas para operações de leitura. Com essa expansão, as equipes ganham um nível muito maior de governança sobre quem pode modificar dados e estruturas dentro do lake.
Além disso, o Glue 5.1 adiciona controle de acesso em nível de tabela completa (full-table access control) no Apache Spark para tabelas Apache Hudi e Delta Lake, ampliando ainda mais as opções de segurança disponíveis.
Como começar a usar
O AWS Glue 5.1 já está disponível em todas as regiões comerciais e GovCloud (US) da AWS. É possível começar a utilizá-lo por meio das APIs da AWS, AWS CLI, AWS SDK ou pelo AWS Glue Studio. Para mais detalhes, a AWS disponibiliza a página do produto e a documentação oficial.
