O acesso ao Claude Platform on AWS unifica três ambientes, mas a precisão do IAM define o resultado de segurança

A AWS documentou três caminhos de acesso ao Claude Platform on AWS sob uma única assinatura, apesar dos requisitos bastante distintos de credenciais e segurança.

Publicada em 1º de outubro, a implementação conecta workloads da AWS, laptops de desenvolvedores e serviços externos a workspaces mantidos em uma conta dedicada de AI Services. Aplicações de produção usam Signature Version 4 entre contas, desenvolvedores recebem chaves de API com escopo definido, e workloads externos se autenticam por meio de federação OpenID Connect.

A arquitetura promete faturamento e administração centralizados sem obrigar todos os ambientes a usar um único modelo de credenciais. A tensão também é clara. A centralização simplifica a responsabilidade, mas uma política IAM excessivamente ampla ou uma chave de desenvolvedor mal gerenciada pode enfraquecer os limites de workspace que tornam o design útil.

Não se trata apenas de mais um guia de integração do Claude. A implementação da AWS transforma a autenticação em um plano de controle específico para cada ambiente. Ela também expõe o trabalho operacional oculto por trás da expressão “assinatura única”.

Amazon Bedrock continua sendo uma referência importante. Ele fornece modelos Claude por meio de um serviço de modelos fundacionais gerenciado pela AWS. Já o Claude Platform on AWS oferece a experiência de plataforma nativa da Anthropic por meio de uma conta AWS, incluindo suas APIs, console e recursos de plataforma.

O novo padrão de acesso não elimina essa distinção. Ele mostra como empresas podem estender a plataforma nativa da Anthropic por toda uma organização AWS, mantendo o controle baseado em IAM sobre o tráfego de produção.

Uma assinatura agora atende a três limites de confiança

A mudança importante não é apenas uma conectividade mais ampla. A AWS mapeou três ambientes para três métodos de autenticação distintos, mantendo a propriedade dos workspaces centralizada.

A topologia proposta começa com três funções de conta. Uma conta de gerenciamento lida com faturamento e governança no nível da organização. Uma conta dedicada de AI Services é proprietária da assinatura do Claude Platform, dos workspaces, das chaves de API e das funções de acesso.

Uma ou mais contas de workload passam então a consumir inferência do Claude sem possuir a assinatura. Suas aplicações assumem funções na conta de AI Services e chamam recursos de workspace autorizados por essas funções.

Essa separação dá à conta de AI Services uma finalidade específica. Ela se torna o limite administrativo em torno do acesso ao Claude, em vez de ser outra conta geral de aplicação cheia de recursos sem relação entre si.

A AWS recomenda criar workspaces separados de produção e desenvolvimento dentro dessa conta. Um workspace é o limite de recurso usado para separar equipes, projetos ou ambientes, preservando a administração centralizada.

Cada workspace possui um Amazon Resource Name, ou ARN, que as políticas IAM podem referenciar. Portanto, as permissões podem autorizar inferência em um workspace sem autorizar automaticamente outro.

O primeiro caminho de acesso abrange aplicações que já executam dentro da AWS. A AWS usa um pod do Amazon EKS como exemplo, embora o padrão possa se aplicar a outros workloads da AWS.

Esse pod primeiro assume uma função entre contas na conta de AI Services. As credenciais temporárias então assinam solicitações ao Claude com AWS Signature Version 4, conhecida como SigV4.

O SigV4 assina criptograficamente solicitações de API da AWS usando credenciais AWS. Ele permite que o serviço receptor verifique o chamador, a integridade da solicitação e o contexto de autorização sem um segredo de API estático separado.

A função entre contas concede ações selecionadas de aws-external-anthropic para o ARN do workspace de produção. O exemplo inclui inferência, contagem de tokens, recuperação de modelos e listagem de modelos.

A função não precisa de permissão para acessar o workspace de desenvolvimento. Isso cria uma relação direta entre a identidade do workload, suas ações de API permitidas e seu workspace Claude autorizado.

