View a markdown version of this page

Inférence géographique interrégionale - Amazon Bedrock

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 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 :

  • Cross-Region les demandes d'inférence relatives à un profil d'inférence lié à une zone géographique (par exemple, États-Unis, UE et Asie-Pacifique) sont conservées dans 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 lors de l'utilisation de profils d'inférence liés à une zone géographique (comme les États-Unis, l'UE et la région APAC), reportez-vous au modèle de demandes d'inférence par minute pour $ {Cross-region Model} et Cross-region aux jetons d'inférence de modèle par minute pour les valeurs de $ {Model} dans les quotas de service Amazon Bedrock dans 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

  2. Le modèle de base dans la région source

  3. 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 sontus-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:<ACCOUNT_ID>: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:<ACCOUNT_ID>: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:InvokeModelAPI 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 relatives à 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 utilise des SCP pour bloquer les régions non utilisées, vous devez vous assurer que vos conditions de Region-specific SCP 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 que vos SCP autorisent 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 des SCP pour l'exclusion de régions, 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

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 lorsque vous exécutez l'inférence de modèle de la manière suivante :

  • On-demand inférence de modèle — Spécifiez l'ID du profil d'inférence modelId lors de l'envoi d'une demande InvokeModelInvokeModelWithResponseStream, d'un Converse ou d'une demande. ConverseStream 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 Faire des demandes d'inférence.

  • 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 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 lots. 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 CreateAgent. Pour de plus amples informations, veuillez consulter Création et configuration manuelles de l’agent.

  • 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.

  • É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.

  • 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.

  • 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éation d’un flux de travail d’IA générative de bout en bout avec Amazon Bedrock Flows.

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.

Pour plus d’informations sur l’inférence interrégionale, consultez Présentation de l’inférence interrégionale dans 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