User's blog

Author: Make.com Service User

  • Como construir aplicações de chat multi-tenant com Amazon Bedrock Managed Knowledge Base

    O problema que essa arquitetura resolve

    Permitir que usuários façam upload de documentos e conversem com eles em tempo real parece simples na superfície. A interface de chat é relativamente fácil de construir — o problema real está na camada de recuperação por trás dela, especialmente quando a aplicação precisa atender múltiplos usuários ao mesmo tempo.

    Em um ambiente multi-tenant, os documentos de cada usuário precisam ficar completamente isolados dos demais. Esse isolamento não pode depender de um valor enviado pelo cliente — ele precisa vir de uma identidade verificada no servidor. Quando você adiciona recuperação agêntica ao cenário, a complexidade aumenta: o agente decompõe uma pergunta em sub-consultas e executa múltiplas buscas em sequência, e cada um desses saltos precisa carregar o filtro correto do tenant. Se qualquer salto deixar de aplicar o filtro, o isolamento quebra.

    Além disso, a equipe ainda precisaria construir e operar um motor de busca vetorial e full-text, um pipeline de ingestão que processe múltiplos formatos e um índice sincronizado. É uma quantidade significativa de infraestrutura para quem quer apenas entregar um recurso de chat com documentos.

    A AWS publicou uma arquitetura de referência que endereça exatamente esse cenário usando o Amazon Bedrock Managed Knowledge Base.

    O que o Amazon Bedrock Managed Knowledge Base oferece aqui

    O serviço cuida da ingestão, armazenamento, embedding e ranqueamento dos documentos — sem infraestrutura para provisionar ou capacidade para monitorar. Ele também traz recuperação agêntica nativa, com planejamento iterativo e múltiplos saltos de busca para responder perguntas complexas, aplicando os filtros de acesso em cada etapa.

    Com a ingestão direta via conector customizado, a aplicação envia o documento direto para a knowledge base e ele fica disponível para consulta em segundos. Não é necessário configurar pipelines externos de ingestão nem gerenciar índices separados.

    Visão geral da solução

    A arquitetura apresentada pela AWS tem dois fluxos principais: ingestão de documentos e recuperação conversacional. Os componentes centrais são:

    • Amazon Bedrock Managed Knowledge Base: processa, armazena e recupera conteúdo multimodal, incluindo texto, vetores, metadados e arquivos estruturados como CSV e Excel. Um conector customizado recebe os uploads dos usuários diretamente.
    • Amazon API Gateway e AWS Lambda: expõem os endpoints de upload, status e chat, e executam a lógica da aplicação.
    • Amazon Cognito: autentica os usuários e fornece a identidade verificada que a aplicação usa para isolar os documentos de cada um.
    • Amazon Simple Queue Service (SQS): desacopla os uploads da ingestão, absorve picos e encaminha mensagens com falha repetida para uma fila de mensagens mortas (dead-letter queue), mantendo o endpoint de upload responsivo.
    • Amazon DynamoDB: rastreia o status de indexação de cada documento para que a aplicação mostre ao usuário quando ele está pronto para consulta.
    • Amazon Simple Storage Service (S3): armazena temporariamente arquivos maiores que o limite inline e hospeda a aplicação de página única (SPA) atrás do Amazon CloudFront.

    Como os dois fluxos funcionam

    Ingestão de documentos

    Quando um usuário faz upload de um documento, a aplicação extrai a identidade dele a partir do Token Web JSON (JWT) validado pelo API Gateway — nunca confia em um valor enviado diretamente pelo cliente. Essa identidade é incluída na mensagem enviada para a fila SQS junto com o documento ou sua referência no S3.

    Arquivos de até 6 MB são enviados inline na chamada de API. Arquivos maiores, até 50 MB para texto, são primeiro enviados ao S3 e a mensagem carrega o URI do S3 para que o Bedrock leia o arquivo diretamente de lá.

    Uma função Lambda worker lê a mensagem da fila, marca o documento com um atributo de metadados user_id igual ao identificador (sub) do usuário no Cognito, e então chama a API IngestKnowledgeBaseDocuments. O Amazon Bedrock fragmenta, faz o embedding e indexa o documento de forma assíncrona. O status de cada documento é registrado no DynamoDB, e o navegador consulta periodicamente um endpoint de status para atualizar a interface.

    Um detalhe importante sobre a ingestão direta via conector customizado: ao contrário do conector S3 — que é projetado para ingestão em lote com sincronizações agendadas e pode sobrescrever ou remover um documento recém-adicionado — a ingestão direta via IngestKnowledgeBaseDocuments não tem sincronização. O documento persiste até ser explicitamente deletado. Além disso, como a aplicação atribui seus próprios IDs de documento, reingeri-lo com o mesmo ID atualiza o registro no lugar, sem criar duplicatas.

    A knowledge base também mantém uma cópia do arquivo original recuperável via API GetDocumentContent, eliminando a necessidade de operar um repositório de documentos separado.

    Ciclo de vida da indexação

    A API de ingestão é assíncrona: ela retorna imediatamente com status STARTING, mas o documento só fica disponível para consulta depois que o Bedrock conclui o processamento. O ciclo passa por cinco estados:

    • STARTING: requisição aceita, processamento ainda não iniciado.
    • PENDING: na fila, aguardando um slot de processamento.
    • IN_PROGRESS: parsing e embedding em execução.
    • TEXT_INDEXED: fragmentos de texto indexados; para PDFs, o processamento multimodal ainda está em andamento. Já é possível consultar o texto.
    • INDEXED: processamento completo, incluindo elementos multimodais como imagens e tabelas em PDFs.

    A recomendação da AWS é marcar o documento como pronto ao atingir TEXT_INDEXED, e não esperar pelo INDEXED — a diferença só é relevante para conteúdo multimodal. Em testes com documentos pequenos (abaixo de 5 MB) em uma knowledge base ociosa, textos simples atingiram INDEXED em 2 a 3 segundos, enquanto PDFs chegaram a TEXT_INDEXED entre 5 e 30 segundos e a INDEXED em cerca de 90 segundos. Esses números são referências de ordem de grandeza para design, não garantias de latência.

    Isolamento por usuário com filtros de metadados

    Em uma aplicação multi-tenant, os documentos de um usuário nunca podem aparecer nos resultados de outro. A solução usa uma knowledge base compartilhada com filtros de metadados, em vez de provisionar uma knowledge base separada por tenant. Essa abordagem escala melhor para grandes volumes de usuários finais, evita custos de base de múltiplos índices pequenos e elimina a latência de criação de uma knowledge base no momento do cadastro.

    O worker marca cada documento com o atributo user_id, e a aplicação aplica um filtro de igualdade nesse atributo em cada consulta. O valor do filtro é construído no servidor a partir do JWT verificado — nunca a partir do corpo da requisição. Esse é o limite de segurança real da solução.

    A knowledge base tem a capacidade de inferir filtros a partir do texto da pergunta, mas isso é um recurso de relevância, não de controle de acesso. O isolamento precisa vir de um filtro explícito construído pela aplicação a partir da identidade autenticada. Como defesa em profundidade, a implementação de referência confirma que o filtro está correto antes de cada requisição e descarta qualquer fragmento retornado cujo user_id não corresponda ao do chamador.

    Para cargas de trabalho reguladas que exigem que o próprio serviço aplique o controle de acesso, a knowledge base também suporta listas de controle de acesso (ACLs) no nível do documento, avaliadas contra um userContext no momento da consulta.

    Recuperação e geração de respostas

    Para responder a uma pergunta, a aplicação chama a API AgenticRetrieveStream com o filtro explícito de user_id. A API executa um ciclo completo de chat: decompõe a pergunta em sub-consultas, executa as buscas com o filtro aplicado em cada salto e transmite uma resposta fundamentada com citações quando o parâmetro generateResponse está ativo. Isso se encaixa diretamente em uma interface de chat e oferece baixo tempo até o primeiro token sem que a equipe precise orquestrar recuperação e geração separadamente.

    Quando é necessário mais controle — como um prompt customizado por tenant ou um modelo específico — a recomendação é usar a API Retrieve para buscar os fragmentos e chamar a API Converse separadamente, passando o mesmo filtro por usuário.

    O histórico de conversa não é persistido entre chamadas pela API. A aplicação precisa armazená-lo em seu próprio repositório (como o DynamoDB) e passar os turnos relevantes em cada requisição. Isso também permite aplicar o mesmo isolamento por usuário ao histórico de conversas.

    Boas práticas para operar em escala

    • Desacople uploads da ingestão com uma fila. Para cargas baixas, é possível chamar a API de ingestão diretamente do handler de upload. Para qualquer aplicação com uploads concorrentes, use o SQS entre o endpoint de upload e a ingestão. O worker pode empacotar até 10 documentos em cada chamada de IngestKnowledgeBaseDocuments, o que é a principal alavanca de throughput. Por exemplo, 500 uploads simultâneos se transformam em aproximadamente 50 chamadas em lote.
    • Planeje para o limite de ingestão, não de recuperação. A API Retrieve suporta picos de 25 consultas por segundo (QPS) ou 10 QPS sustentados por knowledge base — raramente será o gargalo. O throughput de ingestão é adequado para uploads interativos, mas uma migração em massa de um repositório existente vai saturá-lo. Para esses cenários, use o conector S3 com sincronização agendada, que é projetado para cargas grandes de uma vez só.
    • Trate o limite de concorrência como condição de retry. Ao exceder o limite, o Bedrock retorna ValidationException, não ThrottlingException. Um classificador de retry que só trata throttling vai interpretar isso como erro fatal e descartar o documento.
    • Monitore os sinais que antecipam o teto. Acompanhe a taxa de sucesso da ingestão e o tempo para atingir INDEXED nos percentis P50 e P99. Um tempo crescente para INDEXED é o primeiro indicador de que o pipeline de ingestão está se aproximando do limite de throughput — bem antes de as requisições começarem a falhar.
    • Persista o histórico de conversa você mesmo. A API AgenticRetrieveStream aceita turnos anteriores no parâmetro messages para suporte a contexto multi-turno, mas não os persiste entre chamadas. Armazene o histórico em seu próprio repositório e passe os turnos relevantes em cada requisição.

    Custos

    O custo da solução depende da configuração de modelos escolhida. Com modelos gerenciados, o Managed Knowledge Base é cobrado apenas por armazenamento e recuperação (por chamada, não por token), sem custo adicional de ingestão. Se você selecionar um modelo Amazon Bedrock, paga pelos tokens de embedding na ingestão e pelos tokens de orquestração e geração na recuperação agêntica. Os serviços de suporte (Lambda, API Gateway, SQS, DynamoDB e S3) representam uma fração pequena do custo total em escala moderada. Consulte a página de preços do Amazon Bedrock para os valores atuais.

    Como começar

    A AWS disponibilizou um repositório de exemplo no GitHub para quem quiser implantar a solução na própria conta e usá-la como base para uma aplicação de chat com documentos. Para se aprofundar no Amazon Bedrock Managed Knowledge Base, a AWS também publicou posts complementares sobre busca empresarial para agentes com Amazon Bedrock Managed Knowledge Base e sobre recuperação agêntica no Amazon Bedrock Managed Knowledge Base.

    Fonte

    Build multi-tenant agentic chat applications on enterprise data with Amazon Bedrock Managed Knowledge Base (https://aws.amazon.com/blogs/machine-learning/build-multi-tenant-agentic-chat-applications-on-enterprise-data-with-amazon-bedrock-managed-knowledge-base/)

  • Recuperação Agnética Observável com Amazon Bedrock Knowledge Base e AWS CloudFormation

    Do RAG clássico à recuperação agnética empresarial

    Equipes que adicionam Geração Aumentada por Recuperação (RAG) a um modelo de fundação geralmente começam com uma única etapa de recuperação em uma única base de conhecimento. Isso funciona bem enquanto as perguntas são simples — mas começa a falhar quando a resposta está distribuída em múltiplas fontes ou quando o sistema precisa decidir qual fonte consultar antes de responder.

    A recuperação agnética empresarial resolve esse problema: um agente raciocina sobre a pergunta, direciona a consulta para a base de conhecimento correta, recupera informações de forma iterativa e retorna uma resposta fundamentada com citações. Mas essa abordagem introduz um desafio operacional mais complexo — uma vez que o agente raciocina e recupera em loop, fica difícil enxergar o que ele fez e se a resposta foi de boa qualidade.

    Um post anterior da AWS automatizou um fluxo RAG de passo único com uma Knowledge Base autogerenciada (baseada em vector store). Agora, o Amazon Bedrock Knowledge Bases evoluiu para a recuperação agnética com o lançamento das Managed Knowledge Bases. A API AgenticRetrieveStream das Managed Knowledge Bases realiza planejamento em múltiplos turnos, executa ferramentas de recuperação e gera respostas fundamentadas com citações.

    A AWS publicou uma solução que vai além: um sistema de recuperação agnética empresarial onde um agente raciocina, recupera informações em múltiplas bases de conhecimento e sintetiza uma resposta citada. A solução é construída sobre o Amazon Bedrock Managed Knowledge Base e o Amazon Bedrock AgentCore, com observabilidade e avaliação integradas desde o início — e implantada com uma única cadeia de stacks do AWS CloudFormation.

    Como a solução funciona

    O fluxo de trabalho da solução segue estas etapas:

    • Um usuário envia uma pergunta ao agente hospedado no Amazon Bedrock AgentCore runtime. O runtime auto-instrumenta cada etapa com spans OpenTelemetry, tornando o loop de raciocínio e ação observável desde a primeira chamada.
    • O modelo de raciocínio do agente planeja a tarefa e realiza o roteamento entre bases de conhecimento: dado uma ferramenta de recuperação por base de conhecimento, ele seleciona a ferramenta cujo tópico corresponde à pergunta (financeiro ou clima).
    • A chamada de ferramenta selecionada é intermediada pelo Amazon Bedrock AgentCore Gateway via Protocolo de Contexto de Modelo (MCP), que invoca a API AgenticRetrieveStream da Managed Knowledge Base correspondente.
    • O AgenticRetrieveStream decompõe a pergunta em subconsultas, recupera iterativamente do armazenamento gerenciado (ingerido de corpora no Amazon S3) e sintetiza uma resposta fundamentada e citada que flui de volta ao agente via Gateway.
    • O agente verifica se o contexto retornado é suficiente. Se não, recupera novamente em outra iteração do loop antes de compor sua resposta final. Se sim, retorna a resposta citada ao usuário.
    • Durante todo o processo, o runtime emite spans, uso de tokens e métricas para o Amazon CloudWatch e AWS X-Ray, alimentando as sete camadas de observabilidade e os scores de avaliação sob demanda e contínua.

    Managed Knowledge Base vs. Knowledge Base autogerenciada

    O Amazon Bedrock agora oferece uma Managed Knowledge Base (Tipo: MANAGED): a AWS gerencia a ingestão, armazenamento, indexação e recuperação automaticamente — incluindo embedding e reranking com modelos gerenciados pelo serviço por padrão. Isso significa que não há banco de dados vetorial para provisionar, escalar ou corrigir.

    A tabela abaixo resume as diferenças principais entre os dois tipos:

    • Recuperação agnética (AgenticRetrieveStream): disponível apenas na Managed; não suportada na autogerenciada.
    • Integração com AgentCore Gateway: disponível apenas na Managed.
    • Armazenamento de dados: auto scaling totalmente gerenciado pela AWS na Managed; você provisiona, escala e mantém na autogerenciada.
    • Embedding + reranking: modelos gerenciados embutidos na Managed (com opção de selecionar outros modelos disponíveis no Amazon Bedrock); você configura na autogerenciada.
    • Infraestrutura para gerenciar: nenhuma na Managed; banco de dados vetorial e mais na autogerenciada.

    Visão geral da solução: quatro stacks CloudFormation

    A solução é implantada como quatro stacks nativas do AWS CloudFormation, cada uma conectando suas saídas à próxima:

    • 01-knowledge-bases: cria um bucket no Amazon S3, duas Managed Knowledge Bases (um corpus financeiro e um de clima, para que o agente tenha algo para rotear), suas fontes de dados e configurações de Gerenciamento de Identidade e Acesso (IAM), além de um recurso customizado de ingestão que faz upload dos documentos e executa a primeira sincronização.
    • 02-agentic-gateway: provisiona um Amazon Bedrock AgentCore Gateway (autenticação AWS_IAM, MCP) com um alvo por base de conhecimento construído sobre o conector nativo bedrock-knowledge-bases, para que cada base exponha sua própria ferramenta AgenticRetrieveStream sem nenhuma função AWS Lambda ou contêiner extra.
    • 03-agent-runtime: provisiona um repositório no Amazon Registro de Contêineres Elástico (ECR), um projeto AWS CodeBuild que constrói uma imagem de agente Strands instrumentada com OpenTelemetry, o Amazon Bedrock AgentCore runtime que a hospeda, o roteamento de entrega de logs e rastreamentos, e a configuração de avaliação online.
    • 04-dashboards: cria os dois dashboards do Amazon CloudWatch.

    Os datasets da solução

    A solução inclui dois pequenos corpora sintéticos no repositório, na pasta data/:

    • Financeiro: um relatório 10-K sintético da empresa fictícia Octank Financial (octank_financial_10K.pdf, ~198 KB).
    • Clima: um relatório real e publicamente disponível do Serviço de Pesquisa do Congresso dos EUA sobre tornados (IF12695, tornadoes_report.pdf, ~560 KB).

    Os dois corpora são intencionalmente distintos para que o agente precise rotear cada pergunta para a base de conhecimento correta — essa é a proposta de roteamento semântico. A solução usa duas bases de conhecimento separadas em vez de uma única com duas fontes de dados de propósito: cada base é exposta como sua própria ferramenta de recuperação, então o agente toma uma decisão real de roteamento entre elas. Uma única base com duas fontes de dados daria ao agente apenas uma ferramenta, sem roteamento a demonstrar e com os sinais por corpus misturados.

    Por serem Managed Knowledge Bases, não é necessário configurar chunking, embedding ou índice. Na ingestão, o Amazon Bedrock analisa cada PDF, divide em chunks, gera embeddings com seu modelo gerenciado e indexa automaticamente.

    Implantando a solução

    A implantação requer os seguintes pré-requisitos:

    Com os pré-requisitos prontos, a implantação é feita com três comandos:

    git clone https://github.com/aws-samples/amazon-bedrock-samples.git
cd rag/managed-knowledge-bases/07-IaaC/managed-kb-observability-cfn/
./scripts/deploy.sh us-west-2 bmkb-ml21427

    O script implanta os quatro stacks em ordem, conectando as saídas para frente e reportando cada etapa. O stack 03-agent-runtime constrói o contêiner do agente com o CodeBuild, então aguarde aproximadamente 8 a 10 minutos para essa etapa. Ao final, todos os quatro stacks estarão com status CREATE_COMPLETE.

    As sete camadas de observabilidade

    Cada camada responde a uma pergunta operacional diferente e, juntas, cobrem o agente de ponta a ponta. As camadas 1, 4 e 5 são emitidas automaticamente. As camadas 3, 6 e 7 são publicadas como métricas customizadas pelo notebook de driver.

    • L1 — Métricas nativas da Knowledge Base: invocações, erros e throttles por KB. Cada base de conhecimento está saudável e atendendo tráfego?
    • L2 — Ingestão: status do job de ingestão e resultados por documento. Os documentos chegaram à base de conhecimento?
    • L3 — Qualidade da recuperação agnética: utilização sem referência, cobertura fundamentada, taxa de duplicatas. O agente está recuperando contexto relevante e bem fundamentado?
    • L4 — Métricas do Gateway / MCP: volume e latência das chamadas de ferramentas do Gateway. A camada de ferramentas de recuperação é rápida e confiável?
    • L5 — Árvore de spans OTEL: o rastreamento completo de raciocínio e ação do agente. O que o agente fez, passo a passo?
    • L6 — Uso de tokens: tokens gen_ai.usage por sessão e modelo. Quanto cada consulta custa em tokens?
    • L7 — Scores de avaliação: correção, fidelidade, seleção de ferramenta, relevância da resposta. As respostas são realmente boas?

    A solução provisiona dois dashboards do CloudWatch cobrindo essas sete camadas. O Dashboard A cobre a observabilidade agnética de ponta a ponta — para N consultas, você vê aproximadamente N invocações do agente, 2N recuperações, 3N chamadas de LLM e 5N operações MCP do Gateway, tornando o loop agnético visível. O Dashboard B cobre a observabilidade por base de conhecimento: tamanho do índice, volume de recuperação, chamadas de ferramentas agnéticas e uso de tokens por modelo.

    Avaliação: sob demanda e contínua

    A qualidade é medida de duas formas, e ambas são provisionadas pelo stack:

    Sob demanda: o notebook de driver chama o AgentCore Evaluate (LLM como juiz) sobre os spans de cada sessão para avaliadores embutidos (Correção, Fidelidade, Precisão de Seleção de Ferramenta) e publica os scores no CloudWatch, onde aparecem como Camada 7 no Dashboard A.

    Contínua (online): o stack 03-agent-runtime também provisiona um AWS::BedrockAgentCore::OnlineEvaluationConfig que amostra sessões ao vivo e as pontua automaticamente. Os resultados aparecem no console em CloudWatch > GenAI Observability > Bedrock AgentCore > Evaluations, sem necessidade de executar o notebook. A configuração lista os avaliadores: Precisão de Seleção de Ferramenta, Fidelidade, Correção e Relevância da Resposta.

    ⚠️ Amostragem e custo: a solução define SamplingPercentage: 100 apenas para o experimento do post, para que cada sessão seja pontuada e os resultados sejam imediatamente visíveis. Isso não é uma recomendação para produção. A avaliação online invoca um LLM como juiz por sessão amostrada, então o custo escala com a taxa de amostragem e o volume de tráfego. Para um deployment real, escolha uma porcentagem que se encaixe nas suas necessidades de monitoramento de qualidade e orçamento. A taxa é uma única propriedade (OnlineEvaluationConfig.Rule.SamplingConfig.SamplingPercentage) no arquivo templates/03-agent-runtime.yaml.

    Um padrão comum é usar avaliação sob demanda durante a iteração e habilitar a avaliação contínua com uma porcentagem de amostragem modesta quando o agente estiver atendendo usuários reais.

    Limpeza do ambiente

    Para remover todos os recursos em ordem reversa de dependência, basta executar:

    ./scripts/cleanup.sh us-west-2 bmkb-ml21427

    Casos de uso e próximos passos

    Esse padrão é adequado para cargas de trabalho onde a resposta correta está em mais de um lugar e o sistema precisa escolher onde procurar. Exemplos incluem:

    • Um assistente de suporte que roteia entre uma base de conhecimento de documentação de produto e uma base de cobrança.
    • Um assistente de pesquisa que abrange corpora regulatórios e científicos separados.
    • Um helpdesk interno que mantém conteúdo de RH, TI e finanças em bases de conhecimento isoladas para separação de acesso e custos.

    A partir daqui, é possível apontar as fontes de dados para seus próprios corpora, colocar o agente em uma Nuvem Privada Virtual (VPC), ajustar a taxa de amostragem da avaliação online conforme seu orçamento e políticas, ou adicionar mais bases de conhecimento ao roteador. Os templates, o notebook de driver e os utilitários estão disponíveis no repositório. As instruções detalhadas para conduzir tráfego e observar os dashboards estão no README da solução.

    Fonte

    Build observable enterprise agentic retrieval using Managed Amazon Bedrock Knowledge Base with AWS CloudFormation (https://aws.amazon.com/blogs/machine-learning/build-observable-enterprise-agentic-retrieval-using-managed-amazon-bedrock-knowledge-base-with-aws-cloudformation/)

  • Amazon Redshift passa a suportar autenticação via AWS IAM Identity Center com roteamento VPC aprimorado

    O que foi anunciado

    A AWS anunciou que o Amazon Redshift passou a suportar autenticação via AWS IAM Identity Center em clusters provisionados e grupos de trabalho serverless configurados com Roteamento VPC Aprimorado (EVR — Enhanced VPC Routing). A novidade permite que usuários acessem o Redshift por meio de login único (SSO — Single Sign-On) utilizando suas credenciais corporativas, com todo o tráfego passando pela Nuvem Privada Virtual da Amazon (VPC — Amazon Virtual Private Cloud) e permanecendo dentro da rede AWS.

    Por que isso importa

    Para equipes que lidam com requisitos regulatórios, residência de dados ou isolamento de rede, essa combinação é especialmente relevante: com o EVR ativo, nenhum tráfego entre o warehouse do Redshift e outros serviços AWS sai pela internet pública. Todo o fluxo passa pela VPC, onde é possível governá-lo com grupos de segurança, listas de controle de acesso de rede (ACLs) e políticas de endpoint, além de monitorá-lo via VPC Flow Logs.

    Como funciona a autenticação com IAM Identity Center e EVR

    Com esse lançamento, o Redshift passa a validar e trocar tokens do IAM Identity Center por meio de endpoints de interface VPC via AWS PrivateLink, diretamente de dentro da VPC. Isso significa que o processo de autenticação e autorização segue o mesmo caminho de rede controlado que já era aplicado ao restante do tráfego do Redshift — sem exceções ou desvios pela internet.

    Suporte a replicação multi-região

    O recurso também contempla a replicação multi-região do IAM Identity Center, atendendo clientes que executam o Redshift em uma região diferente da instância primária do Identity Center. Essa flexibilidade é importante para arquiteturas distribuídas geograficamente que precisam manter a governança centralizada de identidade.

    Disponibilidade

    A funcionalidade está disponível em todas as regiões AWS onde tanto o Amazon Redshift quanto o IAM Identity Center estão presentes.

    Saiba mais

    Para quem quiser se aprofundar, a AWS disponibiliza a documentação oficial sobre o roteamento VPC aprimorado do Amazon Redshift e um post detalhado no blog da AWS explicando a integração entre o Redshift e o IAM Identity Center com EVR.

    Fonte

    Amazon Redshift now supports AWS IAM Identity Center authentication with enhanced VPC routing (https://aws.amazon.com/about-aws/whats-new/2026/08/amazon-redshift-supports-idc-evr)

  • A AWS convidou um concorrente direto para o Security Hub Extended — e explica o porquê

    Quando o cliente aponta para o concorrente

    Existe um momento delicador para qualquer empresa de tecnologia: quando os próprios clientes recomendam uma solução que compete diretamente com algo que você já oferece. A AWS passou por isso com a Upwind — e, em vez de ignorar o sinal, decidiu trazer a empresa para dentro do AWS Security Hub Extended.

    A lógica é direta: o Security Hub Extended foi criado porque os clientes disseram o que funcionava para eles em segurança corporativa e pediram que a AWS simplificasse a adoção e a integração dessas ferramentas. A Upwind era um dos nomes que aparecia repetidamente nessas conversas. Então a AWS a trouxe para o programa.

    O que é o Security Hub Extended

    O Security Hub Extended é uma camada do AWS Security Hub que reúne soluções de segurança de terceiros dentro da mesma experiência comercial e operacional que os clientes já usam na AWS. A proposta é eliminar a fricção de compra, integração e operação: uma única fatura, suporte unificado e sem necessidade de construir integrações customizadas.

    Dentro do programa, os parceiros precisam ir além de um simples acordo — precisam comprometer engenharia, equipe comercial e modelo de precificação. A Upwind fez exatamente isso: trouxe todo o seu portfólio de soluções ao Extended com precificação pay-as-you-go desde o primeiro dia e alinhou sua equipe de vendas para atuar em negócios conjuntos com a AWS.

    Quem é a Upwind e o que a diferencia

    A Upwind é uma empresa de segurança de nuvem usada por companhias como Siemens, Peloton, Roku, Wix, Nextdoor e Nubank. A Fast Company a elegeu uma das empresas mais inovadoras de 2026.

    O diferencial técnico da Upwind está no conceito de proteção baseada em runtime. A maioria das soluções de segurança em nuvem analisa configurações periodicamente e reporta o que poderia ser um risco — uma abordagem estática de postura. A Upwind funciona de forma diferente: ela implanta um sensor baseado em eBPF diretamente no kernel Linux, que observa em tempo real o que as cargas de trabalho estão fazendo — comportamento de processos, conexões de rede, chamadas de API e interações entre contêineres.

    Isso significa que a Upwind não apenas aponta o que poderia ser explorado teoricamente, mas identifica o que está ativamente em risco agora. Essa distinção reduz drasticamente o volume de alertas e permite que as equipes de segurança foquem no que realmente importa.

    Escolha do cliente, não da AWS

    A AWS deixa claro que o princípio central do programa é a escolha do cliente:

    • Quem prefere gerenciamento de postura de segurança em nuvem e varredura de vulnerabilidades pode optar pelo Security Hub Essentials.
    • Quem prioriza proteção baseada em runtime pode escolher a Upwind.
    • Quem quiser os dois ao mesmo tempo pode combinar as soluções e obter resultados ainda mais robustos.

    A decisão é do cliente — não da AWS. Esse princípio vale para todos os parceiros do Security Hub Extended.

    Melhor juntos: o ecossistema integrado

    Uma das propostas mais interessantes do Security Hub Extended é a integração entre os próprios parceiros do programa. Um cliente que já usa outras soluções do Extended pode combiná-las sem precisar construir integrações manualmente.

    Um exemplo concreto mencionado pela AWS: um cliente que usa Chainguard para segurança da cadeia de suprimentos de software, Upwind para proteção em runtime e Splunk para operações de segurança obtém uma experiência conectada. A Chainguard garante dependências limpas e resistentes a malware na fase de build. A Upwind valida o comportamento das cargas de trabalho em tempo de execução e enriquece os achados com contexto em tempo real. Tudo flui para o Splunk via Security Hub para triagem unificada — uma fatura, sem trabalho de integração customizada.

    O mesmo padrão se aplica com o 7AI, onde automação baseada em IA pode fazer triagem e investigação de eventos de runtime da Upwind junto com sinais de endpoint, identidade e rede, sem trabalho manual de pipeline.

    Os achados fluem pelo Security Hub no formato OCSF (Open Cybersecurity Schema Framework — Estrutura de Esquema Aberto para Cibersegurança), são correlacionados e priorizados em conjunto, e roteados para as ferramentas que a equipe já utiliza.

    Como funciona comercialmente

    A AWS destaca que não se trata de uma parceria apenas no papel. Negócios de múltiplos milhões de dólares já foram fechados por meio do Security Hub Extended com a Upwind.

    Um caso mencionado: uma empresa enterprise substituiu sua solução anterior de CNAPP (Plataforma de Proteção de Aplicações Nativas de Nuvem) pela Upwind por meio de uma Private Offer do Security Hub Extended. Os fatores decisivos foram a visibilidade em runtime que a solução anterior não entregava e um modelo comercial previsível que substituiu a precificação complexa por módulo de múltiplos fornecedores.

    A Upwind está disponível no Security Hub Extended com:

    • Precificação pay-as-you-go
    • Cobrança unificada na fatura AWS
    • Sem compromisso de longo prazo obrigatório
    • Opção de Private Offers para empresas que preferem contratos com preços comprometidos e descontos maiores, com possibilidade de agregar gastos entre parceiros

    O que a Upwind está construindo a seguir

    A AWS também compartilhou o roadmap de expansão da Upwind dentro do programa:

    • Proteção de cargas de trabalho de IA: monitoramento do comportamento de modelos e chamadas de ferramentas de agentes em tempo de execução.
    • Cobertura de VMs Windows Server na AWS, Azure e GCP.
    • Integração mais profunda com o mecanismo de correlação do Security Hub, para que o contexto de runtime enriqueça automaticamente a inteligência de caminhos de ataque.

    O que isso significa na prática

    Para quem já usa o Security Hub para gerenciamento de postura e varredura de vulnerabilidades, adicionar a Upwind significa ganhar visibilidade em runtime sem precisar configurar novas ferramentas ou aprender novos fluxos de trabalho. A solução aparece na visão priorizada de riscos que o time já conhece.

    A Upwind pode ser habilitada diretamente pelo console do AWS Security Hub, com precificação pay-as-you-go e sem compromisso inicial. Para entender como consolidar o stack de segurança com o Security Hub Extended, a recomendação é conversar com o time de conta AWS.

    Fonte

    We invited a direct competitor into Security Hub Extended. Here’s why. (https://aws.amazon.com/blogs/security/we-invited-a-direct-competitor-into-security-hub-extended-heres-why/)

  • Como conectar um servidor MCP hospedado no AgentCore Runtime ao Amazon Quick

    MCP e o papel dos servidores de contexto para agentes de IA

    O Protocolo de Contexto de Modelo (MCP) permite que modelos de fundação acessem dados externos e ferramentas de forma padronizada e segura — incluindo arquivos, bancos de dados e APIs. Com isso, agentes de IA ganham a capacidade de interagir com aplicações reais, reduzir alucinações com contexto preciso e manter conversas com múltiplos turnos e estado persistente. Não é à toa que arquiteturas de IA agêntica adotaram o MCP como padrão do setor rapidamente.

    O Amazon Quick já suporta integrações MCP para execução autônoma, acesso a dados em tempo real e integração com sub-agentes especializados. Se você já tem um servidor MCP, pode usar o guia de integração oficial para conectá-lo ao Amazon Quick. Se ainda não tem, a AWS disponibilizou um guia para implantação de servidores MCP na AWS, seguindo os pilares do AWS Well-Architected.

    Opções de arquitetura para hospedar seu servidor MCP

    Dependendo do seu caso de uso, a AWS oferece três caminhos principais:

    • Se você já tem uma API REST própria ou rodando no Amazon API Gateway, pode integrar o Amazon Quick diretamente via Amazon Bedrock AgentCore Gateway.
    • Se prefere uma arquitetura serverless com o mínimo necessário, pode criar uma função AWS Lambda e integrá-la ao Amazon Quick via AgentCore Gateway.
    • Se precisa de uma solução gerenciada completa — com isolamento de sessão, tempo de execução estendido, sistema de arquivos persistente, autenticação integrada, observabilidade, streaming bidirecional e avaliações — a opção é usar o AgentCore Runtime para hospedar o servidor MCP e conectá-lo ao Amazon Quick via AgentCore Gateway.

    Este artigo cobre exatamente esse terceiro caminho: do servidor MCP local até uma ferramenta autenticada e disponível dentro do seu agente de chat no Amazon Quick.

    Visão geral da solução

    Atualmente, o Amazon Quick pode ser usado via navegador ou aplicativo desktop, com agentes de chat ou Flows que oferecem capacidades de IA agêntica. Para conectar o agente ao servidor MCP, a integração é feita via conectores no lado do Amazon Quick e via AgentCore Gateway no lado do AgentCore.

    O AgentCore Gateway e o Runtime fazem parte do Amazon Bedrock AgentCore, um serviço totalmente gerenciado para construção de aplicações de IA generativa. O fluxo de autorização do Amazon Quick para o AgentCore Gateway é chamado de Inbound Auth (autenticação de entrada), e o fluxo do Gateway para o Runtime é chamado de Outbound Auth (autenticação de saída).

    • Inbound Auth: autentica e autoriza o usuário a acessar o servidor MCP. O exemplo usa Amazon Cognito, mas outros provedores de identidade também são suportados.
    • Outbound Auth: lida com autenticação máquina a máquina usando o AgentCore Identity, um serviço de gerenciamento de identidade e acesso criado especificamente para agentes de IA. O protocolo MCP exige OAuth 2.0 para autenticação, portanto o Outbound Auth usa OAuth 2.0.

    Pré-requisitos

    Antes de começar, é necessário ter:

    • Uma conta AWS.
    • Amazon Quick configurado com assinatura Author ou superior.
    • Permissão para criar funções e políticas do Gerenciamento de Identidade e Acesso da AWS (IAM) e recursos para AgentCore, Amazon Cognito e Amazon CloudWatch.
    • Conhecimento básico dos serviços AWS.
    • Ambiente de linha de comando com AWS SDK e Python instalados.
    • Python 3.10+, credenciais AWS configuradas, SDK do Amazon Bedrock AgentCore, biblioteca MCP e Docker em execução.
    • Acesso ao Amazon Bedrock com modelos Anthropic habilitados.

    Passo 1 — Implementar e implantar o servidor MCP no AgentCore Runtime

    O primeiro passo é criar e implantar um servidor MCP de exemplo no AgentCore Runtime. O código completo está disponível no notebook de exemplos do AgentCore no GitHub. A estrutura básica do projeto é:

    mcp_server_project/
├── mcp_server.py        # Código principal do servidor MCP
├── requirements.txt     # Dependências
└── __init__.py          # Marcador de pacote Python

    O arquivo requirements.txt deve conter:

    mcp>=1.10.0
boto3
bedrock-agentcore
bedrock-agentcore-starter-toolkit>=0.1.21
strands-agents

    Para instalar as dependências:

    uv venv sample-venv                  # Criar ambiente virtual
source sample-venv/bin/activate      # Ativar ambiente virtual
uv pip install -r requirements.txt   # Instalar dependências

    Um exemplo mínimo de servidor MCP (sample_mcp_server.py), conforme descrito pela AWS — para detalhes sobre configuração segura de autenticação, consulte o artigo Building a secure auth code flow setup using AgentCore Gateway with MCP clients:

    from mcp.server.fastmcp import FastMCP

mcp = FastMCP(host="0.0.0.0", stateless_http=True)

@mcp.tool()
def getOrder() -> int:
    """Get an order"""
    return 123

@mcp.tool()
def updateOrder(orderId: int) -> int:
    """Update existing order"""
    return 456

if __name__ == "__main__":
    mcp.run(transport="streamable-http")

    O servidor usa FastMCP com stateless_http=True, obrigatório para compatibilidade com o AgentCore Runtime. O decorador @mcp.tool() transforma funções Python em ferramentas MCP. Quando o AgentCore Runtime é configurado com o protocolo MCP, o serviço espera que os containers do servidor MCP estejam disponíveis no caminho 0.0.0.0:8000/mcp.

    Com o servidor testado localmente, é hora de implantar no AgentCore Runtime usando o starter kit do AgentCore. No terminal, com o diretório do projeto como diretório atual:

    agentcore configure --entrypoint mcp_server.py --name simple_mcp_server

    Esse comando gera automaticamente um Dockerfile, um arquivo .dockerignore e um arquivo de configuração .bedrock_agentcore.yaml. Em seguida, para implantar:

    agentcore launch

    Após a execução, o servidor MCP estará visível no Runtime.

    Passo 2 — Integrar o servidor MCP ao AgentCore Gateway

    O AgentCore Gateway atua como a ponte segura entre o Amazon Quick e o servidor MCP implantado. A configuração envolve quatro sub-etapas. Para configuração programática, consulte o tutorial de MCP server como target no GitHub.

    2a — Criar uma função IAM para o AgentCore Gateway

    No Console de Gerenciamento da AWS, acesse IAM e crie uma nova função selecionando Amazon Bedrock AgentCore como caso de uso. Anexe a seguinte política inline de permissões:

    {
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "MCPServerRuntimePermissions",
      "Effect": "Allow",
      "Action": [
        "bedrock-agentcore:InvokeAgentRuntime",
        "bedrock-agentcore:InvokeRegistryMcp",
        "secretsmanager:GetSecretValue"
      ],
      "Resource": [
        "arn:aws:bedrock-agentcore:::runtime/",
        "arn:aws:bedrock-agentcore:::runtime//runtime-endpoint/*"
      ]
    }
  ]
}

    Use o nome de exemplo agentcore-sample-mcpgateway-role (ou escolha o seu). Em Resource, substitua pelos valores do ARN do servidor MCP implantado no AgentCore Runtime.

    2b — Criar um user pool do Amazon Cognito para Inbound Auth

    Acesse o Amazon Cognito e crie um novo user pool para a camada de autorização de entrada, que valida as requisições vindas do Amazon Quick antes de chegarem ao Gateway. Configure um servidor de recursos com o escopo personalizado protegido invoke. Anote o Client ID, Client Secret e a Discovery URL do formato: https://cognito-idp.{REGION}.amazonaws.com/{gw_user_pool_id}/.well-known/openid-configuration.

    2c — Criar um user pool do Amazon Cognito para Outbound Auth

    Crie um segundo user pool no Amazon Cognito para a camada de autorização de saída, permitindo que o Gateway se autentique ao fazer chamadas para o servidor MCP no AgentCore Runtime. Configure também um servidor de recursos com escopo invoke e anote as mesmas informações (Client ID, Client Secret e Discovery URL).

    Em seguida, crie um provedor de credencial OAuth no AgentCore Identity: acesse Amazon Bedrock AgentCore, escolha Identity, selecione Add Outbound Auth e Create OAuth Client. Preencha com a Discovery URL, Client ID e Client Secret do user pool de Outbound Auth.

    2d — Criar o AgentCore Gateway

    Acesse Amazon Bedrock AgentCore, escolha Gateway e crie um novo gateway (no exemplo, nomeado ac-gateway-mcp-server). Para o Inbound Auth, selecione JWT como tipo de autenticação e forneça a Discovery URL e o Client ID do user pool criado no passo 2b. Na seção de permissões, use a função IAM do passo 2a.

    Na seção Target, registre o servidor MCP como alvo. Selecione OAuth Client como tipo de autorização (o protocolo MCP não suporta outros métodos neste momento). A URL do endpoint MCP segue o template:

    https://bedrock-agentcore.us-east-1.amazonaws.com/runtimes/{encoded_agentcore_runtime_mcp_server_arn}/invocations?qualifier=DEFAULT

    Substitua encoded_agentcore_runtime_mcp_server_arn pelo ARN do seu servidor MCP codificado em URL. Para o Outbound Auth, use o OAuth client criado no passo 2c. Aguarde o Gateway e seu Target atingirem o estado Ready antes de prosseguir.

    Passo 3 — Registrar a integração MCP no Amazon Quick

    No Amazon Quick, acesse Connectors e escolha Create for your team. Selecione Model Context Protocol (MCP) como tipo de integração. Forneça um nome, descrição e o MCP Server Endpoint (a Resource URL do AgentCore Gateway criado no passo 2d). Também é possível escolher conectividade VPC privada para restringir a visibilidade do servidor MCP na rede.

    Na tela de autenticação, preencha os detalhes do Inbound Auth configurado no Gateway. Selecione o tipo de autenticação conforme seu caso de uso: User authentication (para autenticar usuários individuais) ou Service authentication (para integrações mais sistemáticas). O tutorial da AWS usa User authentication com Amazon Cognito.

    Preencha Client ID, Client Secret, Token URL e Authorization URL. Para a Token URL, use o template abaixo — atenção: o underscore no ID do user pool deve ser removido (por exemplo, us-west-2_qNBcTlLbR vira us-west-2qNBcTlLbR):

    https://{user_pool_id_without_underscore}.auth.{REGION}.amazoncognito.com/oauth2/token

    Para a Authorize URL, use a mesma URL substituindo token por authorize. Após criar a integração, aguarde o status da Action ficar como Available ou Ready — isso indica que as ferramentas foram sincronizadas com o servidor MCP.

    Passo 4 — Testar a integração no Amazon Quick

    Com a integração configurada, é possível escolher Test Action APIs para verificar se as ferramentas MCP estão acessíveis e funcionando. Em seguida, adicione a integração como uma Action no seu agente de chat ou Flow. Para o tutorial da AWS, cria-se um agente de chat de exemplo, vincula-se a integração na seção Actions e testa-se diretamente no chat antes de publicar o agente.

    Passo 5 — Limpeza dos recursos

    Para evitar custos desnecessários, exclua os recursos criados na ordem inversa à da criação. Você também pode consultar o código de limpeza no notebook do tutorial no GitHub. A ordem recomendada é:

    1. Agente de chat ou Flow no Amazon Quick
    2. Action no Amazon Quick
    3. AgentCore Gateway
    4. Recursos do AgentCore Identity
    5. User pools do Amazon Cognito (Inbound e Outbound Auth)
    6. AgentCore Runtime
    7. Função IAM do AgentCore Gateway

    Conclusão

    O padrão descrito pela AWS demonstra como o Amazon Quick pode ser integrado a servidores MCP personalizados hospedados no Amazon Bedrock AgentCore Runtime. A abordagem cobre desde a implantação do servidor MCP até a segurança com autenticação de entrada e saída via Amazon Cognito e AgentCore Identity, passando pela ponte com o Amazon Quick por meio do AgentCore Gateway.

    O principal benefício é a reutilização de ferramentas e agentes de IA entre equipes: em vez de criar conectores personalizados para cada caso de uso, as capacidades especializadas são expostas por uma interface MCP padronizada e consumidas diretamente nos agentes de chat e Flows do Amazon Quick.

    Para saber mais sobre o Amazon Quick, consulte o post Announcing Amazon Quick: your agentic teammate for answering questions and taking action. Para mais detalhes sobre o Amazon Bedrock AgentCore, veja o post Introducing Amazon Bedrock AgentCore Gateway: Transforming enterprise AI agent tool development.

    Fonte

    Connect an AgentCore Runtime hosted MCP server to Amazon Quick (https://aws.amazon.com/blogs/machine-learning/connect-an-agentcore-runtime-hosted-mcp-server-to-amazon-quick/)

  • AWS Agent Registry agora integrado ao Amazon Quick: agentes e servidores MCP disponíveis diretamente na plataforma

    O que foi anunciado

    A AWS anunciou a integração do Amazon Quick com o AWS Agent Registry, tornando possível que usuários descubram e utilizem agentes e servidores MCP (Model Context Protocol) diretamente dentro do ambiente do Amazon Quick — sem precisar sair da plataforma ou configurar conexões manualmente.

    Como a integração funciona

    Com essa novidade, o AWS Agent Registry passa a expor seus recursos — incluindo servidores MCP e agentes — diretamente na interface de busca do Amazon Quick. O fluxo é bastante direto:

    • O usuário pesquisa e navega pelos agentes e servidores MCP disponíveis no registry da organização, sem sair do Amazon Quick.
    • Ao encontrar o recurso desejado, basta habilitá-lo com poucos cliques — as informações de conexão já vêm preenchidas automaticamente a partir do registry.
    • Uma vez habilitados, esses recursos podem ser compartilhados com equipes e utilizados em diferentes contextos: chat, agentes, aplicativos, fluxos e pesquisa aprofundada (deep research).

    Por que isso importa

    Antes dessa integração, havia uma lacuna clara entre dois perfis de usuário dentro das organizações. De um lado, as equipes técnicas que constroem agentes usando o Amazon Bedrock AgentCore. Do outro, os usuários de negócio que trabalham no dia a dia dentro do Amazon Quick.

    Com a integração, essa distância diminui significativamente: os usuários de negócio passam a ter acesso direto aos agentes e ferramentas já existentes no AWS Agent Registry, a partir do ambiente que já conhecem, sem esforço duplicado de configuração por parte das equipes de TI.

    Disponibilidade

    A integração entre o Amazon Quick e o AWS Agent Registry já está disponível em todas as regiões AWS onde ambos os serviços — Amazon Quick e Amazon Bedrock AgentCore — estão presentes. As regiões contempladas incluem:

    • Leste dos EUA (Norte da Virgínia)
    • Oeste dos EUA (Oregon)
    • Ásia-Pacífico (Sydney)
    • Ásia-Pacífico (Tóquio)
    • Europa (Frankfurt)
    • Europa (Irlanda)

    Como começar

    Para habilitar a integração, basta acessar o console administrativo do Amazon Quick e navegar até Gerenciar conta > Permissões > AWS Agent Registry para conectar o registry da sua organização.

    Para se aprofundar, a AWS disponibiliza a documentação de integrações do Amazon Quick e a documentação do AWS Agent Registry.

    Fonte

    AWS Agent Registry agents and MCP servers now available in Amazon Quick (https://aws.amazon.com/about-aws/whats-new/2026/08/aws-agent-registry-agents-mcp-servers-quick/)

  • Automatize a governança do IAM Identity Center com descoberta contínua e relatórios

    O desafio de governar identidades em escala na AWS

    O AWS IAM Identity Center é o ponto central de autenticação e autorização para recursos AWS dentro de uma organização. Ele se integra ao provedor de identidade externo (IdP) da empresa e ao AWS Organizations, além de suportar um número crescente de serviços AWS com integração nativa.

    À medida que a organização cresce, manter visibilidade sobre quem acessa o quê — e garantir que as políticas de governança sejam aplicadas de forma consistente em todas as contas e regiões — se torna progressivamente mais complexo. O Identity Center centraliza autenticação e autorização, mas rastrear atribuições de acesso e fazer cumprir políticas de segurança em escala é um desafio próprio.

    A AWS publicou uma solução de exemplo que automatiza a descoberta e o reporte dessas atribuições, ajudando equipes de segurança e governança a responder perguntas como:

    • Quais usuários ou grupos têm acesso a quais aplicações AWS?
    • Quem acessou determinada aplicação pela última vez e quando?
    • Quais usuários e grupos estão atribuídos a aplicações do Identity Center em toda a organização e regiões?
    • Como gerar relatórios rapidamente para auditorias de conformidade ou revisões de segurança?

    Planejando a governança de identidades para atribuições de aplicações

    Antes de implementar qualquer automação, a AWS recomenda alinhar quatro áreas fundamentais, envolvendo equipes de segurança, governança, aplicações e negócios:

    • Quem pode provisionar aplicações gerenciadas: As restrições de criação de recursos AWS nas contas da organização devem ser implementadas via políticas de identidade IAM, Políticas de Controle de Serviço (SCP), Políticas de Controle de Recursos (RCP) ou ferramentas de avaliação de políticas como Open Policy Agent (OPA) ou Checkov.
    • Quem gerencia atribuições de usuários e grupos: O administrador da aplicação gerenciada cuida da autorização dentro de uma conta AWS. É recomendado definir claramente papéis e responsabilidades ao longo do fluxo de trabalho.
    • Como o fluxo de autenticação ocorre do IdP aos recursos AWS: Usuários se autenticam no Identity Center, são autorizados a acessar aplicações gerenciadas e, a partir daí, acessam os serviços e recursos AWS associados.
    • Mapeamento de identidades do IdP ao acesso em recursos AWS: É preciso estabelecer a ligação entre usuários e grupos no IdP, as aplicações gerenciadas no Identity Center e os recursos e permissões downstream. A Propagação de Identidade Confiável (TIP) é um recurso adicional do Identity Center que fornece rastreabilidade completa da identidade até o serviço downstream.

    Criando e gerenciando o ciclo de vida de atribuições de aplicações

    Como boa prática de segurança, a AWS recomenda habilitar a administração delegada ao gerenciar o Identity Center em instâncias de organização AWS. Após configurar o IAM Identity Center em uma instância de organização, as contas-membro podem criar recursos AWS associados. Para isso, os principais IAM que provisionam recursos precisam de dois tipos de permissões IAM específicas:

    • Permissões específicas do serviço AWS: Por exemplo, para criar um domínio do Amazon SageMaker AI, são necessárias as permissões habituais de criação do domínio e dos recursos downstream que o SageMaker AI utiliza.
    • Permissões específicas do IAM Identity Center: O principal IAM usado para criar o recurso também precisa de permissões para gerenciar aplicações dentro da instância do Identity Center.

    Um exemplo de política IAM para criação e gerenciamento de aplicações no Identity Center:

    {
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "sso:CreateManagedApplicationInstance",
        "sso:GetManagedApplicationInstance",
        "sso:DeleteManagedApplicationInstance",
        "sso:DescribeRegisteredRegions"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "sso:CreateApplication",
        "sso:DescribeApplication",
        "sso:DeleteApplication",
        "sso:PutApplicationGrant",
        "sso:PutApplicationAuthenticationMethod",
        "sso:PutApplicationAccessScope"
      ],
      "Resource": [
        "arn:aws:sso::<INSERT-ACCOUNT-ID>:application/ssoins-<INSERT-INSTANCE-ID>/apl-*"
      ]
    }
  ]
}

    Um ponto importante: os Nomes de Recurso Amazon (ARN) de aplicações do Identity Center usam identificadores únicos (GUIDs) gerados no momento da criação, diferente de recursos como buckets do Amazon Simple Storage Service (Amazon S3), cujo nome aparece diretamente no ARN.

    Gerenciando acesso a uma aplicação do Identity Center

    Após criar a aplicação, é necessário gerenciar o acesso a ela. Dois tipos de permissões IAM são necessários:

    1. Permissões para listar usuários e grupos do Identity Center:

    {
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ListIdentityCenterUsers",
      "Effect": "Allow",
      "Action": [
        "identitystore:ListUsers",
        "identitystore:DescribeUser",
        "identitystore:ListGroups",
        "identitystore:DescribeGroup",
        "identitystore:ListGroupMemberships"
      ],
      "Resource": "*"
    }
  ]
}

    Vale notar que as ações de listagem exigem acesso a AllUsers ou AllGroups, o que significa que uma política IAM restritiva não pode impedir que um principal veja um subconjunto de usuários ou grupos no identity store.

    2. Permissões para criar e gerenciar atribuições de aplicações:

    {
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ManageApplicationAssignments",
      "Effect": "Allow",
      "Action": [
        "sso:CreateApplicationAssignment",
        "sso:DeleteApplicationAssignment",
        "sso:ListApplicationAssignments",
        "sso:PutApplicationAssignmentConfiguration"
      ],
      "Resource": [
        "arn:aws:sso::<INSERT-ACCOUNT-ID>:application/ssoins-<INSERT-INSTANCE-ID>/apl-*"
      ]
    }
  ]
}

    Como o ARN da aplicação do Identity Center usa um ID único gerado na criação, não é recomendado implementar políticas IAM que restrinjam principais autorizados a gerenciar aplicações específicas do Identity Center por ARN. Em vez disso, a recomendação é limitar o gerenciamento de aplicações e atribuições a um número reduzido de principais IAM autorizados, complementado por capacidades de detecção e resposta.

    Planejando convenções de nomenclatura e estratégia de automação

    O IAM Identity Center disponibiliza diversas APIs para capturar informações sobre instâncias, aplicações e atribuições na organização. Antes de implementar automação ou guardrails, é importante definir uma abordagem metódica. A AWS sugere:

    • Convenção para grupos no IdP: Ex.: AWS_<ACCT#>_<AWS_Service>_<LOB>_<ENV>_<AppName> → AWS_123412341234_SageMaker_Data_PROD_GTLabel
    • Convenção para recursos AWS integrados ao Identity Center: Ex.: <AWS_Service>_<LOB>_<AppName> → SageMaker_Data_GTLabel
    • Convenção para nomes de aplicações no Identity Center: Ex.: <AWS_Service>_<LOB>_<ENV>_<AppName> → SageMaker_Data_PROD_GTLabel

    Também é importante decidir quais partes do fluxo serão centralizadas — criação de aplicações, atribuições ou remediação de problemas. Centralizar demais pode criar gargalos; descentralizar demais aumenta o risco de atribuições fora dos padrões de segurança corporativos. O equilíbrio certo depende do contexto de cada organização.

    Para localizar o ARN de uma aplicação do Identity Center a partir de um recurso AWS específico (como um domínio SageMaker AI), uma busca reversa é necessária, pois os serviços AWS criam aplicações Identity Center com ARNs baseados em GUID que não são facilmente descobertos. Veja o exemplo em shell:

    #!/bin/bash