O segundo caminho abrange laptops de desenvolvedores. Desenvolvedores frequentemente precisam de uma forma mais simples de testar prompts, o comportamento de SDKs e a lógica de aplicações fora de um workload implantado.

A AWS atribui a esses usuários uma chave de API de longa duração associada ao workspace de desenvolvimento. O SDK padrão da Anthropic pode usar essa chave no endpoint regional do Claude Platform on AWS.

Essa rota preserva uma experiência familiar para desenvolvedores, mas cria uma credencial persistente de portador. Qualquer pessoa que detenha a chave pode usar suas permissões até que ela expire ou um administrador a revogue.

O terceiro caminho tem como alvo serviços externos. Entre os exemplos estão workloads executados no Google Cloud, clusters Kubernetes fora da AWS e sistemas de CI/CD como GitHub Actions ou GitLab CI.

Esses serviços usam federação OIDC, que troca um token assinado de um provedor de identidade por credenciais temporárias da AWS. As credenciais temporárias geram um token de portador do Claude de curta duração.

O exemplo da AWS cria um token com duração de uma hora. A implementação permite durações configuráveis de até 12 horas, após as quais o serviço externo deve obter outro token.

Em conjunto, esses três caminhos formam o núcleo do acesso multiambiente ao Claude. A assinatura permanece em uma conta, enquanto a autenticação muda de acordo com onde o chamador é executado.

Esse é o avanço arquitetural. Ele reconhece que um pod do EKS, um laptop de desenvolvedor e um pipeline externo não devem compartilhar um único padrão universal de credenciais.

O acesso ao Claude Platform on AWS leva o controle para o IAM

O acesso ao Claude Platform on AWS agora depende menos de onde o código é executado e mais de o IAM descrever com precisão sua identidade e seu workspace pretendidos.

A AWS apresentou o serviço como uma forma de usar a plataforma nativa da Anthropic por meio de uma conta AWS existente. A empresa afirmou que a AWS foi o primeiro provedor de nuvem a oferecer essa experiência nativa por meio de sua própria estrutura de contas.

O lançamento original conectou autenticação, faturamento e funções de auditoria à AWS. Os clientes puderam usar as APIs e ferramentas da Anthropic sem estabelecer uma relação comercial separada.

O design multiambiente estende essa proposta além de uma conexão básica de API. Ele torna a organização AWS, em vez de uma aplicação individual, a camada organizadora do acesso ao Claude.

Isso importa porque o uso corporativo de IA raramente permanece em um único ambiente. Uma equipe pode testar uma aplicação localmente, implantá-la no EKS e executar avaliações a partir de outra nuvem.

Uma chave estática compartilhada pode conectar os três locais, mas também colapsa suas identidades. Os logs mostram a chave, não necessariamente o workload, a conta ou o pipeline que a utilizou.

Funções entre contas preservam mais contexto. O workload assume uma função nomeada, recebe credenciais temporárias e faz solicitações assinadas que a AWS pode atribuir a uma entidade principal.

A função também cria dois pontos de verificação de autorização. A conta de workload deve permitir que sua identidade local assuma a função de destino. A conta de AI Services deve confiar nessa identidade e organização.

O exemplo da AWS adiciona uma condição aws:PrincipalOrgID à política de confiança. Essa condição restringe a assunção da função a entidades principais associadas à organização AWS especificada.

A política de permissões então limita a inferência ao ARN do workspace de produção. A confiança responde quem pode assumir a função, enquanto as permissões definem o que essa função pode fazer depois.

Essa separação pressiona equipes que antes tratavam o acesso a modelos como distribuição de segredos. Agora elas precisam gerenciar a autenticação AWS do Claude como uma arquitetura de identidade.

As equipes de segurança, plataforma e aplicações devem concordar sobre a propriedade das contas. Elas também precisam de padrões de nomenclatura para funções, workspaces, políticas e mapeamentos de ambiente.

