L'inférence inter-régions Amazon Bedrock vous donne un débit effectif plus élevé et moins d'erreurs de throttling régional sans surcoût de routage, ce qui approche la résilience gratuite. Le piège est qu'un profil d'inférence global peut envoyer votre prompt vers n'importe quelle région ayant de la capacité, et si ce prompt porte des données réglementées, « où qu'il y ait de la capacité » n'est pas une réponse que votre équipe conformité acceptera. La fonctionnalité est authentiquement utile. Qu'elle soit un gain ou une violation dépend entièrement du type de profil d'inférence que vous choisissez, et ce choix est facile à faire sans lire ce qu'il implique.

L'attrait est réel. Un appel modèle mono-région est plafonné par la capacité de cette région et ses limites de throttling par région. L'inférence inter-régions permet à Bedrock de répartir les requêtes entre régions, si bien qu'un pic qui aurait déclenché des erreurs de throttling dans une région est absorbé. Vous obtenez une meilleure latence de queue et moins de 429 sans payer de prime pour le routage lui-même. La question n'est pas si cela aide. C'est où vos données ont le droit d'aller pendant que ça aide.

Deux profils, deux promesses très différentes

Bedrock vous donne deux saveurs d'inférence inter-régions, et l'écart entre elles est tout l'article :

  • Profil géographique. Le routage est confiné à une géographie nommée, comme les États-Unis ou l'UE. Bedrock choisit la meilleure région à l'intérieur de cette frontière, si bien qu'un profil géographique UE garde le traitement à l'intérieur des régions UE. C'est celui que vous choisissez quand vous avez des exigences de résidence des données.
  • Profil global. Le routage n'est pas contraint pour un débit et une efficacité de coût maximaux. Bedrock envoie la requête vers la meilleure région commerciale disponible n'importe où. C'est celui qui peut déplacer le prompt d'un utilisateur européen vers une région hors d'Europe.

Les deux améliorent la résilience. Un seul respecte une frontière géographique. Choisir le profil global parce qu'il annonce le meilleur débit, sans vérifier quelles données y transitent, est ainsi qu'une optimisation de débit devient un incident de résidence des données.

La résidence concerne le prompt, pas seulement le stockage

Les équipes qui gardent soigneusement leur base de données dans l'UE oublient parfois qu'un appel d'inférence transporte aussi des données. Le prompt est une donnée. S'il contient des données personnelles, des dossiers clients, ou tout ce qu'une réglementation épingle à une géographie, alors la région qui traite ce prompt est dans le périmètre de résidence, exactement comme la région qui le stocke. Un profil global qui relaie ce prompt vers un autre continent pour traitement a déplacé des données réglementées à travers une frontière, même si rien n'a été « stocké » là-bas. La question de résidence suit la donnée à travers l'inférence, pas seulement jusqu'à la base de données.

Comment décider, par charge de travail

Ce n'est pas un seul réglage pour l'ensemble du compte. C'est une décision par charge de travail, et la question décisive est ce que porte le prompt :

Does the prompt contain data bound to a geography?
  yes -> geographic profile, matched to the required region
         (accept the capacity ceiling of that geography)
  no  -> global profile is fine
         (take the throughput and resilience, no residency risk)

Une charge de travail traitant des données européennes réglementées utilise un profil géographique UE et vit avec le fait d'être plafonnée à la capacité UE, car l'alternative est non conforme peu importe sa rapidité. Une charge de travail sur des données non sensibles, outillage interne, contenu public, prompts synthétiques, peut prendre le profil global et profiter de la résilience sans rien risquer. La tarification est calculée à partir de la région depuis laquelle vous appelez dans les deux cas, c'est donc une décision de conformité, pas de coût.

À retenir

L'inférence inter-régions est une résilience bon marché quand vous faites correspondre le profil aux données. Un profil géographique garde le traitement à l'intérieur d'une frontière et est le bon choix par défaut pour tout ce qui touche des données réglementées, au prix du plafond de capacité de cette géographie. Un profil global vous donne le meilleur débit et convient pour des données sans contrainte de résidence. Le piège n'est pas la fonctionnalité, c'est de choisir le profil global par réflexe parce que ça semble plus rapide, et de découvrir plus tard que « meilleure région disponible » a silencieusement relayé des prompts réglementés à travers une frontière. Décidez par charge de travail, et laissez ce que porte le prompt choisir le profil.

À lire ensuite

Pour le playbook d'architecture multi-région et de résidence des données sur AWS, les notes de terrain cloud se trouvent sur ercan.cloud, et le hub est sur ercanermis.com.