DOMAIN_ID="d-xxxxxxxxxxxx"
REGION="xx-xxxx-x"

# Step 1: Get SageMaker domain details
echo "=== SageMaker Domain Details ==="
DOMAIN_INFO=$(aws sagemaker describe-domain \
  --region $REGION \
  --domain-id $DOMAIN_ID)

# Step 2: Extract Identity Center application ARN
SSO_APP_ARN=$(echo $DOMAIN_INFO | jq -r '.SingleSignOnApplicationArn')
echo "Identity Center App ARN: $SSO_APP_ARN"

    A solução de automação: descoberta e relatórios

    A solução de exemplo sample-iam-idc-application-discovery-reporting, disponível no GitHub, é composta por duas stacks separadas do AWS Cloud Development Kit (AWS CDK):

    • Stack de relatórios de governança (/identity-center-reporting): fornece descoberta automatizada e geração de relatórios em CSV.
    • Stack de remediação (/identity-center-remediation): fornece aplicação de políticas em tempo real e notificações.

    A recomendação é implantar primeiro a stack de relatórios para estabelecer visibilidade de baseline, e depois a stack de remediação para aplicação de políticas.

    Recursos implantados pela stack de relatórios

    • Amazon EventBridge: regra que invoca o fluxo de descoberta diariamente às 2h UTC (configurável).
    • AWS Step Functions: orquestra o fluxo de descoberta em múltiplos estágios — instâncias, aplicações e atribuições.
    • AWS Lambda: realiza a descoberta de instâncias do Identity Center, enumera aplicações e mapeia usuários e grupos a aplicações, resolvendo nomes amigáveis do Identity Store.
    • Amazon DynamoDB: armazena instâncias, aplicações e atribuições descobertas, criptografadas com chave gerenciada pelo cliente via AWS Key Management Service (AWS KMS).
    • Amazon API Gateway: fornece uma API REST autenticada via IAM para geração e exportação de relatórios como arquivos CSV.
    • Amazon S3: armazena as exportações CSV criptografadas, com políticas de ciclo de vida e URLs pré-assinadas com tempo limitado para download.

    Pré-requisitos e implantação da stack de relatórios

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

    • Uma organização AWS com instância do IAM Identity Center e administração delegada configurada.
    • IAM Identity Center configurado com ao menos uma instância.
    • Interface de Linha de Comando AWS (AWS CLI) configurada com credenciais adequadas.
    • Python 3.12 e Node.js 18 ou superior instalados para o deploy com CDK.

    Comandos para implantação:

    git clone https://github.com/aws-samples/sample-iam-idc-application-discovery-reporting
