Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Inférence interrégionale mondiale

L'inférence interrégionale globale étend l'inférence interrégionale au-delà des frontières géographiques, permettant l'acheminement des demandes d'inférence vers des sites commerciaux pris en charge dans le monde entier. Régions AWS

Avantages de l'inférence interrégionale globale

Avec l'inférence interrégionale globale pour le modèle Anthropic Claude Sonnet 4.5, vous bénéficiez des avantages suivants par rapport à un profil d'inférence géographique interrégional :

Considérations relatives à l'inférence interrégionale globale

Notez les informations suivantes concernant l'inférence globale entre régions :

Exigences relatives à la politique IAM pour l'inférence interrégionale globale

Pour activer l'inférence interrégionale globale pour vos utilisateurs, vous devez appliquer une politique IAM en trois parties au rôle. Voici un exemple de politique IAM visant à fournir un contrôle granulaire. <REQUESTING REGION>Dans l'exemple de politique, vous pouvez remplacer la politique dans laquelle Région AWS vous opérez.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "GrantGlobalCrisInferenceProfileRegionAccess",
            "Effect": "Allow",
            "Action": "bedrock:InvokeModel",
            "Resource": [
                "arn:aws:bedrock:<REQUESTING REGION>:<ACCOUNT>:inference-profile/global.<MODEL NAME>"
            ],
            "Condition": {
                "StringEquals": {
                    "aws:RequestedRegion": "<REQUESTING REGION>"
                }
            }
        },
        {
            "Sid": "GrantGlobalCrisInferenceProfileInRegionModelAccess",
            "Effect": "Allow",
            "Action": "bedrock:InvokeModel",
            "Resource": [
                "arn:aws:bedrock:<REQUESTING REGION>::foundation-model/<MODEL NAME>"
            ],
            "Condition": {
                "StringEquals": {
                    "aws:RequestedRegion": "<REQUESTING REGION>",
                    "bedrock:InferenceProfileArn": "arn:aws:bedrock:<REQUESTING REGION>:<ACCOUNT>:inference-profile/global.<MODEL NAME>"
                }
            }
        },
        {
            "Sid": "GrantGlobalCrisInferenceProfileGlobalModelAccess",
            "Effect": "Allow",
            "Action": "bedrock:InvokeModel",
            "Resource": [
                "arn:aws:bedrock:::foundation-model/<MODEL NAME>"
            ],
            "Condition": {
                "StringEquals": {
                    "aws:RequestedRegion": "unspecified",
                    "bedrock:InferenceProfileArn": "arn:aws:bedrock:<REQUESTING REGION>:<ACCOUNT>:inference-profile/global.<MODEL NAME>"
                }
            }
        }
    ]
}

La première partie de la politique donne accès au profil d'inférence régional figurant dans votre demande Région AWS. La deuxième partie donne accès à la ressource FM régionale. La troisième partie donne accès à la ressource FM globale, ce qui permet la capacité de routage interrégional.

Lors de la mise en œuvre de ces politiques, incluez les trois noms de ressources Amazon (ARN) des ressources dans vos déclarations IAM :

Aucun compte Région AWS ou aucun compte n'est spécifié pour l'ARN FM global, ce qui est intentionnel et requis pour la fonctionnalité interrégionale.

Désactiver l'inférence globale entre régions

Vous pouvez choisir entre deux approches principales pour mettre en œuvre des politiques de refus dans le CRIS global pour des rôles IAM spécifiques, chacune ayant des cas d'utilisation et des implications différents :

Lors de la mise en œuvre de politiques de refus, il est essentiel de comprendre que le CRIS global modifie le comportement du aws:RequestedRegion terrain. Les politiques Région AWS de refus traditionnelles qui utilisent StringEquals des conditions portant des Région AWS noms spécifiques, par exemple, ne "aws:RequestedRegion": "us-west-2" fonctionneront pas comme prévu avec le CRIS global. Le service définit ce champ sur la destination global plutôt que sur la destination réelle Région AWS. Cependant, comme mentionné précédemment, "aws:RequestedRegion": "unspecified" cela entraînera un effet de refus.

Exigences relatives à la politique de contrôle des services pour l'inférence interrégionale globale

À des fins d'inférence interrégionale globale, si la politique de sécurité de votre organisation utilise des SCP pour bloquer les régions non utilisées, vous devez mettre à jour les conditions SCP spécifiques à votre région pour autoriser l'accès avec. "aws:RequestedRegion": "unspecified" Cette condition est spécifique à l'inférence interrégionale mondiale d'Amazon Bedrock et garantit que les demandes peuvent être acheminées vers toutes les régions commerciales prises en charge. AWS

