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 globale

L'inférence interrégionale mondiale étend l'inférence interrégionale au-delà des limites géographiques, permettant d'acheminer les demandes d'inférence vers les entreprises commerciales prises en charge Régions AWS dans le monde entier, d'optimiser les ressources disponibles et d'augmenter le débit des modèles.

Avantages de l'inférence interrégionale à l'échelle mondiale

L'inférence interrégionale globale pour Claude Sonnet 4.5 d'Anthropic offre de nombreux avantages par rapport aux profils d'inférence interrégionaux géographiques traditionnels :

Considérations relatives à l'inférence interrégionale à l'échelle mondiale

Notez les informations suivantes concernant l'inférence interrégionale globale :

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 permettant un contrôle granulaire. Vous pouvez remplacer <REQUESTING REGION> dans l'exemple de politique par celle dans Région AWS laquelle 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 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 mondiale, qui permet la capacité de routage entre régions.

Lors de la mise en œuvre de ces politiques, assurez-vous que les trois ressources Amazon Resource Names (ARNs) sont incluses dans vos instructions IAM :

L'ARN FM global n'a pas Région AWS de compte spécifié, ce qui est intentionnel et requis pour la fonctionnalité interrégionale.

Désactiver l'inférence interrégionale globale

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 des StringEquals conditions portant des Région AWS noms spécifiques, tels que, ne "aws:RequestedRegion": "us-west-2" fonctionneront pas comme prévu avec le CRIS global, car 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, il en "aws:RequestedRegion": "unspecified" résultera un effet de refus.

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

Pour l'inférence interrégionale globale, si la politique de sécurité de votre organisation bloque les régions non utilisées, vous devez mettre SCPs à 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 d'Amazon Bedrock Global 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 mondial :

{
    "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 interrégionale globale

Organisations soumises à des exigences en matière de résidence ou de conformité des données 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 interrégionale globale, 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 condition "aws:RequestedRegion" est "unspecified" et la "ArnLike" condition ciblent les profils d'inférence dont le global préfixe est dans l'ARN.

AWS Implémentation de la Control Tower

L'édition manuelle SCPs gérée 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 de base impliquent soit d'étendre les contrôles de refus de région existants, soit d'activer les régions, puis d'appliquer une politique de blocage conditionnel personnalisée.

Pour obtenir des step-by-step conseils détaillés sur la mise en œuvre de l'inférence interrégionale avec Control Tower, consultez le billet de blog Enable Amazon Bedrock Cross-region inférence in multi-comptes. Cela couvre l'extension du refus de région existant SCPs, l'activation des régions refusées avec la personnalisation SCPs et l'utilisation de Customizations for AWS Control Tower (CfCT) pour déployer une infrastructure personnalisée SCPs 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. Comme il s'agira d'une limite globale, les demandes d'affichage, de gestion ou d'augmentation des quotas pour les profils d'inférence interrégionaux globaux doivent être effectuées via la console Service Quotas ou l'interface de ligne de AWS commande (AWS CLI) de 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, n'oubliez pas de prendre en compte le taux de combustion, défini comme le taux auquel les jetons d'entrée et de sortie sont convertis en quotas d'utilisation de jetons pour le système de régulation. Les modèles suivants ont un taux de combustion 5 fois supérieur à celui des 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 existant. 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'])