Em 1º de outubro de 2026, a Amazon Web Services publicou no seu blog de machine learning um guia completo para configurar acesso multiambiente ao Claude Platform on AWS a partir de uma única assinatura. O texto parte de um cenário comum nas empresas: a necessidade de consumir inferência de três lugares diferentes — cargas de produção rodando na própria AWS, notebooks de desenvolvedores para iteração local e serviços externos hospedados em outras nuvens ou em pipelines de CI/CD on-premises.
Cada ambiente tem exigências próprias de autenticação, mas todos devem compartilhar a mesma assinatura, com isolamento por workspace entre o tráfego de produção e o de desenvolvimento.
Conta dedicada e isolamento por workspace
A arquitetura proposta coloca a assinatura do Claude Platform on AWS (CPonAWS) em uma conta de Serviços de IA dedicada dentro da organização. Essa conta concentra a assinatura, os workspaces, as chaves de API e os papéis de acesso entre contas.
As contas de carga de trabalho não tocam a assinatura diretamente: elas assumem papéis na conta de Serviços de IA para fazer as chamadas de inferência. O resultado é uma estrutura de três contas, a conta pagadora (management), responsável por faturamento e governança; a conta de Serviços de IA, que hospeda a assinatura e os workspaces; e uma ou mais contas de carga de trabalho que consomem inferência via papéis cross-account.
Organizações com mais ambientes podem criar um workspace por time ou por carga de trabalho e repetir o padrão de papel entre contas para cada um deles.
Três caminhos de autenticação
O guia detalha três padrões de acesso. No primeiro, cargas na AWS usam SigV4 entre contas: um pod hospedado no Amazon Elastic Kubernetes Service (Amazon EKS) em uma conta de carga de trabalho assume um papel na conta de Serviços de IA e passa a fazer chamadas de inferência assinadas com SigV4, sem chaves de API armazenadas e sem segredos para rotacionar.
No segundo, desenvolvedores recebem uma chave de API de longa duração restrita a um workspace de desenvolvimento e a utilizam localmente com o SDK padrão da Anthropic. No terceiro, cargas externas usam federação OpenID Connect (OIDC) e chaves de curta duração: o workload se autentica via OIDC, obtém credenciais temporárias da AWS, gera um token de curta duração e faz as chamadas de inferência sem nenhuma credencial persistente.
Pré-requisitos e execução
Antes de começar, o material pede uma organização no AWS Organizations com conta pagadora, uma conta vinculada para as assinaturas de Serviços de IA e uma conta vinculada para hospedar a carga de trabalho (o exemplo usa o nome "Prod"). Também são necessários o AWS Command Line Interface (AWS CLI) v2, configurado com perfis nomeados para as duas contas, e Python 3.12 ou superior com os pacotes Anthropic[aws], boto3 e token-generator-for-aws-external-Anthropic.
O passo a passo é dividido em quatro partes, pensadas para serem executadas em ordem, cada uma configurando uma camada: a assinatura e a estrutura de workspaces, o acesso SigV4 entre contas para cargas na AWS, as chaves de API por workspace para desenvolvedores e a federação OIDC para ambientes externos. Cada etapa traz um comando de CLI, uma instrução de console ou um trecho de código, o que reduz o espaço para configurações improvisadas.
Por que isso importa
Para empresas que colocam IA generativa em produção, o ponto central do guia é o controle de alcance e de custo. Ao isolar a assinatura em uma conta própria e separar produção de desenvolvimento em workspaces distintos, a organização consegue aplicar políticas de IAM e rastreamento onde a assinatura realmente vive, sem replicar credenciais em cada conta de time.
O padrão também evita que segredos de longa duração circulem por pipelines: nos caminhos SigV4 e OIDC, as credenciais são temporárias e assumidas por papel, o que reduz a superfície de exposição caso um ambiente seja comprometido.
Vale notar a assimetria entre os caminhos: apenas o acesso de desenvolvedores depende de uma chave de longa duração, ainda que restrita a um workspace de desenvolvimento. Os outros dois foram desenhados para não guardar credenciais permanentes, o que indica qual opção tende a ser preferida em ambientes automatizados e em produção.
O material também remete a dois textos anteriores que ajudam a decidir o desenho antes de implementar: Architecture Patterns for Claude Platform on AWS, sobre qual estrutura de contas faz sentido para cada organização, e Authentication Paths for Claude Platform on AWS, sobre qual caminho de autenticação combina com cada carga de trabalho.
Fontes e links
- AWS
- Architecture Patterns for Claude Platform on AWS
- Authentication Paths for Claude Platform on AWS