Uma conta dedicada pode tornar essas responsabilidades visíveis. No entanto, ela não as torna automaticamente corretas.

A arquitetura também afeta a resposta a incidentes. Uma função de produção pode ser desabilitada sem remover imediatamente o acesso de desenvolvedores. Uma chave de desenvolvimento comprometida pode ser revogada sem alterar uma função de workload do EKS.

A separação de workspaces também pode apoiar a atribuição de custos. A AWS afirma que organizações podem marcar workspaces com tags e ativá-las para alocação de custos.

Após a ativação, que a AWS diz poder levar de 24 a 48 horas, as equipes podem filtrar dados do AWS Cost Explorer por workspace. Isso cria um caminho do isolamento técnico à análise de gastos no nível de projeto.

A auditabilidade exige outra escolha explícita. A administração de workspaces aparece em eventos de gerenciamento do CloudTrail por padrão, mas a inferência pertence à categoria de eventos de dados.

A documentação de monitoramento diz que as equipes devem habilitar o registro de eventos de dados para capturar inferência e outras operações de workspace. Esses eventos também podem gerar cobranças adicionais do CloudTrail.

Essa distinção é fácil de ignorar. Centralizar a assinatura melhora o potencial de trilha de auditoria, mas não garante que a atividade de inferência esteja sendo registrada.

Portanto, o design pressiona proprietários de plataforma a tratar a observabilidade como parte do controle de acesso. Uma política pode limitar uma ação, enquanto o registro fornece evidências sobre qual entidade principal de fato a executou.

Os três caminhos de autenticação resolvem problemas diferentes

A arquitetura funciona porque evita forçar conveniência, identidade de workload e federação externa ao mesmo ciclo de vida de credenciais.

Para workloads da AWS, o SigV4 entre contas oferece o alinhamento mais claro com a identidade de nuvem existente. A aplicação recebe credenciais temporárias da AWS ao assumir uma função.

Em seguida, ela assina cada solicitação ao endpoint do Claude. Não há uma chave de API do Claude separada armazenada na conta de workload, na imagem de contêiner ou na configuração de implantação.

Essa abordagem segue as orientações estabelecidas da AWS. As práticas recomendadas de IAM da empresa recomendam credenciais temporárias de função para workloads em vez de chaves de acesso de longa duração.

A função de produção pode incluir apenas as ações de que a aplicação precisa. Uma aplicação síncrona básica pode precisar de permissões de inferência e contagem de tokens, mas não de ações administrativas, de arquivos ou de lote.

O Claude Platform on AWS usa o namespace IAM aws-external-anthropic. Seu modelo de permissões mapeia rotas de API para ações específicas, como CreateInference para solicitações de mensagens.

Essa ação pode referenciar um ARN de workspace. A aplicação obtém acesso ao workspace de produção sem herdar privilégios do Claude para toda a conta.

Este é o mais forte dos três caminhos para workloads contínuos da AWS. A aplicação não carrega um segredo durável do Claude, e a AWS pode atribuir solicitações a uma identidade assumida.

Laptops de desenvolvedores criam uma restrição diferente. Exigir que cada experimento local percorra uma cadeia de funções entre contas pode aumentar os custos de configuração e desacelerar a iteração.

Por isso, a AWS usa uma chave de API com escopo de workspace para desenvolvimento. A chave funciona com o cliente padrão da Anthropic e aponta para o endpoint regional do Claude Platform on AWS.

A qualificação importante é que uma chave recém-gerada não é automaticamente restrita o suficiente para esse padrão. A AWS diz que seu usuário IAM de suporte recebe inicialmente a política gerenciada AnthropicLimitedAccess.

Segundo o guia de implementação, essa política gerenciada concede acesso a todos os workspaces. Um administrador deve desvinculá-la e substituí-la por uma política inline limitada ao desenvolvimento.

