AWS cloisonne Claude Platform entre trois environnements

AWS centralise l’accès à Claude Platform on AWS dans un compte dédié aux services IA. La configuration vise trois environnements distincts. Les charges de production résident dans AWS. Les développeurs travaillent depuis leurs ordinateurs portables. Des services externes utilisent d’autres fournisseurs cloud ou des chaînes d’intégration et de livraison continues sur site. Chaque environnement possède ses propres exigences d’authentification. Tous partagent toutefois un même abonnement. Deux espaces de travail séparent les flux de production et de développement. Le guide publié par AWS le 2 octobre 2026 détaille la mise en œuvre complète. Il fournit des commandes AWS CLI, des instructions de console et des extraits de code pour chaque étape.

Trois comptes structurent l’architecture proposée par AWS. Le compte payeur assure la facturation et la gouvernance. Le compte AI Services héberge l’abonnement Claude Platform, les espaces de travail, les clés API et les rôles intercomptes. Un ou plusieurs comptes de charges consomment l’inférence grâce à ces rôles. Les comptes de charges ne touchent donc pas directement à l’abonnement. Ils assument des rôles dans le compte AI Services. L’organisation doit disposer d’AWS Organizations, de profils AWS CLI v2 pour les deux comptes et de Python 3.12 ou supérieur. Les paquets requis incluent [anthropic](/signal-ia/actu/anthropic-lance-claude-fable-5-avec-des-garde-fous-renforces)[aws], boto3 et token-generator-for-aws-external-anthropic.

AWS sépare production et développement

Deux espaces isolent les usages de production et de développement. L’administrateur les crée dans Claude Platform on AWS, puis enregistre leurs identifiants ARN. Chaque espace de travail appartient à une région AWS précise. Les appels doivent cibler le point de terminaison régional correspondant, comme aws-external-anthropic.us-east-1.api.aws. Cette région détermine le point d’accès, mais pas la géographie de l’inférence. Les paramètres de sécurité de l’espace contrôlent cette géographie avec les options « US » et « Global routing ». AWS recommande aussi de créer un espace par équipe ou charge lorsque l’organisation ajoute d’autres environnements. Le même schéma de rôle intercompte peut alors être répété.

Amazon EKS assume un rôle du compte AI Services pour appeler l’espace de production. Le rôle intercompte autorise les actions CreateInference, CountTokens, GetModel et ListModels. La ressource d’inférence est limitée à l’ARN de l’espace de production. Le rôle ne peut donc pas accéder à l’espace de développement ni aux espaces supplémentaires. Le rôle du pod EKS reçoit de son côté l’autorisation sts:AssumeRole. Le script de test utilise ensuite boto3 pour obtenir des identifiants temporaires. Le client AnthropicAWS signe les appels avec SigV4. Cette voie ne stocke aucune clé API et ne nécessite aucune rotation de secret persistant.

OIDC fournit des identifiants temporaires

Les développeurs utilisent une clé API longue durée depuis leurs ordinateurs portables. AWS demande de choisir une expiration lors de sa génération. La valeur n’est affichée qu’une seule fois et doit être conservée de manière sécurisée. Par défaut, l’utilisateur IAM associé reçoit la politique gérée AnthropicLimitedAccess, qui ouvre l’accès à tous les espaces. Le guide recommande de retirer cette politique. Une politique intégrée peut ensuite limiter CreateInference et CountTokens à l’ARN de l’espace de développement. Les environnements externes suivent une troisième voie. Ils s’authentifient avec OIDC, obtiennent des identifiants AWS temporaires, génèrent un jeton court et appellent Claude sans identifiants persistants. Consultez aussi les modèles d’architecture AWS et les parcours d’authentification.

Le déploiement suit quatre parties successives. La première active l’abonnement et crée les espaces de travail. La deuxième configure l’accès SigV4 depuis un compte de charges AWS. La troisième génère une clé API et la limite à l’espace de développement. La quatrième met en place la fédération OIDC pour les environnements externes. AWS demande de remplacer les valeurs d’exemple par l’identifiant de l’organisation, la région, les identifiants de comptes, les ARN d’espaces et l’émetteur OIDC réels. Pour les clés courtes, la génération et l’utilisation doivent viser le même point de terminaison régional. Les clés longues ne sont pas limitées à une région. Les régions et modèles pris en charge figurent dans la documentation Claude Platform on AWS.