Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124

Amazon Bedrock ha esteso la disponibilità dei modelli Anthropic a nuove geografie, ma lo ha fatto con due meccanismi diversi di residenza dei dati. In India arrivano Claude Opus 5, Claude Sonnet 5 e Claude Haiku 4.5 tramite inferenza cross-Region geografica; a Seoul (Opus 5 e Sonnet 5) e Singapore (Sonnet 5) la disponibilità è in-region. La scelta tra i due modelli non è un dettaglio tecnico: definisce chi, tra le aziende con requisiti di trattamento locale, può davvero usare questi modelli — e a quale prezzo di scalabilità.
In India i tre modelli Anthropic sono raggiungibili attraverso un profilo di inferenza geografico che instrada le richieste solo tra ap-south-1 (Mumbai) e ap-south-2 (Hyderabad). La chiamata parte dalla Region sorgente e viene direzionata automaticamente verso una delle due destinazioni, senza che il cliente debba gestire capacità in ciascuna.
Il vantaggio è la scala: le richieste attingono a un bacino di calcolo più ampio invece di dipendere da una singola Region, con un effetto diretto su throughput e stabilità nei picchi di traffico. Input e output possono muoversi tra le due Region, ma i dati del cliente non vengono archiviati nella Region di destinazione e restano esclusivamente in quella sorgente. Bedrock applica di default un modello zero data retention (ZDR): non conserva input e output, salvo i casi in cui i classificatori automatici di sicurezza segnalino contenuti che richiedono una revisione umana da parte di AWS.
Fatturazione, quote di consumo, log su CloudWatch e CloudTrail restano ancorati alla Region sorgente: il monitoraggio non si sdoppia. Il profilo geografico è disponibile sull'endpoint bedrock-runtime e supporta la Messages API di Anthropic, le API native InvokeModel e Converse, oltre a Amazon Bedrock Guardrails e all'intelligent prompt routing. Chi usa l'SDK Python invoca per esempio il model ID in.anthropic.claude-sonnet-5 da ap-south-1.

A Seoul (ap-northeast-2) Opus 5 e Sonnet 5 girano con inferenza in-region, elaborata interamente dentro la singola Region chiamata. A Singapore (ap-southeast-1) è disponibile il solo Claude Sonnet 5, con lo stesso meccanismo. Non esiste alcun layer di routing: la richiesta è servita da quella Region e input e output restano al suo interno per l'intero ciclo di vita.
Il compromesso è opposto a quello indiano. La capacità della Region diventa il tetto del throughput e le richieste sono soggette a quote di servizio per Region. In compenso, fatturazione, metriche CloudWatch e log CloudTrail sono tutti circoscritti alla stessa Region: non c'è distinzione source/destination da riconciliare. AWS indica esplicitamente servizi finanziari, sanità e settore pubblico come i casi in cui il vincolo di singola Region è rilevante in Sud Corea e Singapore. L'invocazione avviene con il model ID diretto — anthropic.claude-opus-5 o anthropic.claude-sonnet-5 — sempre su bedrock-runtime.
Le due modalità non sono varianti di performance: descrivono due impegni distinti sulla residenza dei dati.
| Area | Modelli disponibili | Tipo di inferenza | Regioni coinvolte |
|---|---|---|---|
| India | Opus 5, Sonnet 5, Haiku 4.5 | Cross-Region geografica | ap-south-1 e ap-south-2 |
| Seoul | Opus 5, Sonnet 5 | In-region | ap-northeast-2 |
| Singapore | Sonnet 5 | In-region | ap-southeast-1 |
Il calcolo delle coperture chiarisce la portata dell'annuncio: tre modelli distribuiti su tre aree generano 6 combinazioni modello-paese su un massimo teorico di 9 — circa il 66,7%. Il profilo geografico indiano copre 3 modelli su 3 (100%), Seoul 2 su 3 (66,7%), Singapore 1 su 3 (33,3%).
Per chi deve rispettare un requisito di singola Region, l'India non basta: il profilo geografico presume che la residenza sia la geografia “India”, non una Region specifica, e ammette il transito tra Mumbai e Hyderabad. Per chi invece ha bisogno di scala entro un vincolo geografico nazionale, è l'unica delle tre opzioni che sfrutta due Region di calcolo. Seoul e Singapore offrono certezza normativa, ma il tetto di capacità resta quello della Region chiamata: chi dimensiona un'applicazione su picchi elevati deve tenerne conto fin dalla scelta del profilo di inferenza.