Essa etapa é o controle manual mais importante no caminho do desenvolvedor. Gerar a chave é fácil, mas impor o limite pretendido do workspace exige uma alteração separada no IAM.

A AWS recomenda testar o limite posteriormente. O desenvolvedor deve chamar o workspace de desenvolvimento com sucesso, depois tentar uma solicitação de produção e confirmar que o IAM a nega.

Esse teste negativo é mais importante do que a solicitação bem-sucedida. Uma resposta de desenvolvimento comprova a conectividade, mas apenas uma chamada de produção rejeitada verifica a alegação de isolamento.

A chave de API continua sendo autoautenticável. Ela funciona na AWS, em outra nuvem ou em um laptop porque a posse da chave fornece a credencial.

Portanto, as equipes devem armazená-la em um gerenciador de segredos aprovado e definir uma expiração. Elas também precisam de procedimentos de revogação para dispositivos perdidos, mudanças de função e exposição acidental em repositórios.

O caminho de cargas de trabalho externas elimina esse segredo persistente. O OIDC permite que um provedor de identidade compatível emita um JSON Web Token que identifica a carga de trabalho.

O AWS Security Token Service valida o token e verifica as condições de confiança da função. Em seguida, retorna credenciais temporárias da AWS por meio de AssumeRoleWithWebIdentity.

A orientação sobre OIDC recomenda esse padrão para aplicações fora da AWS porque ele evita credenciais de longo prazo incorporadas.

A carga de trabalho externa usa suas credenciais temporárias da AWS para solicitar um token de portador Claude de curta duração. Depois de gerado, esse token de portador pode chamar Claude sem reter as credenciais da AWS.

Isso é útil para contêineres externos e jobs de CI/CD, mas a renovação do token passa a fazer parte da aplicação. Um serviço executado continuamente deve atualizar o token antes da expiração.

A política de confiança do OIDC também merece atenção rigorosa. O exemplo da AWS verifica as declarações de público e de sujeito do token em relação aos valores esperados.

O público identifica o destinatário pretendido do token. O sujeito distingue a carga de trabalho, conta de serviço, repositório ou identidade de pipeline permitida.

Filtros de declarações permissivos podem admitir mais identidades externas do que o previsto. Um mecanismo de federação correto com uma condição de confiança imprecisa ainda produz acesso excessivo.

Essas rotas são, portanto, complementares, não intercambiáveis.

• O SigV4 entre contas é adequado para cargas de trabalho de produção já controladas por identidades da AWS.

• Chaves de API com escopo de workspace reduzem o atrito no desenvolvimento local.

• A federação OIDC é adequada para automação externa que pode apresentar uma identidade de carga de trabalho verificável.

O elemento compartilhado é o workspace. Cada caminho de credencial deve, em última instância, resultar em permissões para o workspace apropriado àquele ambiente.

A centralização não elimina o risco de credenciais

O design melhora o isolamento apenas quando cada função, chave, condição de confiança, endpoint e configuração de logs corresponde ao workspace pretendido.

O risco mais claro está no caminho do desenvolvedor. As próprias instruções da AWS dizem que uma chave de API gerada inicialmente recebe uma política gerenciada com acesso a todos os workspaces.

Um administrador deve identificar o usuário IAM de suporte recém-criado, remover essa política e anexar uma política embutida mais restrita.

Esse fluxo de trabalho é vulnerável a erros humanos. Um administrador pode definir o escopo para o usuário errado, manter a política gerenciada ou referenciar um ARN de workspace incorreto.

A chave resultante ainda funcionaria. Sua solicitação de desenvolvimento bem-sucedida não revelaria que ela também manteve acesso à produção.

Um teste obrigatório de negação pode detectar esse erro. As organizações devem tornar o teste de acesso à produção parte da emissão de chaves, e não uma validação opcional realizada posteriormente.

Chaves de longa duração também oferecem atribuição mais fraca do que o acesso baseado em funções. Vários desenvolvedores compartilhando uma chave podem aparecer como o mesmo principal nos registros de auditoria.

