Non : les sessions natives Claude Code --cloud exigent un compte Anthropic et ne sont pas disponibles lorsque Claude Code est configuré avec Amazon Bedrock, selon la documentation d’Anthropic sur Claude Code dans le cloud. Pour exécuter des tâches de code avec Bedrock à distance, AWS décrit une autre voie : un déploiement personnalisé qui lance chaque tâche dans une session Amazon Bedrock AgentCore Runtime et renvoie une pull request GitHub à examiner par une personne, comme l’explique le tutoriel AWS sur l’exemple AgentCore.
| Parcours | Compte et fournisseur | Envoi et exécution |
--cloud natif | Compte Anthropic ; indisponible avec Amazon Bedrock comme fournisseur configuré | Session cloud native de Claude Code |
| Exemple AWS AgentCore | Compte AWS de déploiement ; appels de modèles via Amazon Bedrock | Plugin Claude Code avec serveur MCP local, ou console web ; tâche exécutée dans une session AgentCore Runtime |
Si Claude Code utilise Amazon Bedrock, la commande native --cloud ne sert donc pas à aiguiller la tâche vers AgentCore. Il faut déployer le parcours AWS séparément et en assumer l’infrastructure, les autorisations et les frais.
Comment l’exemple AWS traite une tâche
Le plugin ou la console transmet la demande à une API. AWS décrit un plan de contrôle fondé sur API Gateway, Lambda, Amazon SQS et DynamoDB, puis une session AgentCore Runtime distincte pour la tâche. Chaque session utilise sa propre microVM, avec un processeur, une mémoire et un système de fichiers isolés, selon AWS.
Dans le flux présenté, Claude Opus planifie le travail, Claude Sonnet écrit le code, puis le dépôt exécute ses propres commandes de préparation et de test. Claude Opus examine ensuite le résultat. Si la revue demande des changements, le cycle peut repartir, pour un maximum de trois tentatives au total.
Le résultat est une pull request GitHub. AWS indique qu’elle est créée en brouillon tant que la vérification n’a pas réussi. Une personne examine les changements et décide de la fusion : l’agent ne la réalise pas.
Considérez la pull request comme une proposition à examiner : la vérification automatisée ne remplace pas la revue humaine.
Prérequis avant le déploiement
Préparez les éléments demandés par AWS avant de lancer le déploiement :
- un compte AWS et des identifiants pour l’interface de ligne de commande AWS ;
- Docker en cours d’exécution ;
- Python 3.11 ou une version ultérieure,
uvet Node.js 22.12 ou une version ultérieure ; - un dépôt GitHub de confiance, avec des commandes de préparation et de test définies.
Le tutoriel AWS énumère cinq régions pour AgentCore Runtime V2 : us-east-1, us-east-2, us-west-2, ap-northeast-1 et eu-west-1. Son pas-à-pas utilise us-west-2. Ce choix décrit le tutoriel, pas une disponibilité garantie dans chaque région au moment où vous déployez.
AWS estime le déploiement à 15 à 25 minutes, puis l’enregistrement d’un dépôt à 8 à 12 minutes. Ce sont les durées annoncées dans son tutoriel publié le 6 novembre 2026.
Déployer et raccorder le dépôt
Respectez l’ordre des opérations : le dépôt doit être prêt avant le lancement, et l’application GitHub doit être autorisée avant son enregistrement.
- Préparez le dépôt. Définissez les commandes de préparation et de test que l’agent exécutera, et choisissez un dépôt dont le code est digne de confiance.
- Lancez le contrôle préalable (preflight). AWS place cette vérification avant le déploiement afin de contrôler la configuration préparée.
- Déployez les ressources AWS. Lancez le déploiement de l’exemple dans le compte et la région retenus.
- Installez et autorisez la GitHub App. L’application utilise les accès GitHub nécessaires au contenu du dépôt et aux pull requests.
- Enregistrez le dépôt. Faites-le après l’autorisation de l’application pour que le parcours puisse travailler avec le dépôt choisi.
Le plugin Claude Code s’appuie sur un serveur MCP local pour envoyer une tâche depuis le terminal. La console web constitue l’autre point d’entrée. AWS décrit des chemins d’autorisation différents : IAM pour le parcours du plugin et Cognito pour la console.
Examiner le résultat et les limites de sécurité
Pour chaque tâche, examinez les changements proposés et le résultat des commandes du dépôt avant toute fusion. La demande envoyée passe par le filtre de prompts d’AWS, mais ce contrôle ne porte pas sur les fichiers du dépôt ni sur la sortie des commandes. Une instruction présente dans le code consulté pendant l’exécution se trouve donc hors du périmètre de ce filtre.
AWS décrit des sous-réseaux privés et des points de terminaison privés pour les services AWS. Le trafic HTTPS sortant vers GitHub et les registres de paquets passe toutefois par une passerelle NAT. Le pare-feu DNS présenté bloque certains domaines ; il ne constitue pas une liste générale d’autorisation pour les connexions HTTPS.
Pour GitHub, AWS décrit AgentCore Identity et un jeton utilisateur-serveur associé à l’application. Selon AWS, ce jeton expire après huit heures et est renouvelé automatiquement. La GitHub App limite aussi l’accès aux dépôts auxquels elle est installée.
AWS déconseille cet exemple pour les dépôts non fiables : l’agent exécute les commandes définies par le dépôt. Le cycle limité à trois tentatives ne convient pas non plus aux tâches ouvertes qui demandent un travail sans périmètre précis.
Les ressources continuent à entraîner des frais lorsque l’installation est inactive. AWS cite notamment la passerelle NAT, les points de terminaison d’interface, AWS WAF, le groupe d’utilisateurs Cognito, le pare-feu DNS, les images et les journaux. Le budget Amazon Bedrock de 200 dollars par mois configuré par défaut envoie une alerte par e-mail ; il ne plafonne pas les dépenses.
Supprimer les ressources après usage
AWS indique l’ordre de nettoyage suivant : désenregistrez d’abord les dépôts, déconnectez ensuite GitHub, détruisez les piles AWS, puis supprimez la GitHub App. La suppression des piles et la fermeture de la connexion GitHub ne remplacent pas la suppression de l’application elle-même.