cd identity-center-reporting

python3.12 -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt

cdk bootstrap aws://<INSERT-ACCOUNT-ID>/<INSERT-REGION>

export IDC_EXTERNAL_ID="$(uuidgen)"
cdk deploy --parameters AllowedIpRange=10.0.0.0/8 --parameters CrossAccountExternalId="$IDC_EXTERNAL_ID"

    O parâmetro AllowedIPRange é opcional, mas recomendado como boa prática de segurança — ele adiciona uma restrição de rede ao download da URL pré-assinada do Amazon S3. Para descoberta de instâncias Identity Center em nível de conta AWS, é necessária uma função IAM entre contas:

    python scripts/deploy-cross-account-roles.py --external-id "$IDC_EXTERNAL_ID"

    Após o deploy, a automação roda em agendamento diário. A primeira execução de descoberta ocorre imediatamente após a implantação. É possível monitorar o histórico de execuções pelo console do AWS Step Functions, revisar logs detalhados no Amazon CloudWatch Logs e consultar instâncias, aplicações e atribuições descobertas diretamente no console do DynamoDB.

    Gerando relatórios de atribuições

    Para gerar relatórios sob demanda como arquivos CSV via API REST:

    export AWS_REGION="<REPLACE-REGION>"
export API_ID="<REPLACE-API-ID>"
eval "$(aws configure export-credentials --profile "<YOUR-PROFILE>" --format env)"

