User's blog

Author: Make.com Service User

  • Como construir um atendente de voz com IA para restaurantes usando o Amazon Connect

    O problema: pedidos por telefone ainda dominam em restaurantes

    Em muitos restaurantes, uma fatia expressiva dos pedidos ainda chega por telefone. O problema é que essas ligações geralmente caem no colo de um funcionário que já está atendendo clientes no balcão. O resultado é previsível: cliente esperando na linha, pedido anotado à mão e o caos se intensificando nos horários de pico.

    Criar um app ou site resolve para quem prefere pedir online, mas não ajuda em nada quem quer simplesmente ligar. A AWS publicou um guia técnico mostrando como resolver exatamente esse problema: um sistema de pedidos por voz que atende a ligação e conduz o pedido do início ao fim, sem app, sem site e sem login.

    Como a solução funciona

    O cliente liga para um número de telefone. Um atendente de IA cumprimenta, responde perguntas sobre o cardápio, encontra a unidade de retirada mais próxima e confirma o pedido em voz alta. Tudo por telefone, sem nenhuma etapa digital adicional.

    A arquitetura usa três serviços principais trabalhando juntos:

    O design mantém três responsabilidades bem separadas: o Amazon Connect cuida da ligação, o agente de IA conduz a conversa e o backend armazena cardápio, carrinho, pedidos e localizações. Essa separação é intencional — o backend pode mudar sem que seja necessário mexer no agente.

    Componentes implantados pela solução

    A solução completa é implantada via Kit de Desenvolvimento em Nuvem da AWS (AWS CDK) em oito stacks. Os principais componentes são:

    • Amazon Connect: fornece a telefonia de entrada, o fluxo de contato e o número de telefone que recebe as ligações.
    • Amazon Lex V2: hospeda o bot de voz que o fluxo de contato conecta ao chamador, usando o Agentic Voice para fala e roteando cada turno ao agente de IA.
    • Amazon Connect Agentic Voice: oferece Reconhecimento Automático de Fala Avançado (Advanced ASR) com detecção de fim de turno baseada em confiança, além de síntese de voz (TTS) expressiva, tudo nativamente no Amazon Connect.
    • Amazon Connect AI Agents: o agente de orquestração alimentado pelo Anthropic Claude Haiku 4.5 no Amazon Bedrock.
    • Amazon Connect AI Guardrails: mantém a conversa segura e dentro do tema com filtros de conteúdo, tópicos negados e filtragem de linguagem inapropriada.
    • AgentCore Gateway: expõe as APIs do backend como ferramentas MCP que o agente pode descobrir e chamar pelo nome.
    • Amazon AppIntegrations: registra o AgentCore Gateway como uma aplicação MCP que o agente de IA pode usar.
    • Amazon API Gateway: expõe o backend com endpoints REST protegidos por Gerenciamento de Identidade e Acesso da AWS (IAM).
    • AWS Lambda: executa a lógica de negócio para cardápios, carrinhos, pedidos e buscas de localização.
    • Amazon DynamoDB: armazena perfis de clientes, pedidos, itens do cardápio, carrinhos e localizações.
    • Amazon Location Service: fornece geocodificação e cálculo de rotas para recomendações de retirada.

    O fluxo de uma ligação de ponta a ponta

    Quando o cliente liga, o Amazon Connect atende e um fluxo de contato entra em ação. Esse fluxo executa uma sequência curta de passos: habilita o registro no Amazon CloudWatch, define a voz Agentic Voice para a chamada, captura o número de telefone do chamador e abre uma sessão do agente de IA. Em seguida, uma função Lambda injeta o número de telefone nessa sessão — assim o agente já sabe quem está ligando sem precisar perguntar. Por fim, o fluxo reproduz uma saudação e conecta o chamador ao bot do Amazon Lex V2, que assume o controle da conversa usando o Agentic Voice para ouvir e falar.

    Quando o agente de IA termina, o bot devolve o controle ao fluxo de contato, que lê o resultado e encerra a chamada. O agente sinaliza o fim com um de dois resultados: Concluído, para um pedido finalizado, ou Escalonar, quando o chamador pede para falar com uma pessoa. Nessa solução ambos os resultados encerram a chamada, mas como tudo vive dentro do Amazon Connect, é possível configurar o caminho de escalonamento para transferir o chamador para um atendente humano com o contexto completo da conversa.

    Reconhecimento de voz e naturalidade na conversa

    O Amazon Connect Agentic Voice cuida da camada de fala nativamente dentro do Amazon Connect. Seu Advanced ASR reconhece fala com diferentes sotaques e tolera o ruído de fundo típico de uma linha telefônica. A detecção de fim de turno baseada em confiança identifica quando o chamador terminou de falar, em vez de aguardar um silêncio fixo — isso encurta a pausa entre o fim da fala do cliente e a resposta do agente, tornando a conversa mais natural. O chamador também pode interromper o agente, como acontece em ligações reais.

    O agente de IA, alimentado pelo Anthropic Claude Haiku 4.5, tem um prompt de sistema escrito para voz: respostas curtas, preços falados de forma natural (como “cinco reais e noventa e nove”) e sem leitura de IDs internos. O agente cumprimenta, responde dúvidas sobre o cardápio, resolve a localização de retirada, monta o carrinho, lê o resumo para confirmação e registra o pedido.

    Os limiares de confiança de fim de turno e de silêncio podem ser ajustados por intenção, para casos como a leitura de um número de cartão ou um endereço. A AWS disponibiliza um guia de boas práticas do Agentic Voice para esses ajustes.

    Conectando o agente ao backend via MCP

    O agente de IA nunca chama as funções Lambda do backend diretamente. O AgentCore Gateway fica no meio e apresenta os endpoints do backend como ferramentas MCP que o agente descobre e chama pelo nome — consultas ao cardápio, operações de carrinho, registro de pedido, histórico do cliente, geocodificação e busca de localização.

    O gateway é registrado no assistente Amazon Connect AI Agents como uma aplicação MCP via Amazon AppIntegrations, e autoriza cada chamada com um Token Web JSON (JWT) validado contra a instância do Amazon Connect. Quando o agente chama uma ferramenta como PlaceOrder, o gateway transforma isso em uma requisição REST para o Amazon API Gateway, que roteia para a função Lambda correspondente.

    Como o agente fala com ferramentas nomeadas e não com funções específicas, é possível trocar um handler do backend ou adicionar uma ferramenta sem alterar o agente. O mesmo backend também pode servir outros canais, pois todos registram pedidos nas mesmas ferramentas e dados.

    Identificando o chamador sem login

    Um chamador por telefone não faz login. O sistema usa o número de telefone como base de identidade: o fluxo de contato captura esse número e uma função Lambda o injeta na sessão do agente como atributo de sessão. O agente converte esse número em um ID de cliente e o usa em todas as chamadas de ferramentas da conversa.

    Se o número não estiver disponível — porque o chamador bloqueou o identificador de chamadas — o agente gera um ID anônimo para a sessão e o pedido ainda é processado. Cada chamador tem um carrinho isolado, então ligações simultâneas nunca interferem umas nas outras.

    Vale destacar: isso reconhece um chamador recorrente, mas não é verificação de identidade. O número de telefone não deve ser tratado como prova de quem está ligando. Uma implantação em produção que exija identidade verificada pode adicionar uma etapa como senha de uso único.

    Mantendo a conversa segura com AI Guardrails

    O agente de IA tem um Amazon Connect AI Guardrail configurado que mantém a conversa segura e dentro do tema. O guardrail aplica filtros de conteúdo para categorias como discurso de ódio, insultos, conteúdo sexual, violência e ataques de prompt. Ele bloqueia tópicos negados como discussões políticas e conselhos de investimento financeiro, e filtra linguagem inapropriada com uma lista gerenciada e uma lista personalizada.

    Quando o chamador diz algo fora do tema ou inadequado, o guardrail intervém e o agente responde com uma mensagem padrão, como “Desculpe, só posso ajudar com pedidos do restaurante”, e redireciona a conversa.

    Um ponto de atenção: filtros muito amplos podem bloquear turnos legítimos. Filtros de informações pessoais identificáveis, em particular, podem capturar o endereço ou CEP que o chamador precisa fornecer para encontrar uma unidade de retirada. Vale calibrar o guardrail contra o seu próprio prompt antes de subir para produção.

    Armazenamento: cardápio, carrinhos e pedidos

    Cinco tabelas do Amazon DynamoDB cobrem o fluxo de pedidos. A tabela Customers armazena perfis com nome, telefone e informações de fidelidade. A tabela Orders guarda o histórico de pedidos com a localização de retirada. A tabela Menu contém itens, preços e disponibilidade, que podem variar por unidade. A tabela Carts mantém carrinhos em andamento com um valor de tempo de expiração (TTL) para limpeza automática de carrinhos abandonados. A tabela Locations armazena detalhes dos restaurantes como coordenadas, horários e alíquotas de impostos.

    O DynamoDB opera em modo sob demanda, então não há throughput para gerenciar.

    Localização de retirada com Amazon Location Service

    Um chamador por telefone não tem navegador para compartilhar localização. O agente pede um CEP ou um cruzamento de ruas e usa o Amazon Location Service para converter isso em coordenadas. A partir daí, o backend pode encontrar os restaurantes mais próximos, ranqueá-los por tempo de deslocamento em vez de distância em linha reta, ou geocodificar um endereço específico. Isso permite que o agente diga algo acionável como “a unidade mais próxima fica na Rua Principal, a cerca de cinco minutos daqui”.

    Pré-requisitos e implantação

    Para implantar a solução, são necessários:

    A solução completa está disponível no repositório de exemplo no GitHub. Após clonar o repositório, basta executar o script de implantação com um prefixo:

    ./scripts/deploy-all.sh --deploymentPrefix qsr-cn

    O script executa uma verificação prévia e implanta cada stack do AWS CDK em ordem de dependência. Ao final, ele exibe o número para discagem. A AWS recomenda a região US East (Norte da Virgínia), us-east-1, como ponto de partida, pois todos os serviços necessários estão disponíveis lá.

    Custos estimados

    Segundo a AWS, em julho de 2026, executar essa solução com as configurações padrão na região US East (Norte da Virgínia) custa aproximadamente US$ 35 por mês para 1.000 pedidos por voz com média de cinco minutos cada. Os maiores itens de custo são os minutos de chamada de entrada no Amazon Connect, os tokens do Anthropic Claude Haiku 4.5 para orquestração e as requisições de fala do Amazon Lex V2. Não há cobranças fixas de computação, pois o Amazon Connect e os serviços de IA cobram por uso. A AWS recomenda configurar um orçamento no AWS Cost Explorer para acompanhar os gastos.

    Limpeza dos recursos

    Para evitar cobranças contínuas, a AWS disponibiliza um script de limpeza que remove os stacks em ordem inversa:

    ./scripts/cleanup-all.sh --force --deploymentPrefix qsr-cn

    Atenção: a limpeza é destrutiva. Ela libera o número de telefone, apaga o histórico de pedidos no DynamoDB e remove a instância do Amazon Connect, o assistente, o agente de IA, o guardrail, o bot Lex e o AgentCore Gateway. Faça backup do que quiser preservar antes de executar. Ao final, confirme no console do AWS CloudFormation que todos os oito stacks foram removidos.

    Recursos adicionais

    Fonte

    Building a restaurant telephony AI host with Amazon Connect (https://aws.amazon.com/blogs/machine-learning/building-a-restaurant-telephony-ai-host-with-amazon-connect/)

  • Correção e Harmonização de Metadados com IA na AWS

    O problema que a IA veio resolver

    À medida que a produção de dados cresce em ritmo acelerado, a capacidade de padronizá-los não acompanha o mesmo ritmo. Metadados inconsistentes — com rótulos divergentes, identificadores fora do padrão e formatos incompatíveis entre fontes diferentes — criam um gargalo crítico que atrasa análises e dificulta o compartilhamento de dados entre organizações.

    A harmonização de metadados, que consiste em padronizar rótulos, identificadores e formatos para que conjuntos de dados de origens distintas possam trabalhar juntos, ainda é feita majoritariamente de forma manual. A AWS publicou um post técnico detalhando como a inteligência artificial pode transformar esse processo, tornando-o escalável e compatível com os volumes de dados modernos.

    Arquitetura da solução

    A AWS descreve um fluxo centralizado de correção e harmonização de metadados construído sobre serviços gerenciados. Os componentes principais são:

    O fluxo opera de forma cíclica: os arquivos de metadados são enviados pelo usuário, passam por validação paralela em dois eixos — alinhamento de esquema e validação de campos individuais — e, quando problemas são detectados, o sistema gera recomendações direcionadas que são apresentadas ao usuário para aprovação final.

    Etapas do processo de correção

    Alinhamento de esquema

    A primeira etapa compara os esquemas de dados de origem e destino, verificando se as colunas corretas existem e estão devidamente alinhadas. Problemas comuns incluem convenções de nomenclatura inconsistentes (sinônimos, erros de digitação, abreviações), colunas ausentes ou extras, e situações onde colunas precisam ser divididas ou combinadas.

    Técnicas de correspondência aproximada de strings (fuzzy string matching) resolvem discrepâncias básicas de nomenclatura. Para casos mais complexos, os LLMs disponíveis no Amazon Bedrock trazem compreensão semântica ao problema: em vez de depender apenas de similaridade de texto, a abordagem baseada em LLM reconhece sinônimos específicos de um domínio, infere significado a partir das colunas vizinhas e detecta quando uma coluna de origem deve ser dividida em múltiplas colunas de destino — casos que sistemas baseados em regras simples não conseguem resolver.

    Validação de campos de metadados

    Essa etapa verifica se os valores individuais de cada campo estão em conformidade com os requisitos do esquema. As falhas são classificadas em três tipos:

    • Validação de campos obrigatórios: identifica campos mandatórios que estão ausentes, vazios ou preenchidos apenas com espaços em branco.
    • Validação de valores enumerados: compara o conteúdo dos campos com vocabulários controlados definidos no esquema. Valores fora da lista permitida geram um erro de validação.
    • Validação de padrões: aplica correspondência por expressões regulares para verificar convenções de formatação — por exemplo, datas no formato AAAA-MM-DD ou identificadores com padrões alfanuméricos específicos.

    Geração de recomendações de correção

    Quando erros de validação são detectados, o sistema gera recomendações usando uma combinação em camadas de técnicas de Processamento de Linguagem Natural (PLN) e IA. A lógica prioriza métodos mais simples e baratos antes de acionar os LLMs, mantendo os custos de inferência previsíveis. As quatro técnicas utilizadas são:

    • Similaridade semântica por embeddings: vetores de embedding permitem comparar valores de metadados semanticamente, identificando correspondências próximas com base em limiares de similaridade. Por exemplo, o sistema consegue mapear “Human” para “Homo sapiens” ou “NYC” para “New York City”. A AWS avaliou múltiplos modelos de embedding e selecionou o Amazon Titan por seu desempenho em tarefas gerais e biomédicas, disponibilidade comercial e compatibilidade com o Amazon Bedrock.
    • Inferência contextual: o sistema recomenda correções identificando padrões e relações dentro do próprio conjunto de metadados, sem depender de grandes bases de dados externas. A implementação combina k-vizinhos mais próximos ponderados por distância com representações TF-IDF e análise de co-ocorrência por Informação Mútua Pontual (PMI). O resultado são recomendações estáveis e explicáveis, fundamentadas na estrutura interna dos dados.
    • Correspondência fuzzy: algoritmos como a distância de Levenshtein detectam e corrigem inconsistências tipográficas ou de formatação — erros de digitação, espaçamento, diferenças de pontuação. Essa técnica é aplicada no início do fluxo para capturar inconsistências de baixo nível antes das camadas semânticas.
    • Resolução por LLM (camada de fallback): quando os métodos anteriores não atingem um nível de confiança suficiente, o Amazon Bedrock é acionado como fallback. Os LLMs conseguem raciocinar sobre estruturas complexas de metadados e interpretar padrões ambíguos ou inéditos. Os resultados são então apresentados para revisão humana.

    Abordagem 1: fluxo com supervisão humana

    No modelo com supervisão humana (human-in-the-loop), o colaborador mantém controle total sobre as correções aplicadas. O fluxo funciona assim: o usuário faz o upload do arquivo de metadados pela interface web, o sistema executa a validação e harmonização automatizada, e as recomendações geradas pela IA são apresentadas na interface para revisão. O colaborador pode inspecionar cada entrada sinalizada, revisar as sugestões geradas automaticamente e aceitar, editar ou rejeitar cada uma delas. Após a revisão, o arquivo corrigido é reenviado para revalidação. Submissões bem-sucedidas são automaticamente confirmadas e propagadas.

    Imagem original — fonte: Aws

    Cada ciclo reduz o esforço manual enquanto preserva a responsabilidade do colaborador sobre o resultado final. A automação acelera as correções, mas o conhecimento de domínio do pesquisador permanece central no processo.

    Abordagem 2: fluxo com agente autônomo

    Para conjuntos de dados com centenas ou milhares de registros, a participação ativa do colaborador em cada ciclo de revisão ainda representa um esforço considerável. Para reduzir essa carga, a solução pode ser estendida com agentes autônomos.

    Nesse modelo, um agente de metadados opera como um sistema autônomo ou semi-autônomo capaz de analisar, corrigir e validar registros de metadados. Ele usa tanto raciocínio determinístico (lógica baseada em regras) quanto não-determinístico (inferência por LLM via Amazon Bedrock). Por meio do Protocolo de Contexto de Modelo (MCP), o agente acessa ferramentas especializadas — o serviço remoto de processamento de metadados, validadores de esquema e módulos de similaridade por embedding.

    O fluxo operacional do agente espelha a estrutura do fluxo humano, mas substitui as ações diretas do usuário por raciocínio autônomo:

    Imagem original — fonte: Aws

    Essa configuração permite escalar a curadoria de metadados em grandes volumes com intervenção humana mínima, mantendo um log auditável de todas as correções aplicadas.

    Para dados de alto valor ou de domínios específicos, agentes especializados por organização podem ser implantados, com acesso a repositórios privados, logs de experimentos e publicações científicas internas. Isso permite dois níveis de adaptação: raciocínio local (inferência com base no dataset imediato e submissões anteriores) e enriquecimento contextual (uso de ontologias, protocolos e vocabulários controlados da organização).

    Como implantar a solução

    A AWS disponibilizou o código-fonte da solução no repositório no GitHub. Os pré-requisitos para implantação são:

    O processo de implantação segue seis passos principais:

    Passo 1: clonar o repositório e instalar dependências

    git clone https://github.com/aws-samples/sample-intelligent-metadata-harmonization.git
cd metadata-harmonization

# Criar e ativar ambiente virtual Python
make createPythonEnvironment
source .venv/bin/activate

# Instalar todas as dependências
make install

    Passo 2: configurar o deployment

    cp config.yaml.example config.yaml

    Edite o arquivo config.yaml com os dados da sua conta AWS:

    appName: "metadata-harmonization-app"
env: "dev"
dev:
  profile: "your-aws-profile"
  deploymentName: "metadata-harmonization-dev"
  accountNumber: "123456789012" # Seu número de conta AWS com 12 dígitos
  region: "us-east-1"
  deploymentStage: "dev"
  removalPolicy: "destroy"
  logLevel: "INFO"
  targetPlatform: "linux/amd64"

    Valide a configuração com make validateConfig.

    Passo 3: implantar a infraestrutura

    # Configuração inicial (apenas na primeira vez)
make bootstrap

# Implantar todos os recursos AWS
make deploy

    Após o deploy, gere o arquivo .env local com os identificadores dos recursos:

    make createLocalDotEnvFile

    Passo 4: criar usuários no Amazon Cognito

    Acesse o console do Amazon Cognito, selecione o user pool criado pelo deployment, vá até “Users” e crie os usuários necessários com e-mail e senha temporária.

    Passo 5: executar a aplicação web localmente

    # Executar API e frontend juntos (recomendado)
make runLocal

    A interface web fica disponível em http://localhost:3000 e a documentação da API em http://localhost:8080/api/docs.

    Passo 6: executar o agente de metadados

    uv run metadata-agent validate data/synthetic_dataset/simple_test.csv --interactive

    O agente se conecta à API via MCP, valida o dataset, recupera os relatórios de falha e aplica correções de forma autônoma.

    Considerações de governança e segurança

    A transição de prova de conceito para produção exige atenção a quatro áreas:

    • Integridade dos dados e rastreamento de mudanças: organizações devem estabelecer frameworks claros para documentar e preservar as alterações de metadados, com políticas de retenção, trilhas de auditoria e controles de integridade adequados ao ambiente regulatório.
    • Governança de arquitetura: é necessário definir se as correções geradas pela IA requerem aprovação antes de serem aplicadas ou se podem ser aplicadas automaticamente com revisão posterior. Essa decisão afeta a integridade dos dados e a capacidade de reversão.
    • IA responsável e segurança de conteúdo: deployments em produção que usam inferência de LLM devem incorporar o Amazon Bedrock Guardrails para estabelecer limites no comportamento dos modelos e proteger contra ataques de injeção de prompt — especialmente quando valores de metadados de fontes externas são passados diretamente para os prompts dos modelos.
    • Segurança: sistemas de IA que lidam com dados genômicos sensíveis devem atender aos mesmos padrões de segurança de sistemas tradicionais de pesquisa, incluindo controle de acesso baseado em papéis e proteção de dados em todo o pipeline de validação.

    Para encerrar o ambiente e evitar cobranças contínuas, basta executar make destroy, que remove toda a stack do AWS CDK.

    Conclusão

    A solução de correção e harmonização de metadados com IA apresentada pela AWS endereça um desafio persistente em pesquisa biomédica: o tempo gasto em padronização de dados em vez de trabalho científico. As duas abordagens de implementação — com supervisão humana e com agentes autônomos — oferecem flexibilidade para organizações em diferentes estágios de adoção de IA. Equipes podem começar com correções supervisionadas para construir confiança no sistema e, gradualmente, migrar para abordagens mais automatizadas. A arquitetura nativa em nuvem escala com o volume de dados e o design modular permite customização para necessidades institucionais específicas.

    Fonte

    AI-powered metadata correction and harmonization (https://aws.amazon.com/blogs/machine-learning/ai-powered-metadata-correction-and-harmonization/)

  • Amazon SageMaker HyperPod amplia suporte ao Ray com observabilidade, resiliência e inferência acelerada

    O que mudou no HyperPod com Ray

    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.

    Fonte

    Amazon SageMaker HyperPod enhances support for Ray (https://aws.amazon.com/about-aws/whats-new/2026/08/amazon-sagemaker-hyperpod-ray)

  • Amazon Aurora passa a suportar PostgreSQL 18.4, 17.10, 16.14, 15.18 e 14.23

    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.

    Para um guia completo sobre como conduzir o processo, consulte a documentação oficial sobre upgrade de clusters Amazon Aurora PostgreSQL.

    Sobre o Amazon Aurora

    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.

    Fonte

    Amazon Aurora now supports PostgreSQL 18.4, 17.10, 16.14, 15.18, and 14.23 (https://aws.amazon.com/about-aws/whats-new/2026/08/amazon-aurora-postgresql-18-4-17-10-16-14-15-18-14-23/)

  • Amazon EKS agora suporta múltiplos provedores de identidade OIDC externos por cluster

    O que mudou no Amazon EKS

    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.

    Para se aprofundar na configuração, a documentação oficial da AWS traz um guia detalhado: Conceder acesso a usuários no Kubernetes com um provedor OIDC externo, disponível no Amazon EKS User Guide.

    Fonte

    Amazon EKS now supports multiple external OIDC identity providers per cluster (https://aws.amazon.com/about-aws/whats-new/2026/08/amazon-eks-multiple-oidc-providers)

  • SageMaker MLflow agora suporta chaves gerenciadas pelo cliente

    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.

    O recurso já está em disponibilidade geral (generally available) em todas as regiões AWS onde o MLflow App está disponível. Para conhecer os detalhes técnicos e a documentação completa, a AWS disponibilizou a página de detalhes do SageMaker MLflow.

    Por que isso importa

    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.

    Fonte

    SageMaker MLflow now supports customer managed keys (https://aws.amazon.com/about-aws/whats-new/2026/08/sagemaker-mlflow-custom-keys)

  • CloudTroop Weekly #026 — 2026-w34





    CloudTroop Weekly #026 — 2026-w34

    23 de agosto de 2026

    Resumo da Semana

    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.

    Top 10 da Semana

    1

    Governe o acesso de agentes de IA com Bedrock AgentCore Gateway

    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.

    Segurança IA

    2

    Security Hub Extended adiciona Segurança da Cadeia de Suprimentos

    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.

    Supply Chain Security

    3

    AWS Glue 6.0: 30% mais barato com Iceberg v3 e Spark 4.1

    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.

    Engenharia de Dados

    4

    Propague contexto de autorização do usuário em agentes de IA

    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.

    Segurança IA

    5

    Reduza custos de RAG no Bedrock com compressão por consulta

    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.

    Otimização RAG

    6

    Amazon EKS suporta rotação automática de CA com rollback

    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.

    Kubernetes Segurança

    7

    3 padrões assíncronos para agentes IA em pipelines serverless

    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.

    Serverless IA

    8

    Atualização crítica de segurança do Amazon Corretto — Agosto 2026

    Patch de segurança crítico para todas as versões LTS do Corretto exige ação imediata de equipes que rodam Java em produção na AWS.

    Para quem: Engenheiros e SREs que utilizam Amazon Corretto em qualquer versão LTS em ambientes de produção.

    Patch Segurança

    9

    CloudFront OAC nativo para S3 Multi-Region Access Points

    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.

    Arquitetura Multi-Região

    10

    AgentCore Payments em GA: agentes de IA fazem pagamentos autônomos

    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.

    Agentes IA Pagamentos


  • AWS Glue 6.0 chega com redução de 30% no preço e suporte ao Iceberg v3

    O que mudou no AWS Glue 6.0

    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.

    Quem já possui jobs existentes pode migrá-los utilizando o Agente de Atualização do Spark. Para mais detalhes técnicos, a AWS disponibiliza a documentação oficial do AWS Glue e a página de preços do AWS Glue.

    Fonte

    AWS Glue 6.0 delivers 30% price reduction and Iceberg v3 support (https://aws.amazon.com/about-aws/whats-new/2026/08/aws-glue-6-0-price-reduction-iceberg-v3)

  • Governe o acesso de agentes de IA com o Amazon Bedrock AgentCore Gateway

    O problema que ninguém quer admitir

    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.

    Imagem original — fonte: Aws

    Escopo 1 — Connect: a porta governada mínima

    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 é:

    aws bedrock-agentcore-control create-gateway \
  --name pilot-gateway \
  --role-arn arn:aws:iam::<account-id>:role/GatewayRole \
  --protocol-type MCP \
  --authorizer-type CUSTOM_JWT \
  --authorizer-configuration '{
    "customJWTAuthorizer": {
      "discoveryUrl": "https://cognito-idp.<region>.amazonaws.com/<pool-id>/.well-known/openid-configuration",
      "allowedClients": ["pilot-gateway-client"]
    }
  }'

    O registro de um alvo Lambda como ferramenta MCP é feito assim:

    aws bedrock-agentcore-control create-gateway-target \
  --gateway-identifier pilot-gateway \
  --name TicketSearch \
  --target-configuration '{
    "mcp": {
      "lambda": {
        "lambdaArn": "arn:aws:lambda:<region>:<account-id>:function:ticket-search",
        "toolSchema": {"inlinePayload": "<tool-schema-json>"}
      }
    }
  }'

    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:

    {
  "contentPolicyConfig": {
    "filtersConfig": [{
      "type": "PROMPT_ATTACK",
      "inputStrength": "HIGH",
      "outputStrength": "NONE"
    }]
  },
  "sensitiveInformationPolicyConfig": {
    "piiEntitiesConfig": [
      { "type": "EMAIL", "action": "ANONYMIZE" },
      { "type": "US_SOCIAL_SECURITY_NUMBER", "action": "BLOCK" },
      { "type": "CREDIT_DEBIT_CARD_NUMBER", "action": "BLOCK" }
    ]
  }
}

    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.

    Imagem original — fonte: Aws

    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:

    # registry/tools/payment-refund.yaml
name: PaymentRefund
owner: payments-platform@example.com
target:
  type: lambda
  arn: arn:aws:lambda:us-west-2:<account-id>:function:payment-refund
access:
  allowed_groups: [finance-ops, senior-support]
  environments: [staging] # prod requires separate approval
risk_tier: high

    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:

    package mcp.tools
import rego.v1

default allow := false

allow if {
  input.tool == "db_write"
  clock := time.clock(time.now_ns())
  clock[0] >= 9
  clock[0] < 17
  weekday := time.weekday(time.now_ns())
  not weekday in {"Saturday", "Sunday"}
  input.claims.change_ticket_id != ""
}

    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:

    [
  {
    "Name": "gateway.example.com.",
    "Type": "CNAME",
    "SetIdentifier": "primary-us-west-2",
    "Failover": "PRIMARY",
    "TTL": 30,
    "HealthCheckId": "hc-0123456789abcdef0",
    "ResourceRecords": [{"Value": "dxxxxxxxxxxxxx.cloudfront.net"}]
  },
  {
    "Name": "gateway.example.com.",
    "Type": "CNAME",
    "SetIdentifier": "secondary-eu-west-1",
    "Failover": "SECONDARY",
    "TTL": 30,
    "ResourceRecords": [{"Value": "dyyyyyyyyyyyyy.cloudfront.net"}]
  }
]

    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:

    aws bedrock-agentcore-control delete-gateway --gateway-identifier pilot-gateway

    Veja DeleteGateway para a referência completa da API.

    Leituras complementares

    Fonte

    Govern AI agent tool access with Amazon Bedrock AgentCore Gateway (https://aws.amazon.com/blogs/machine-learning/govern-ai-agent-tool-access-with-amazon-bedrock-agentcore-gateway/)

  • Amazon Connect Customer permite que gestores conversem com seus dados em linguagem natural

    O que mudou no Amazon Connect Customer

    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.

    Fonte

    Amazon Connect Customer now lets managers chat with their data (https://aws.amazon.com/about-aws/whats-new/2026/08/amazon-connect-customer-ai-data-analytics)