Claude Platform su AWS disponibile a tutti i clienti: cosa cambia per gli stack enterprise già su Amazon

Anthropic e AWS hanno dichiarato la general availability (GA) di Claude Platform su AWS, un servizio che porta dentro l’account Amazon Web Services l’intera esperienza nativa delle API Claude, con la stessa documentazione, la stessa console, gli stessi modelli e le stesse beta in arrivo lo stesso giorno del lancio sulla piattaforma diretta. L’annuncio è del 12 maggio.

Per chi è dentro AWS già da anni, è la prima volta che può chiamare Claude senza aprire un secondo contratto, senza creare un secondo billing, senza gestire un secondo set di credenziali.

La differenza non è cosmetica. AWS è il primo cloud provider a offrire questo livello di integrazione nativa con Anthropic, e il pattern che ne esce ridefinisce dove finiscono i confini operativi tra cloud provider e fornitore di modelli, soprattutto in un mercato dove l’adozione di Claude in produzione è cresciuta in modo non lineare nell’ultimo anno.

La presenza simultanea di Claude su Amazon Bedrock e di Claude Platform su AWS genera però un tradeoff che ogni CTO deve risolvere consapevolmente, perché i due servizi rispondono a domande diverse e hanno modelli di rischio diversi.

Cosa si riceve nell’account AWS: feature parity con la Claude Platform nativa

Il primo punto da fissare è quello che sta dentro il pacchetto. Claude Platform su AWS include la Messages API completa, Claude Managed Agents in beta, advisor strategy in beta, web search e web fetch, code execution per script Python eseguibili dentro la chiamata API, Files API in beta, Skills in beta, connettore MCP in beta, prompt caching, citations, batch processing, e l’accesso pieno alla Claude Console per prompt development e valutazione.

I modelli disponibili al lancio sono Claude Opus 4.7, Sonnet 4.6 e Haiku 4.5, e Anthropic ha dichiarato che ogni nuovo modello sarà disponibile day-one sulla piattaforma AWS, allo stesso prezzo della piattaforma diretta.

Il dettaglio della parità feature è quello che fa la differenza per chi sta costruendo agenti complessi. Su Bedrock, storicamente, le novità di prodotto Anthropic arrivavano con uno sfasamento di settimane o mesi rispetto al rilascio nativo, e alcune capability avanzate, come Skills o il connettore MCP, non erano disponibili affatto.

Adesso un team che sta sviluppando un agente con Claude Code o con Cowork può puntare gli SDK ai nuovi endpoint regionali del tipo e ottenere lo stesso comportamento dell’API canonica, ma dentro il perimetro IAM dell’azienda.

OpenRouter, citato da Anthropic come early adopter, ha dichiarato in un breakout col team Anthropic riportato nel post di lancio Claude di aver scelto Claude Platform su AWS perché “ottiene accesso diretto alle ultime feature dell’API Claude nativa controllando l’accesso con le stesse credenziali IAM usate per altri servizi AWS”.

È il pattern che la maggior parte degli enterprise customer si troverà a percorrere quando dovrà decidere come orchestrare l’adozione su scala team multipli.

Authentication via IAM, billing in fattura unica, audit dentro CloudTrail

La seconda parte della proposta è infrastrutturale, e qui i decisori tecnici trovano la motivazione principale per valutare il passaggio. L’autenticazione passa per AWS IAM con Signature Version 4, perciò le policy che già governano l’accesso ai bucket S3, ai database RDS o alle code SQS si estendono direttamente alle chiamate Claude. Si può limitare un workspace specifico tramite ARN, si possono dare permessi a un ruolo IAM temporaneo per un agente che gira in Lambda, si possono revocare credenziali centralmente dal security team senza coordinarsi con Anthropic. È una continuità operativa che riduce di molto il costo cognitivo per chi gestisce identity governance in ambienti regolamentati.

Il billing è dentro AWS Marketplace, modello consumption-based, e il fatto rilevante è che le spese Claude entrano nello stesso pool degli AWS commitments e ne erodono il saldo. Per le aziende che hanno enterprise discount agreement con AWS questa è una leva economica concreta: il consumo Claude non diventa una voce di spesa separata da rendicontare al CFO, diventa una colonna in più dentro Cost Explorer, allineata a EC2, S3 e RDS nella stessa visualizzazione.

Anthropic specifica nel suo annuncio che chi ha già un private offer attivo su Bedrock deve coordinarsi col proprio account executive prima di iniziare, perché gli sconti non si applicano retroattivamente.