# Exportar aplicações
curl -sS --fail-with-body \
  --aws-sigv4 "aws:amz:${AWS_REGION}:execute-api" \
  --user "${AWS_ACCESS_KEY_ID}:${AWS_SECRET_ACCESS_KEY}" \
  --header "x-amz-security-token: ${AWS_SESSION_TOKEN}" \
  "https://${API_ID}.execute-api.${AWS_REGION}.amazonaws.com/prod/export/applications" \
  -o applications.json

# Exportar atribuições com nomes de usuários e grupos
curl -sS --fail-with-body \
  --aws-sigv4 "aws:amz:${AWS_REGION}:execute-api" \
  --user "${AWS_ACCESS_KEY_ID}:${AWS_SECRET_ACCESS_KEY}" \
  --header "x-amz-security-token: ${AWS_SESSION_TOKEN}" \
  "https://${API_ID}.execute-api.${AWS_REGION}.amazonaws.com/prod/export/assignments" \
  -o assignments.json

    A API retorna um JSON com uma URL pré-assinada do Amazon S3 válida por 15 minutos. Os arquivos CSV gerados incluem dados enriquecidos com nomes amigáveis, como ARN da instância, ID da conta, nome da aplicação, tipo de principal, nome do principal e status. Com esses dados, é possível identificar anomalias ou atribuições não conformes — por exemplo, uma aplicação de produção que deveria ter apenas atribuições de grupo, mas possui um usuário individual atribuído.

    Stack de remediação: monitoramento e resposta em tempo real

    A stack de remediação complementa os relatórios com aplicação de políticas em tempo real. Os recursos implantados incluem:

    • Amazon EventBridge: captura eventos de atribuição e perfil do IAM Identity Center via CloudTrail (sso.amazonaws.com) para ações como CreateApplicationAssignment, DeleteApplicationAssignment, PutApplicationAssignmentConfiguration, AssociateProfile, DisassociateProfile, CreateProfile, UpdateProfile e DeleteProfile.
    • AWS Lambda: resolve nomes de aplicações e grupos, valida a atribuição contra a convenção de nomenclatura e notifica ou remedia conforme o modo configurado.
    • Amazon Simple Notification Service (Amazon SNS): publica alertas de atribuições não conformes para assinantes (como e-mail).
    • Amazon Simple Queue Service (Amazon SQS): captura eventos que a função Lambda não conseguiu processar para inspeção posterior.
    • AWS KMS: chave gerenciada pelo cliente para criptografar variáveis de ambiente do Lambda, logs do CloudWatch, tópico SNS e fila de mensagens mortas.
    • Amazon CloudWatch: grupo de logs armazena os logs estruturados e criptografados da função como trilha de auditoria.

    As políticas de nomenclatura suportam correspondência por expressões regulares (regex) para requisitos organizacionais específicos.

    Implantação da stack de remediação

    git clone https://github.com/aws-samples/sample-iam-idc-application-discovery-reporting
