A AWS anunciou melhorias no suporte ao Ray dentro do Amazon SageMaker HyperPod. Para quem não conhece, o Ray é um framework open-source bastante popular para escalar cargas de trabalho de Inteligência Artificial (IA) em uma camada de computação unificada — cobrindo desde processamento de dados e treinamento distribuído até aprendizado por reforço e serviço de modelos.
O problema que a AWS endereça com essa atualização é real: rodar Ray em Kubernetes em escala de produção costuma ser trabalhoso. Travamentos de jobs, baixa utilização de GPU por conta de alocações estáticas por equipe, configuração de observabilidade em múltiplas etapas e a ausência de um ambiente de desenvolvimento interativo são dores conhecidas de quem opera esse tipo de workload. Cada mudança de código exigia um novo envio de job e familiaridade com kubectl.
As três frentes de melhoria
Desenvolvimento mais ágil
Com a atualização, cientistas de dados podem criar, editar, monitorar e excluir clusters Ray diretamente por uma interface web no Amazon SageMaker Studio. É possível conectar o JupyterLab, o Code Editor ou até uma IDE local a um cluster Ray em execução e iterar de forma interativa com a escala do cluster disponível. O comportamento de um cluster Ray com múltiplos nós passa a se parecer com um ambiente de desenvolvimento local — cada mudança pode ser testada imediatamente, sem esperar um novo job entrar na fila.
Observabilidade integrada
O HyperPod agora provisiona dashboards no Grafana com métricas armazenadas no Amazon Managed Service for Prometheus, além de oferecer acesso com um clique ao Ray Dashboard por meio de um link seguro no navegador. Isso garante visibilidade sobre os workloads desde a primeira execução, sem configurações manuais complexas.
Treinamento resiliente em escala
Para treinar modelos em larga escala, o HyperPod traz recuperação automática de nós e detecção de jobs travados, lidando com falhas de GPU, travamentos, picos de perda e degradação de throughput. O checkpointing em camadas restaura o estado a partir da memória do cluster para maximizar o goodput, e a governança de tarefas melhora a utilização de computação por meio de cotas, prioridades e preempção. Juntos, esses mecanismos mantêm as execuções longas de treinamento progredindo mesmo diante de falhas.
Inferência acelerada com Ray Serve
Para inferência usando o Ray Serve, um cache de chave-valor (KV cache) em camadas reutiliza prefixos em cache para reduzir o tempo até o primeiro token. Também é possível fazer o deploy de modelos do Amazon SageMaker JumpStart diretamente. O código Ray open-source roda sem alterações, e as equipes podem adotar a experiência integrada no SageMaker Studio ou incorporar capacidades individuais em sua própria plataforma de Machine Learning (ML).
Disponibilidade
O suporte ao Ray está disponível para clusters HyperPod orquestrados pelo Amazon Elastic Kubernetes Service (EKS), nas regiões AWS onde o SageMaker HyperPod é suportado. Para se aprofundar, a AWS disponibiliza a documentação do SageMaker HyperPod e um demo interativo para explorar as novidades na prática.
Novas versões do PostgreSQL disponíveis no Amazon Aurora
A AWS anunciou que o Amazon Aurora PostgreSQL-Compatible Edition passa a suportar as versões 18.4, 17.10, 16.14, 15.18 e 14.23 do PostgreSQL. As atualizações trazem correções de bugs da comunidade PostgreSQL, além de melhorias específicas da plataforma Aurora.
Por que atualizar?
A AWS recomenda que os usuários migrem para as versões minor mais recentes assim que possível. O principal motivo é a correção de Vulnerabilidades e Exposições Comuns (CVEs) conhecidas — falhas de segurança documentadas publicamente que podem representar risco para os ambientes de banco de dados. Além da segurança, as novas versões também entregam melhorias de estabilidade e desempenho. Os detalhes completos de cada atualização estão disponíveis nas notas de lançamento.
Como realizar o upgrade
A atualização pode ser feita de forma simples, sem necessidade de intervenção manual. O Aurora permite que os upgrades de versões minor sejam executados automaticamente durante as janelas de manutenção programadas. Para isso, basta habilitar a opção de upgrades automáticos de versão minor no cluster.
Para equipes que gerenciam múltiplos bancos de dados em escala, a AWS disponibiliza um recurso adicional bastante útil: a Política de Rollout de Upgrade do AWS Organizations. Com ela, é possível orquestrar os upgrades em fases — começando pelos ambientes de menor criticidade para validar o processo antes de atualizar os ambientes mais críticos do negócio.
O Amazon Aurora é o serviço de banco de dados relacional gerenciado da AWS, projetado para oferecer alta performance e disponibilidade em escala global, com compatibilidade total com o PostgreSQL. Entre seus principais recursos estão:
Computação serverless com escala até zero, reduzindo custos quando o banco não está em uso
Aurora Global Database, para resiliência multi-região
Aurora I/O-Optimized, com melhor relação custo-benefício para cargas de trabalho intensivas em operações de entrada e saída (I/O)
Segurança integrada e backups contínuos
Para quem ainda não utiliza o serviço e quer dar os primeiros passos, a AWS disponibiliza uma página de introdução ao Aurora com os recursos necessários para começar.
A AWS anunciou uma atualização importante no Amazon Elastic Kubernetes Service (Amazon EKS): agora é possível associar múltiplos provedores de identidade externos baseados em OpenID Connect (OIDC) a um único cluster. Com essa novidade, cada cluster pode ter até 10 provedores OIDC configurados simultaneamente, ampliando consideravelmente a flexibilidade na autenticação de usuários e cargas de trabalho.
Por que isso importa na prática
Muitas organizações trabalham com diferentes grupos de usuários — funcionários internos, prestadores de serviço, sistemas de Integração Contínua e Entrega Contínua (CI/CD), entre outros. Cada um desses grupos costuma ter seu próprio provedor de identidade, e até então o EKS exigia que tudo fosse consolidado em um único provedor ou que se usasse um broker de identidade intermediário para contornar essa limitação.
Com a atualização, cada grupo pode se autenticar diretamente pelo seu próprio provedor, sem a necessidade de centralização forçada ou de soluções de contorno. Cada provedor é configurado e gerenciado de forma independente, com seu próprio mapeamento de identidade.
Compatibilidade com a autenticação IAM existente
Um ponto relevante destacado pela AWS é que a autenticação via IAM (Gerenciamento de Identidade e Acesso) continua funcionando normalmente em paralelo com todos os provedores OIDC configurados. Ou seja, não é necessário abrir mão da configuração atual para aproveitar a nova capacidade.
Como configurar
A forma de adicionar provedores segue o mesmo processo já conhecido: via AWS Management Console ou por meio da API AssociateIdentityProviderConfig, acessível pelo AWS CLI e pelos AWS SDKs. Não há mudança no fluxo de configuração — apenas a possibilidade de repetir o processo para cada novo provedor que precise ser associado ao cluster.
Disponibilidade e custo
A funcionalidade está disponível em todas as regiões da AWS onde o Amazon EKS é oferecido e não tem custo adicional.
Controle total sobre a criptografia no SageMaker MLflow
A AWS anunciou uma melhoria importante para equipes que utilizam o SageMaker MLflow: agora é possível criptografar os dados da plataforma usando chaves gerenciadas pelo cliente (CMK — Customer-Managed Keys), integradas ao Serviço de Gerenciamento de Chaves (KMS — Key Management Service) da AWS.
Essa novidade é especialmente relevante para organizações que operam em setores regulados ou que possuem políticas internas rígidas de segurança e conformidade. Com as CMKs, as equipes deixam de depender exclusivamente das chaves gerenciadas pela própria AWS e passam a ter autonomia sobre o ciclo de vida das suas chaves de criptografia.
O que muda na prática
Com esse novo suporte, as organizações passam a contar com dois benefícios centrais:
Controle de segurança aprimorado: é possível criptografar os dados do MLflow com chaves KMS próprias, sem depender das chaves padrão gerenciadas pela AWS.
Auditoria abrangente: toda a movimentação de acesso aos dados pode ser rastreada por meio da integração com o AWS CloudTrail, facilitando auditorias de segurança e o atendimento a requisitos de conformidade.
Requisitos e disponibilidade
Há alguns pontos de atenção importantes para quem for adotar esse recurso:
As chaves gerenciadas pelo cliente precisam ser criadas na mesma conta e região AWS onde o MLflow App está configurado.
Apenas chaves KMS simétricas são suportadas — chaves assimétricas não são compatíveis com esse recurso.
A adoção de chaves gerenciadas pelo cliente é um requisito comum em ambientes que precisam atender a normas como LGPD, ISO 27001, SOC 2, entre outras. Ter esse nível de controle diretamente no SageMaker MLflow — ferramenta amplamente usada para rastreamento de experimentos e gestão do ciclo de vida de modelos de Machine Learning (ML) — representa um avanço relevante para equipes de dados que operam em contextos com exigências regulatórias elevadas.
A semana foi dominada por governança e operacionalização de agentes de IA em produção. A AWS lançou o Bedrock AgentCore Gateway com modelo de maturidade em 4 escopos para controlar acesso de agentes a dados sensíveis, complementado por padrões de autorização por usuário e integração assíncrona com serverless. No lado de custos, Glue 6.0 entrega 30% de redução e compressão em pipelines RAG corta até 33% do TCO. Segurança também ganhou força com Security Hub cobrindo cadeia de suprimentos, rotação automática de CA no EKS e patch crítico do Corretto exigindo ação imediata.
O que muda na prática
Agentes de IA em produção agora têm um modelo formal de governança de acesso na AWS: credenciais centralizadas, auditoria nativa e escopos definidos pelo AgentCore Gateway — sem mais gambiarras de IAM espalhadas pelo código.
Pipelines de dados ficaram mais baratos sem mudança de arquitetura: Glue 6.0 reduz custo em 30% e a técnica de compressão por consulta no Bedrock corta até 8,6x os tokens enviados ao modelo, impactando diretamente o orçamento de times de dados e IA.
Segurança de supply chain e certificados entrou no radar operacional: Security Hub agora bloqueia dependências open source maliciosas no CI/CD, e o EKS faz rotação automática de CA com rollback — dois vetores que já causaram incidentes graves em produção.
Ações da semana
Se você roda Java na AWS: aplique o patch crítico do Amazon Corretto de agosto/2026 em todos os ambientes com versões LTS — é ação imediata, sem janela de espera.
Se você opera ou está planejando agentes de IA: revise o modelo de escopos do AgentCore Gateway e mapeie quais agentes acessam dados sensíveis sem auditoria hoje — use o artigo do rank 1 como checklist de maturidade.
Define um modelo de maturidade em 4 escopos para controlar quais agentes acessam dados sensíveis, resolvendo o problema crítico de credenciais espalhadas e falta de auditoria em produção.
Para quem: Arquitetos de segurança e engenheiros que estão levando agentes de IA para ambientes corporativos.
Supply Chain Security é a categoria mais solicitada e cobre duas frentes críticas — verificação de origem de pacotes open source e bloqueio de dependências maliciosas — diretamente no console do Security Hub.
Para quem: Times de segurança e DevSecOps que gerenciam dependências open source em pipelines de CI/CD.
Redução de custo imediata combinada com suporte ao Iceberg v3 e streaming sub-segundo impacta diretamente decisões de arquitetura de dados e orçamento de pipelines existentes.
Para quem: Engenheiros de dados e arquitetos que operam pipelines ETL/ELT com AWS Glue em produção.
Garante que cada usuário acesse apenas seus dados dentro de agentes de IA, seguindo a prática AGENTSEC03 do Well-Architected — essencial para compliance e auditoria em sistemas multi-usuário.
Para quem: Engenheiros de segurança e desenvolvedores que constroem agentes de IA com acesso a dados corporativos sensíveis.
Técnica comprovada que reduz em até 33% os custos e 8,6x os tokens enviados ao modelo principal, com impacto direto no TCO de aplicações RAG em produção.
Para quem: Engenheiros de IA e arquitetos que operam pipelines RAG de alto volume no Amazon Bedrock.
Elimina o risco de expiração silenciosa de certificados em clusters Kubernetes, com notificações antecipadas e rollback — problema que já causou indisponibilidades em produção em larga escala.
Para quem: Engenheiros de plataforma e SREs que operam clusters EKS em ambientes críticos.
Elimina o custo ocioso de Lambdas bloqueadas aguardando resposta de agentes de IA, com padrões prontos para produção que reduzem desperdício de compute.
Para quem: Desenvolvedores e arquitetos que integram agentes de IA do Bedrock AgentCore em arquiteturas serverless.
Remove a necessidade de Lambda@Edge customizado para assinar requisições ao S3 MRAP, simplificando arquiteturas multi-região e reduzindo superfície de ataque.
Para quem: Arquitetos de soluções que usam CloudFront com S3 em arquiteturas multi-região de alta disponibilidade.
Primeira solução GA da AWS para pagamentos autônomos por agentes de IA com controles de limite e observabilidade, abrindo uma nova categoria de automação financeira com guardrails.
Para quem: Arquitetos e product managers explorando automação de processos financeiros com agentes de IA.
Equipes de engenharia de dados vivem um ciclo repetitivo e desgastante: cada nova fonte de dados exige semanas de trabalho manual — escrevendo Extração, Transformação e Carga (ETL), criando verificações de qualidade à mão, atualizando modelos semânticos e validando conformidade regulatória. A Plataforma de Operações de Dados Agênticos (ADOP) na AWS foi projetada justamente para quebrar esse ciclo.
Trata-se de uma arquitetura de referência construída sobre o Amazon Bedrock que usa agentes de Inteligência Artificial (IA) especializados para automatizar o ciclo completo Bronze → Silver → Gold, com controles configuráveis de governança e conformidade regulatória aplicados desde o momento do onboarding.
Para líderes de engenharia de dados, a mudança é significativa em três frentes: os engenheiros deixam de gastar a maior parte do tempo em encanamento de pipelines e passam a entregar produtos de dados; a conformidade sai do papel de portão final e passa a ser um controle inline aplicado no onboarding; e a arquitetura — não o modelo de IA — governa como cada ferramenta de codificação com IA (Claude Code, Kiro, Cursor, Codex) interage com os sistemas de dados.
Agentes no desenvolvimento, artefatos na produção
Essa é a escolha de design que diferencia a ADOP de uma plataforma agêntica comum. A ADOP é um acelerador em tempo de construção, não uma dependência em tempo de execução. Os agentes rodam em ambientes de desenvolvimento, onde raciocinam, propõem e geram: código ETL, verificações de qualidade, definições de camada semântica e controles de regulação. Os engenheiros revisam o resultado. O processo de Integração e Entrega Contínua (CI/CD) então promove os artefatos gerados — PySpark determinístico, SQL, DAGs do Airflow, políticas de Gerenciamento de Identidade e Acesso (IAM) e Cedar — para staging e produção.
No padrão padrão da ADOP, a produção executa artefatos determinísticos sem chamar nenhum modelo. Organizações que precisam de inferência com modelo em tempo de execução podem estender a arquitetura usando endpoints do Amazon Bedrock, mas o código de pipeline gerado permanece estático e auditável.
Como a ADOP se diferencia de assistentes de código genéricos
Ferramentas como GitHub Copilot ou o próprio Claude sem contexto são assistentes de propósito geral: brilhantes, mas sem opiniões sobre arquitetura. Apontados para uma plataforma de dados, cada engenheiro acaba com uma arquitetura diferente a cada dia. A ADOP é opinativa por design. Ela envolve esses mesmos modelos com:
Uma faixa restrita — habilidades e prompts de engenharia de dados, não “qualquer coisa que você digitar”.
Filosofia da empresa incorporada — seus padrões vivem no design, não na memória de alguém.
Sem improvisação arquitetural do Modelo de Linguagem Grande (LLM) — o modelo preenche o blueprint, não o desenha.
Guardrails de política e regulação — controles aplicados em tempo de construção, não apenas na revisão.
Um fluxo de onboarding único para toda a empresa — cada fonte chega da mesma forma, sempre.
A diferença resume bem: ferramentas genéricas tornam um desenvolvedor mais rápido. A ADOP torna todos os desenvolvedores consistentes.
Arquitetura: como os agentes se organizam
A ADOP é um framework de codificação com IA que constrói pipelines de dados end-to-end na AWS e em ambientes multi-cloud. Ela lança um Agente de Onboarding de Dados no Claude Code via Amazon Bedrock, usando o recurso de Fluxo de Trabalho Dinâmico do Claude Code para criar sub-agentes especializados para cada estágio da construção do pipeline.
Os sub-agentes cuidam de geração de metadados, dedução de ontologia de dados, verificações de qualidade, transformações ETL e orquestração (Airflow ou AWS Step Functions). Os requisitos são enriquecidos iterativamente por meio de interação conversacional, e cada artefato é validado localmente antes do deploy na AWS, com aprovação humana no loop.
Motor de Decisão (clone de IA)
O Motor de Decisão funciona como uma versão codificada em IA do arquiteto corporativo da empresa. Ele incorpora as diretrizes da organização, padrões tecnológicos e filosofia de design diretamente no processo de construção. Isso promove consistência entre os desenvolvedores e reduz a fragmentação que ocorre quando equipes usam ferramentas genéricas sem guardrails compartilhados.
Guardrails e conformidade
Os sub-agentes são restringidos pelo contrato arquitetural: regras de roteamento de ferramentas, políticas de autorização Cedar, invariantes e prompts de conformidade inline. A implementação de referência aponta para AWS, mas o framework se estende a outros serviços com Interface de Linha de Comando (CLI) ou interface do Protocolo de Contexto de Modelo (MCP), suportando ambientes híbridos e multi-cloud.
Para conformidade regulatória, um prompt de regulação por framework de governança pode ser aplicado no onboarding — a equipe jurídica revisa um arquivo de prompt, não o código da aplicação. Cada decisão dos agentes é rastreada via AgentTrace (intenção, ferramenta selecionada, resultado, custo) e publicável no Amazon CloudWatch ou em um sink OpenTelemetry para auditoria.
Casos de uso
A ADOP se aplica onde a velocidade de engenharia de dados é travada por onboarding manual e overhead de conformidade. Os padrões mais comuns incluem:
Onboarding de dados corporativos em escala — descreva uma nova fonte em linguagem natural. Os agentes cuidam de inferência de schema, ETL, verificações de qualidade e atualizações da camada semântica.
Pipelines regulados em saúde e serviços financeiros — controles configuráveis aplicados por dataset via prompts de governança dedicados (GDPR, HIPAA, SOX, PCI DSS, CCPA).
Camadas Gold prontas para IA — populadas e mantidas automaticamente para Business Intelligence (BI) e features de Aprendizado de Máquina (ML).
Governança de desenvolvimento multi-ferramenta — Claude Code, Kiro, Cursor e Codex operam a partir do mesmo contrato arquitetural.
Em seguida, faça upload de um dataset para o Amazon Simple Storage Service (Amazon S3) ou armazenamento local e execute um prompt adaptado. O exemplo abaixo usa dados fictícios apenas para fins ilustrativos — não representa dados reais de Informação Pessoalmente Identificável (PII) e não constitui orientação de conformidade regulatória ou aconselhamento jurídico:
/onboard-workflow Onboard attendance data from s3://amzn-s3-demo-source-bucket/demo_landing/attendance.csv into Silver with dedup on (employee_id, check_in) and not-null policy on employee_id and check_in,and into a flat denormalized Gold Iceberg table aggregated daily-per-employee with derived measures(hours_worked_clean, attendance_rate, late_arrival_flag, overtime_hours, absence_category). Run daily at 03:00 UTC. Apply data governance controls: hash/pseudonymize PII fields in Silver, suppress or mask sensitive fields in Gold, enforce retention policies, and log processing metadata. Apply guidelines (This example is illustrative only and does not constitute compliance guidance.) Please profile the data first, then propose your recommended quality thresholds and transforms before generating any code.
Da prova de conceito à produção
As primeiras semanas são intensas em arquitetura porque codificar seus padrões — não construir pipelines — é o investimento único. Depois que o contrato existe, cada nova fonte é um prompt, não um projeto. Equipes que adotam esse padrão relatam compressão significativa nos prazos de onboarding de fontes subsequentes, com a curva se achatando ainda mais à medida que a memória de rastreamento de habilidades se acumula.
O plano de adoção sugerido divide-se em três fases. Na Fase 1 (Semanas 1–3), o piloto envolve dois ou três engenheiros campeões e uma fonte de dados não crítica. Na Fase 2 (Semanas 4–6), a expansão alcança o time completo de plataforma, com 3 a 5 fontes adicionais de complexidade crescente. Na Fase 3 (Semanas 7–12), o rollout organizacional ocorre com novas fontes fluindo pela ADOP e pipelines existentes migrando oportunisticamente durante janelas de manutenção.
Quatro indicadores-chave devem ser monitorados: tempo de ciclo de onboarding de fontes; taxa de aceitação de artefatos na primeira passagem; pontuação de satisfação dos engenheiros via pesquisas anônimas; e taxa de conformidade dos guardrails, medindo a consistência com que os pipelines gerados passam nas verificações automatizadas sem intervenção manual.
Segurança, privacidade e IA responsável
Gerenciamento de segredos e isolamento de dados
Segredos não entram no contexto dos agentes. Credenciais de banco de dados, chaves de API e tokens de serviço são resolvidos em tempo de deploy via AWS Secrets Manager. Os agentes referenciam ARNs ou variáveis placeholder — eles não veem nem processam valores reais de credenciais. Dados sensíveis ficam no lugar: os agentes trabalham com metadados de schema, contagens de linhas de amostra e estatísticas de colunas, não com dados brutos de produção.
Privacidade e isolamento de rede
As interações com o Claude via Amazon Bedrock não são retidas para treinamento do modelo (consulte o FAQ de Privacidade e Segurança de Dados do Amazon Bedrock). Prompts e respostas existem apenas durante a sessão, e a inferência permanece dentro dos limites da conta AWS. O modelo de desenvolvimento local-first significa que os agentes rodam nas máquinas dos desenvolvedores ou dentro da Nuvem Privada Virtual (VPC) — nenhum dado sai da rede sem configuração explícita.
Revisão humana obrigatória
Artefatos gerados — especialmente controles de conformidade e regulação — devem ser revisados por engenheiros qualificados antes de serem promovidos para produção. LLMs podem produzir lógica plausível, mas incorreta. Regras de mascaramento, políticas de retenção ou controles de acesso gerados podem estar incompletos ou sutilmente errados. Trate cada controle gerado como não verificado até que seja validado pela equipe jurídica ou de compliance.
Controles do Amazon Bedrock Guardrails
A ADOP trata o Amazon Bedrock Guardrails como controles obrigatórios de produção na arquitetura. Três capacidades se aplicam aos agentes na camada de API: filtragem de conteúdo (bloqueia outputs fora do escopo de engenharia de dados), validação de fundamentação (verifica que os outputs dos agentes estão ancorados nos metadados de schema e no contrato arquitetural) e filtros de informação sensível (detecção de PII e filtros baseados em regex que evitam que credenciais ou dados regulados apareçam nas respostas dos agentes ou no código gerado). Esses controles rodam inline a cada invocação de agente e são configurados uma vez no contrato arquitetural, sendo aplicados uniformemente em todos os sub-agentes.
Arquitetura SoAL (Spark on AWS Lambda) — se os pipelines gerados pela ADOP precisarem compilar código PySpark, esta arquitetura pode reduzir significativamente a contagem de tokens executando jobs Spark sem servidor.
A AWS anunciou a disponibilidade geral do AWS Glue 6.0, trazendo uma combinação bastante atrativa: redução de 30% no preço do serviço e uma série de melhorias técnicas significativas. A nova versão inclui suporte completo ao Apache Iceberg v3, versões mais recentes do Apache Hudi e Delta Lake, além de recursos voltados à produtividade dos times de desenvolvimento.
Atualização do runtime
O Glue 6.0 atualiza o ambiente de execução para componentes mais modernos. A stack agora inclui:
Apache Spark 4.1
Python 3.13
Scala 2.13
Essas atualizações garantem que os jobs rodem sobre versões estáveis e recentes das principais ferramentas do ecossistema de dados.
Novidades com o Apache Iceberg v3
O suporte ao Apache Iceberg v3 é um dos destaques da versão. Com ele, o Glue 6.0 passa a oferecer:
Tipo de dado VARIANT com shredding automático — acelera leituras em dados semi-estruturados
Vetores de deleção — permite atualizações em nível de linha com alta performance
Tipos de dados de geometria e geografia — habilita processamento espacial diretamente nos jobs
Evolução de schema flexível — por meio do tipo UNKNOWN e valores padrão (DEFAULT) para colunas
Melhorias de produtividade para desenvolvedores
Além das novidades relacionadas ao Iceberg, o Glue 6.0 introduz recursos que simplificam o dia a dia de quem constrói pipelines de dados:
Spark Declarative Pipelines — eliminam código repetitivo de orquestração, tornando os pipelines mais limpos e fáceis de manter
Real-Time Mode (modo em tempo real) — streaming com latências abaixo de um segundo
Arrow-native Python UDFs — funções definidas pelo usuário com melhor desempenho no PySpark
Esses recursos cobrem casos de uso como ETL em larga escala, cargas em batch recorrentes, análise de streaming e desenvolvimento de aplicações de IA.
Disponibilidade e como começar
O AWS Glue 6.0 já está disponível em todas as regiões comerciais da AWS, na AWS GovCloud (US) e nas regiões da AWS China. Para começar, basta selecionar a versão 6.0 no menu de versões do console do AWS Glue ou do SageMaker Unified Studio ao criar um novo job.
Imagine um engenheiro de infraestrutura abrindo o laptop de um colega para depurar uma build. Na pasta de configuração, um arquivo chamado mcp.json contém uma senha de banco de dados de produção em texto puro, ao lado de um comentário TODO: rotate this. A equipe de segurança não tem visibilidade de quais agentes de IA estão acessando ferramentas internas, quem concedeu esse acesso, nem qual seria o impacto se aquela credencial vazasse.
Esse cenário representa um padrão recorrente em empresas que adotam assistentes habilitados com o Protocolo de Contexto de Modelo (MCP) — como Kiro, Claude Code e Amazon Quick — sem uma camada centralizada de governança. A AWS identificou cinco padrões de falha estrutural nesse cenário: espalhamento de credenciais em configs locais, divergência silenciosa de políticas, lacunas de auditoria, opacidade de custos e Shadow IT.
Para endereçar isso, a AWS documentou uma abordagem progressiva usando o AgentCore Gateway, uma capacidade do Amazon Bedrock AgentCore que fornece um ponto de entrada único, seguro e auditável para o tráfego de agentes em direção às ferramentas corporativas.
A jornada de maturidade em quatro escopos
A proposta da AWS não é construir tudo de uma vez — é avançar conforme as dores reais aparecem. Cada escopo entrega valor independente e preserva o caminho para o próximo.
Indicado para pilotos com 1 a 20 usuários e ferramentas de baixo risco. O objetivo é simples: criar um único ponto de entrada para que os agentes de IA cheguem aos recursos organizacionais, com autenticação via SSO (Entrada Única), credenciais centralizadas e auditoria pelo AWS CloudTrail.
Na prática, o gateway é provisionado com um autorizador JWT (Token Web JSON) apontando para um pool do Amazon Cognito. Uma função AWS Lambda de baixo risco — como uma busca de tickets somente leitura — é registrada como alvo MCP. O arquivo mcp.json dos assistentes passa a apontar para o endpoint do gateway em vez de servidores locais. As credenciais de backend nunca saem da AWS, e toda invocação aparece nos logs do Amazon CloudWatch.
O comando para criar o gateway com autorizador JWT é:
O resultado: o caminho fim a fim funciona, o mcp.json agora contém um endpoint que alcança recursos organizacionais, e produtividade e controles chegam juntos.
Escopo 2 — Control: autorização por identidade e guardrails
Com a porta aberta, o Escopo 2 identifica quem está chamando e filtra o que passa. É indicado quando a base de usuários cresce e a conformidade começa a perguntar “quem fez o quê, sob qual política?”
A mudança central é migrar de confiança no nível de máquina para confiança no nível de usuário. Os clientes passam a ser registrados dinamicamente via Registro Dinâmico de Clientes (DCR) — um shim Lambda que cria um app client no Cognito e o adiciona à lista de clientes permitidos do gateway. O usuário se autentica via SSO com fluxo de Código de Autorização (Authorization Code), e a partir daí cada requisição carrega a identidade real do usuário.
O AgentCore Policy aplica regras Cedar com controle de acesso baseado em papéis (RBAC) e atributos (ABAC). Por exemplo, a política abaixo restringe deploys de CI ao ambiente de staging para membros do grupo de pagamentos, enquanto mantém ferramentas de leitura abertas para qualquer principal autenticado:
// Payments deployers can deploy, but only to staging
permit (
principal,
action == AgentCore::Action::"DeployCI___invoke",
resource
)
when {
principal.hasTag("groups") &&
principal.getTag("groups").contains("repo-payments-service")
/* Note: for Cognito, the claim is cognito:groups, not groups.
Refer to your deployed Gateway Cedar schema for the precise tag names. */
&& context.input.environment == "staging"
};
// Read-only tools are open to any authenticated principal with a group
permit (
principal,
action in [
AgentCore::Action::"TicketSearch___invoke",
AgentCore::Action::"DocsSearch___invoke"
],
resource
)
when {
principal.hasTag("groups")
};
O Amazon Bedrock Guardrails é integrado nativamente ao AgentCore Policy para aplicar filtros de Informações de Identificação Pessoal (PII), políticas de conteúdo e detecção de ataques de prompt na camada do gateway, sem código customizado. A configuração abaixo, por exemplo, bloqueia números de CPF/SSN e cartões de crédito, e anonimiza e-mails:
A recomendação é implantar o AgentCore Policy primeiro em modo LOG_ONLY para monitorar quais decisões mudariam antes de ativar o modo ENFORCE. Quando um recurso downstream precisa da identidade do usuário em um sistema SaaS (como GitHub ou Slack), o AgentCore Identity gerencia o fluxo de três pernas (3LO), emitindo um erro de elicitação -32042 para que o assistente conduza o usuário pelo consentimento no navegador. Para recursos que compartilham a mesma cadeia de identidade, o On-Behalf-Of (OBO) token exchange substitui o redirecionamento pelo navegador, sem fluxo adicional de consentimento.
Escopo 3 — Catalog: autoatendimento, registro e alcance multi-ambiente
Quando os tickets de “adicione esta ferramenta” se acumulam ou é preciso alcançar sistemas fora da AWS, é hora do Escopo 3. Indicado para mais de 100 usuários, esse escopo elimina o gargalo de cadastro manual de ferramentas.
Os donos de ferramentas passam a criar um manifesto YAML e abrir um pull request. O pipeline de CI valida, escaneia e, no merge, chama create-gateway-target e atualiza a política Cedar automaticamente. Um exemplo de manifesto:
O AWS Agent Registry centraliza a descoberta de ferramentas e habilidades. Um servidor Resources MCP distribui automaticamente para todos os assistentes contextos organizacionais como padrões de código, runbooks de plantão e checklists de release — sem configuração por desenvolvedor.
Para sistemas fora da AWS, o gateway alcança bancos de dados on-premises via AWS Direct Connect ou VPN, e APIs SaaS via OAuth de saída. O Open Policy Agent (OPA) complementa o Cedar com regras que ele não expressa nativamente, como janelas de tempo e verificação de ticket de mudança. A política Rego abaixo, por exemplo, permite escrita em banco de dados somente em dias úteis, das 9h às 17h UTC, com ticket de mudança anexado:
Para FinOps, tags por ferramenta no AWS Cost Explorer permitem que o financeiro atribua gastos ao time responsável. Um alerta de AWS Budgets pode ser configurado por ferramenta com um limite mensal de custo de invocação.
Escopo 4 — Harden: resiliência e governança de borda
Para workloads com mais de 1.000 usuários, indústrias reguladas ou requisitos de alta disponibilidade global, o Escopo 4 endurece o perímetro e prepara o gateway para falhas.
O tráfego passa a fluir pela rede corporativa: Amazon CloudFront na borda → Application Load Balancer restrito ao CloudFront via header secreto → VPC Endpoint em subnet privada → PrivateLink → gateway. O DNS público é eliminado. Para agentes hospedados em Runtime, a AWS recomenda ativar enforcement de entrada exclusiva, de modo que o Runtime rejeite qualquer invocação que não venha pelo gateway, impedindo contornos à política e à auditoria.
O failover multi-região é configurado via Amazon Route 53 com health checks. O registro de failover abaixo alterna para a região secundária quando o health check primário falha, dentro de um TTL de 30 segundos:
Uma Lambda noturna de deprecação lê métricas do CloudWatch e abre pull requests automaticamente para ferramentas com zero invocações nos últimos 30 dias. Após 90 dias sem uso, o alvo é removido — eliminando ferramentas zumbi do registry.
Para responder perguntas de conformidade como “quais principals tiveram maior taxa de negação na última semana?”, o Amazon Athena consulta os logs do CloudTrail:
SELECT
attributes.`aws.agentcore.policy.determining_policies` as policies,
COUNT(*) AS denies,
DATE_TRUNC('day', from_iso8601_timestamp(event_time)) AS day
FROM aws_spans_export
WHERE
attributes.`aws.agentcore.policy.authorization_decision` = 'DENY'
AND from_iso8601_timestamp(event_time) > current_date - INTERVAL '7' DAY
GROUP BY principal, matched_policy, DATE_TRUNC('day', from_iso8601_timestamp(event_time))
ORDER BY denies DESC
LIMIT 25;
Referência de implantação: caso de serviços financeiros
A AWS documentou como uma organização de serviços financeiros percorreu os quatro escopos em seis meses: começou no Escopo 1 com dois analistas e uma ferramenta SQL de staging; evoluiu para o Escopo 2 em três semanas com 30 analistas, RBAC por mesa de operação e auditoria completa; chegou ao Escopo 3 no terceiro mês com 200 usuários e queda de ~40% na fila de tickets; e completou o Escopo 4 no sexto mês com 1.000 usuários, isolamento de rede exigido pela MiFID II e RTO de 4 horas via Route 53 failover. O gatilho para avançar cada escopo foi sempre uma pergunta organizacional concreta, não um prazo predefinido.
Considerações operacionais e de custos
A AWS recomenda tratar o gateway com as mesmas práticas operacionais de serviços de produção desde o primeiro dia. Ambientes de dev, staging e produção devem rodar em contas AWS separadas, promovidos via Infraestrutura como Código (IaC).
Em segurança, credenciais devem ser armazenadas no AWS Secrets Manager com rotação, ou eliminadas com autenticação por Chave Privada JWT (private key no AWS KMS). Nunca em variáveis de ambiente. O mcp.json deve ser distribuído centralmente via MDM. Políticas de Controle de Serviço (SCPs) do AWS IAM com a condição aws:ViaAWSMCPService bloqueiam operações destrutivas invocadas por servidores MCP gerenciados pela AWS.
Em custos, a referência da AWS aponta que ~50 desenvolvedores executando 572.000 operações mensais custam aproximadamente US$ 17 combinando Gateway e Policy (Gateway InvokeTool a US$ 5 por milhão + Policy authorization a US$ 25 por milhão; Identity custa US$ 0 quando consumido pelo Gateway). Consulte a página de preços do Amazon Bedrock AgentCore para valores atualizados.
Limpeza de recursos
Para evitar cobranças contínuas após testes, a AWS recomenda remover os recursos na ordem inversa da criação. Os comandos principais incluem deletar targets com DeleteGatewayTarget e o gateway em si:
Redução de preços chega ao GPT-5.6 Sol no Amazon Bedrock
A OpenAI anunciou a redução dos preços de API para o modelo GPT-5.6 Sol, disponível no Amazon Bedrock. A novidade segue uma tendência recente de cortes de preço que já havia contemplado outros modelos da linha, como o Terra e o Luna. Agora é a vez do Sol receber um ajuste significativo, tornando o acesso mais viável para equipes que trabalham com cargas de trabalho intensas e de alto volume.
Novos valores de precificação
Com a atualização, o GPT-5.6 Sol passa a custar:
$4 por milhão de tokens de entrada — redução de 20% em relação ao preço anterior
$20 por milhão de tokens de saída — redução de 33,3% em relação ao preço anterior
Vale destacar que essa é uma precificação promocional, garantida pelo menos até 21 de novembro de 2026. Ou seja, há uma janela relevante para times que queiram experimentar o modelo ou escalar projetos que já estão em andamento.
Para quais casos de uso faz sentido?
O GPT-5.6 Sol é um modelo posicionado para tarefas que exigem alto desempenho em cenários agênticos — aqueles em que o modelo age de forma autônoma para executar sequências de tarefas. Entre os casos de uso mais relevantes estão:
Agentes de codificação autônomos, que escrevem, revisam e depuram código de forma independente
Análises complexas com múltiplos passos, em que o modelo precisa encadear raciocínios e tomar decisões intermediárias
Fluxos de trabalho avançados de pesquisa, que demandam processamento extenso de informações
O modelo já entrega resultados de ponta em benchmarks de codificação agêntica, e a queda no preço amplia o espaço para experimentação e para sustentar operações de maior escala sem comprometer o orçamento.
Disponibilidade e documentação
A disponibilidade do GPT-5.6 Sol varia por região da AWS. Para verificar em quais regiões AWS o modelo já está disponível, consulte a página oficial de compatibilidade regional. Para detalhes completos sobre preços e como começar a usar o modelo, a documentação do Amazon Bedrock traz todas as informações necessárias.
A AWS anunciou uma atualização relevante para quem gerencia contact centers com o Amazon Connect Customer: agora os gestores podem simplesmente conversar com seus dados operacionais em linguagem natural e receber, em segundos, a resposta que procuram — junto com as evidências que a sustentam e a recomendação de ação mais adequada.
Na prática, isso significa o fim da dependência de dashboards complexos, analistas de dados e semanas de investigação para entender o que está afetando a performance do time.
O problema que essa funcionalidade resolve
Gestores de contact center sempre tiveram acesso a dados. O que faltava era tempo — e clareza. Identificar o que está impactando o desempenho, entender a causa raiz e decidir o próximo passo exigia cruzar múltiplos relatórios, envolver analistas e aguardar dias ou semanas por uma resposta confiável.
Com essa novidade, o Amazon Connect Customer assume esse trabalho. A ferramenta vasculha mais de 150 métricas distribuídas em três grandes dimensões operacionais:
Autoatendimento — desempenho dos fluxos automatizados
Performance dos agentes — indicadores individuais e de equipe
Performance das filas — comportamento e gargalos no atendimento
A partir dessas métricas, o sistema identifica o que importa, explica o porquê e recomenda o melhor próximo passo.
Como funciona na prática
A interação acontece em formato conversacional: o gestor começa com uma pergunta ampla e pode ir aprofundando o tema dentro da mesma conversa, sem precisar trocar de ferramenta ou reformular a busca do zero.
Um exemplo ilustrativo citado pela própria AWS: um gestor pergunta quais filas são as melhores candidatas para automação. O Amazon Connect Customer então analisa onde o tempo médio de atendimento e o trabalho pós-contato estão mais elevados, e devolve uma lista priorizada com pontuações de confiança e o impacto projetado de cada ação.
O que antes demandava analistas, dashboards e semanas de investigação passa a ser um plano de ação priorizado gerado em segundos.
Disponibilidade
O recurso está disponível em todas as regiões AWS onde os Amazon Connect Customer AI Agents são suportados. Para saber mais sobre como configurar e utilizar essa funcionalidade, a AWS disponibiliza a documentação oficial do produto.