L’audit logging passa attraverso AWS CloudTrail, con management events catturati di default per le operazioni sui workspace e la possibilità di abilitare il data event logging per loggare anche l’attività di inferenza. Per chi opera in settori regolati, banking, healthcare, assicurazioni, pubblica amministrazione, questa è la differenza tra “abbiamo un audit trail” e “abbiamo l’audit trail dentro lo stesso sistema su cui il SOC compliance lavora già da anni”.

Riduce il tempo di onboarding del servizio nel processo di security review interna, perché il framework di osservabilità non cambia.

Bedrock o Platform: perché non è interscambiabile?

Anthropic e AWS hanno presentato i due servizi come complementari, non come alternativi, e vale la pena prendere sul serio questa formulazione perché rispondono a esigenze di compliance diverse. Su Amazon Bedrock, AWS è il data processor: le richieste di inferenza restano dentro il security boundary AWS, e la regione AWS scelta determina anche la regione di processing dei dati.

Su Claude Platform su AWS il rapporto è invertito: Anthropic opera il servizio, e i dati di inferenza vengono processati fuori dal perimetro AWS, in infrastruttura Anthropic. Lo dice esplicitamente sia il post AWS Machine Learning Blog sia la documentazione Claude, e non è un dettaglio negoziabile.

Per chi ha requisiti di data residency stringenti, settori finanziari sotto vigilanza, dati sanitari sotto HIPAA, contratti pubblici con clausole sovranistiche, Bedrock resta la scelta corretta perché tiene il dato dentro il confine geografico e legale AWS. Per chi non ha quel vincolo e vuole accesso pieno alle capability native Anthropic con tutti i benefici di feature parity e console di sviluppo, Claude Platform su AWS è la scelta più aggressiva sul time-to-market e quella che apre la strada agli scenari più avanzati con Managed Agents, Skills e advisor strategy.

La domanda da porsi non è quale dei due è migliore in assoluto, è quale dei due si allinea al profilo di rischio del singolo caso d’uso, sapendo che convivono nello stesso account AWS e possono essere usati simultaneamente da workload diversi.

Claude Managed Agents

Tra le beta che diventano usabili in produzione dentro AWS, Claude Managed Agents è quella che più probabilmente sposterà gli equilibri nei prossimi sei mesi. La documentazione Anthropic la descrive come un “pre-built, configurable agent harness that runs in managed infrastructure“, pensato per task a lunga esecuzione e lavoro asincrono. Per un team che oggi sta costruendo agenti in-house con framework custom, gestione manuale dello stato, scheduler proprietari e logica di retry codificata da zero, l’arrivo di un harness gestito direttamente da Anthropic dentro un account AWS sposta una quantità di lavoro di scaffolding fuori dal proprio backlog.

L’effetto netto è che l’unità di adoption sale di livello. Fino a qualche mese fa, un decision-maker tecnico ragionava in termini di chiamate API singole, prompt engineering e RAG. Oggi può ragionare in termini di agenti gestiti che esistono in produzione, con accesso a code execution, web fetch e Skills, dentro un account AWS dove le permission sono già configurate e l’audit trail è già acceso.

Il salto operativo è esattamente quello che The New Stack ha definito come la prima volta in cui un cloud provider offre l’esperienza nativa di una piattaforma AI di terze parti, senza intermediari di processo.

Come funziona l’adoption?

Per chi è già su AWS e usa Claude tramite Bedrock o tramite API key Anthropic separata, le prossime settimane sono il momento giusto per fare tre cose concrete.

Prima cosa: capire se il caso d’uso ha requisiti di data residency che obbligano a restare su Bedrock o se può migrare al servizio nativo, e separare i workload di conseguenza.

Seconda: verificare con l’account executive se ci sono enterprise commitments AWS che possono assorbire la spesa Claude e a quali condizioni, prima di accendere consumi rilevanti.

Terza: valutare se l’introduzione di Managed Agents e Skills consente di compattare progetti agentici interni che oggi richiedono più team coordinati, riducendo il footprint operativo.

Anthropic ha ri-firmato in aprile un commitment infrastrutturale con AWS che vale oltre 100 miliardi di dollari di compute capacity sui prossimi dieci anni, con accesso a Trainium e fino a 5 gigawatt di capacità.

Questa general availability è il primo prodotto consumer-grade che esce da quel deal, e definisce un modello che potrebbe replicarsi su altri cloud nei prossimi cicli. Per chi sta scegliendo oggi dove fare convergere lo stack agentico aziendale, il segnale è che la rotta sull’integrazione tra cloud provider e fornitori di modelli sta diventando più stretta, più contrattuale e meno occasionale.

Senza dubbio resta da capire quanto velocemente questa stretta si tradurrà in lock-in operativi non reversibili. Chi sta progettando adesso può ancora orientare la scelta, chi rimanda di sei mesi probabilmente la troverà già fatta.