cd identity-center-remediation
cdk deploy --context enableAutoDeletion=false --parameters IdentityCenterInstanceArn=arn:aws:sso:::instance/ssoins-<INSERT-ORG-INSTANCE-ID> --parameters ManagementAccountId=<INSERT-MANAGEMENT-ACCOUNT>

    Por padrão, a solução verifica se o nome do grupo aparece como palavra completa no nome da aplicação (sem distinção entre maiúsculas e minúsculas, separando por -, _ e espaços). Assim, ReadOnly corresponde a sagemaker_readonly, mas read não corresponde. Para casos de uso diferentes, o parâmetro GroupNameRegex pode ser passado durante o deploy.

    Testando atribuições conformes e não conformes

    Para obter as informações necessárias do ambiente:

    INSTANCE_ARN=$(aws sso-admin list-instances --region <REPLACE-REGION> --query "Instances[0].InstanceArn" --output text)
echo "$INSTANCE_ARN"

IDENTITY_STORE_ID=$(aws sso-admin list-instances --region <REPLACE-REGION> --query "Instances[0].IdentityStoreId" --output text)
echo "$IDENTITY_STORE_ID"

aws identitystore list-groups --identity-store-id $IDENTITY_STORE_ID --query "Groups[].{Name:DisplayName,Id:GroupId}" --output table