Chaves individuais melhoram a atribuição, mas ampliam o número de credenciais que exigem armazenamento seguro, expiração, revogação e rastreamento de propriedade.

O caminho entre contas tem modos de falha diferentes. Uma política de confiança pode ser ampla demais, ou a permissão de assunção no lado da carga de trabalho pode alcançar a função de destino errada.

A condição aws:PrincipalOrgID ajuda a restringir o escopo organizacional. No entanto, ela não substitui um ARN de principal exato ou uma nomenclatura cuidadosa de funções.

As permissões também merecem revisão no nível das ações. Conceder acesso curinga em todo o namespace aws-external-anthropic enfraqueceria a estrutura de privilégio mínimo do guia.

A AWS publica exemplos detalhados de políticas IAM para inferência em um único workspace e outros controles. As equipes devem validar as políticas implantadas em relação aos recursos de API que realmente usam.

A rota OIDC desloca a segurança para declarações de identidade externas. Sua segurança depende de o emissor, o público, o filtro de sujeito, a política de função e a lógica de renovação de tokens funcionarem juntos.

Um padrão de sujeito que abrange um grupo inteiro de repositórios pode autorizar pipelines não relacionados. Um padrão amplo de conta de serviço pode admitir cargas de trabalho fora do namespace pretendido.

Credenciais temporárias limitam a duração da exposição, mas não corrigem permissões excessivas durante esse período. Acesso de curta duração é mais seguro do que acesso permanente, mas não é automaticamente de privilégio mínimo.

O token Claude gerado também se torna uma credencial de portador autônoma. Até expirar, a posse é suficiente para usá-lo dentro do limite de autorização herdado.

As aplicações devem evitar imprimi-lo em logs, saídas de build, rastreamentos de exceções ou metadados de monitoramento. Quando prático, a duração do token deve corresponder à duração do job.

O comportamento regional acrescenta outra restrição operacional. Os workspaces são criados em uma Região da AWS, e as solicitações de API devem atingir o endpoint regional correspondente.

A AWS distingue essa vinculação ao endpoint da geografia de inferência. As configurações de segurança do workspace determinam independentemente se a inferência usa roteamento dos EUA ou global.

Chaves de curta duração funcionam apenas com o mesmo endpoint regional em que foram geradas. As chaves de API de longa duração não são bloqueadas por região, segundo o guia da AWS.

Essa diferença pode produzir falhas confusas durante a implantação. Um processo de renovação de token pode funcionar em uma Região enquanto uma aplicação aponta para outro endpoint.

A arquitetura também tem um limite mais amplo que os compradores precisam entender. A AWS afirma que o Claude Platform on AWS é operado pela Anthropic, com solicitações e dados processados fora do limite de segurança da AWS.

Isso torna o serviço distinto da suposição de que todo o processamento permanece dentro de um perímetro de serviço controlado pela AWS. Organizações com requisitos rigorosos de residência precisam de uma revisão separada.

A AWS posiciona o Claude Platform on AWS como complementar aos modelos Claude disponíveis via Amazon Bedrock. Portanto, a escolha não é apenas entre um método de autenticação e outro.

Ela inclui recursos de plataforma, responsabilidade operacional, limites de processamento e requisitos regionais. O acesso a múltiplos ambientes não resolve essas questões para todas as cargas de trabalho.

A centralização também pode aumentar o raio de impacto de erros administrativos. A conta AI Services mantém a assinatura, os workspaces, as chaves de API e as funções de acesso.

Uma alteração nessa conta pode afetar várias contas de aplicação ao mesmo tempo. Portanto, o design deve aplicar controles de mudança mais fortes a essa conta do que a um ambiente casual de desenvolvimento.

As equipes devem separar, quando possível, a autoria de políticas da aprovação. A infraestrutura como código também pode reduzir definições inconsistentes de funções entre equipes e workspaces adicionais.

