Author: Make.com Service User

  • 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/)

  • Escrita em lote e descoberta de registros no Amazon SageMaker Feature Store

    O que é o Amazon SageMaker Feature Store

    O Amazon SageMaker Feature Store é um repositório gerenciado pela AWS para armazenar, compartilhar e gerenciar features de modelos de Aprendizado de Máquina (ML). Ele oferece serving online de baixa latência para inferência em tempo real, um offline store para retenção histórica e dados de treinamento, além de suporte a padrões de ingestão via streaming e batch.

    Os dois problemas que motivaram as novas APIs

    À medida que as plataformas de ML amadurecem, dois gaps operacionais aparecem com frequência.

    Problema 1: throughput limitado na ingestão

    O primeiro desafio envolve pipelines de features de alta vazão. A API existente, o PutRecord, grava um único registro por chamada, em um único feature group. Isso força um padrão de chamadas N×M — N registros multiplicados por M feature groups. O resultado prático: uma pipeline de detecção de fraudes que ingere 10.000 registros por segundo em cinco feature groups precisa sustentar 50.000 chamadas individuais de API por segundo, gerando overhead de conexão e alta latência de cauda.

    Problema 2: registros irrecuperáveis no tier In-Memory

    O segundo problema afeta quem usa o storage tier In-Memory. Nesse modelo, não há como navegar ou enumerar os registros armazenados no online store. Se os identificadores de registro forem perdidos por um bug ou falha de pipeline, esses registros se tornam permanentemente irrecuperáveis — não existe offline store para consultar, nenhuma query no Amazon Athena para rodar, e nenhuma API para descobrir o que existe.

    As duas novas APIs anunciadas

    Para endereçar esses dois problemas, a AWS anunciou duas novas APIs para o Amazon SageMaker Feature Store:

    • BatchWriteRecord — Grava até 25 registros em múltiplos feature groups em uma única chamada de API, com semântica de sucesso parcial, controle de TTL (Time-to-Live) por registro e as mesmas garantias de ordenação baseadas em EventTime do PutRecord.
    • ListRecords — Enumera identificadores de registro dentro de um feature group com paginação. Funciona com os dois tiers de storage: Standard (baseado em Amazon DynamoDB) e In-Memory (baseado em Redis).

    Pré-requisitos

    Para acompanhar os exemplos apresentados, você precisará de:

    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Action": [
            "sagemaker:BatchWriteRecord",
            "sagemaker:PutRecord",
            "sagemaker:ListRecords"
          ],
          "Resource": "arn:aws:sagemaker:*:*:feature-group/*"
        }
      ]
    }

    BatchWriteRecord

    A API BatchWriteRecord aceita até 25 entradas em uma única requisição, podendo atingir um ou mais feature groups simultaneamente. Cada registro tem sucesso ou falha de forma independente — trata-se de uma API de sucesso parcial, o que significa que falhas individuais não cancelam a requisição inteira.

    A API preserva a mesma ordenação baseada em EventTime do PutRecord:

    • Se o EventTime do registro recebido for mais recente do que o existente, ele se torna a versão mais atual no online store.
    • Caso contrário, o registro é gravado como versão histórica no offline store (para feature groups com storage offline habilitado).
    • Registros que falham por outros motivos (erros de autenticação, validação ou throttling) são retornados na resposta com detalhes do erro. As entradas não processadas aparecem em UnprocessedEntries e podem ser retentadas.

    Estrutura da requisição

    {
      "Entries": [
        {
          "FeatureGroupName": "click-features",
          "Record": [
            {"FeatureName": "user_id", "ValueAsString": "user-123"},
            {"FeatureName": "event_time", "ValueAsString": "2026-06-05T12:00:00Z"},
            {"FeatureName": "click_count", "ValueAsString": "42"}
          ],
          "TargetStores": ["OnlineStore", "OfflineStore"],
          "TtlDuration": {"Unit": "Days", "Value": 7}
        },
        {
          "FeatureGroupName": "login-features",
          "Record": [
            {"FeatureName": "user_id", "ValueAsString": "user-456"},
            {"FeatureName": "event_time", "ValueAsString": "2026-06-05T12:00:01Z"},
            {"FeatureName": "login_count", "ValueAsString": "18"}
          ],
          "TargetStores": ["OnlineStore", "OfflineStore"]
        }
      ]
    }

    A resposta retorna apenas os registros que falharam. Registros não listados em Errors ou UnprocessedEntries foram gravados com sucesso. A aplicação deve retentar apenas os registros falhos usando exponential backoff para erros retriáveis.

    Exemplo de código: ingestão em lote com Boto3

    import boto3
    
    featurestore_runtime = boto3.client("sagemaker-featurestore-runtime")
    
    response = featurestore_runtime.batch_write_record(
        Entries=[
            {
                "FeatureGroupName": "click-features",
                "Record": [
                    {"FeatureName": "user_id", "ValueAsString": "user-123"},
                    {"FeatureName": "event_time", "ValueAsString": "2026-06-05T12:00:00Z"},
                    {"FeatureName": "click_count", "ValueAsString": "42"},
                ],
                "TargetStores": ["OnlineStore", "OfflineStore"],
            },
            {
                "FeatureGroupName": "login-features",
                "Record": [
                    {"FeatureName": "user_id", "ValueAsString": "user-456"},
                    {"FeatureName": "event_time", "ValueAsString": "2026-06-05T12:00:01Z"},
                    {"FeatureName": "login_count", "ValueAsString": "18"},
                ],
                "TargetStores": ["OnlineStore", "OfflineStore"],
            },
        ]
    )
    
    if response["Errors"]:
        for error in response["Errors"]:
            print(f"Record {error['Entry']}, ErrorCode: {error['ErrorCode']} Failed: {error['ErrorMessage']}")
    
    if response["UnprocessedEntries"]:
        for unprocessed in response["UnprocessedEntries"]:
            print(f"Unprocessed: {unprocessed['FeatureGroupName']}")
    
    if not response["Errors"] and not response["UnprocessedEntries"]:
        print("All records written successfully.")

    Exemplo de código: gravando em múltiplos feature groups

    É possível atingir múltiplos feature groups em uma única requisição. Os registros são agrupados por feature group e processados de forma independente:

    featurestore_runtime = boto3.client("sagemaker-featurestore-runtime")
    
    response = featurestore_runtime.batch_write_record(
        Entries=[
            {
                "FeatureGroupName": "user-profile-features",
                "Record": [
                    {"FeatureName": "user_id", "ValueAsString": "user-123"},
                    {"FeatureName": "event_time", "ValueAsString": "2026-06-05T12:00:00Z"},
                    {"FeatureName": "age", "ValueAsString": "34"},
                    {"FeatureName": "region", "ValueAsString": "us-west-2"},
                ],
                "TargetStores": ["OnlineStore"],
            },
            {
                "FeatureGroupName": "click-features",
                "Record": [
                    {"FeatureName": "user_id", "ValueAsString": "user-123"},
                    {"FeatureName": "event_time", "ValueAsString": "2026-06-05T12:00:00Z"},
                    {"FeatureName": "click_count", "ValueAsString": "42"},
                ],
                "TargetStores": ["OnlineStore", "OfflineStore"],
            },
        ]
    )

    Uma falha em um feature group não afeta os registros destinados a outros feature groups.

    Suporte a TTL (Time-to-Live)

    A API BatchWriteRecord suporta TTL em três níveis de precedência:

    • TTL por registro — Definido via TtlDuration em entradas individuais. Tem a maior prioridade.
    • TTL por requisição — Um TtlDuration padrão no nível superior da requisição, aplicado às entradas sem TTL de registro.
    • TTL por feature group — O TTL configurado no próprio feature group, aplicado quando nem o TTL de registro nem o de requisição estão definidos.

    Considerações importantes

    • Máximo de 25 entradas por requisição, contando o total de entradas em todos os feature groups.
    • Semântica de sucesso parcial: ao contrário de APIs transacionais, o BatchWriteRecord não desfaz gravações bem-sucedidas se alguns registros falharem. Projete a lógica de retry para reenviar apenas os registros retornados em Errors.
    • Modelo de IAM similar ao PutRecord: o chamador precisa ter permissões sagemaker:BatchWriteRecord e sagemaker:PutRecord no ARN (Nome de Recurso da Amazon) de cada feature group alvo.
    • Ordenação por EventTime preservada: um registro desatualizado não pode sobrescrever um mais recente no online store.
    • Flexibilidade de TargetStores: cada entrada pode independentemente ter como alvo o OnlineStore, o OfflineStore ou ambos.

    ListRecords

    A API ListRecords fecha a lacuna na descoberta de registros para ambos os tiers de storage. Ela enumera identificadores de registro dentro de um feature group usando paginação, retornando apenas registros ativos, não deletados e não expirados — prontos para uso com GetRecord ou DeleteRecord.

    O problema com a descoberta de registros

    O Feature Store suporta PutRecord, GetRecord e DeleteRecord, mas todas exigem que o chamador conheça o identificador exato do registro. Não havia API para navegar ou enumerar registros dentro de um feature group.

    Para o tier Standard, o workaround era consultar o offline store via Amazon Athena — o que exige configuração de offline store, adiciona custo e não é em tempo real. Para o tier In-Memory, a situação é crítica: não há offline store correspondente por padrão. Se os identificadores de registro forem perdidos, esses registros se tornam completamente irrecuperáveis, gerando dados fantasmas, custos de storage desperdiçados e riscos de conformidade quando usuários solicitam exclusão de dados.

    Como o ListRecords funciona

    A API funciona com os dois tiers de storage:

    • Tier Standard (Amazon DynamoDB): Faz scan do online store, retornando o identificador da versão mais recente de cada registro. Registros soft-deleted e expirados são automaticamente excluídos.
    • Tier In-Memory (Redis): Faz scan das keys e filtra registros soft-deleted e keys internas do sistema. Retorna identificadores de registro extraídos dos nomes das keys.

    Exemplo de código: enumerar todos os registros de um feature group

    import boto3
    
    featurestore_runtime = boto3.client("sagemaker-featurestore-runtime")
    
    all_identifiers = []
    next_token = None
    
    while True:
        params = {
            "FeatureGroupName": "user-profile-features",
            "MaxResults": 100,
        }
        if next_token:
            params["NextToken"] = next_token
    
        response = featurestore_runtime.list_records(**params)
        all_identifiers.extend(response["RecordIdentifiers"])
        next_token = response.get("NextToken")
    
        if not next_token:
            break
    
    print(f"Found {len(all_identifiers)} active records.")

    Exemplo de código: limpeza de registros órfãos

    Um caso de uso comum é identificar e deletar registros que não são mais necessários. Isso é crítico para feature groups do tier In-Memory, onde registros órfãos persistem indefinidamente:

    import boto3
    
    featurestore_runtime = boto3.client("sagemaker-featurestore-runtime")
    
    # Step 1: Enumerate all record identifiers
    all_ids = []
    next_token = None
    
    while True:
        params = {"FeatureGroupName": "session-features", "MaxResults": 100}
        if next_token:
            params["NextToken"] = next_token
    
        response = featurestore_runtime.list_records(**params)
        all_ids.extend(response["RecordIdentifiers"])
        next_token = response.get("NextToken")
    
        if not next_token:
            break
    
    # Step 2: Compare against your application's active session list
    active_sessions = get_active_sessions()  # Your application logic
    orphaned = [rid for rid in all_ids if rid not in active_sessions]
    
    # Step 3: Delete orphaned records
    for record_id in orphaned:
        featurestore_runtime.delete_record(
            FeatureGroupName="session-features",
            RecordIdentifierValueAsString=record_id,
            EventTime="2026-06-05T12:00:00Z",
        )
    
    print(f"Deleted {len(orphaned)} orphaned records.")

    Comportamento da paginação

    • Tamanho da página: configurável via MaxResults (padrão 10, máximo 100).
    • Formato do token: string opaca e criptografada. Não tente parsear ou construir tokens — passe-os sem alteração.
    • Ordenação: os resultados não têm garantia de ordem específica.
    • Escritas concorrentes: se registros forem gravados ou deletados durante a paginação, podem ocorrer duplicatas ou lacunas. Esse é um comportamento documentado.
    • Escopo do token: tokens estão vinculados a um feature group e conta específicos e não podem ser reutilizados entre eles.

    Considerações importantes

    • Apenas identificadores de registro: a versão atual retorna identificadores de registro sem valores de features. Use GetRecord ou BatchGetRecord para recuperar os registros completos.
    • Filtragem automática: a API exclui registros soft-deleted, expirados e keys internas do sistema. Você vê apenas registros ativos e recuperáveis.
    • Permissão IAM: o chamador precisa ter a permissão sagemaker:ListRecords no ARN do feature group.
    • Ambos os tiers suportados: o ListRecords funciona de forma idêntica do ponto de vista do chamador, independentemente do tier de storage.

    Combinando as duas APIs: um caso de uso completo

    As duas APIs se complementam naturalmente. Veja um exemplo de workflow de conformidade que verifica a exclusão completa de dados de um usuário em múltiplos feature groups:

    import boto3
    
    featurestore_runtime = boto3.client("sagemaker-featurestore-runtime")
    
    feature_groups = ["user-profiles", "click-history", "purchase-signals"]
    user_to_delete = "user-789"
    
    # Step 1: Find and delete the user across all feature groups
    for fg_name in feature_groups:
        all_ids = []
        next_token = None
    
        while True:
            params = {"FeatureGroupName": fg_name, "MaxResults": 100}
            if next_token:
                params["NextToken"] = next_token
    
            response = featurestore_runtime.list_records(**params)
            all_ids.extend(response["RecordIdentifiers"])
            next_token = response.get("NextToken")
    
            if not next_token:
                break
    
        if user_to_delete in all_ids:
            featurestore_runtime.delete_record(
                FeatureGroupName=fg_name,
                RecordIdentifierValueAsString=user_to_delete,
                EventTime="2026-06-05T23:59:59Z",
            )
            print(f"Deleted '{user_to_delete}' from {fg_name}")
    
    # Step 2: Log the deletion event using BatchWriteRecord
    featurestore_runtime.batch_write_record(
        Entries=[
            {
                "FeatureGroupName": "deletion-audit-log",
                "Record": [
                    {"FeatureName": "request_id", "ValueAsString": "del-001"},
                    {"FeatureName": "event_time", "ValueAsString": "2026-06-05T23:59:59Z"},
                    {"FeatureName": "user_id", "ValueAsString": user_to_delete},
                    {"FeatureName": "status", "ValueAsString": "completed"},
                    {"FeatureName": "feature_groups_cleaned", "ValueAsString": "3"},
                ],
                "TargetStores": ["OnlineStore", "OfflineStore"],
            }
        ]
    )

    Limpeza de recursos

    Para evitar cobranças contínuas, exclua os feature groups criados durante os testes. Para feature groups do tier In-Memory, use o ListRecords para enumerar os registros e o DeleteRecord para removê-los antes de excluir o feature group.

    Conclusão

    As APIs BatchWriteRecord e ListRecords representam melhorias significativas no plano de dados do Amazon SageMaker Feature Store. O BatchWriteRecord reduz o volume de chamadas de API para ingestão de alta vazão em até 25x, preservando as garantias de ordenação baseadas em EventTime. O ListRecords habilita a descoberta e o gerenciamento do ciclo de vida de registros — algo crítico para clientes do tier In-Memory, que anteriormente não tinham como enumerar ou limpar seus dados.

    Juntas, essas APIs viabilizam padrões que antes eram difíceis ou impossíveis: pipelines de ingestão em bulk com menos conexões e menor latência, workflows de conformidade que verificam exclusão completa de dados, e ferramentas operacionais que navegam pelo conteúdo de feature groups em tempo real.

    Para mais informações, consulte a documentação do Feature Store, a referência de API do Feature Store, a documentação de configuração do offline store e o anúncio de novidades. Para aprofundar o conhecimento sobre as capacidades do Feature Store, confira também os posts relacionados: Understanding the Key Capabilities of Amazon SageMaker Feature Store, Accelerate ML Feature Pipelines with new capabilities in Amazon SageMaker Feature Store e Using Streaming Ingestion with Amazon SageMaker Feature Store.

    Fonte

    Batch write and discover records in Amazon SageMaker Feature Store (https://aws.amazon.com/blogs/machine-learning/batch-write-and-discover-records-in-amazon-sagemaker-feature-store/)

  • Instâncias Amazon EC2 C8gn já disponíveis na região AWS Europa (Paris)

    Graviton4 chega a Paris: o que muda para workloads de rede

    A AWS expandiu a disponibilidade das instâncias Amazon EC2 C8gn para a região Europa (Paris). Movidas pelos processadores AWS Graviton4 de última geração, essas instâncias entregam até 30% mais desempenho computacional em comparação com as C7gn, que eram baseadas no Graviton3.

    Principais capacidades técnicas

    As instâncias C8gn se destacam especialmente no quesito conectividade. Elas utilizam as Nitro Cards de 6ª geração e oferecem até 600 Gbps de largura de banda de rede — o maior valor disponível entre todas as instâncias EC2 voltadas para cargas de trabalho intensivas em rede.

    Em termos de escalabilidade, as C8gn chegam ao tamanho 48xlarge, com até 384 GiB de memória e até 120 Gbps de banda para o Amazon Elastic Block Store (EBS).

    Para clusters de alto desempenho, os tamanhos 16xlarge, 24xlarge, 48xlarge, metal-24xl e metal-48xl contam com suporte ao Elastic Fabric Adapter (EFA), o que reduz a latência e melhora o desempenho em ambientes com nós fortemente acoplados.

    Casos de uso recomendados

    A AWS posiciona as instâncias C8gn para cenários que exigem alto throughput de rede combinado com eficiência de custo, como:

    • Appliances virtuais de rede (network virtual appliances)
    • Análise de dados em larga escala
    • Inferência de inteligência artificial e aprendizado de máquina (IA/ML) baseada em CPU

    Disponibilidade global

    Com a adição de Paris, as instâncias C8gn estão agora disponíveis em um conjunto amplo de regiões AWS ao redor do mundo:

    • América do Norte: Leste dos EUA (N. Virgínia, Ohio), Oeste dos EUA (Oregon, N. Califórnia), Canadá Oeste (Calgary, Central)
    • Europa: Frankfurt, Estocolmo, Irlanda, Londres, Espanha, Zurique, Milão e Paris
    • Ásia-Pacífico: Singapura, Malásia, Sydney, Tailândia, Mumbai, Seul, Melbourne, Jacarta, Hyderabad, Tóquio, Hong Kong
    • Oriente Médio: EAU
    • África: Cidade do Cabo
    • América do Sul: São Paulo
    • AWS GovCloud: Leste e Oeste dos EUA

    Como começar

    Para quem quiser se aprofundar nas especificações e começar a usar as instâncias C8gn, a AWS disponibiliza documentação e recursos de acesso direto:

    Fonte

    Amazon EC2 C8gn instances are now available in AWS Europe (Paris) region (https://aws.amazon.com/about-aws/whats-new/2026/08/amazon-ec2-c8gn-europe-paris/)