L'exemple de SCP suivant bloque tous les appels d' AWS API en dehors des régions approuvées tout en autorisant les appels d'inférence interrégionaux Amazon Bedrock Global qui sont utilisés "unspecified" comme région pour le routage global :

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyAllOutsideApprovedRegions",
            "Effect": "Deny",
            "Action": "*",
            "Resource": "*",
            "Condition": {
                "StringNotEquals": {
                    "aws:RequestedRegion": [
                        "us-east-1",
                        "us-east-2",
                        "us-west-2",
                        "unspecified"
                    ]
                }
            }
        }
    ]
}

Désactiver l'inférence globale entre régions

Les organisations ayant des exigences en matière de résidence des données ou de conformité doivent évaluer si l'inférence interrégionale globale correspond à leur cadre de conformité, étant donné que les demandes peuvent être traitées dans d'autres régions AWS commerciales prises en charge. Pour désactiver explicitement l'inférence globale entre régions, implémentez la politique SCP suivante :

{
    "Effect": "Deny",
    "Action": "bedrock:*",
    "Resource": "*",
    "Condition": {
        "StringEquals": {
            "aws:RequestedRegion": "unspecified"
        },
        "ArnLike": {
            "bedrock:InferenceProfileArn": "arn:aws:bedrock:*:*:inference-profile/global.*"
        }
    }
}

Ce SCP refuse explicitement l'inférence interrégionale globale car la valeur "aws:RequestedRegion" is "unspecified" et la "ArnLike" condition ciblent les profils d'inférence dont le global préfixe figure dans l'ARN.

AWS Implémentation de la tour

La modification manuelle des SCP gérés par AWS Control Tower est fortement déconseillée car elle peut entraîner une dérive. Utilisez plutôt les mécanismes fournis par Control Tower pour gérer ces exceptions. Les principes fondamentaux consistent soit à étendre les contrôles de refus de régions existants, soit à activer des régions, puis à appliquer une politique de blocage conditionnelle personnalisée.

Pour obtenir des instructions détaillées, étape par étape, sur la mise en œuvre de l'inférence interrégionale avec Control Tower, consultez l'article de blog Activer l'inférence interrégionale Amazon Bedrock dans les environnements multicomptes. Cela couvre l'extension des SCP de refus de région existants, l'activation des régions refusées avec des SCP personnalisés et l'utilisation de Customizations for AWS Control Tower (cFCT) pour déployer des SCP personnalisés sous forme d'infrastructure sous forme de code.

Augmentation de la limite de demandes pour l'inférence interrégionale globale

Lorsque vous utilisez des profils d'inférence CRIS globaux, vous pouvez utiliser des CRIS globaux provenant de plus de 20 sources Régions AWS prises en charge. Il s'agit d'une limite globale. Pour afficher, gérer ou augmenter les quotas pour les profils d'inférence interrégionaux globaux, utilisez la console Service Quotas ou l' AWS interface de ligne de commande dans la source demandée. Région AWS

Procédez comme suit pour demander une augmentation de limite :

Lorsque vous calculez l'augmentation de quota requise, tenez compte du taux d'épuisement. Le taux de combustion est le taux auquel les jetons d'entrée et de sortie sont convertis en quotas d'utilisation de jetons pour le système de limitation. Les modèles suivants ont un taux de combustion de 5 fois supérieur pour les jetons de sortie (1 jeton de sortie consomme 5 jetons de vos quotas)  :

Pour tous les autres modèles, le taux de destruction est de 1:1 (1 jeton de sortie consomme 1 jeton de votre quota). Pour les jetons d'entrée, le ratio jeton/quota est de 1:1. Le calcul du nombre total de jetons par demande est le suivant :

Input token count + Cache write input tokens + (Output token count x Burndown rate)

Utiliser l'inférence interrégionale globale

Pour utiliser l'inférence interrégionale globale avec Claude Sonnet 4.5 d'Anthropic, les développeurs doivent suivre les étapes clés suivantes :

L'inférence interrégionale globale est prise en charge pour :

Mettre en œuvre l'inférence interrégionale globale

La mise en œuvre de l'inférence interrégionale globale avec Claude Sonnet 4.5 d'Anthropic est simple et ne nécessite que quelques modifications du code de votre application existante. Voici un exemple de mise à jour de votre code en Python :

import boto3
import json
bedrock = boto3.client('bedrock-runtime', region_name='us-east-1')
model_id = "global.anthropic.claude-sonnet-4-5-20250929-v1:0"  
response = bedrock.converse(
    messages=[{"role": "user", "content": [{"text": "Explain cloud computing in 2 sentences."}]}],
    modelId=model_id,
)

print("Response:", response['output']['message']['content'][0]['text'])
print("Token usage:", response['usage'])
print("Total tokens:", response['usage']['totalTokens'])