A AWS afirma que organizações com mais ambientes podem criar um workspace para cada equipe ou carga de trabalho e repetir o padrão de função entre contas.

Essa abordagem amplia o modelo de isolamento, mas também multiplica políticas, relacionamentos entre funções, logs, tags e configurações de endpoint. A disciplina operacional se torna o fator limitante.

A promessa central deve, portanto, ser apresentada com cuidado. O padrão fornece os componentes para o isolamento de workspaces, mas as políticas implantadas e o tratamento das credenciais determinam se esse isolamento se mantém.

O que as empresas devem validar em seguida

O próximo teste é verificar se as organizações conseguem operar esse modelo de acesso de modo consistente, e não se os três fluxos de autenticação funcionam em uma demonstração.

O primeiro sinal é a validação automatizada de políticas. As equipes devem confirmar que cada função de produção tem como destino um ARN de workspace esperado e apenas as ações de API necessárias.

A emissão de chaves de desenvolvedor deve incluir substituição de política, expiração, armazenamento de segredos e um teste forçado de negação de acesso à produção. Um processo que depende da memória acabará se desviando.

Se as organizações automatizarem essas verificações por meio de pipelines de implantação, o modelo centralizado da AWS se tornará mais confiável em escala. Exceções manuais repetidas enfraqueceriam essa conclusão.

O segundo sinal é a cobertura de auditoria. Os eventos de gerenciamento do CloudTrail, por si só, não fornecem visibilidade de inferência por chamada.

As organizações devem habilitar eventos de dados para o tipo de recurso Claude workspace relevante e, em seguida, verificar se os registros contêm atribuição útil de principal.

Elas também devem testar se os responsáveis pela resposta a incidentes conseguem conectar uma solicitação a uma função do EKS, uma chave de desenvolvedor ou uma identidade OIDC externa.

Se o caminho de auditoria preservar essas distinções, a arquitetura de três rotas oferece suporte a um acesso responsável. Se os logs reduzirem os chamadores a identidades compartilhadas, a centralização terá menos valor investigativo.

O terceiro sinal é a adoção além de aplicações nativas da AWS. O caminho OIDC foi projetado para nuvens externas, implantações Kubernetes e sistemas de CI/CD.

Seu teste real será a rotação confiável de tokens durante jobs de longa execução. As equipes também devem manter declarações estreitas de sujeito e público à medida que repositórios e contas de serviço mudam.

Falhas frequentes de autenticação incentivariam os desenvolvedores a recorrer a segredos de longa duração. Uma renovação estável com condições de confiança precisas fortaleceria a abordagem federada.

As empresas também devem monitorar a proliferação de workspaces. Criar um workspace por equipe ou carga de trabalho pode melhorar o isolamento, a propriedade e a alocação de custos.

Workspaces demais sem rótulos consistentes e regras de ciclo de vida podem criar outra forma de dispersão. Chaves antigas, funções abandonadas e workspaces não utilizados precisam de um processo de desativação.

A conta dedicada AI Services deve se tornar um limite de serviço governado. Seus administradores precisam de registros de propriedade para cada workspace, função e credencial.

As equipes de plataforma podem registrar decisões de acesso juntamente com a arquitetura da aplicação e os procedimentos de incidentes. Uma base de conhecimento de engenharia pesquisável pode ajudar a preservar esses mapeamentos à medida que as equipes mudam.

A avaliação mais útil começa com um caminho completo de aplicação. Conecte uma carga de trabalho de produção via SigV4, um cliente de desenvolvimento por meio de uma chave restrita e um pipeline via OIDC.

Em seguida, verifique solicitações entre workspaces negadas, renovação de token, eventos de dados do CloudTrail e revogação de emergência. Esses controles continuam válidos após mudanças rotineiras de política?

Essa resposta importa mais do que a primeira solicitação bem-sucedida. O acesso ao Claude Platform on AWS agora oferece suporte a três ambientes sob uma única assinatura, mas seu valor de segurança depende de uma comprovação repetível de isolamento.