aws sso-admin list-applications --instance-arn $INSTANCE_ARN --query "Applications[?Status=='ENABLED'].{Name:Name,ARN:ApplicationArn}" --output table

    Definindo variáveis para os grupos e aplicação de teste:

    export GRP_READONLY=abc12345-1234-1234-1234-abcdef123456
export GRP_DEVELOPER=abc12345-1234-1234-1234-abcdef123457
export APP_READONLY="arn:aws:sso::<INSERT-ACCOUNT-ID>:application/<INSERT-INSTANCE-ARN>/<INSERT-APPLICATION-ARN>"

    Atribuição conforme — adicionando o grupo ReadOnly à aplicação sagemaker_readonly:

    aws sso-admin create-application-assignment --application-arn $APP_READONLY --principal-id $GRP_READONLY --principal-type GROUP

    O log da função Lambda mostrará:

    ✓ COMPLIANT - Group name found in application name applicationName="sagemaker_readonly" groupName="ReadOnly"
Remediation action determined: NONE

    Atribuição não conforme — tentando adicionar o grupo Developer à aplicação sagemaker_readonly:

    aws sso-admin create-application-assignment --application-arn $APP_READONLY --principal-id $GRP_DEVELOPER --principal-type GROUP

    O log mostrará:

    ✗ NON-COMPLIANT - Group name not found in application name applicationName="sagemaker_readonly" groupName="Developer"
Remediation action determined: NOTIFICATION_ONLY
SNS notification sent successfully

    Com enableAutoDeletion=false, a solução apenas notifica. Para que a atribuição seja removida automaticamente, o valor deve ser alterado para enableAutoDeletion=true. A mensagem SNS enviada inclui detalhes como tipo de evento, nome da aplicação, nome do grupo, ação tomada, ARN da aplicação e quem iniciou a ação.

    Governança IAM em escala: um framework de alto nível

    A AWS sugere os seguintes passos de alto nível para estruturar a governança do Identity Center com essas soluções:

    • Implantar a automação com um principal IAM que tenha acesso na conta de administrador delegado.
    • Estabelecer uma baseline executando a primeira descoberta e revisando os relatórios gerados.
    • Configurar políticas de nomenclatura alinhadas às convenções de segurança da organização.
    • Implantar o monitoramento orientado a eventos para habilitar aplicação de políticas em tempo real.
    • Começar no modo de notificação para validar as políticas antes de habilitar a auto-remediação.
    • Integrar com ferramentas de governança conectando os endpoints da API a dashboards de conformidade ou ferramentas de ITSM.
    • Migrar para auto-remediação após validar que as políticas estão funcionando conforme esperado.

    Os relatórios agendados fornecem visibilidade de baseline sobre as aplicações gerenciadas pelo IAM Identity Center. O monitoramento orientado a eventos entrega notificações ou aplicação de políticas em tempo quase real. Juntas, essas soluções ajudam a alinhar e escalar o Identity Center com os padrões de governança e segurança da organização — por meio de análise histórica e resposta imediata.

    Limpeza do ambiente

    Para remover as stacks implantadas, execute os seguintes comandos nas respectivas contas AWS:

    # Remover a stack de remediação
cd sample-iam-idc-application-discovery-reporting/identity-center-remediation
cdk destroy

