Claude Code su AgentCore: requisiti e setup AWS

Claude Code --cloud non può usare Amazon Bedrock come provider: Anthropic richiede un account Anthropic per le sessioni cloud native e le esclude quando Claude Code è configurato per Bedrock. Per eseguire attività remote usando Bedrock, AWS descrive un percorso distinto: un’implementazione personalizzata che avvia sessioni Amazon Bedrock AgentCore Runtime e restituisce pull request da sottoporre a revisione umana. Anthropic AWS

Se il repository esegue comandi definiti al suo interno, collegane uno di cui ti fidi: il filtro descritto da AWS controlla il testo dell’attività, non i file del progetto né l’output dei comandi.

Due percorsi diversi per le sessioni remote

La funzione nativa --cloud di Claude Code e l’esempio AWS non sono intercambiabili. Anthropic lega le sessioni native a un account Anthropic; se Claude Code è configurato per Amazon Bedrock, quella funzione non è disponibile. L’esempio AWS, invece, è un deployment personalizzato che usa Bedrock per le chiamate ai modelli e AgentCore Runtime per eseguire le attività.

Come funziona l’esempio AWS

AWS descrive un flusso in cui una richiesta passa da API Gateway, Lambda, SQS e DynamoDB prima di arrivare alla sessione di runtime. Per avviare il lavoro si può usare il plugin con un server MCP locale oppure la console web; il tutorial descrive rispettivamente percorsi API autorizzati tramite IAM e Amazon Cognito.

Ogni attività viene eseguita in una sessione AgentCore Runtime e in una microVM separata, con CPU, memoria e filesystem isolati secondo la descrizione di AWS. Nel flusso di esempio Claude Opus pianifica l’intervento, Claude Sonnet scrive il codice e Claude Opus rivede il risultato. Il sistema esegue i comandi di setup e test definiti dal repository; la revisione può rimandare il lavoro alla pianificazione, fino a tre tentativi complessivi.

Al termine, l’agente apre una pull request su GitHub, ma non la unisce. Se la verifica non passa, la pull request è una bozza; una persona deve esaminare le modifiche e decidere se fare il merge.

Prima del deployment: account, strumenti e repository

Per seguire il percorso descritto da AWS servono:

• un account AWS e credenziali CLI;
• Docker in esecuzione;
• Python 3.11 o successivo, uv e Node.js 22.12 o successivo;
• un repository GitHub affidabile, con comandi di setup e test definiti;
• il supporto al marketplace dei plugin di Claude Code, se vuoi inviare attività dal terminale.

AWS indica cinque regioni per AgentCore Runtime V2 nel tutorial: us-east-1, us-east-2, us-west-2, ap-northeast-1 ed eu-west-1; il walkthrough usa us-west-2. La guida stima 15–25 minuti per il deployment e altri 8–12 minuti per registrare un repository. Sono tempi indicati da AWS per la procedura descritta.

AWS sconsiglia questo schema per repository non affidabili, perché l’agente esegue comandi definiti dal progetto. Non è pensato neppure per attività aperte: il ciclo di lavoro si ferma dopo tre tentativi.

Deployment e collegamento a GitHub

Segui l’ordine previsto dal tutorial: prima i controlli preliminari, poi il deployment; quindi collega GitHub e registra il repository. In questo modo il repository entra nel flusso dopo che l’accesso GitHub è stato configurato.

1. Esegui il preflight. Controlla account e credenziali AWS, strumenti richiesti e comandi di setup e test del repository. Il preflight verifica che l’ambiente soddisfi i prerequisiti indicati da AWS.
2. Distribuisci l’esempio. Completa il deployment seguendo il tutorial AWS e la regione scelta tra quelle indicate nella guida.
3. Installa e autorizza la GitHub App. L’app limita l’accesso ai repository autorizzati e usa i permessi per leggere i contenuti e aprire pull request.
4. Registra il repository. Dopo aver autorizzato GitHub, aggiungi il repository al servizio e attendi che risulti pronto prima di assegnargli attività.

Inviare un’attività e controllare il risultato

Puoi inviare il lavoro dalla console web o dal plugin di Claude Code, tramite il server MCP locale. L’esempio inoltra l’attività al runtime, esegue i passaggi di pianificazione, coding, verifica e revisione, poi crea una pull request. Controlla i risultati dei test e le modifiche nella pull request: il sistema non esegue il merge al posto tuo.

Limiti di sicurezza e costi

AWS descrive subnet private e endpoint privati per i servizi AWS. L’uscita verso Internet resta però possibile tramite un gateway NAT per raggiungere GitHub e i registri dei pacchetti. Il DNS Firewall illustrato è una lista di domini bloccati, non una lista generale di destinazioni HTTPS consentite.

AgentCore Identity gestisce il token utente-server per GitHub: AWS dice che scade dopo otto ore e si aggiorna automaticamente. Il filtro dei prompt esamina la richiesta inviata prima che venga messa in coda; non controlla i file del repository né l’output dei comandi durante l’esecuzione. L’isolamento della sessione non sostituisce quindi la scelta di repository affidabili e la revisione delle modifiche.

Le risorse del deployment continuano a generare costi anche quando il sistema è inattivo. AWS cita tra le voci addebitate gateway NAT, endpoint di interfaccia, AWS WAF, pool utenti Cognito, DNS Firewall, immagini e log. L’impostazione predefinita di 200 USD al mese per il budget Amazon Bedrock invia un’email, ma non limita la spesa.

Rimuovere il deployment

Per dismettere l’ambiente, AWS indica di deregistrare prima i repository, scollegare GitHub, eliminare gli stack e infine rimuovere la GitHub App. Elimina separatamente le risorse conservate che continuano a generare costi dopo la rimozione degli stack.