AWS Lance Amazon Bedrock en Nouvelle-Zélande avec Claude et Inférence Inter-Régions

AWS a lancé Amazon Bedrock dans la région Asie-Pacifique (Nouvelle-Zélande) le 26 mars 2026, c'est-à-dire à Auckland. Pour les entreprises locales, cela signifie que les demandes vers les modèles génératifs peuvent maintenant être envoyées depuis la région AWS de Nouvelle-Zélande, et Bedrock distribuera automatiquement l'inférence entre Auckland et les installations australiennes selon les besoins.

Comment fonctionne le lancement

La nouvelle région AWS a reçu l'identifiant ap-southeast-6 et est devenue le point de départ de l'inférence multi-régions dans Bedrock. En pratique, cela signifie qu'une application peut effectuer un appel API depuis Auckland, et le traitement de la demande ira soit dans la même région, soit à Sydney, soit à Melbourne. AWS a ajouté une configuration géographique distincte AU pour la Nouvelle-Zélande, qui maintient le traitement dans l'espace Australie-Nouvelle-Zélande et offre aux entreprises plus d'options de bande passante.

Si une entreprise n'a pas d'exigences strictes en matière de résidence des données, elle peut choisir un profil de routage global. Dans ce mode, Bedrock envoie les demandes aux régions commerciales AWS prises en charge dans le monde entier pour réduire le risque de limitation et gérer les pics de charge.

AWS souligne séparément que le trafic circule sur le réseau global de sa propre entreprise, ne sort pas sur l'Internet public et est chiffré lors de la transmission entre régions. Les journaux de tous les appels multi-régions restent dans la région source, c'est-à-dire à Auckland.

Quels modèles sont disponibles

Au lancement, la région de Nouvelle-Zélande a obtenu l'accès à la gamme Anthropic Claude : Opus 4.5, Opus 4.6, Sonnet 4.5, Sonnet 4.6 et Haiku 4.5. Pour le profil global, AWS indique également l'accès à Amazon Nova 2 Lite et à un ensemble plus large de modèles provenant de différents fournisseurs.

Les développeurs n'ont pas besoin de réapprendre les intégrations à partir de zéro : les profils fonctionnent via les API Bedrock standard, y compris InvokeModel, InvokeModelWithResponseStream, Converse et ConverseStream.

• Le profil géographique AU maintient l'inférence à Auckland, Sydney et Melbourne
• Le profil global fournit plus de capacité disponible et un choix de modèles plus large
• Les identifiants de modèles changent via les préfixes au. et global.
• Le routage existant pour Sydney et Melbourne reste inchangé
• Le format Converse unifié simplifie le passage d'un modèle à l'autre sans réécriture de code

Un détail important : pour le profil Australie-Nouvelle-Zélande, seuls les modèles Claude sont actuellement pris en charge, tandis que le routage global ouvre un ensemble plus large de modèles de base. Cette séparation est importante pour les équipes qui doivent surveiller à la fois les exigences de conformité interne et la disponibilité des capacités. Si une géographie de traitement prévisible est nécessaire, le profil AU est plus logique. Si le débit maximal est plus critique, la route globale avec distribution dynamique de la charge est plus utile.

Contrôle et limites

Le lancement dans une nouvelle région n'élimine pas le besoin de configuration d'infrastructure. Pour appeler les modèles via le profil AU depuis Auckland, la politique IAM doit autoriser l'accès au profil d'inférence dans ap-southeast-6 et aux modèles eux-mêmes dans toutes les régions de destination. AWS recommande un schéma de privilèges minimaux : autoriser l'invocation de modèles à Sydney, Melbourne et Auckland uniquement lorsque la demande passe par le profil d'inférence, pas directement.

Pour les entreprises disposant de Politiques de contrôle des services, c'est également important car Bedrock doit être explicitement autorisé à fonctionner dans les trois régions ANZ. Il existe également des nuances opérationnelles.

Les quotas sont calculés au niveau de la région source, de sorte que l'augmentation de la limite à Auckland ne s'applique qu'aux demandes envoyées depuis ap-southeast-6. AWS mesure la charge sur deux axes — tokens par minute et demandes par minute, et pour certains modèles Claude, les jetons de sortie sont facturés à un ratio de 5:1 par rapport aux jetons d'entrée. Pour Claude Haiku 4.5 et les modèles Nova, un ratio de 1:1 s'applique.

Vous pouvez vérifier exactement où une demande a été traitée via CloudTrail par le champ inferenceRegion, et surveiller la latence, les erreurs et la consommation de jetons via les métriques CloudWatch.

Qu'est-ce que cela signifie

Pour AWS, ce n'est pas simplement une région de plus sur la liste, mais une tentative de rapprocher Bedrock des clients d'entreprise en Nouvelle-Zélande qui se soucient à la fois de la latence et du contrôle de la géographie du traitement. Pour le marché, c'est un bon signal : les plateformes d'IA en nuage rivalisent de plus en plus non seulement sur les modèles, mais sur la façon dont elles traitent soigneusement les questions de routage, de quotas et de conformité.