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.
# Augmentez le débit grâce à l’inférence entre régions
Avec l’inférence entre régions, vous pouvez choisir soit un profil d’inférence interrégional lié à une zone géographique spécifique (comme les États-Unis ou l’UE), soit un profil d’inférence global. Lorsque vous choisissez un profil d'inférence lié à une zone géographique spécifique, Amazon Bedrock sélectionne automatiquement le commercial optimal au Région AWS sein de cette zone géographique pour traiter votre demande d'inférence. Grâce aux profils d’inférence globaux, Amazon Bedrock sélectionne automatiquement la Région AWS commerciale optimale pour traiter la demande, ce qui optimise les ressources disponibles et augmente le débit du modèle.
Les deux types d'inférence interrégionale fonctionnent grâce à des [profils d'inférence](inference-profiles.md), qui définissent un modèle de base (FM) et le modèle Régions AWS vers lequel les demandes peuvent être acheminées. Lorsque vous exécutez l’inférence de modèles en mode à la demande, vos demandes peuvent être limitées par des quotas de service ou pendant les périodes de pointe d’utilisation. L'inférence entre régions vous permet de gérer de manière fluide les pics de trafic imprévus en utilisant le calcul entre différentes régions. Régions AWS
Vous pouvez également augmenter le débit d’un modèle en achetant du [débit provisionné](prov-throughput.md). Les profils d’inférence ne prennent actuellement pas en charge le débit provisionné.
Pour voir les régions et les modèles avec lesquels vous pouvez utiliser des profils d’inférence pour exécuter une inférence entre régions, consultez [Régions et modèles pris en charge pour les profils d'inférence](inference-profiles-support.md).
**Topics**
+ [Choisir entre une inférence géographique et une inférence interrégionale globale](#cross-region-inference-comparison)
+ [Considérations d’ordre général](#cross-region-inference-general-considerations)
+ [Inférence géographique interrégionale](geographic-cross-region-inference.md)
+ [Inférence interrégionale globale](global-cross-region-inference.md)
## Choisir entre une inférence géographique et une inférence interrégionale globale
Amazon Bedrock propose deux types de profils d'inférence interrégionaux, chacun étant conçu pour différents cas d'utilisation et exigences de conformité :
| Fonctionnalité | Inférence géographique interrégionale | Inférence interrégionale globale | Recommendation |
| --- | --- | --- | --- |
| Résidence des données | À l'intérieur des limites géographiques (États-Unis, UE, APAC, etc.) | Toute région AWS commerciale prise en charge dans le monde | Choisissez Geographic pour les exigences de conformité |
| Débit | Supérieur à celui d'une seule région | Le plus haut disponible | Choisissez Global pour des performances optimales |
| Cost | Tarification standard | Environ 10 % d'économies | Choisissez Global pour optimiser les coûts |
| Exigences relatives au SCP | Autoriser toutes les régions de destination dans le profil | Autoriser "aws:RequestedRegion": "unspecified" | Configurez en fonction des politiques de votre organisation |
| Le mieux adapté pour | Organisations soumises à des réglementations relatives à la résidence des données | Organisations priorisant les coûts et les performances | Évaluez vos besoins en matière de conformité et de performance |
Choisissez l'inférence géographique interrégionale lorsque vous avez des exigences en matière de résidence des données et que vous devez vous assurer que le traitement des données reste dans des limites géographiques spécifiques. Optez pour l'inférence interrégionale globale lorsque vous souhaitez un débit maximal et des économies de coûts sans restrictions géographiques.
## Considérations d’ordre général
Notez les informations suivantes concernant l’inférence interrégionale :
+ L’inférence interrégionale n’entraîne aucun coût d’acheminement supplémentaire. Le prix est calculé en fonction de la région à partir de laquelle vous appelez un profil d’inférence. Pour plus d’informations sur la tarification, consultez [Tarification d’Amazon Bedrock](https://aws.amazon.com/bedrock/pricing/).
+ L'inférence entre régions peut acheminer les demandes vers celles Régions AWS qui ne sont pas activées manuellement dans votre. Compte AWS L'activation manuelle des régions n'est pas requise pour que l'inférence interrégionale fonctionne.
+ Toutes les données transmises pendant les opérations interrégionales restent sur le AWS réseau et ne transitent pas par l'Internet public. Les données sont cryptées pendant leur transit entre les deux Régions AWS.
+ Toutes les demandes d'inférence interrégionales sont enregistrées CloudTrail dans votre région source. Recherchez le `additionalEventData.inferenceRegion` champ pour identifier l'endroit où les demandes ont été traitées.
+ AWS Les services fournis par Amazon Bedrock peuvent également utiliser CRIS. Pour plus de détails, consultez la documentation spécifique aux services.
# Inférence géographique interrégionale
L'inférence géographique interrégionale permet de maintenir le traitement des données dans les limites géographiques spécifiées (États-Unis, UE, Asie-Pacifique, etc.) tout en fournissant un débit supérieur à celui de l'inférence à une seule région. Cette option est idéale pour les entreprises soumises à des exigences en matière de résidence des données et à des réglementations de conformité.
## Considérations relatives à l'inférence géographique entre régions
Notez les informations suivantes concernant l'inférence géographique interrégionale :
+ Les demandes d'inférence interrégionales relatives à un profil d'inférence lié à une zone géographique (États-Unis, UE et Asie-Pacifique, par exemple) sont conservées dans les limites de la Régions AWS zone géographique dans laquelle les données se trouvent à l'origine. Par exemple, une demande faite aux États-Unis est conservée Régions AWS aux États-Unis. Bien que les données restent stockées uniquement dans la région, vos invites de saisie et les résultats de sortie peuvent être déplacés en dehors de votre région source durant l’inférence interrégionale. Toutes les données seront transmises chiffrées sur le réseau sécurisé d’Amazon.
+ Pour voir les quotas par défaut pour le débit interrégional lorsque vous utilisez des profils d’inférence liés à une zone géographique (comme US, EU et APAC), consultez les valeurs relatives aux **demandes d’inférence de modèles interrégionales par minute pour \$1\$1Model\$1** et aux **jetons d’inférence de modèle interrégionaux par minute pour \$1\$1Model\$1** dans la section [Quotas de service Amazon Bedrock](https://docs.aws.amazon.com/general/latest/gr/bedrock.html#limits_bedrock) de la *Référence générale AWS *.
## Exigences de la politique IAM pour l'inférence géographique interrégionale
Pour autoriser un utilisateur ou un rôle IAM à invoquer un profil d'inférence géographique interrégional, vous devez autoriser l'accès aux ressources suivantes :
1. Le profil d'inférence interrégional spécifique à la géographie (ces profils ont des préfixes géographiques tels que,,) `us` `eu` `apac`
1. Le modèle de base dans la région source
1. Le modèle de base dans toutes les régions de destination répertoriées dans le profil géographique
L'exemple de politique suivant accorde les autorisations requises pour utiliser le modèle de base Claude Sonnet 4.5 avec un profil d'inférence géographique interrégional pour les États-Unis, où se trouvent la région source `us-east-1` et les régions de destination sont`us-east-1`, `us-east-2` et : `us-west-2`
```
{
"Version": "2012-10-17" ,
"Statement": [
{
"Sid": "GrantGeoCrisInferenceProfileAccess",
"Effect": "Allow",
"Action": "bedrock:InvokeModel",
"Resource": [
"arn:aws:bedrock:us-east-1::inference-profile/us.anthropic.claude-sonnet-4-5-20250929-v1:0"
]
},
{
"Sid": "GrantGeoCrisModelAccess",
"Effect": "Allow",
"Action": "bedrock:InvokeModel",
"Resource": [
"arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-sonnet-4-5-20250929-v1:0",
"arn:aws:bedrock:us-east-2::foundation-model/anthropic.claude-sonnet-4-5-20250929-v1:0",
"arn:aws:bedrock:us-west-2::foundation-model/anthropic.claude-sonnet-4-5-20250929-v1:0"
],
"Condition": {
"StringEquals": {
"bedrock:InferenceProfileArn": "arn:aws:bedrock:us-east-1::inference-profile/us.anthropic.claude-sonnet-4-5-20250929-v1:0"
}
}
}
]
}
```
La première instruction accorde à `bedrock:InvokeModel` l'API l'accès au profil d'inférence géographique interrégional pour les demandes provenant de la région demandeuse. La deuxième déclaration accorde à l'`bedrock:InvokeModel`API l'accès au modèle de base à la fois dans la région demandeuse et dans toutes les régions de destination répertoriées dans le profil d'inférence.
## Exigences de la politique de contrôle des services pour l'inférence géographique interrégionale
De nombreuses organisations mettent en œuvre des contrôles d'accès régionaux par le biais de politiques de contrôle des services dans AWS les organisations à des fins de sécurité et de conformité. Si la politique de sécurité de votre organisation consiste SCPs à bloquer les régions non utilisées, vous devez vous assurer que les conditions SCP spécifiques à votre région autorisent l'accès à toutes les régions de destination répertoriées dans le profil d'inférence géographique interrégional de votre région source.
Pour l'inférence géographique entre régions, vous devez comprendre la relation entre votre région source (où vous effectuez l'appel d'API) et les régions de destination (où les demandes peuvent être acheminées). Consultez la documentation du profil d'inférence pour identifier toutes les régions de destination pour votre région source, puis assurez-vous d' SCPs autoriser l'accès à toutes ces régions de destination.
Par exemple, si vous appelez depuis us-east-1 (région source) en utilisant le profil géographique 4.5 de l'anthropique américain Claude Sonnet, les demandes peuvent être acheminées vers us-east-1, us-east-2 et us-west-2 (régions de destination). Si un SCP restreint l'accès uniquement à us-east-1, l'inférence interrégionale échouera lors de la tentative de routage vers us-east-2 ou us-west-2. Par conséquent, vous devez autoriser les trois régions de destination dans votre SCP, quelle que soit la région d'où vous appelez.
Lorsque vous configurez SCPs l'exclusion de région, n'oubliez pas que le blocage de toute région de destination dans le profil d'inférence empêchera l'inférence entre régions de fonctionner correctement, même si votre région source reste accessible. Pour les exigences du SCP pour l'inférence interrégionale globale, voir. [Exigences relatives à la politique de contrôle des services pour l'inférence interrégionale globale](global-cross-region-inference.md#global-cris-scp-setup)
Pour améliorer la sécurité, pensez à utiliser `bedrock:InferenceProfileArn` cette condition pour limiter l'accès à des profils d'inférence spécifiques. Cela vous permet d'accorder l'accès aux régions requises tout en limitant les profils d'inférence pouvant être utilisés.
## Utiliser l'inférence géographique entre régions
Pour utiliser l'inférence géographique entre régions, vous devez inclure un [profil d'inférence](inference-profiles.md) lorsque vous exécutez l'inférence de modèle de la manière suivante :
+ **Inférence de modèle à la demande** : spécifiez l'identifiant du profil d'inférence `modelId` lors de l'envoi d'une demande [InvokeModel[InvokeModelWithResponseStream](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_runtime_InvokeModelWithResponseStream.html)](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_runtime_InvokeModel.html), d'un [Converse](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_runtime_Converse.html) ou d'une demande. [ConverseStream](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_runtime_ConverseStream.html) Un profil d’inférence définit une ou plusieurs régions vers lesquelles il peut acheminer les demandes d’inférence provenant de votre région source. L’utilisation de l’inférence interrégionale augmente le débit et les performances en acheminant dynamiquement les demandes d’invocation du modèle entre les régions définies dans le profil d’inférence. Facteurs de routage influant sur le trafic utilisateur, la demande et l’utilisation des ressources. Pour de plus amples informations, consultez [Soumission d’invites et génération de réponses à l’aide de l’inférence de modèle](inference.md).
+ **Inférence par lots** — Soumettez les demandes de manière asynchrone avec l'inférence par lots en spécifiant l'ID du profil d'inférence lors de l'envoi d'une demande. `modelId` [CreateModelInvocationJob](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_CreateModelInvocationJob.html) L’utilisation d’un profil d’inférence vous permet d’utiliser le calcul sur plusieurs Régions AWS et d’accélérer les temps de traitement de vos tâches par lot. Une fois le travail terminé, vous pouvez récupérer les fichiers de sortie depuis le compartiment Amazon S3 dans la région source.
+ **Agents** : spécifiez l’ID du profil d’inférence dans le champ `foundationModel` d’une demande [https://docs.aws.amazon.com/bedrock/latest/APIReference/API_agent_CreateAgent.html](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_agent_CreateAgent.html). Pour de plus amples informations, veuillez consulter [Création et configuration manuelles de l’agent](agents-create.md).
+ **Génération de réponses dans la base de connaissances** : vous pouvez utiliser l’inférence interrégionale lorsque vous générez une réponse après avoir interrogé une base de connaissances. Pour de plus amples informations, veuillez consulter [Test de votre base de connaissances avec des requêtes et des réponses](knowledge-base-test.md).
+ **Évaluation du modèle** : vous pouvez soumettre un profil d’inférence en tant que modèle à évaluer lorsque vous soumettez une tâche d’évaluation des modèles. Pour de plus amples informations, veuillez consulter [Évaluation des performances des ressources Amazon Bedrock](evaluation.md).
+ **Gestion des promptes** : vous pouvez utiliser l’inférence interrégionale lorsque vous générez une réponse à une invite que vous avez créée dans Gestion des invites. Pour de plus amples informations, consultez [Création et stockage d’invites réutilisables avec la gestion des invites dans Amazon Bedrock](prompt-management.md).
+ **Flux d’invite** : vous pouvez utiliser l’inférence interrégionale lorsque vous générez une réponse à une invite que vous définissez en ligne dans un nœud d’invite d’un flux d’invite. Pour de plus amples informations, veuillez consulter [Créez un flux de travail d'IA end-to-end génératif avec Amazon Bedrock Flows](flows.md).
Pour savoir comment utiliser un profil d’inférence pour envoyer des demandes d’invocation de modèles interrégionaux, consultez [Utilisation d’un profil d’inférence lors de l’invocation du modèle](inference-profiles-use.md).
Pour plus d’informations sur l’inférence interrégionale, consultez [Présentation de l’inférence interrégionale dans Amazon Bedrock](https://aws.amazon.com/blogs/machine-learning/getting-started-with-cross-region-inference-in-amazon-bedrock/).
Pour des informations détaillées sur l'inférence interrégionale globale, y compris la configuration IAM et la gestion des quotas de service, consultez. [Inférence interrégionale globale](global-cross-region-inference.md)
# 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 :
+ **Débit amélioré en période de pointe** — L'inférence interrégionale globale améliore la résilience pendant les périodes de pointe en acheminant automatiquement les demandes vers Régions AWS la capacité disponible. Ce routage dynamique s'effectue de manière fluide, sans configuration supplémentaire ni intervention de la part des développeurs. Contrairement aux approches traditionnelles qui peuvent nécessiter un équilibrage de charge complexe côté client Régions AWS, l'inférence interrégionale globale gère automatiquement les pics de trafic. Cela est particulièrement important pour les applications critiques pour lesquelles les temps d'arrêt ou la dégradation des performances peuvent avoir des répercussions financières ou de réputation importantes.
+ **Rentabilité — L'**inférence interrégionale globale pour Claude Sonnet 4.5 d'Anthropic permet de réaliser des économies d'environ 10 % sur la tarification des jetons d'entrée et de sortie par rapport à l'inférence géographique interrégionale. Le prix est calculé en fonction Région AWS de l'origine de la demande (source Région AWS). Cela signifie que les entreprises peuvent bénéficier d'une résilience améliorée à des coûts encore plus bas. Ce modèle de tarification fait de l'inférence interrégionale mondiale une solution rentable pour les entreprises qui cherchent à optimiser leurs déploiements d'IA générative. En améliorant l'utilisation des ressources et en permettant d'augmenter le débit sans coûts supplémentaires, il aide les entreprises à maximiser la valeur de leur investissement dans Amazon Bedrock.
+ **Surveillance rationalisée** : lorsque vous utilisez l'inférence interrégionale globale, CloudTrail continuez à enregistrer CloudWatch les entrées du journal dans votre source Région AWS, ce qui simplifie l'observabilité et la gestion. Même si vos demandes sont traitées dans différents pays du Régions AWS monde, vous conservez une vue centralisée des performances et des modèles d'utilisation de votre application grâce à vos outils AWS de surveillance habituels.
+ **Flexibilité des quotas à la demande** — Grâce à l'inférence interrégionale globale, vos charges de travail ne sont plus limitées par la capacité régionale individuelle. Au lieu d'être limitées à la capacité disponible dans un domaine spécifique Région AWS, vos demandes peuvent être acheminées dynamiquement à travers l'infrastructure AWS mondiale. Cela permet d'accéder à un pool de ressources beaucoup plus important, ce qui simplifie la gestion de charges de travail volumineuses et de pics de trafic soudains.
## Considérations relatives à l'inférence interrégionale à l'échelle mondiale
Notez les informations suivantes concernant l'inférence interrégionale globale :
+ Les profils d’inférence interrégionaux mondiaux fournissent un débit supérieur à celui d’un profil d’inférence lié à une zone géographique particulière. Un profil d’inférence lié à une zone géographique particulière offre un débit supérieur à celui de l’inférence à une seule région.
+ Pour voir les quotas par défaut pour le débit interrégional lorsque vous utilisez des profils d’inférence globaux, consultez les valeurs relatives aux **demandes d’inférence de modèle interrégionales globales par minute pour \$1\$1Model\$1** et aux **jetons d’inférence de modèle interrégionale par minute pour \$1\$1Model\$1** dans la section [Quotas de service Amazon Bedrock](https://docs.aws.amazon.com/general/latest/gr/bedrock.html#limits_bedrock) de la *Référence générale AWS *.
Vous pouvez demander, consulter et gérer des quotas pour le profil d'inférence interrégional global à partir de la [console Service Quotas](https://console.aws.amazon.com/servicequotas/home/services/bedrock/quotas) ou à l'aide des commandes AWS CLI dans votre région **source**.
## 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 `` 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:::inference-profile/global."
],
"Condition": {
"StringEquals": {
"aws:RequestedRegion": ""
}
}
},
{
"Sid": "GrantGlobalCrisInferenceProfileInRegionModelAccess",
"Effect": "Allow",
"Action": "bedrock:InvokeModel",
"Resource": [
"arn:aws:bedrock:::foundation-model/"
],
"Condition": {
"StringEquals": {
"aws:RequestedRegion": "",
"bedrock:InferenceProfileArn": "arn:aws:bedrock:::inference-profile/global."
}
}
},
{
"Sid": "GrantGlobalCrisInferenceProfileGlobalModelAccess",
"Effect": "Allow",
"Action": "bedrock:InvokeModel",
"Resource": [
"arn:aws:bedrock:::foundation-model/"
],
"Condition": {
"StringEquals": {
"aws:RequestedRegion": "unspecified",
"bedrock:InferenceProfileArn": "arn:aws:bedrock:::inference-profile/global."
}
}
}
]
}
```
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 :
+ Le profil d'inférence régional ARN suit le modèle. `arn:aws:bedrock:REGION:ACCOUNT:inference-profile/global.MODEL-NAME` Ceci est utilisé pour donner accès au profil d'inférence global dans la source Région AWS.
+ Le Regional FM utilise`arn:aws:bedrock:REGION::foundation-model/MODEL-NAME`. Ceci est utilisé pour donner accès au FM dans la source Région AWS.
+ Le FM mondial nécessite`arn:aws:bedrock:::foundation-model/MODEL-NAME`. Ceci est utilisé pour donner accès à la FM dans différents pays Régions AWS.
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 :
+ **Supprimer une stratégie IAM** — La première méthode consiste à supprimer une ou plusieurs des trois politiques IAM requises des autorisations utilisateur. Étant donné que le CRIS global nécessite le fonctionnement des trois politiques, la suppression d'une politique entraînera un refus d'accès.
+ **Mettre en œuvre une politique de refus** — La deuxième approche consiste à mettre en œuvre une politique de refus explicite qui cible spécifiquement les profils d'inférence CRIS globaux. Cette méthode fournit une documentation claire de vos intentions en matière de sécurité et garantit que même si quelqu'un ajoute accidentellement les politiques d'autorisation requises ultérieurement, le refus explicite aura la priorité. La politique de refus doit utiliser une `StringEquals` condition correspondant au modèle`"aws:RequestedRegion": "unspecified"`. Ce modèle cible spécifiquement les profils d'inférence avec le `global` préfixe.
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](https://aws.amazon.com/blogs/machine-learning/enable-amazon-bedrock-cross-region-inference-in-multi-account-environments/). 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 :
1. Connectez-vous à la console Service Quotas de votre AWS compte.
1. Dans le panneau de navigation, choisissez **Services AWS **.
1. Dans la liste des services, recherchez et choisissez **Amazon Bedrock**.
1. Dans la liste des quotas pour Amazon Bedrock, utilisez le filtre de recherche pour trouver les quotas mondiaux CRIS spécifiques. Par exemple :
+ Jetons d'inférence de modèles interrégionaux mondiaux par minute pour Anthropic Claude Sonnet 4.5 V1
1. Sélectionnez le quota que vous souhaitez augmenter.
1. Choisissez **Demander une augmentation au niveau du compte**.
1. Entrez la nouvelle valeur de quota souhaitée.
1. Choisissez **Request** pour soumettre votre demande.
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)** :
+ Claude Anthropic, opus 4
+ Claude Sonnet anthropique 4.5
+ Anthropic Claude Sonnet 4
+ Sonnet Anthropic Claude 3.7
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 :
+ **Utiliser l'identifiant du profil d'inférence global** : lorsque vous effectuez des appels d'API vers Amazon Bedrock, spécifiez l'identifiant du profil d'inférence Claude Sonnet 4.5 d'Anthropic global (`global.anthropic.claude-sonnet-4-5-20250929-v1:0`) au lieu d'un identifiant de modèle spécifique. Région AWS
+ **Configurer les autorisations IAM** : accordez les autorisations IAM appropriées pour accéder au profil d'inférence et FMs à une destination potentielle. Régions AWS
L'inférence interrégionale globale est prise en charge pour :
+ Inférence de modèles à la demande
+ Inférence par lots
+ Agents
+ Évaluation de modèle
+ Gestion des invites
+ Des flux rapides
**Note**
Le profil d’inférence global est pris en charge pour l’inférence de modèle à la demande, l’inférence par lots, les agents, l’évaluation des modèles, la gestion des invites et les flux d’invite.
## 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'])
```