A AWS anunciou que o Amazon SageMaker HyperPod passou a suportar configuração baseada em AMI (Amazon Machine Image — Imagem de Máquina da Amazon) para clusters Slurm que utilizam provisionamento contínuo. Essa novidade estende uma capacidade já existente para um modo de operação importante: o provisionamento contínuo, que adiciona nós ao cluster conforme a capacidade vai ficando disponível.
O que muda na prática
Com esse suporte, clusters que usam provisionamento contínuo agora podem ser criados sem a necessidade de baixar, configurar ou fazer upload de scripts de configuração de ciclo de vida para o Amazon S3. Isso simplifica bastante o processo de setup.
A configuração baseada em AMI provisiona os nós com o software e as configurações necessárias para um ambiente pronto para produção, voltado à execução de workloads de treinamento de IA/ML. Isso inclui softwares como Docker, Enroot e Pyxis, além de configurações como contabilidade do Slurm, geração de chaves SSH e rotação de logs.
No modo de provisionamento contínuo, cada nó é configurado a partir da AMI à medida que é adicionado ao cluster — sem necessidade de gerenciar scripts de ciclo de vida. O resultado é que os nós ficam disponíveis para agendamento de jobs mais rapidamente.
Como habilitar a configuração baseada em AMI
Para ativar esse recurso, basta omitir o bloco LifeCycleConfig na configuração do grupo de instâncias ao criar clusters via API. Quem preferir usar o console do SageMaker AI, deve selecionar a opção “None” em Lifecycle scripts dentro de Custom setup.
Customizações adicionais ainda são possíveis
Para quem precisar de personalizações além da linha de base oferecida pela AMI, é possível fornecer um script de extensão. Isso é feito especificando o parâmetro OnInitComplete e o SourceS3Uri no bloco LifeCycleConfig via API — ou informando o URI do S3 no campo “Extension script file in S3” no console.
Vale destacar que os scripts de ciclo de vida personalizados continuam totalmente suportados para casos de uso que exigem controle total sobre o provisionamento.
Disponibilidade
A configuração de ciclo de vida de nós baseada em AMI para clusters Slurm com provisionamento contínuo está disponível em todas as regiões da AWS onde o SageMaker HyperPod está disponível.
Para começar, a AWS disponibiliza documentação tanto para quem prefere usar a linha de comando quanto o console:
Novidade: EC2 G7 chega à região US East (Norte da Virgínia)
A AWS anunciou que as instâncias Amazon Elastic Compute Cloud (Amazon EC2) G7 estão agora disponíveis na região US East (Norte da Virgínia). Movidas por GPUs NVIDIA RTX PRO 4500 Blackwell Server Edition, essas instâncias representam um salto significativo de desempenho em relação à geração anterior.
Ganhos de desempenho em relação às G6
Comparadas às instâncias G6, as G7 entregam:
Até 4,6x mais desempenho em inferência de IA
Até 2,1x mais desempenho gráfico
Performance superior também em cargas de trabalho de análise de dados acelerada por GPU
Para quais cargas de trabalho as G7 são indicadas?
As instâncias EC2 G7 foram projetadas para atender a uma ampla variedade de casos de uso exigentes. Entre os principais, a AWS destaca:
Inferência de modelos de IA: tradução de idiomas, análise de vídeo e imagem, e reconhecimento de fala
Cargas gráficas: criação e renderização de gráficos em tempo real com qualidade cinematográfica, e streaming de jogos
Transcodificação de vídeo e computação espacial
Análise de dados: sistemas de recomendação, inferência com Geração Aumentada por Recuperação (RAG) e pipelines de dados em tempo real
Especificações técnicas
Em termos de hardware, as instâncias G7 contam com uma configuração robusta:
Até 8 GPUs NVIDIA RTX PRO 4500 Blackwell Server Edition, com 32 GB de memória por GPU
Processadores Intel Xeon 6 customizados
Suporte a até 192 vCPUs (CPUs virtuais)
Até 700 Gbps de largura de banda de rede via Elastic Fabric Adapter (EFA)
Até 768 GiB de memória do sistema
Até 7,6 TB de armazenamento local NVMe SSD
Disponibilidade e formas de aquisição
As instâncias EC2 G7 já estão disponíveis em três regiões da AWS:
Diagnóstico inteligente para jobs Spark com linguagem natural
A AWS anunciou que o Amazon EMR no EKS passa a contar com suporte ao agente de diagnóstico do Apache Spark. Com essa novidade, engenheiros de dados conseguem investigar falhas em jobs do EMR on EKS usando linguagem natural — sem precisar navegar manualmente por logs distribuídos ou pela interface do Spark History Server.
O que o agente é capaz de fazer
O agente analisa três fontes principais de informação para identificar a raiz dos problemas:
Dados do Spark History Server
Logs distribuídos dos executores
Configurações do cluster
A partir dessa análise, ele consegue identificar problemas como erros de memória, distorção de dados (data skew), contenção de recursos e falhas de conectividade. Além de apontar a causa raiz, o agente também entrega recomendações de código PySpark para ajudar na correção.
Cobertura completa das opções de implantação do EMR
Com esse lançamento, o agente de diagnóstico do Spark passa a cobrir todas as modalidades de implantação do Amazon EMR:
EMR on EC2
EMR Serverless
EMR on EKS
Ou seja, independentemente de como o ambiente EMR está configurado, o agente já está disponível para uso.
Como acessar o agente
O acesso pode ser feito de duas formas:
Pelo console do EMR on EKS: em jobs com falha, basta acionar a opção “Troubleshoot with AI” diretamente na interface.
Via MCP (Protocolo de Contexto de Modelo): o agente também está disponível por meio do MCP, podendo ser integrado a qualquer agente de codificação compatível, incluindo Kiro, Claude Code e Cursor.
Segurança e auditoria
Todas as operações realizadas pelo agente são somente leitura, autenticadas via funções do IAM (Gerenciamento de Identidade e Acesso) e registradas no AWS CloudTrail. Isso garante rastreabilidade completa e alinhamento com práticas de segurança já estabelecidas nos ambientes AWS.
Disponibilidade
O agente de diagnóstico do Spark para o Amazon EMR on EKS está disponível em todas as regiões AWS onde o SageMaker Unified Studio estiver presente. Para começar, basta acessar o console do EMR on EKS ou configurar o servidor MCP no agente de codificação de sua preferência. Para orientações detalhadas, consulte a documentação do agente de diagnóstico do EMR.
Muitas equipes começam expondo uma API existente diretamente como uma ferramenta Protocolo de Contexto de Modelo (MCP) e esperam que o agente resolva o resto. Para casos simples, isso até funciona. Mas na maioria das situações, não funciona. O motivo é direto: você precisa projetar suas ferramentas pensando em como os Modelos de Linguagem de Grande Escala (LLMs) e sistemas agênticos realmente operam.
Sem esse cuidado, o resultado é chamadas de ferramenta falhando, parâmetros errados sendo passados e retentativas que consomem contexto e degradam a performance. A AWS publicou um post técnico detalhado sobre esse tema, explorando onde o design de ferramentas MCP costuma falhar e como corrigi-lo com abordagens práticas de engenharia de contexto.
Os dois vilões: inchaço e confusão
Dois problemas estão por trás da maioria das falhas em ferramentas MCP.
O primeiro é o inchaço. Definições de ferramentas são carregadas no contexto do LLM a cada chamada, mesmo que a ferramenta não seja usada. Quando múltiplos servidores MCP estão conectados, o contexto pode ser consumido significativamente antes que o usuário tenha feito sequer uma pergunta. À medida que o contexto enche, a capacidade do modelo de raciocinar pode se degradar, tornando a sessão menos produtiva.
O segundo é a confusão. Com o raciocínio degradado, o LLM passa a fazer escolhas piores: chama a ferramenta errada, usa parâmetros incorretos. As retentativas pioram ainda mais o inchaço. Similaridade semântica entre ferramentas, excesso de opções e nomes ambíguos também contribuem para a confusão.
A solução instintiva — enriquecer as descrições das ferramentas com definições mais claras, mapeamentos de linguagem natural e exemplos de uso — ajuda com a confusão, mas agrava o inchaço. É um ciclo vicioso. Resolver esse equilíbrio é, fundamentalmente, um problema de engenharia de contexto: moldar o que o LLM vê e quando ele vê, para que o modelo produza resultados melhores.
Seis abordagens na prática
Para tornar os conceitos concretos, a AWS construiu seis versões de um servidor MCP que expõe uma API simulada de busca de conteúdo educacional K-12 (ensino básico americano). Cada versão aplica uma abordagem diferente sobre o mesmo backend. Os exemplos podem ser executados localmente usando o Kiro CLI. O repositório de código de exemplo está disponível no GitHub.
V1: Passagem direta (anti-padrão de referência)
A primeira versão é o anti-padrão clássico: expõe a API do backend diretamente, com 14 parâmetros usando nomes internos como discipline, media_type e content_bucket, e apenas uma linha de documentação genérica. O LLM não tem orientação sobre quais valores são válidos. Pode tentar passar “quiz” para media_type quando o valor válido é “Assessment”, ou “math” quando o campo espera “Math”. Cada escolha errada dispara uma retentativa que consome mais contexto. O baixo custo inicial é enganoso, pois a confusão eleva o custo real por meio de tentativas repetidas.
V2: Descrições enriquecidas
Mesma estrutura da V1, sem refatoração do backend. A documentação agora lista valores válidos e mapeamentos de sinônimos para cada campo — por exemplo, media_type indica que “‘quiz’/’test’ → Assessment, ‘worksheet’ → Activity”. Três parâmetros raramente usados são removidos e as mensagens de erro passam a orientar a próxima tentativa em vez de retornar apenas resultado vazio.
A precisão melhora imediatamente porque o LLM vê os valores válidos. A definição da ferramenta fica visivelmente maior — esse é o trade-off do inchaço. Cada chamada paga esse custo, independentemente de a ferramenta ser usada. Porém, menos retentativas frequentemente tornam o custo total menor do que na V1. Segundo pesquisa da Anthropic, adotar uma abordagem sob demanda para saídas detalhadas pode reduzir os tokens de resposta em cerca de dois terços.
Esta versão renomeia parâmetros para refletir como o LLM pensa no domínio, não como o banco de dados nomeia suas colunas. discipline vira subject; content_bucket vira resource_class. Campos com valores finitos usam o tipo Literal, listando as opções diretamente no schema. Valores padrão sensatos cobrem o caso mais comum: structure='Asset', resource_class='Student Resource', language='en'. Uma ferramenta separada get_resource_detail cuida dos detalhes sob demanda.
Os enums previnem valores errados no nível do protocolo. Os padrões fazem com que o LLM só precise especificar o que varia. A definição fica menor do que na V2, porque nomes e enums fazem o trabalho que antes exigia descrições verbosas. O AWS Prescriptive Guidance para Estratégias MCP recomenda manter a contagem de parâmetros de ferramentas em torno de oito ou menos.
V4: Carregamento preguiçoso (lazy loading)
Em vez de embutir enums e descrições detalhadas na ferramenta de busca, esta abordagem move essas informações para uma ferramenta separada. A ferramenta de busca mantém apenas dicas curtas. Uma ferramenta get_taxonomy recebe uma lista de nomes de campos e retorna valores válidos e mapeamentos de linguagem natural apenas para os campos relevantes à consulta atual.
Para consultas ambíguas, o LLM chama get_taxonomy antes de buscar, para confirmar os valores válidos. Para consultas diretas onde as dicas são suficientes, pode pular essa chamada e buscar diretamente. O Amazon Bedrock AgentCore Gateway aplica esses conceitos em escala. A Anthropic reporta redução de até 85% nos tokens ao carregar definições de ferramentas apenas quando relevantes.
As Skills são outro exemplo de carregamento preguiçoso, mas implementado do lado do cliente. Esses arquivos locais contêm contexto útil para a ferramenta, mas são lidos no contexto apenas quando relevantes. A economia neste exemplo é modesta, mas em ambientes com muitas ferramentas conectadas e schemas complexos, o ganho se acumula rapidamente.
V5: Introspecção via LLM no servidor
Engenharia de contexto se torna desafiadora quando você não controla qual modelo vai interpretar suas instruções. Uma descrição ajustada para um modelo pode confundir outro. Testar todos os modelos possíveis é inviável.
Esta versão adiciona uma ferramenta introspect respaldada pelo Amazon Nova 2 Lite no Amazon Bedrock. A ferramenta introspect_query recebe a pergunta em linguagem natural do usuário e retorna filtros recomendados com justificativa para cada escolha. Por exemplo, interpreta “conteúdo alinhado ao TEKS para crianças trabalhando divisão no ensino médio” e retorna filtros recomendados: subject “Math”, grades 6-8, state_standard “TX-TEKS”, topic “dividing,division”.
Como a introspecção roda em um modelo de sua escolha, engenharia de prompt e testes se tornam confiáveis. A interpretação acontece no servidor, mantendo o contexto do cliente enxuto. O trade-off é custo: você paga pela chamada ao servidor, mas os resultados ficam consistentes independentemente de qual modelo o cliente usa.
V6: Agente como ferramenta
Quando você precisa de precisão e controle total, o próximo passo lógico é sustentar seu servidor MCP inteiro com um agente próprio. Esta versão expõe uma única ferramenta MCP respaldada por um agente Strands Agents com seu próprio system prompt e ferramentas internas. A interface externa é uma ferramenta com um único parâmetro: agentic_search_content(question: str).
O agente cuida internamente de busca de taxonomia, pesquisa, recuperação de detalhes e formatação de resposta — usando suas próprias ferramentas que o LLM cliente não vê. O comportamento é consistente independentemente de qual cliente se conecta, porque seu agente é dono do raciocínio. O histórico de conversa persiste entre chamadas, então perguntas de acompanhamento funcionam naturalmente. O trade-off é custo e latência em troca de controle direto sobre o comportamento.
Comparativo de trade-offs
Cada versão troca um custo por outro. O post original resume assim:
V2 – Descrições enriquecidas: precisão aumenta, mas a definição da ferramenta fica maior
V3 – Schema e padrões: precisão aumenta e a definição fica menor
V4 – Reestruturação com lazy loading: contexto base mais enxuto, mas com uma viagem extra de ida e volta
V5 – Introspecção no servidor: lida bem com ambiguidade, mas você paga pela inferência
V6 – Agente como ferramenta: controle direto total, maior custo de infraestrutura
Nenhuma versão vence em todas as dimensões. A escolha certa depende da quantidade de campos, da estabilidade do vocabulário, do orçamento de latência e de quanto você precisa de comportamento consistente entre diferentes clientes.
Para ir mais fundo
O protocolo MCP continua evoluindo. O Roadmap MCP 2026 aborda escalabilidade de transporte, comunicação entre agentes e funcionalidades para implantação empresarial. Para aprofundamento, a AWS indica os seguintes recursos:
Estratégias MCP na AWS — cobre a arquitetura mais ampla: quais padrões MCP usar, quando conectar múltiplos servidores e como estruturar seu sistema MCP além de uma única ferramenta.
AWS MCP Server — servidor MCP gerenciado que dá a agentes de codificação IA acesso a APIs da AWS, busca de documentação e skills de agente curadas por uma única conexão.
Strands Agents SDK — para aprofundar na abordagem agêntica da V6, com agentes multi-turno, orquestração de ferramentas e comportamento testável.
Amazon Bedrock AgentCore — implante seu servidor MCP sem gerenciar infraestrutura, com hospedagem em runtime, gateway para descoberta de ferramentas multi-servidor e memória persistente entre sessões.
Servidores MCP Open Source para AWS — 56 servidores MCP de código aberto cobrindo documentação, infraestrutura, IA/ML, dados, ferramentas de desenvolvedor e mais.
Amazon Bedrock AgentCore Samples — guias de início rápido, demos de funcionalidades, exemplos de casos de uso, blueprints e workshops para o AgentCore.
Servidores MCP Serverless de Exemplo — implementações de referência para hospedar servidores MCP no AWS Lambda e no Amazon Elastic Container Service (Amazon ECS).
Inferência empresarial no SageMaker HyperPod: o que mudou
À medida que as organizações escalam suas cargas de trabalho de IA generativa, cresce também a demanda por infraestrutura de inferência mais rápida, observável e flexível. A AWS respondeu a esse desafio com um conjunto de novas capacidades no Amazon SageMaker HyperPod, voltadas para simplificar como equipes implantam e operam modelos de grande porte em produção.
As novidades cobrem cinco frentes: captura de dados em múltiplos níveis da cadeia de inferência, deploy direto a partir do Hugging Face Hub, carregamento de pesos via armazenamento NVMe local, gerenciamento automatizado de registros DNS com o Amazon Route 53 e controle granular de permissões por pod via contas de serviço personalizadas.
Captura de dados de inferência em múltiplas camadas
O recurso de captura de dados do HyperPod permite registrar as requisições e respostas de inferência para fins de monitoramento, depuração e melhoria de modelos. O fluxo de uma requisição passa pelo endpoint do SageMaker AI, depois pelo Balanceador de Carga de Aplicação (ALB) e, por fim, chega ao pod do modelo. Cada camada pode ser configurada de forma independente, oferecendo flexibilidade para escolher o nível de visibilidade adequado para cada caso de uso.
Pré-requisitos
Para habilitar a captura de dados, é necessário ter um bucket do Amazon S3 (com URI no formato s3://amzn-s3-demo-bucket ou s3://amzn-s3-demo-bucket/prefix) e as permissões de Gerenciamento de Identidade e Acesso (IAM) corretas para que o operador possa gravar nele. Caso nenhum URI seja informado, o sistema utiliza o bucket do certificado TLS como destino padrão. A AWS também recomenda o uso de uma chave do Serviço de Gerenciamento de Chaves (AWS KMS) para criptografar os dados capturados.
As três camadas de captura
A captura de dados suporta três camadas, cada uma registrando em um ponto diferente do fluxo:
Camada 1 – Endpoint do SageMaker AI ({s3Uri}/{hash}/sme/): captura os payloads completos de entrada e saída na fronteira da API do SageMaker AI Runtime. Indicada para compatibilidade com o SageMaker AI Model Monitor.
Camada 2 – Balanceador de Carga de Aplicação (ALB) ({s3Uri}/{hash}/alb/): ativa os logs de acesso do ALB, que registram metadados como IPs de clientes, caminhos de requisição e latências.
Camada 3 – Pod do modelo ({s3Uri}/{hash}/pod/): captura os payloads completos diretamente no contêiner de inferência, com amostragem, buffer e limites de tamanho configuráveis. Funciona sem registro de endpoint do SageMaker AI — ideal para quem precisa da visibilidade mais próxima possível do modelo.
Configurando a captura de dados
A captura é habilitada adicionando uma seção dataCapture ao recurso personalizado de definição (CRD) InferenceEndpointConfig ou JumpStartModel. O exemplo abaixo mostra a estrutura completa com as três camadas ativas:
O HyperPod agora permite implantar modelos diretamente do Hugging Face Hub, sem a necessidade de pré-carregar os pesos no Amazon S3 ou no Amazon FSx. Essa integração suporta modelos restritos (gated) via tokenSecretRef, fixação de revisões via commitSHA e isolamento de tokens. É compatível com os runtimes vLLM, TGI e SGLang. Consulte como fazer deploy de modelos a partir do S3, FSx ou Hugging Face Hub com kubectl para mais detalhes.
Passos para implantar um modelo do Hugging Face
Primeiro, crie um Kubernetes Secret com o token da API do Hugging Face. Esse token é obrigatório para modelos restritos e recomendado para todos os downloads. Você pode gerar um token em huggingface.co/settings/tokens.
O SageMaker HyperPod agora se integra ao Amazon Route 53 para criar e gerenciar automaticamente registros DNS para os endpoints de inferência. Basta especificar um ID de zona hospedada no CRD e o operador cuida da criação, atualização e remoção dos registros para o domínio personalizado.
Pré-requisitos
Um certificado do Gerenciador de Certificados da AWS (ACM) no estado Issued cobrindo o domínio desejado.
Uma zona hospedada no Route 53 para esse domínio.
As permissões IAM corretas adicionadas ao papel de execução do Operador de Inferência.
O domainName deve corresponder a um domínio coberto pelo certificado ACM. Para certificados wildcard (por exemplo, *.example.com), especifique o subdomínio exato (por exemplo, api.example.com).
O SageMaker HyperPod agora suporta o carregamento de pesos de modelos diretamente do armazenamento NVMe local do nó, em vez de transferi-los pela rede a partir do S3 ou do FSx. Ao eliminar o salto de rede durante a inicialização do pod, essa abordagem reduz significativamente o tempo de cold-start. É especialmente útil em eventos de autoescalonamento, cargas de trabalho scale-from-zero e failovers sensíveis à latência. O armazenamento NVMe local está disponível tipicamente nas famílias de instâncias P, G e Trn.
Contas de serviço personalizadas com permissões por pod
Por padrão, os pods de inferência usam a ServiceAccount padrão do namespace. Para cargas de trabalho que precisam de credenciais AWS — como o download de pesos do S3 em um initContainer de fallback — é possível atribuir uma ServiceAccount personalizada com suporte a IRSA (Funções IAM para Contas de Serviço).
Habilitando o suporte a contas de serviço personalizadas
Esse recurso permanece desativado por padrão. Um administrador do cluster deve habilitá-lo:
Se o operador estiver implantado como um complemento (add-on) do Amazon EKS, atualize a configuração do add-on para incluir enableCustomServiceAccounts: true nas configurações avançadas.
Configurando uma conta de serviço personalizada
Crie uma ServiceAccount do Kubernetes anotada com o ARN do papel IRSA:
kubectl create sa my-inference-sa -n my-namespace
kubectl annotate sa my-inference-sa -n my-namespace \
eks.amazonaws.com/role-arn=arn:aws:iam::<ACCOUNT_ID>:role/<ROLE_NAME>
Adicione o rótulo user-assignable à ServiceAccount. Apenas contas com esse rótulo podem ser referenciadas por endpoints de inferência — esse é um controle de segurança para evitar escalada não autorizada de privilégios:
A AWS recomenda criar uma ServiceAccount dedicada por carga de trabalho de inferência, sem reutilização entre workloads não relacionadas. Os papéis IAM associados via IRSA devem ser escopados ao bucket S3 e prefixo específicos que contêm os pesos do modelo — evite políticas amplas como AmazonS3FullAccess.
Como começar
Para aproveitar todas essas capacidades, a AWS orienta atualizar o Operador de Inferência para a versão v3.2 e experimentar a adição de uma seção dataCapture ou dnsConfig a um deploy existente. As referências completas de configuração estão disponíveis na documentação oficial de cada funcionalidade.
Agentes de IA agora se conectam ao AWS MCP Server via OAuth
A AWS anunciou suporte a OAuth no AWS MCP Server, permitindo que agentes de inteligência artificial se conectem diretamente ao serviço usando o AWS Sign-In. A novidade elimina a necessidade de softwares adicionais de autenticação, já que a integração segue o padrão de mercado OAuth — amplamente adotado na indústria.
Como funciona na prática
Com essa atualização, as identidades AWS existentes continuam sendo utilizadas normalmente. Isso significa que métodos de login, permissões do Gerenciamento de Identidade e Acesso (IAM) e controles de governança já configurados seguem valendo — sem necessidade de reconfiguração.
A autorização pode acontecer de duas formas:
De forma interativa: o desenvolvedor autoriza o agente diretamente pelo navegador.
De forma programática: usando autorização não-interativa (headless), ideal para pipelines automatizados e ambientes sem interface gráfica.
Governança e controle para administradores
Para quem cuida da segurança e compliance do ambiente, a AWS disponibilizou um conjunto de ferramentas para governar o acesso OAuth com os mecanismos já conhecidos do IAM. Entre as novidades estão:
Chaves de condição globais para políticas IAM
APIs de introspecção e revogação de tokens
Registro dinâmico de clientes (dynamic client registration)
Eventos de auditoria no CloudTrail
Ou seja, os times de segurança ganham visibilidade e controle sobre o acesso dos agentes sem precisar adotar ferramentas fora do ecossistema AWS.
Saiba mais
Para aprofundar o tema, a AWS disponibiliza três recursos de documentação:
A AWS anunciou a expansão do AWS Client VPN para quatro novas regiões globais. A partir de agora, o serviço está disponível em:
Canadá Oeste (Calgary)
México (Central)
Ásia-Pacífico (Nova Zelândia)
Ásia-Pacífico (Taipei)
Com essa expansão, organizações que operam nessas localidades passam a contar com uma opção de conectividade segura gerenciada diretamente pela AWS, sem precisar depender de soluções de terceiros ou infraestrutura própria de VPN.
O que é o AWS Client VPN?
O AWS Client VPN é um serviço totalmente gerenciado que permite conectar com segurança uma força de trabalho remota a recursos hospedados na AWS ou em redes on-premises — ou seja, em ambientes físicos da própria organização. Ele é especialmente útil para empresas com equipes distribuídas que precisam de acesso seguro e confiável aos sistemas corporativos, independentemente de onde os colaboradores estejam.
Uma das principais vantagens do serviço é eliminar a necessidade de appliances de hardware dedicados à VPN e toda a complexidade operacional que eles trazem. Em vez disso, a AWS cuida da infraestrutura subjacente, e as organizações pagam apenas pelo que utilizam, seguindo o modelo pay-as-you-go — pague conforme o uso.
Gerenciamento centralizado
Outro ponto relevante destacado pela AWS é a facilidade de administração: todas as conexões VPN podem ser gerenciadas e monitoradas por meio de um único console. Isso reduz a fragmentação operacional e facilita a visibilidade sobre quem está conectado, quando e de onde.
Saiba mais
Para quem quiser se aprofundar no serviço, a AWS disponibiliza os seguintes recursos oficiais:
A AWS anunciou suporte a OAuth no AWS MCP Server, abrindo um caminho mais simples e seguro para conectar agentes de Inteligência Artificial às ferramentas e serviços da plataforma. A novidade permite que desenvolvedores autorizem o acesso de agentes usando os mesmos métodos de autenticação já conhecidos — seja pelo Console AWS ou pela Interface de Linha de Comando AWS (AWS CLI) — por meio de um fluxo baseado em navegador e amparado pelo padrão OAuth.
Nova API para conectividade OAuth sem interface (headless)
Tudo isso é compatível com a configuração IAM existente — permissões, roles, acesso federado — sem exigir mudanças estruturais.
Como conectar um agente ao AWS MCP Server
O passo a passo descrito pela AWS utiliza o Claude Code como exemplo, mas o mesmo processo se aplica a qualquer agente compatível com o Protocolo de Contexto de Modelo (MCP), como Kiro, Codex e Gemini. A documentação completa de configuração está disponível em Configurando o AWS MCP Server.
Permissões necessárias
Para conectar um agente ao AWS MCP Server, é preciso ter as permissões IAM necessárias para o fluxo OAuth. O comando abaixo adiciona uma política gerenciada com as permissões exigidas à role IAM desejada (substitua <MyRole> pelo nome da sua role):
aws iam attach-role-policy \
--role-name <MyRole> \
--policy-arn arn:aws:iam::aws:policy/AWSMCPSignInOAuthAccessPolicy
Passo 1: Configurar o AWS MCP Server no agente
Execute o comando abaixo para adicionar o endpoint do AWS MCP Server à configuração do agente:
claude mcp add --transport http aws-mcp https://aws-mcp.us-east-1.api.aws/mcp
Passo 2: Revisar a solicitação de autorização
Na primeira vez que o agente precisar acessar o AWS MCP Server, um navegador será aberto e o usuário será redirecionado para a página de autenticação do AWS Sign-In. Basta autenticar normalmente — como no console ou na CLI —, revisar a solicitação de autorização e aprovar o acesso. Uma mensagem de confirmação será exibida ao final.
Vale destacar que, se já houver uma sessão ativa no AWS Sign-In (por exemplo, porque o usuário se autenticou no console mais cedo), ela pode ser reutilizada sem necessidade de novo login.
Passo 3: Começar a usar as ferramentas AWS
Após a conexão, é possível verificar se o agente está devidamente conectado ao AWS MCP Server executando o comando /mcp dentro do Claude Code. O comando lista os servidores MCP configurados e confirma o status da conexão.
Com a conexão estabelecida, o agente já pode invocar as ferramentas disponíveis no servidor. Por exemplo, ao enviar o prompt:
Deploy a sample serverless web application into my development AWS account
O Claude Code utiliza o AWS MCP Server para identificar a conta AWS ativa, confirmar a conta de destino e descrever o que será implantado antes de acionar qualquer serviço.
Modelos de autorização disponíveis
O AWS Sign-In suporta dois modelos de autorização para conectar agentes ao AWS MCP Server:
Autorização interativa: voltada para agentes de IA usados por desenvolvedores, com autenticação via navegador.
Autorização não-interativa (headless): para aplicações e agentes que já possuem credenciais AWS e não têm acesso a um navegador.
Um ponto importante: autorizar um agente permite que ele acesse o AWS MCP Server em nome do usuário, mas não concede permissões AWS adicionais. Cada requisição ainda é avaliada pelas políticas IAM existentes, SCPs, RCPs, limites de permissão e demais controles organizacionais.
Acesso interativo
No fluxo interativo, o agente primeiro descobre o servidor OAuth do AWS Sign-In e se registra como cliente OAuth via Registro Dinâmico de Cliente (DCR). Em seguida, o usuário é redirecionado para autenticação e autorização. Após a aprovação, o AWS Sign-In emite tokens de acesso de curta duração e tokens de atualização. O gerenciamento automático desses tokens permite que o agente continue operando sem que o usuário precise se autenticar repetidamente.
Esse modelo suporta três métodos de autenticação: credenciais IAM nativas para desenvolvedores individuais, acesso gerenciado via AWS IAM Identity Center para empresas, e acesso federado por provedores terceiros como Okta e Ping Identity para organizações maiores.
Metadados OAuth e DCR
Antes de solicitar autorização, o agente precisa descobrir os endpoints OAuth do AWS Sign-In e se registrar como cliente. O AWS Sign-In suporta descoberta de metadados OAuth e DCR, permitindo que agentes compatíveis se configurem automaticamente — sem que desenvolvedores precisem provisionar manualmente IDs e segredos de cliente OAuth.
Quando um agente se conecta ao AWS MCP Server pela primeira vez, ele recupera os metadados do recurso protegido (RFC 9728) e os metadados OAuth do AWS Sign-In (RFC 8414). Em seguida, usa a RFC 7591 para se registrar, obter um client ID e iniciar o fluxo padrão de código de autorização OAuth. A lista de agentes e ambientes suportados está disponível em URIs de redirecionamento suportados para o AWS MCP Server.
Acesso não-interativo (headless)
Para agentes e aplicações que operam sem navegador ou interação humana, o AWS Sign-In oferece o fluxo de credenciais de cliente OAuth. Aplicações que já possuem credenciais AWS podem obter tokens de acesso OAuth diretamente. Veja um exemplo de como obter um token de acesso:
Nesse modelo, a autenticação no endpoint de token do AWS Sign-In é feita com credenciais SigV4, e o retorno é um token OAuth de curta duração. Pode ser necessário atualizar o SDK e a AWS CLI — consulte o guia da CLI para mais detalhes.
Gerenciando o acesso OAuth
O AWS Sign-In estende o modelo de autorização IAM com controles específicos para OAuth. Administradores podem combinar políticas IAM convencionais com novas condições voltadas para OAuth.
Concedendo permissões OAuth
O acesso OAuth é controlado via políticas IAM e requer duas ações específicas:
signin:AuthorizeOAuth2Access — permite autenticação interativa pelo fluxo de código de autorização OAuth
signin:CreateOAuth2Token — permite que aplicações obtenham tokens OAuth trocando códigos de autorização, tokens de atualização ou usando credenciais de cliente
Quando uma aplicação solicita acesso, o AWS Sign-In cria uma concessão de autorização OAuth entre o agente e o AWS MCP Server. Essa concessão é representada como um recurso IAM:
O AWS Sign-In introduz chaves de condição específicas para OAuth, permitindo controle granular sobre como os agentes obtêm autorização. A seguir, dois exemplos de padrões comuns de governança.
Restringir OAuth ao localhost: a política abaixo permite apenas os fluxos de código de autorização e token de atualização para o AWS MCP Server, e restringe a entrega de tokens ao localhost:
Negar acesso para uma sessão OAuth específica: use a chave de condição global aws:SignInSessionArn para bloquear uma sessão suspeita ou comprometida sem afetar outras sessões ativas:
O AWS Sign-In oferece APIs de introspecção e revogação de tokens, permitindo que administradores construam ferramentas personalizadas para validação e revogação. O acesso a essas APIs é controlado pelas permissões signin:IntrospectOAuth2Token e signin:RevokeOAuth2Token.
A API de introspecção verifica se um token está ativo e retorna informações sobre a autorização associada. Já a API de revogação permite invalidar tokens de atualização individuais sem afetar outras sessões ativas — útil quando é preciso revogar o acesso de uma autorização específica sem impactar o restante da organização.
Monitorando a atividade OAuth com CloudTrail
Todas as atividades relacionadas ao OAuth são registradas no AWS CloudTrail, incluindo solicitações de autorização, emissão de tokens, revogações e eventos de introspecção. Os logs capturam detalhes como o cliente OAuth, o AWS MCP Server de destino, a URI de redirecionamento, o fluxo de autorização e a sessão de autenticação associada.
Além disso, chamadas de API feitas com tokens de acesso OAuth incluem o contexto aws:SignInSessionArn, permitindo correlacionar a atividade de API com a sessão OAuth de origem. Isso facilita o monitoramento, a investigação de comportamentos anômalos e a integração com fluxos de auditoria, conformidade e resposta a incidentes.
Abaixo, um exemplo de evento AuthorizeOAuth2Access no CloudTrail:
O suporte a OAuth no AWS Sign-In representa um avanço importante para quem trabalha com agentes de IA integrados à AWS. A novidade simplifica a conexão de aplicações e agentes à plataforma, mantendo toda a estrutura de IAM, governança e auditoria já existente. Para aprofundar o conhecimento, a AWS disponibiliza a documentação de Autenticação com OAuth 2.0 no Guia do Usuário do AWS Sign-In e o guia de Configuração do AWS MCP Server no Guia do Usuário do Agent Toolkit para AWS.
A AWS anunciou que o Amazon SageMaker Unified Studio agora suporta tipos de ativos personalizados para domínios baseados em Gerenciamento de Identidade e Acesso (IAM). Essa novidade amplia consideravelmente o que pode ser catalogado dentro da plataforma, indo muito além dos formatos nativos já suportados.
O que são tipos de ativos personalizados
Até então, o catálogo do SageMaker Unified Studio era limitado a formatos de ativos já reconhecidos pela plataforma. Com a nova funcionalidade, administradores de domínio podem catalogar qualquer formato de ativo — independentemente de sua origem ou estrutura. Os exemplos citados pela AWS incluem:
Arquivos de imagens médicas armazenados no Amazon S3
Dashboards de receita criados no PowerBI
Relatórios de pesquisa em PDF gerados por plataformas de terceiros
A ideia central é que todos esses ativos passem a existir dentro do mesmo catálogo governado, eliminando a necessidade de ferramentas ou processos separados para cada tipo de conteúdo.
Como funciona na prática
O fluxo de criação é direto. Um administrador começa definindo o tipo de ativo com um nome, uma descrição e, opcionalmente, formulários de metadados — que determinam quais campos cada ativo daquele tipo deve preencher.
Com o tipo criado, os ativos individuais podem ser instanciados a partir dele e enriquecidos com:
Termos de glossário, para contextualização semântica
Documentação em formato README, para adicionar contexto de negócio útil tanto para humanos quanto para agentes de IA
Após esse enriquecimento, o ativo é publicado e fica disponível para descoberta por qualquer pessoa no domínio. A busca pode ser feita por nome, tipo ou termo de glossário, e a solicitação de acesso segue o mesmo fluxo de assinatura governada já utilizado para todos os outros ativos do catálogo.
Disponibilidade
Os tipos de ativos personalizados para domínios baseados em IAM já estão disponíveis em todas as regiões da AWS onde o Amazon SageMaker Unified Studio opera. Para explorar os detalhes técnicos e começar a usar o recurso, a AWS disponibiliza o guia do usuário do SageMaker Unified Studio.
A AWS anunciou que o Amazon SageMaker HyperPod passou a oferecer suporte a verificações profundas de saúde (deep health checks) em clusters orquestrados pelo Slurm quando criados com provisionamento contínuo. Com isso, equipes de machine learning podem verificar proativamente a saúde dos aceleradores GPU em instâncias em execução a qualquer momento — sem precisar esperar uma falha acontecer para descobrir que um nó está comprometido.
Contexto: o que é provisionamento contínuo no HyperPod
O provisionamento contínuo permite iniciar treinamentos rapidamente e escalar grupos de instâncias de forma assíncrona, sem o modelo “tudo ou nada” — ou seja, a ausência de uma instância não bloqueia o início do job. À medida que a capacidade vai ficando disponível, novos nós são adicionados ao cluster Slurm de forma independente.
Esse modelo traz agilidade, mas também um desafio: como garantir que cada nó adicionado está saudável antes de receber cargas de trabalho?
O problema que a novidade resolve
Mesmo um único nó com hardware defeituoso pode desperdiçar horas de tempo computacional e atrasar workloads críticos. Antes dessa atualização, não havia uma forma integrada de validar a saúde do hardware em nós adicionados de forma assíncrona sem interromper o que já estava rodando.
Como funcionam as verificações profundas de saúde
Com o recurso agora disponível, é possível direcionar as verificações para grupos de instâncias inteiros ou para instâncias específicas, executando testes abrangentes de estresse de hardware e testes de conectividade antes de comprometer recursos computacionais a um job.
O fluxo funciona da seguinte forma:
À medida que novos nós são adicionados ao cluster pelo provisionamento contínuo, as verificações profundas de saúde podem ser executadas em cada nó assim que ele fica online.
O hardware é validado antes de qualquer job ser agendado naquele nó.
Workloads já em execução nos nós saudáveis não são interrompidos durante esse processo.
Instâncias em processo de verificação são automaticamente isoladas do agendamento de jobs e retornam ao serviço assim que passam nos testes.
Visibilidade e recuperação automática
O progresso e os resultados das verificações ficam visíveis tanto no nível do grupo de instâncias quanto no nível de instância individual — acessíveis pelo console do SageMaker e pelas APIs. Isso oferece visibilidade completa sobre saúde da GPU, conectividade de rede e desempenho de comunicação entre múltiplos nós.
Quando combinado com o recurso de recuperação automática de nós do HyperPod, instâncias que falham nas verificações são automaticamente reiniciadas ou substituídas, mantendo a saúde geral do cluster sem intervenção manual.
Disponibilidade
O recurso está disponível em todas as regiões onde o Amazon SageMaker HyperPod já opera. Para saber mais sobre as verificações profundas de saúde sob demanda e o provisionamento contínuo, consulte o Guia do Usuário do Amazon SageMaker HyperPod.
