A AWS anunciou a disponibilidade geral do role manager, uma nova funcionalidade dentro do Gerenciamento de Identidade e Acesso (IAM) da AWS que automatiza a criação das roles necessárias para os serviços da plataforma. A novidade foi disponibilizada em 12 de agosto de 2026.
Como funciona o role manager
A ideia central é simples: ao configurar um serviço compatível pelo console da AWS, o role manager cuida automaticamente da criação da role necessária — ou reutiliza uma já existente na conta, caso ela já tenha as permissões adequadas. Isso elimina aquele passo manual de criar e configurar roles do zero toda vez que um novo serviço é habilitado.
A funcionalidade pode ser ativada ou desativada a qualquer momento. Além disso, é possível inspecionar os templates gerenciados pela AWS que o role manager utiliza para criar as roles, garantindo transparência sobre o que está sendo provisionado.
Serviços suportados no lançamento
No lançamento, o role manager oferece suporte a 6 consoles de serviços da AWS, incluindo AWS Lambda e Amazon EventBridge. Por exemplo, ao criar uma função Lambda, o role manager aplica automaticamente o template gerenciado pela AWS correspondente a esse fluxo de trabalho.
Visibilidade e controle total
As roles criadas pelo role manager aparecem no console do IAM como roles padrão — ou seja, o usuário mantém controle total sobre elas. É possível identificar facilmente quais roles foram criadas por essa funcionalidade, o que facilita a auditoria e o gerenciamento.
Quando chegar o momento de restringir permissões com mais precisão, basta desativar o role manager e utilizar o IAM Access Analyzer para refinar cada role, deixando apenas as permissões estritamente necessárias para cada caso.
Disponibilidade
O role manager está disponível em todas as regiões da AWS, com exceção das regiões AWS GovCloud (US) e das regiões da China.
O que é o C5:2020 e por que isso importa para empresas na Europa
Organizações que operam na Alemanha e em outros países europeus enfrentam uma exigência crescente: precisam comprovar que seus ambientes de nuvem estão em conformidade com o Catálogo de Critérios de Conformidade para Computação em Nuvem (C5:2020), um padrão publicado pelo Escritório Federal de Segurança da Informação da Alemanha (BSI — Bundesamt für Sicherheit in der Informationstechnik). Trata-se de um dos marcos regulatórios mais rigorosos da Europa para uso de nuvem pública, e atender a ele exige esforço considerável de arquitetura, documentação e evidências técnicas.
É nesse contexto que a AWS fez um anúncio relevante: a disponibilização de um novo relatório de avaliação independente no AWS Artifact, que analisa como o Landing Zone Accelerator (LZA) cobre os requisitos do C5:2020 por meio da implementação de quase 200 controles de segurança nativos.
O que é o Landing Zone Accelerator (LZA)
O Landing Zone Accelerator (LZA) é uma solução da AWS que automatiza a criação de um ambiente de nuvem seguro e bem arquitetado desde o início. Ele define uma linha de base de arquitetura de segurança e provisiona automaticamente o ambiente AWS de forma que ele escale conforme a organização cresce.
O LZA pode ser utilizado em duas configurações: a configuração padrão com múltiplas contas (multi-account) ou como uma opção de implantação baseada em contêiner no AWS European Sovereign Cloud. Essa segunda opção é especialmente importante para clientes com requisitos de residência de dados, pois permite usar a mesma linha de base de configuração de segurança em um ambiente soberano europeu.
No ano passado, a AWS já havia introduzido suporte do LZA para soberania digital. Agora, o passo seguinte é a publicação desse relatório de avaliação independente voltado ao C5:2020.
O que traz o novo relatório de avaliação independente
O LZA pode ajudar a implementar 325 controles de segurança no total, distribuídos em oito áreas de controle do C5:2020.
O documento descreve o design da arquitetura do LZA, as melhores práticas de segurança e as considerações de escopo para avaliações C5:2020.
Este é o primeiro relatório C5 independente para o LZA — e está prevista uma atualização em 2027 para cobrir a revisão C5:2026, que ainda está pendente.
Como isso acelera a jornada de conformidade
É importante entender a diferença entre o que a AWS já oferecia e o que esse novo relatório acrescenta. A AWS já disponibiliza os relatórios de atestação C5 Tipo 2, que cobrem a “segurança da nuvem” — ou seja, a responsabilidade da própria AWS como provedora de infraestrutura. O novo relatório do LZA, por sua vez, oferece uma opinião independente sobre como a linha de base de segurança provisionada pelo LZA se alinha aos critérios de “segurança na nuvem” — a parte que é responsabilidade do cliente.
Essa distinção é fundamental dentro do modelo de responsabilidade compartilhada. O LZA assume parte dessa responsabilidade do lado do cliente, definindo uma arquitetura de segurança e automatizando o provisionamento do ambiente. Com o relatório em mãos, as organizações podem:
Implantar o LZA já com uma cobertura de controles documentada e avaliada de forma independente;
Usar o relatório para entender o escopo de cobertura existente e identificar o que ainda precisa ser customizado;
Utilizar o LZA Compliance Workbook para construir e adaptar a documentação de conformidade para os casos de uso específicos da organização.
O resultado prático é uma redução significativa no tempo gasto com design de arquitetura, coleta de evidências e preparação para avaliações C5:2020.
Recursos disponíveis: Workbook, repositório e agente de conformidade com IA
Além do relatório de avaliação, a AWS também disponibilizou no AWS Artifact o LZA Compliance Workbook gratuitamente. Esse documento mapeia os identificadores de requisitos do C5:2020 para declarações de implementação de segurança, oferecendo um ponto de partida para que as equipes possam customizar e aprimorar a documentação de conformidade após implantar o LZA.
Por que isso é relevante para o público brasileiro
Embora o C5:2020 seja um padrão alemão, ele é cada vez mais adotado como referência de conformidade em toda a Europa — e empresas brasileiras com operações no continente europeu ou que atendem clientes europeus precisam estar atentas a esse tipo de exigência regulatória. Além disso, a abordagem do LZA — automatizar uma linha de base de segurança documentada e avaliada de forma independente — é um modelo que pode inspirar práticas de conformidade em outros contextos regulatórios.
A disponibilização desse relatório no AWS Artifact representa um avanço concreto para reduzir a carga de trabalho de equipes de segurança e conformidade que precisam demonstrar aderência a padrões rigorosos sem partir do zero.
O NHS DSPT é uma ferramenta de avaliação que permite às organizações medir seu desempenho em relação aos 10 padrões de segurança de dados do Guardião Nacional de Dados (National Data Guardian). Todas as organizações que acessam dados de pacientes e sistemas do NHS — o sistema nacional de saúde do Reino Unido — são obrigadas a utilizar esse toolkit para demonstrar conformidade com os padrões exigidos de segurança de dados.
Entre os temas cobertos pela avaliação estão:
Dados Pessoais Confidenciais
Planejamento de Continuidade
Proteção de TI
Outros padrões relacionados à proteção de dados no setor de saúde
Por que a AWS passa por essa avaliação?
A AWS submete-se ao NHS DSPT para oferecer garantias concretas aos seus clientes de que a empresa adota boas práticas de segurança de dados. Trata-se de um compromisso importante para organizações do setor de saúde no Reino Unido que utilizam a nuvem AWS para armazenar ou processar informações sensíveis de pacientes.
A certificação obtida neste ciclo é válida até 30 de junho de 2027. O certificado que confirma a conformidade está disponível tanto no site do NHS England quanto no AWS Artifact.
O que é o AWS Artifact?
O AWS Artifact é um portal de autoatendimento que oferece acesso sob demanda a relatórios de conformidade da AWS. Por meio dele, clientes conseguem acessar documentos de auditoria e certificações relevantes para suas necessidades regulatórias. Para utilizá-lo, basta acessar o AWS Artifact no Console de Gerenciamento da AWS ou consultar o guia de Introdução ao AWS Artifact.
Responsabilidade Compartilhada
Vale reforçar um conceito fundamental para qualquer cliente AWS: segurança e conformidade na nuvem são uma responsabilidade compartilhada entre a AWS e o próprio cliente. Quando uma organização migra seus sistemas e dados para a nuvem, as responsabilidades de segurança são divididas entre o cliente e o provedor de serviços. Para entender melhor essa divisão, a AWS disponibiliza o Modelo de Responsabilidade Compartilhada de Segurança da AWS.
AWS disponibiliza relatório SOC 1 com cobertura de 185 serviços
A Amazon Web Services (AWS) anunciou a disponibilidade do relatório de Controles de Sistema e Organização (SOC) 1 referente ao ciclo de Verão 2026. Trata-se de uma atualização importante para empresas que dependem de conformidade regulatória ao usar a nuvem da AWS — especialmente aquelas sujeitas a auditorias financeiras e de controles internos.
O que está coberto neste relatório
O relatório SOC 1 do ciclo Verão 2026 cobre 185 serviços da AWS ao longo de um período de 12 meses completos, de 1º de julho de 2025 a 30 de junho de 2026. Esse intervalo anual é relevante porque oferece aos clientes uma garantia contínua e abrangente sobre os controles dos serviços utilizados, sem lacunas de cobertura.
A publicação desse relatório reforça o compromisso da AWS com padrões elevados de conformidade para provedores de serviços em nuvem — algo que tem peso direto na hora de demonstrar conformidade para auditores e reguladores.
Como acessar o relatório
O relatório está disponível para download pelo AWS Artifact, portal de autoatendimento da AWS para acesso sob demanda a documentos de conformidade. Para obtê-lo, basta acessar o AWS Artifact no Console de Gerenciamento da AWS. Caso ainda não conheça a ferramenta, a AWS disponibiliza um guia introdutório em Primeiros Passos com o AWS Artifact.
Lista de serviços no escopo
A AWS mantém uma página atualizada com todos os serviços que fazem parte do escopo dos seus programas de conformidade. Para consultar a lista completa e verificar se os serviços que você utiliza estão incluídos, acesse a página de Serviços no Escopo.
A AWS segue ampliando continuamente o número de serviços cobertos por seus programas de conformidade, com o objetivo de ajudar os clientes a atender tanto requisitos arquiteturais quanto regulatórios.
Dúvidas sobre conformidade SOC
Clientes que tiverem dúvidas ou quiserem dar feedback sobre a conformidade SOC podem entrar em contato diretamente com o time de conta da AWS. Para uma visão mais ampla sobre os programas de conformidade e segurança da AWS, consulte os Programas de Conformidade da AWS.
Nunca as equipes de segurança tiveram tanto poder computacional à disposição — e nunca precisaram tanto dele. Os modelos de IA de fronteira já conseguem raciocinar sobre bases de código inteiras, rastrear a causa raiz de uma vulnerabilidade e propor correções em minutos. O problema é que essas mesmas capacidades estão disponíveis para os adversários também.
É por isso que a janela entre a divulgação de uma vulnerabilidade e sua exploração ativa continua encolhendo. Os defensores precisam navegar por bases de código extensas e pouco familiares, validar quais descobertas são reais, desenvolver patches que funcionem — e fazer tudo isso antes que o tempo acabe. O desafio não é mais encontrar problemas potenciais, mas confirmar quais são genuínos, corrigi-los e agir antes que a janela se feche.
A parceria: OpenAI e AWS no Amazon Bedrock
A AWS sempre operou com o princípio de que a segurança deve ser incorporada desde o início. O mesmo vale para IA: os clientes executam cargas de trabalho no Amazon Bedrock, desde inferência até agentes totalmente autônomos, sob a mesma infraestrutura, controles e governança que já utilizam em todo o ambiente AWS.
Agora, a AWS e a OpenAI estão estendendo essa base para a defesa cibernética. O Daybreak Red e o Daybreak Blue da OpenAI estão disponíveis no Amazon Bedrock para clientes elegíveis.
Daybreak Red oferece acesso ao GPT-5.6 Cyber, um modelo de cibersegurança treinado especificamente para essa finalidade.
Daybreak Blue oferece acesso ao GPT-5.6 Sol, com salvaguardas calibradas para trabalhos defensivos de cibersegurança.
Ambos fazem parte do Daybreak, a iniciativa de defesa cibernética da OpenAI que oferece aos defensores acesso governado à IA de fronteira — incluindo ferramentas agênticas, red teaming de aplicações e serviços que ajudam a avançar de descobertas até correções testadas.
Segundo a própria AWS, as equipes de segurança da empresa já utilizam ambos os modelos para analisar código-fonte, descobrir vulnerabilidades e conduzir pesquisas de red team. No Bedrock, esse trabalho roda sob os mesmos controles de infraestrutura aplicados a qualquer outra carga de trabalho crítica.
Modelos especializados para trabalhos avançados de segurança
O caminho entre descobrir uma vulnerabilidade e corrigi-la é longo: confirmar se ela é explorável, rastrear como o componente vulnerável é acessível, desenvolver uma correção que trate a causa raiz sem introduzir regressões, validar que a correção funciona em condições realistas e entregar o patch dentro da janela de divulgação. Os defensores precisam de modelos capazes de acelerar cada uma dessas etapas.
A cibersegurança é, por natureza, de uso dual. Uma solicitação para reproduzir uma vulnerabilidade ou fazer engenharia reversa de uma cadeia de exploit é idêntica independentemente da intenção — e modelos de uso geral resolvem essa ambiguidade simplesmente recusando a solicitação. O Daybreak Red e o Daybreak Blue resolvem isso pelo contexto: quem está usando o modelo, onde o trabalho ocorre e quais salvaguardas governam esse acesso.
Daybreak Blue: ponto de partida para a maioria das equipes
O Daybreak Blue é indicado para a maioria das equipes de segurança. Ele suporta descoberta de vulnerabilidades, engenharia de detecção e resposta a incidentes.
Daybreak Red: para tarefas avançadas
O Daybreak Red é projetado para tarefas avançadas como pesquisa de vulnerabilidades, reprodução de exploits e desenvolvimento de mitigações. Para essas atividades, um limiar de recusa mais baixo — combinado com verificação de identidade mais rigorosa, monitoramento e controles de acesso mais fortes — melhora a velocidade e a profundidade de uma investigação.
Como exemplo concreto, a OpenAI relata que pesquisadores de segurança utilizando o GPT-5.6 Cyber pelo Daybreak Red identificaram duas vulnerabilidades previamente desconhecidas no V8, o motor JavaScript utilizado pelo Chrome. Quando encadeadas, essas falhas poderiam permitir corrupção de memória e escape do heap sandbox. A vulnerabilidade inicial foi corrigida e registrada como CVE-2026-15903 — uma das apenas quatro entradas bem-sucedidas de zero-day no V8 CTF em 2026.
Rodando na infraestrutura em que você já confia
Uma carga de trabalho de cibersegurança alimenta o modelo com os seus insumos mais sensíveis: código-fonte proprietário, detalhes de vulnerabilidades ainda não corrigidas e telemetria ao vivo de sistemas em produção. Antes de qualquer coisa passar por um modelo, é preciso ter certeza sobre para onde vai e quem pode ver.
Ambos os modelos rodam no mecanismo de inferência de nova geração do Amazon Bedrock, construído para alta performance, segurança e confiabilidade. Os principais controles incluem:
Acesso zero por operadores (ZOA — Zero-Operator Access): aplicado no nível do chip, impedindo que até mesmo operadores da AWS acessem seus prompts e respostas durante a inferência.
Criptografia: tudo é criptografado em trânsito e em repouso com chaves gerenciadas pelo cliente via Serviço de Gerenciamento de Chaves da AWS (AWS KMS — Key Management Service).
Controle de acesso e auditoria: o acesso é governado pelas suas políticas de Gerenciamento de Identidade e Acesso da AWS (AWS IAM — Identity and Access Management), registrado no AWS CloudTrail e roteado por endpoints de Nuvem Privada Virtual (VPC — Virtual Private Cloud).
Perímetro de dados: é possível configurar políticas de perímetro de dados no nível organizacional para evitar exfiltração entre limites de conta e rede.
Os dados de inferência não são utilizados para treinamento dos modelos, e nenhum dos dois modelos exige que o cliente opte por compartilhar dados com a OpenAI. Para detecção automatizada de abuso, o tráfego sinalizado por classificadores é retido pela AWS por até 30 dias e processado de forma programática. Clientes podem solicitar retenção zero de dados por meio da equipe de contas AWS. Consulte a política de retenção de dados para mais detalhes.
Como começar
O Daybreak Red (GPT-5.6 Cyber) e o Daybreak Blue (GPT-5.6 Sol) estão disponíveis para clientes elegíveis no Amazon Bedrock na seguinte região AWS: US East (N. Virginia).
O acesso aos modelos requer inscrição no programa Trusted Access for Cyber da OpenAI. Para se inscrever, entre em contato com a OpenAI ou com a equipe de contas AWS para orientação sobre elegibilidade. Após a aprovação, trabalhe com sua equipe de contas para solicitar o acesso na AWS. Para saber mais, consulte a documentação oficial.
Quando uma empresa começa a distribuir o Claude Code e o Claude Desktop para dezenas ou centenas de desenvolvedores, surgem perguntas que não têm resposta fácil sem uma camada de controle dedicada: quem está usando qual modelo? Quanto cada time está gastando? Como revogar acesso imediatamente quando alguém sai da empresa? Como garantir que contratados não acessem modelos mais caros que o necessário?
O Claude Apps Gateway foi criado exatamente para isso. Trata-se de uma camada de governança self-hosted que fica entre essas aplicações e o Amazon Bedrock (ou o Claude Platform on AWS), centralizando autenticação, políticas de acesso, telemetria e controle de custos em um único ponto. A AWS publicou agora uma referência completa de implantação em produção, expandindo o post de lançamento inicial com arquitetura detalhada, padrões corporativos e recursos de implementação.
Computação e estado: cada tarefa do Fargate executa um container stateless do gateway. O Amazon Relational Database Service (Amazon RDS) para PostgreSQL armazena o estado de autenticação de curta duração — códigos de dispositivo, sessões, contadores de gasto por usuário e registros de auditoria. Como o estado vive no banco e não no container, qualquer tarefa pode atender qualquer requisição, sem necessidade de sessões fixas no balanceador.
Conectividade de serviços: endpoints de VPC mantêm o tráfego de serviços AWS no perímetro privado, enquanto um NAT gateway fornece o egresso externo necessário.
Credenciais upstream: o gateway se autentica no Amazon Bedrock usando a role do AWS Identity and Access Management (IAM) atribuída à tarefa. A chave de API do Claude Platform on AWS e outras credenciais estáticas ficam no AWS Secrets Manager. Nenhuma credencial upstream chega às máquinas dos desenvolvedores.
Nota operacional importante: o timeout de inatividade do load balancer deve ser configurado para superar o maior intervalo esperado sem dados. O padrão é 60 segundos — conexões ociosas além desse limite são encerradas. Vale verificar tanto respostas não-streaming com atraso quanto pausas entre chunks em respostas streaming.
O fluxo tem duas etapas distintas. No login (uma vez por sessão), o time de plataforma distribui configurações gerenciadas (managed settings) que apontam o Claude Code e o Claude Desktop para a URL privada do gateway. Quando o desenvolvedor executa /login, o cliente inicia o fluxo OAuth 2.0 de autorização de dispositivo e abre o navegador para autenticação via provedor de identidade OpenID Connect (OIDC). Após autenticação, o gateway emite um token de curta duração (válido por 1 hora por padrão), com renovação silenciosa em background.
Nas requisições de inferência, cada chamada carrega o bearer token. O gateway o valida, resolve identidade e grupos do desenvolvedor, aplica a política correspondente, avalia o limite de gasto e roteia a requisição para o Amazon Bedrock ou Claude Platform on AWS. A resposta retorna em streaming. As métricas de uso são encaminhadas via Protocolo OpenTelemetry (OTLP) para o coletor configurado, atribuídas à identidade autenticada.
O gateway delega a autenticação ao provedor de identidade OIDC da empresa. Os desenvolvedores fazem login uma única vez via SSO no navegador. Provedores compatíveis incluem Okta, Microsoft Entra ID, Auth0, Keycloak e Amazon Cognito.
O gateway não mantém diretório de usuários próprio — não há contas para pré-criar nem sincronização SCIM para configurar. Os grupos que o provedor de identidade atribui ao usuário são os mesmos usados para correspondência de políticas, sem camada de tradução. O desligamento de um colaborador é simplesmente removê-lo do provedor: a sessão expira dentro do tempo configurado (1 hora por padrão), sem necessidade de rotacionar credenciais.
Atenção: o Microsoft Entra ID não inclui claims de grupo ou role por padrão. Se as políticas usarem match: {groups: [...]} com roles do Entra, é necessário adicionar groups_claim: roles à configuração OIDC. Sem isso, o gateway não consegue resolver membros de grupo e todos os usuários correspondem apenas à política catch-all. Para instruções específicas por provedor, consulte o guia de configuração de provedores de identidade.
2. Políticas centralizadas de acesso a modelos
O gateway aplica o controle de acesso a modelos no lado do servidor e distribui permissões de ferramentas como configurações gerenciadas, com escopo por grupo do provedor de identidade. As políticas são avaliadas na ordem de declaração — a primeira correspondência é selecionada e mesclada com a política base match: {}. Sempre inclua uma política match: {} ao final como catch-all; sem ela, usuários sem correspondência recebem acesso irrestrito ao catálogo.
Managed:
policies:
# Contratados: apenas Haiku, sem acesso à web
- match: { groups: [contractors] }
cli:
availableModels: [claude-sonnet-5, claude-haiku-4-5]
enforceAvailableModels: true
permissions:
deny: ["WebFetch", "WebSearch"]
# Engenheiros: acesso completo com restrições
- match: { groups: [engineers] }
cli:
availableModels: [claude-opus-4-8, claude-sonnet-5, claude-haiku-4-5]
permissions:
allow: [Read, Grep, Bash, Edit]
deny: ["Read(./.env)", "Read(./secrets/**)"]
# Catch-all: todos os outros usuários autenticados. Deve ser o último.
- match: {}
cli:
availableModels: [claude-haiku-4-5, claude-sonnet-5]
O controle de modelos é aplicado no servidor. Um desenvolvedor cujo grupo permite apenas Claude Haiku não consegue contornar a restrição, mesmo com um cliente modificado. O seletor de modelos no Claude Code e no Claude Desktop exibe apenas os modelos permitidos. Alterações propagam para clientes conectados em até uma hora, sem ação necessária dos desenvolvedores.
Atenção: inclua desktop: {} em cada entrada de política para habilitar clientes Claude Desktop. Sem isso, o gateway rejeita requisições de inferência do Desktop para usuários que correspondem àquela política, mesmo que o login tenha sido bem-sucedido. Para o schema completo de políticas, consulte a referência de configuração.
3. Telemetria e atribuição por usuário
O cliente emite métricas de uso (claude_code.token.usage, claude_code.cost.usage e claude_code.active_time.total) atribuídas à identidade do desenvolvedor autenticado: ID de usuário, e-mail e grupos. O gateway repassa essa telemetria via Protocolo OpenTelemetry (OTLP) para o coletor configurado. Backends compatíveis incluem Datadog, Splunk, Grafana e Amazon CloudWatch via coletor AWS Distro for OpenTelemetry (ADOT).
Logs e traces são opt-in porque podem conter código-fonte e conteúdo de prompts. A maioria das implantações começa apenas com métricas, que fornecem breakdowns de custo e uso por usuário sem expor dados sensíveis. Mais detalhes na página de configuração do Claude Apps Gateway.
4. Roteamento com failover
O gateway roteia inferência para um ou mais upstreams na ordem declarada, com failover automático em caso de indisponibilidade, throttling ou timeout. É possível combinar Amazon Bedrock em múltiplas regiões e Claude Platform on AWS:
upstreams:
# Amazon Bedrock (usa a role da task ECS, sem chaves estáticas)
- name: bedrock-east
provider: bedrock
region: us-east-1
auth: {}
# Amazon Bedrock em segunda região para failover
- name: bedrock-west
provider: bedrock
region: us-west-2
auth: {}
# Claude Platform on AWS (fallback entre provedores)
- name: claude-platform
provider: anthropicAws
region: us-east-1
workspace_id: wrkspc_01ABCDEFGHIJKLMN
auth:
api_key: ${ANTHROPIC_AWS_API_KEY}
Atenção: failover entre provedores diferentes pode alterar os termos de serviço aplicáveis e a geografia de processamento de dados. Para o schema completo de upstreams, consulte a referência de upstreams.
5. Limites de gasto por usuário
Enquanto o AWS Budgets e o AWS Cost Explorer oferecem visibilidade no nível de conta com agregação periódica, o gateway complementa essas ferramentas com enforcement inline antes da inferência ocorrer. Os limites operam em três níveis: padrão organizacional, por grupo e por usuário (com precedência nessa ordem, do mais específico para o mais geral). Cada limite se aplica individualmente por desenvolvedor, não como pool compartilhado.
# Padrão organizacional: $500/mês por desenvolvedor (valores em centavos de USD)
curl -X POST https://<gateway>/v1/organizations/spend_limits \
-H "x-api-key: $ADMIN_KEY" \
-H "Content-Type: application/json" \
-d '{"scope":{"type":"organization"},"amount":"50000","period":"monthly"}'
# Limite mais restritivo para um grupo: $10/dia para contratados
curl -X POST https://<gateway>/v1/organizations/spend_limits \
-H "x-api-key: $ADMIN_KEY" \
-H "Content-Type: application/json" \
-d '{"scope":{"type":"rbac_group","rbac_group_id":"contractors"},"amount":"1000","period":"daily"}'
# Bloqueio imediato de um usuário: limite zerado
curl -X POST https://<gateway>/v1/organizations/spend_limits \
-H "x-api-key: $ADMIN_KEY" \
-H "Content-Type: application/json" \
-d '{"scope":{"type":"user","user_id":"<oidc-sub>"},"amount":"0","period":"daily"}'
Quando o desenvolvedor atinge o teto, o gateway retorna HTTP 429 imediatamente. Os contadores resetam automaticamente no início de cada período (diário, semanal ou mensal). Os limites de gasto são gerenciados exclusivamente via Admin API — não há interface gráfica. Times de plataforma tipicamente automatizam isso com um script que sincroniza limites de um arquivo de configuração versionado como parte do pipeline de deploy, ou via Terraform chamando a API.
Limitações importantes: o gasto é estimado com base em contagens de tokens pelo preço de tabela — é um circuit breaker em tempo real, não uma fatura. Descontos por uso comprometido e taxas negociadas não são refletidos. Se o banco de dados estiver indisponível, o enforcement falha aberto por padrão (inferência continua). Organizações que precisam de enforcement estrito podem configurar fail_closed_on_error: true para bloquear requisições. Para faturamento definitivo, reconcilie com os logs de invocação do Amazon Bedrock ou o AWS Cost and Usage Report. Detalhes completos na documentação de limites de gasto.
Padrões de implantação
A forma de implantar o gateway depende da estrutura da organização, dos padrões de tráfego e dos requisitos de governança. Não existe uma arquitetura única correta. A AWS descreve cinco padrões principais:
Padrão A: Time único, região única
Recomendado para times avaliando o gateway ou organizações com um único grupo de desenvolvimento em uma região. Implantação mínima: um upstream Amazon Bedrock em us-east-1, um limite de gasto diário organizacional e todos os desenvolvedores com o mesmo acesso a modelos. Ponto de partida ideal — adicione complexidade conforme o caso de uso exigir.
Padrão B: Multi-time com acesso diferenciado
Indicado para organizações com múltiplos times que precisam de níveis diferentes de acesso a modelos e limites de gasto. Os grupos do provedor de identidade direcionam políticas diferenciadas. Por exemplo: engenharia de plataforma com acesso a Opus + Sonnet + Haiku e $50/dia; desenvolvedores de aplicação com Sonnet + Haiku e $20/dia; contratados apenas com Haiku, $5/dia e ferramentas web bloqueadas. Os limites de grupo são herdados individualmente por cada desenvolvedor, não como orçamento compartilhado.
Padrão C: Amazon Bedrock + Claude Platform on AWS (híbrido)
Ideal para organizações que querem o Amazon Bedrock como upstream preferencial com o Claude Platform on AWS como capacidade de overflow. As requisições vão primeiro para o Bedrock; somente em caso de rate limit ou indisponibilidade o gateway faz fallback para o Claude Platform on AWS.
Padrão D: Gateway para ferramentas de desenvolvimento, Bedrock direto para aplicações
Recomendado para organizações onde as ferramentas de desenvolvimento precisam de governança (SSO, limites de gasto, telemetria), mas as aplicações de produção chamam o Amazon Bedrock diretamente com cotas isoladas e acesso a funcionalidades nativas como Amazon Bedrock Knowledge Bases, Agents e Flows — que o gateway não faz proxy.
Recomendado para organizações onde um time central de plataforma opera o gateway e unidades de negócio individuais possuem seu próprio acesso ao Amazon Bedrock em contas separadas. O faturamento cai na conta de cada time; o gateway roteia para o upstream correto com base na configuração de modelos.
Atenção: o gateway não assume nativamente uma role IAM diferente por upstream. O roteamento multi-conta requer credenciais explícitas na configuração de upstreams. Armazene essas credenciais no AWS Secrets Manager e rotacione-as periodicamente. Chaves de acesso de longa duração representam um tradeoff significativo de segurança. Considere um processo externo que atualize periodicamente credenciais de curta duração do AWS Security Token Service (AWS STS) no ambiente do gateway para reduzir a exposição.
O Claude Apps Gateway entrega cinco capacidades — autenticação SSO, políticas de modelos por grupo, telemetria por usuário, roteamento multi-região com failover e limites de gasto — em um único container e um arquivo YAML. Não há taxa por assento. Quando o Amazon Bedrock é o upstream, nenhum dado dos desenvolvedores sai da conta AWS. Os desenvolvedores continuam usando o mesmo binário claude que já conhecem; o gateway é invisível para eles após o login inicial.
Para começar, clone o repositório no GitHub e escolha uma de duas trilhas — ambas provisionam o mesmo deployment no Amazon ECS Fargate: um ALB interno, Amazon RDS para PostgreSQL, ECR, Secrets Manager, uma role IAM para a task e um coletor de telemetria ADOT. A escolha é entre o script idempotente setup.sh, para visibilidade total de cada chamada AWS, ou um stack do AWS Cloud Development Kit (AWS CDK) para um ciclo de vida gerenciado. Para detalhes de configuração, consulte a documentação do Claude Apps Gateway.
Novos modelos de fundação disponíveis no SageMaker JumpStart
A AWS expandiu o catálogo de modelos de fundação do Amazon SageMaker JumpStart com a chegada de três novos modelos: LocateAnything-3B, da NVIDIA, e Qwen-AgentWorld-35B-A3B e Qwen3.5-122B-A10B, ambos da Qwen. Juntos, eles cobrem capacidades especializadas em ancoragem visual, simulação de ambientes para agentes e raciocínio multimodal em larga escala.
O que cada modelo oferece
LocateAnything-3B — Localização visual por linguagem natural
O LocateAnything-3B da NVIDIA é otimizado para ancoragem visual (visual grounding) e localização de objetos a partir de instruções em linguagem natural. O modelo utiliza um framework chamado Decodificação Paralela de Caixas (PBD — Parallel Box Decoding), que decodifica caixas delimitadoras e pontos como unidades atômicas em uma única etapa. Essa abordagem preserva a coerência geométrica e permite alto grau de paralelismo no processamento.
O modelo é indicado para casos de uso em Inteligência Empresarial e IA Física, cobrindo localização precisa de objetos, detecção densa e localização baseada em pontos em domínios variados.
Qwen-AgentWorld-35B-A3B — Simulação de ambientes para agentes
O Qwen-AgentWorld-35B-A3B se destaca na simulação de ambientes de agentes em sete domínios de interação: chamada de ferramentas, busca, terminal, engenharia de software, Android, web e interação com sistema operacional. É apresentado como o primeiro modelo de linguagem de mundo (language world model) a cobrir todos esses sete domínios dentro de um único modelo.
O funcionamento é baseado em raciocínio por cadeia de pensamento longa (long chain-of-thought reasoning), prevendo os próximos estados do ambiente a partir das ações e do histórico de interações de um agente. O treinamento foi realizado com mais de 10 milhões de trajetórias reais de interação.
Qwen3.5-122B-A10B — Raciocínio multimodal de alta performance
O Qwen3.5-122B-A10B entrega raciocínio multimodal de alta performance com eficiência voltada para produção. O modelo conta com 122 bilhões de parâmetros totais, mas ativa apenas 10 bilhões por token, graças a uma arquitetura híbrida que combina Redes Delta com Porta (Gated Delta Networks) com uma Mistura Esparsa de Especialistas (MoE — Mixture-of-Experts) com 256 especialistas.
O resultado é forte desempenho em raciocínio, codificação, agentes e compreensão visual, com uma janela de contexto nativa de 262 mil tokens e baixa sobrecarga de latência.
Como acessar os modelos
Com o SageMaker JumpStart, os clientes da AWS podem implantar qualquer um desses modelos com poucos cliques, diretamente pelo catálogo de modelos no console do SageMaker ou via SageMaker Python SDK. Para mais detalhes sobre como implantar e utilizar modelos de fundação no SageMaker JumpStart, consulte a documentação oficial do Amazon SageMaker JumpStart.
Integração direta entre AWS Glue e SageMaker Unified Studio
A AWS anunciou uma novidade que vai simplificar bastante o dia a dia de engenheiros de dados e analistas: o AWS Glue agora oferece acesso direto ao Amazon SageMaker Unified Studio com um único clique, diretamente pelo console da AWS.
Na prática, quem já trabalha no console do Glue — seja navegando por tabelas do catálogo ou construindo jobs de Extração, Transformação e Carga (ETL) — agora pode abrir o SageMaker Unified Studio instantaneamente e começar a trabalhar com os dados imediatamente, sem precisar trocar de aba ou refazer configurações de acesso.
O que muda na prática
Com essa integração, o SageMaker Unified Studio passa a ser acessível com um clique a partir de cinco consoles da AWS:
S3 Tables
Athena
EMR
Redshift
AWS Glue
A partir do console do Glue, o usuário pode abrir o SageMaker Unified Studio e já começar a trabalhar com os dados do catálogo ou executar consultas via SageMaker Notebooks — e tudo isso utilizando a mesma função do Gerenciamento de Identidade e Acesso (IAM) já configurada, sem necessidade de reautenticação ou reconfiguração.
Configuração simplificada para novos usuários
Para quem ainda não configurou o SageMaker Unified Studio, a AWS também trouxe uma melhoria importante no processo de setup. Um novo painel de permissões inline foi adicionado diretamente ao fluxo de configuração, permitindo criar e ajustar as políticas de IAM necessárias sem precisar navegar até o console do IAM em outra aba do navegador.
Isso significa que é possível reutilizar a função IAM existente e personalizar as permissões no próprio contexto, reduzindo significativamente o número de etapas para começar a usar o serviço.
Disponibilidade
O recurso já está disponível em todas as regiões da AWS onde o Amazon SageMaker Unified Studio é suportado. Para experimentar, basta acessar o console do AWS Glue.
A AWS anunciou uma expansão importante na capacidade de rastreamento de custos do Amazon Bedrock: agora é possível alocar custos de inferência de modelos por principal do Gerenciamento de Identidade e Acesso (IAM), incluindo usuários e funções (roles) do IAM, para requisições feitas pelo endpoint bedrock-mantle.
Essa funcionalidade já existia para o endpoint bedrock-runtime e agora chega ao bedrock-mantle, completando a cobertura para equipes que utilizam os dois pontos de acesso do serviço.
Por que isso importa
Em ambientes corporativos, múltiplos times, projetos e aplicações costumam compartilhar a mesma conta AWS — e saber exatamente quem está gerando qual custo de inferência de IA é uma necessidade real de governança financeira. Com essa expansão, a AWS permite que as organizações atribuam os custos de inferência do bedrock-mantle a usuários, equipes, projetos e aplicações de forma granular.
Como funciona na prática
O mecanismo é baseado em tags de alocação de custos do IAM. O fluxo funciona da seguinte forma:
Adicione tags aos usuários e funções do IAM com atributos relevantes, como equipe, projeto ou centro de custo.
Ative essas tags como tags de alocação de custos no console de Faturamento e Gerenciamento de Custos da AWS.
Filtre ou agrupe os custos por essas tags no AWS Cost Explorer.
Alternativamente, crie uma exportação de dados no Relatório de Custo e Uso 2.0 (CUR 2.0) e selecione a opção Include caller identity (IAM principal) allocation data para obter os dados no nível de linha de item.
Disponibilidade
O recurso está disponível em todas as regiões da AWS onde o endpoint bedrock-mantle já está disponível.
A AWS anunciou que o modelo NVIDIA Nemotron 3.5 Lightning está agora disponível no Amazon SageMaker JumpStart. Com isso, os clientes AWS passam a ter acesso ao modelo aberto mais rápido de sua categoria, projetado especificamente para cargas de trabalho com agentes persistentes e execução ágil de tarefas.
Para que serve o Nemotron 3.5 Lightning
O modelo foi desenvolvido com foco em automação empresarial de alto volume em diferentes domínios. Entre os casos de uso destacados pela NVIDIA estão:
Assistentes pessoais inteligentes
Processamento de documentos financeiros
Triagem em cibersegurança
Operações em telecomunicações
A proposta central é atender cenários onde agentes de IA precisam operar de forma contínua e com alta demanda de processamento.
Arquitetura técnica
O Nemotron 3.5 Lightning é construído sobre uma arquitetura híbrida de Mistura de Especialistas (MoE — Mixture-of-Experts), com 30 bilhões de parâmetros totais, mas apenas 3 bilhões de parâmetros ativos por passagem. Essa abordagem permite um desempenho expressivo sem o custo computacional de ativar toda a rede a cada inferência.
Os números de desempenho são relevantes: o modelo alcança até 4x mais throughput (aproximadamente 410 tokens por segundo) e 30% mais velocidade na conclusão de tarefas em comparação com modelos similares. Ele também suporta até 1 milhão de tokens de contexto, viabilizado pela técnica de decodificação especulativa DFlash.
O modelo foi destilado a partir do Nemotron 3 Ultra e possui integração nativa com os principais frameworks de agentes do mercado.
Abertura e flexibilidade para empresas
Um diferencial importante é que o Nemotron 3.5 Lightning foi treinado integralmente em conjuntos de dados abertos. Isso significa que empresas podem realizar pós-treinamento do modelo para adaptá-lo às suas próprias ferramentas, fluxos de trabalho e políticas internas — e fazer o deploy com total propriedade sobre a infraestrutura, seja em edge, on-premises ou nuvem.
Como acessar pelo SageMaker JumpStart
Com o SageMaker JumpStart, o deploy do modelo pode ser feito em poucos cliques, sem a necessidade de configurações complexas. Para começar, basta acessar o catálogo de modelos do SageMaker JumpStart pelo console do SageMaker, ou utilizar o SageMaker Python SDK para realizar o deploy diretamente na conta AWS.