# Remover a stack de relatórios
cd sample-iam-idc-application-discovery-reporting/identity-center-reporting
cdk destroy

    Fonte

    Automate IAM Identity Center governance with continuous discovery and reporting (https://aws.amazon.com/blogs/security/automate-iam-identity-center-governance-with-continuous-discovery-and-reporting/)

  • CloudTroop Weekly #027 — 2026-w35





    CloudTroop Weekly #027 — 2026-w35

    30 de agosto de 2026

    Resumo da Semana

    A semana foi dominada por três frentes que se reforçam: IA agêntica ganhando camadas de governança e segurança, acesso a recursos cloud migrando para dentro da VPC e modernização de infraestrutura com impacto direto em custo. GPUs Blackwell Ultra chegaram a São Paulo, o console AWS pode agora rodar sem internet pública e o Glue 6.0 ficou 30% mais barato. Para quem opera agentes de IA, a semana trouxe controles concretos de memória, ferramentas externas e governança de acesso, sinalizando que IA em produção exige arquitetura de segurança, não só modelo.

    O que muda na prática

    • Ambientes regulados (financeiro, saúde, governo) podem agora isolar completamente o acesso ao console AWS e workloads Lambda dentro da VPC via PrivateLink, sem nenhum tráfego exposto à internet pública.
    • Pipelines de dados com AWS Glue ficam automaticamente 30% mais baratos na versão 6.0, com suporte ao Iceberg v3 e Spark 4.1, o que acelera a decisão de migrar workloads ETL/ELT legados.
    • Agentes de IA em produção agora têm controles de segurança na infraestrutura (Guardrails para ferramentas externas, Cedar/OAuth para memória), reduzindo a responsabilidade de autorização que antes ficava no código da aplicação.

    Ações da semana

    • Verifique a versão do seu RDS PostgreSQL agora: a AWS recomenda upgrade imediato para corrigir CVEs ativos. Acesse o console, filtre instâncias desatualizadas e agende a janela de manutenção esta semana.
    • Se você opera pipelines no AWS Glue, abra um ticket ou spike para avaliar a migração para a versão 6.0: a redução de 30% no custo já justifica o esforço, e o suporte ao Iceberg v3 pode eliminar workarounds que você já tem em produção.

    Top 10 da Semana

    1

    EC2 P6-B300 com GPUs Blackwell Ultra chega à região de São Paulo

    Equipes brasileiras de IA ganham acesso local a hardware de ponta para treinar e servir LLMs de trilhões de parâmetros, eliminando latência e custos de transferência entre regiões.

    Para quem: Engenheiros de ML e arquitetos de IA que desenvolvem ou planejam workloads de treinamento e inferência de modelos grandes no Brasil.

    IA, Infraestrutura

    2

    Console AWS agora acessível 100% via PrivateLink, sem internet

    Organizações em setores regulados podem isolar completamente o acesso ao console AWS dentro da VPC, eliminando a última dependência de conectividade pública em ambientes air-gapped.

    Para quem: Arquitetos de segurança e times de compliance em setores financeiro, saúde e governo que operam ambientes com restrições rígidas de rede.

    Segurança, Rede

    3

    AWS Glue 6.0: 30% mais barato e com suporte ao Iceberg v3

    A combinação de redução de preço, Spark 4.1 e suporte nativo ao Iceberg v3 impacta diretamente o custo e a modernização de pipelines de dados em produção.

    Para quem: Engenheiros de dados e arquitetos de data lake que usam AWS Glue em pipelines ETL/ELT de médio a grande porte.

    Dados, Custo

    4

    Amazon EKS suporta até 10 provedores OIDC externos por cluster

    Times com múltiplos grupos de usuários (funcionários, terceiros, CI/CD) podem agora federar identidades distintas no mesmo cluster sem gambiarras, reduzindo risco e complexidade operacional.

    Para quem: Engenheiros de plataforma e administradores de Kubernetes que gerenciam clusters EKS com múltiplos perfis de acesso.

    Segurança, Kubernetes

    5

    Bedrock Guardrails estendido para ferramentas externas em agentes de IA

    Proteger apenas a fronteira do modelo não é suficiente; esta abordagem cobre entradas, parâmetros de ferramentas e respostas externas sem alterar o código do agente.

    Para quem: Desenvolvedores e arquitetos que constroem agentes de IA com acesso a ferramentas e APIs externas e precisam garantir segurança end-to-end.

    Segurança, IA Agêntica

    6

    Lambda MicroVMs agora suporta AWS PrivateLink

    Workloads serverless em setores regulados podem agora rodar em isolamento total de rede, sem tráfego exposto à internet pública.

    Para quem: Arquitetos e engenheiros de segurança que usam Lambda em ambientes financeiros, de saúde ou governamentais com requisitos de isolamento de rede.

    Segurança, Serverless

    7

    Reduza custos de RAG em até 33% com compressão orientada por consulta

    Uma técnica concreta e mensurável para cortar custos de pipelines RAG em produção sem sacrificar qualidade das respostas.

    Para quem: Engenheiros de ML e arquitetos de soluções que operam pipelines RAG de alto volume no Amazon Bedrock e buscam otimização de custo.

    IA, Custo

    8

    Bedrock AgentCore Memory ganha controle de acesso refinado com Cedar e OAuth

    O controle de acesso à memória de agentes migra da camada de aplicação para a infraestrutura, simplificando isolamento multi-tenant e reduzindo superfície de erro.

    Para quem: Desenvolvedores de aplicações multi-tenant com agentes de IA que precisam isolar memória por usuário ou organização sem lógica de autorização customizada.

    Segurança, IA Agêntica

    9

    Amazon RDS PostgreSQL atualiza para versões com correções de CVEs

    As novas versões corrigem vulnerabilidades conhecidas e a AWS recomenda upgrade imediato, tornando esta uma ação operacional urgente para quem roda RDS PostgreSQL.

    Para quem: DBAs e engenheiros de infraestrutura responsáveis por instâncias Amazon RDS PostgreSQL em qualquer versão suportada.

    Banco de Dados, Segurança

    10

    Modelo de maturidade para governar acesso de agentes de IA com AgentCore Gateway

    Oferece um caminho progressivo e prático para sair de credenciais espalhadas em arquivos locais até uma arquitetura de governança multi-região para agentes de IA.

    Para quem: Arquitetos de soluções e líderes técnicos que estão escalando agentes de IA para produção e precisam de um framework de governança de acesso.

    IA Agêntica, Governança


  • AWS Transform agora está em conformidade com o FedRAMP Classe C

    O que mudou

    A AWS anunciou que o AWS Transform agora está dentro do escopo do Programa Federal de Gerenciamento de Risco e Autorização (FedRAMP) — especificamente na classificação Classe C (anteriormente conhecida como baseline Moderada), na região US East (Ohio).

    Na prática, isso significa que organizações sujeitas aos requisitos de conformidade do FedRAMP Classe C já podem utilizar o AWS Transform para construir aplicações e executar cargas de trabalho dentro desse padrão regulatório.

    O que é o FedRAMP

    O FedRAMP é um programa do governo dos Estados Unidos que estabelece uma abordagem padronizada para avaliação de segurança, autorização e monitoramento contínuo de produtos e serviços em nuvem. Ele é exigido para fornecedores de tecnologia que atendem agências federais norte-americanas, funcionando como um selo de conformidade rigoroso no setor público americano.

    Para saber quais serviços da AWS já estão dentro do escopo do FedRAMP, a AWS mantém uma página de serviços em conformidade atualizada.

    O que é o AWS Transform

    O AWS Transform é um serviço de migração e modernização com capacidades agênticas — ou seja, ele age de forma autônoma para conduzir processos complexos com menos intervenção manual. O objetivo declarado do serviço é comprimir cronogramas corporativos que normalmente levariam anos para algo na casa de meses.

    Entre as capacidades do serviço estão:

    • Migrações de infraestrutura em larga escala
    • Redução contínua de débito técnico
    • Eliminação das transferências manuais e da perda de contexto que costumam travar esses programas

    Por que isso importa

    A certificação FedRAMP é um requisito crítico para qualquer serviço de nuvem utilizado no setor público americano. Ao atingir o nível Classe C no AWS Transform, a AWS amplia as possibilidades de adoção do serviço por órgãos governamentais e contratados federais nos EUA que precisam garantir conformidade regulatória em seus projetos de modernização.

    Para equipes brasileiras que atendem clientes ou parceiros no mercado americano — especialmente no setor público —, essa é uma informação relevante para avaliar o uso do AWS Transform em projetos com requisitos de compliance federal.

    Saiba mais

    Para aprofundar o conhecimento sobre o serviço, a AWS disponibiliza a página oficial do AWS Transform e a documentação técnica completa.

    Fonte

    AWS Transform now in scope for FedRAMP Class C (https://aws.amazon.com/about-aws/whats-new/2026/08/aws-transform-fedramp-class-c/)

  • AWS Management Console Private Access: acesso sem internet para ambientes isolados

    O problema que a AWS resolveu

    Organizações em setores regulados como serviços financeiros, governo, defesa e saúde costumam restringir suas cargas de trabalho a ambientes de rede isolados, sem qualquer acesso à internet pública. Até recentemente, havia uma tensão clara nesse modelo: era possível restringir o acesso ao AWS Management Console a contas e redes corporativas autorizadas, mas o console em si ainda exigia conectividade com a internet para funcionar completamente.

    Isso colocava as equipes de segurança diante de uma escolha difícil — permitir alguma saída para a internet para usar o console, ou negar o acesso ao console para operadores que trabalham em ambientes completamente isolados.

    A AWS anunciou a disponibilidade geral do AWS Management Console Private Access com suporte a Nuvens Privadas Virtuais (VPCs) sem conectividade com a internet. Agora, todo o tráfego dos consoles de serviço suportados — fluxos de autenticação, assets estáticos (JavaScript, CSS, imagens), APIs exclusivas do console e chamadas às APIs de serviços AWS — pode ser roteado por endpoints de VPC via AWS PrivateLink, eliminando a necessidade de internet gateway, NAT gateway ou qualquer rota para a internet pública. O recurso está disponível em todas as Regiões comerciais da AWS para um conjunto selecionado de consoles de serviço suportados.

    O que mudou em relação ao lançamento anterior

    Em 2023, a AWS lançou a primeira versão do Console Private Access, que já permitia rotear chamadas de console, sign-in e APIs de serviço por endpoints de VPC. No entanto, os assets estáticos e as APIs exclusivas do console ainda dependiam de conectividade com a internet. Esse gap foi eliminado com este lançamento.

    Dois cenários principais atendidos

    Tráfego do console em redes sem acesso à internet

    Com a atualização, o tráfego dos consoles de serviço suportados flui inteiramente pelos endpoints de VPC — sem listas de domínios permitidos para manter, sem proxies interceptando TLS e sem a necessidade de aceitar fluxos exclusivamente via CLI como solução de contorno. O mesmo caminho funciona a partir do Amazon WorkSpaces, instâncias do Amazon Elastic Compute Cloud (Amazon EC2) e redes on-premises conectadas via AWS Direct Connect ou AWS Site-to-Site VPN.

    Combinando com Políticas de Controle de Recursos (RCPs) de sign-in e políticas de recursos de sign-in, é possível garantir que a autenticação no console só seja bem-sucedida a partir de redes esperadas — mesmo que credenciais válidas sejam apresentadas de outro lugar, a sessão é negada.

    Prevenção de exfiltração de dados

    O Private Access também permite restringir quais contas AWS e identidades organizacionais podem usar o AWS Management Console a partir da VPC. Isso impede o acesso via contas pessoais ou contas fora da organização. Ao anexar uma política de endpoint de VPC com a condição aws:ResourceOrgID, as ações do console ficam automaticamente limitadas a recursos dentro da organização. As RCPs de sign-in adicionam uma segunda camada, garantindo que a autenticação só funcione a partir de redes dentro do perímetro.

    Como o tráfego flui em um ambiente sem internet

    O Console Private Access utiliza três endpoints de VPC distintos para cobrir todo o tráfego necessário:

    • Fluxos de autenticação — sign-in, troca de credenciais e requisições de token de sessão
    • Assets estáticos — JavaScript, CSS e imagens que renderizam a interface do console
    • Chamadas de API do console de serviço — as requisições de backend feitas quando usuários interagem com os consoles de serviço

    O fluxo completo a partir de uma carga de trabalho em uma VPC privada funciona assim: o navegador do operador requisita <região>.console.aws.amazon.com; o encaminhador de DNS corporativo repassa a consulta para um endpoint de entrada do Amazon Route 53 Resolver configurado na VPC, que encaminha o tráfego para o endpoint de VPC do console. O tráfego flui de on-premises via Direct Connect (ou AWS Site-to-Site VPN) até a VPC, e o endpoint de VPC roteia o tráfego para o serviço do console pela rede privada da AWS. O console redireciona para o endpoint de sign-in, que avalia as políticas de endpoint de VPC, políticas baseadas em recursos (RBPs) e RCPs antes de redirecionar de volta ao console. Por fim, o console carrega o conteúdo estático pelo endpoint de VPC do console-static e aplica as restrições de identidade e recurso ao fazer chamadas às APIs dos serviços AWS.

    Controles de perímetro de dados aplicados ao console

    O Console Private Access e as políticas de recursos de sign-in são uma extensão natural das Políticas de Controle de Serviço (SCPs), RCPs e políticas de endpoint de VPC que as equipes já utilizam para tráfego de API. Agora, os mesmos controles de perímetro de dados para identidade, recurso e rede que protegem o acesso programático também protegem as sessões interativas do navegador.

    A tabela de controles cobre quatro objetivos principais:

    • Identidade: Apenas identidades confiáveis podem acessar recursos — via RCPs e RBPs de sign-in, restringindo quais principals podem autenticar no console usando condições como aws:PrincipalOrgID, aws:PrincipalAccount e aws:PrincipalArn.
    • Recurso: Identidades só podem acessar recursos confiáveis — via SCP com aws:ResourceOrgID, que segue os principals em cada sessão do console e nega chamadas de API cujo recurso-alvo esteja fora da organização.
    • Rede (identidade): Identidades só acessam recursos a partir de redes esperadas — via SCPs de perímetro de rede com aws:SourceVpc. Com o Private Access, requisições enviadas pelo console aos serviços suportados carregam aws:SourceVpc definido para a VPC que hospeda os endpoints.
    • Rede (recurso): Recursos só podem ser acessados a partir de redes esperadas — via RBPs e RCPs de sign-in que negam autenticação no console a partir de redes inesperadas, usando condições como aws:SourceIp, aws:SourceVpc, aws:SourceVpce e aws:VpcSourceIp.

    Guia de implantação passo a passo

    A AWS recomenda um rollout incremental, validando cada etapa antes de expandir para Regiões e Unidades Organizacionais (OUs) adicionais. Para quem quiser validar a mecânica antes de construir a solução completa, o guia de início rápido com ambiente de teste apresenta uma configuração mínima com uma única VPC, os três endpoints e uma política permissiva.

    Pré-requisitos

    Passo 1: Mapear o acesso atual ao console

    Antes de qualquer mudança, use o CloudTrail para mapear como os usuários acessam o console hoje. Busque por eventName = ConsoleLogin em uma janela representativa (recomenda-se 30 dias) e revise os campos sourceIPAddress, vpcEndpointId e awsRegion. Identifique quais tipos de identidade estão em uso: usuário root, usuário IAM, federação SAML e AWS IAM Identity Center. Escolha a OU ou conta que será usada no piloto — evite contas de produção ou compartilhadas.

    Passo 2: Criar os endpoints de VPC do Private Access

    Na Região escolhida, crie ou identifique uma VPC para hospedar os endpoints e, em seguida, crie três endpoints de interface de VPC nessa VPC:

    • com.amazonaws.<região>.console — para o console
    • com.amazonaws.<região>.signin — para o AWS Sign-In
    • com.amazonaws.<região>.console-static — para APIs exclusivas do console (obrigatório apenas se a VPC não tiver caminho para a internet)

    Passo 3: Configurar o DNS privado

    Para cargas de trabalho dentro da VPC que usam o Amazon Route 53 Resolver padrão, nenhuma configuração adicional de DNS é necessária — basta habilitar o nome de DNS privado em cada endpoint (PrivateDnsEnabled = true). Se você usar um resolver de DNS customizado ou uma zona hospedada privada, é necessário configurá-lo explicitamente para mapear os domínios do console para os endereços dos endpoints. Consulte a documentação de zonas hospedadas privadas e a documentação de endpoints obrigatórios do Console Private Access para a lista completa de domínios.

    Para cargas de trabalho fora da VPC — como escritórios corporativos conectados via Direct Connect ou Site-to-Site VPN — garanta que o resolver de DNS corporativo retorne os endereços dos endpoints para esses domínios. O post Simplify DNS management in a multi-account environment with Route 53 Resolver traz orientações detalhadas.

    Passo 4: Verificar a conectividade privada

    Faça login no console a partir de uma carga de trabalho dentro da VPC. Para confirmar que o tráfego está roteando pelos endpoints de VPC, verifique o ícone de cadeado na barra de navegação do console. Você também pode confirmar no CloudTrail que eventos recentes de ConsoleLogin mostram o campo vpcEndpointId preenchido com um dos seus IDs de endpoint. Veja um exemplo de evento:

    {
  "eventVersion": "1.08",
  "userIdentity": {
    "type": "AssumedRole",
    "principalId": "AROA3XFRBF23EXAMPLE:john.doe",
    "arn": "arn:aws:sts::123456789012:assumed-role/Admin/john.doe",
    "accountId": "123456789012"
  },
  "eventTime": "2026-07-08T19:15:32Z",
  "eventSource": "signin.amazonaws.com",
  "eventName": "ConsoleLogin",
  "awsRegion": "us-east-1",
  "sourceIPAddress": "10.0.1.47",
  "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)...",
  "requestParameters": null,
  "responseElements": {
    "ConsoleLogin": "Success"
  },
  "additionalEventData": {
    "LoginTo": "https://console.aws.amazon.com/console/home",
    "MobileVersion": "No",
    "MFAUsed": "Yes",
    "vpcEndpointId": "vpce-0abc123def456789a"
  },
  "eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
  "eventType": "AwsConsoleSignIn",
  "recipientAccountId": "123456789012"
}

    Se o console não carregar, verifique: se o DNS privado está habilitado em cada endpoint; se os grupos de segurança dos endpoints permitem HTTPS (TCP 443) das sub-redes das cargas de trabalho; e se, para tráfego externo à VPC, o DNS corporativo retorna os IPs privados dos endpoints. Para validação end-to-end, execute traceroute console.aws.amazon.com a partir da sua estação de trabalho e confirme que o caminho usa apenas hops privados.

    Passo 5: Aplicar políticas de endpoint de VPC

    Anexe uma política de endpoint nos endpoints do console e do AWS Sign-In que limite o acesso a identidades da sua organização. Comece com uma política permissiva Allow * e confirme que o tráfego está roteando pelos endpoints. Depois, adicione restrições usando as condições aws:PrincipalOrgID e aws:ResourceOrgID. A referência completa está no guia do usuário do Console Private Access. Para políticas além do piloto, consulte Data perimeters on AWS e o repositório de exemplos de políticas de perímetro de dados no GitHub.

    Passo 6: Aplicar uma política de Sign-In

    As políticas de Sign-In negam requisições de autenticação no console que não correspondam às condições de rede ou de principal definidas. A política é composta por uma instrução de pré-autenticação cobrindo signin:Authenticate e uma instrução de pós-autenticação cobrindo signin:AuthorizeOAuth2Access e signin:CreateOAuth2Token — inclua ambas.

    Para o piloto, implante a política como uma RCP a partir da conta de gerenciamento do AWS Organizations. Como a RCP se aplica a todas as contas da organização, recomenda-se pilotar em uma organização de teste dedicada antes de expandir. Ative a aplicação chamando a API signin:PutConsoleAuthorizationConfiguration para a organização na Região us-east-1.

    Importante: Configure pelo menos um principal excluído como caminho de acesso emergencial (break-glass) antes de habilitar a RCP. O principal recomendado é uma role IAM dedicada.

    Exemplo — Restringir acesso à VPC corporativa:

    aws signin put-resource-permission-statement \
  --source-vpc vpc-0abc123def456789 \
  --requested-region us-west-2 \
  --excluded-principal "arn:aws:iam::123456789012:user/EmergencyAdmin" \
  --region us-east-1

    Exemplo — Restringir acesso a um intervalo de IP específico:

    aws signin put-resource-permission-statement \
  --source-ip "IP_ADDRESS" \
  --excluded-principal "arn:aws:iam::123456789012:role/BreakGlassRole" \
  --region us-east-1

    Habilitar a autorização do console para a organização:

    aws signin put-console-authorization-configuration \
  --target-id <your-target-id> \
  --region us-east-1

    Para exemplos de políticas, referência da Interface de Linha de Comando da AWS (AWS CLI) e o procedimento de recuperação em caso de bloqueio, consulte o post sobre RBPs de sign-in e a documentação de controle de acesso ao console com políticas baseadas em recursos.

    Passo 7: Adicionar endpoints de VPC para cada serviço

    Os endpoints do Private Access carregam o shell do console, mas não as chamadas de API de serviço que o console faz em nome do usuário. Em uma VPC sem internet gateway, essas chamadas não têm para onde ir. Por isso, é necessário adicionar um endpoint de VPC para cada serviço utilizado.

    Para o piloto, crie um endpoint de interface do AWS KMS (com.amazonaws.<região>.kms) na mesma VPC, com DNS privado habilitado, e confirme que a lista de chaves carrega ao acessar o console do AWS Key Management Service (AWS KMS) de dentro da VPC. Repita para cada serviço necessário. A lista atual de serviços que suportam PrivateLink está na documentação do AWS PrivateLink. Consoles de serviços que não suportam PrivateLink não funcionarão em VPCs sem internet e precisam ser tratados separadamente.

    Passo 8: Ocultar Regiões e serviços não configurados (opcional)

    Links do console para serviços ou Regiões sem endpoints configurados falharão dentro da VPC. Para evitar que usuários naveguem para páginas quebradas, use a Personalização de Experiência do Usuário (UXC) para ocultar Regiões e serviços que não fazem parte da implantação do Private Access. A UXC é configurada no nível da conta e se aplica à navegação, resultados de busca e menus de seleção de serviços.

    Passo 9: Validar e expandir

    Após aplicar as políticas de endpoint e a RCP de Sign-In a uma conta piloto, valide dois cenários: login de dentro da rede corporativa (deve ter sucesso) e login de fora da rede corporativa (deve ser negado na etapa de Sign-In, antes de chegar ao console). No CloudTrail, confirme que os eventos ConsoleLogin mostram vpcEndpointId preenchido para tráfego de dentro da rede. Para negações inesperadas, procure eventos ConsoleLogin com as mensagens de erro Authorization denied because of a resource-based policy ou Authorization denied because of a resource control policy.

    Considerações importantes

    • IAM Identity Center: O suporte ao sign-in via IAM Identity Center ainda não está disponível por endpoint de VPC. A autenticação inicial de Single Sign-On (SSO) ainda precisa transitar pela internet.
    • Acesso programático: RBPs e RCPs de Sign-In controlam o sign-in interativo no console. Requisições do AWS SDK e da AWS CLI assinadas com SigV4 não são afetadas. Esse também é o caminho de recuperação: um principal com permissão signin:DeleteConsoleAuthorizationConfiguration pode desabilitar a aplicação programaticamente se a autorização do console estiver mal configurada.
    • Aplicações integradas ao AWS Sign-In: As políticas de Sign-In também se aplicam ao Amazon Connect, Amazon WorkSpaces, Amazon QuickSight, AWS Health Dashboard, Amazon AppStream 2.0 e Amazon Lightsail quando essas aplicações usam o AWS Sign-In para autenticar.
    • Suporte parcial a consoles: O Console Private Access está disponível em todas as Regiões comerciais da AWS, mas suporta apenas um subconjunto dos consoles de serviço. Consulte a documentação de Regiões, consoles de serviço e funcionalidades suportadas no Private Access. Para serviços não suportados, a conectividade com a internet ainda é necessária.
    • Custos: São cobrados os preços regulares de endpoint do AWS PrivateLink e processamento de dados para cada endpoint e cada Região implantada. Os três endpoints do Private Access (console, signin e console-static), mais os endpoints de serviço já utilizados, são os itens relevantes de custo.

    Conclusão

    Com o AWS Management Console Private Access, a AWS estendeu o framework de perímetro de dados ao próprio console interativo. Agora, os quatro objetivos de controle — identidade, recurso, rede de identidade e rede de recurso — que já eram aplicados ao tráfego de API também se aplicam às sessões de navegador. Para começar, consulte a documentação do AWS Management Console Private Access, as arquiteturas de referência do Console Private Access e o guia Establishing a data perimeter on AWS.

    Fonte

    Extend your data perimeter to the AWS Management Console with Private Access (https://aws.amazon.com/blogs/security/extend-your-data-perimeter-to-the-aws-management-console-with-private-access/)