Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Inferencia global interregional

La inferencia global entre regiones amplía la inferencia entre regiones más allá de los límites geográficos, lo que permite enrutar las solicitudes de inferencia a empresas comerciales de todo el Regiones de AWS mundo, optimiza los recursos disponibles y permite un mayor rendimiento del modelo.

Ventajas de la inferencia global entre regiones

La inferencia global entre regiones del Claude Sonnet 4.5 de Anthropic ofrece múltiples ventajas con respecto a los perfiles de inferencia transregional geográfica tradicionales:

Consideraciones sobre la inferencia global entre regiones

Tenga en cuenta la siguiente información sobre la inferencia global entre regiones:

Requisitos de la política de IAM para la inferencia global entre regiones

Para habilitar la inferencia global entre regiones para sus usuarios, debe aplicar al rol una política de IAM dividida en tres partes. El siguiente es un ejemplo de una política de IAM para proporcionar un control detallado. <REQUESTING REGION>En el ejemplo, puede sustituir la política por la Región de AWS que está utilizando.

{
    "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 primera parte de la política permite el acceso al perfil de inferencia regional incluido en su solicitud Región de AWS. La segunda parte proporciona acceso al recurso FM regional. La tercera parte otorga acceso al recurso FM global, lo que permite la capacidad de enrutamiento entre regiones.

Al implementar estas políticas, asegúrese de que los tres nombres de recursos de Amazon (ARN) de los recursos estén incluidos en sus declaraciones de IAM:

El ARN FM global no tiene ninguna Región de AWS cuenta especificada, lo cual es intencional y obligatorio para la funcionalidad entre regiones.

Deshabilite la inferencia global entre regiones

Puede elegir entre dos enfoques principales para implementar políticas de rechazo en el CRIS global para funciones específicas de IAM, cada uno con diferentes casos de uso e implicaciones:

Al implementar políticas de rechazo, es crucial entender que el CRIS global cambia el comportamiento del aws:RequestedRegion campo. Las políticas Región de AWS de rechazo tradicionales que utilizan StringEquals condiciones con Región de AWS nombres específicos, por ejemplo, no "aws:RequestedRegion": "us-west-2" funcionarán como se esperaba con el CRIS global, ya que el servicio establece este campo global en lugar de en el destino real. Región de AWS Sin embargo, como se mencionó anteriormente, "aws:RequestedRegion": "unspecified" tendrá como resultado el efecto de denegación.

Requisitos de la política de control de servicios para la inferencia global entre regiones

Para obtener conclusiones globales entre regiones, si la política de seguridad de su organización utiliza los SCP para bloquear las regiones no utilizadas, debe actualizar las condiciones del SCP específicas de la región para permitir el acceso a ellos. "aws:RequestedRegion": "unspecified" Esta condición es específica de la inferencia global entre regiones de Amazon Bedrock y garantiza que las solicitudes se puedan enrutar a todas las regiones comerciales compatibles. AWS

El siguiente ejemplo de SCP bloquea todas las llamadas a la AWS API fuera de las regiones aprobadas y, al mismo tiempo, permite las llamadas de inferencia transregional global de Amazon Bedrock que se utilizan "unspecified" como región para el enrutamiento 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"
                    ]
                }
            }
        }
    ]
}

Deshabilite la inferencia global entre regiones

Las organizaciones con requisitos de cumplimiento o residencia de datos deben evaluar si la inferencia global transregional se ajusta a su marco de cumplimiento, ya que las solicitudes pueden procesarse en otras regiones AWS comerciales compatibles. Para deshabilitar de forma explícita la inferencia global entre regiones, implemente la siguiente política de SCP:

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

Este SCP niega explícitamente la inferencia global entre regiones porque "aws:RequestedRegion" es "unspecified" y la "ArnLike" condición se dirige a los perfiles de inferencia con el global prefijo en el ARN.

AWS Implementación de la Torre de Control

Se desaconseja encarecidamente editar manualmente los SCP gestionados por la Torre de AWS Control, ya que puede provocar desviaciones. En su lugar, utilice los mecanismos proporcionados por la Torre de Control para gestionar estas excepciones. Los principios básicos implican ampliar los controles de denegación de regiones existentes o habilitar las regiones y, posteriormente, aplicar una política de bloqueo condicional y personalizada.

Para obtener una guía detallada y paso a paso sobre la implementación de la inferencia entre regiones con Control Tower, consulte la entrada del blog Habilitar la inferencia entre regiones de Amazon Bedrock en entornos de múltiples cuentas. Esto incluye ampliar los SCP de denegación de región existentes, habilitar las regiones denegadas con SCP personalizados y utilizar Customizations for AWS Control Tower (cFCT) para implementar SCP personalizados como infraestructura como código.

El límite de solicitudes aumenta para la inferencia global entre regiones

Al utilizar perfiles de inferencia CRIS globales, puede utilizar el CRIS global de más de 20 fuentes compatibles. Regiones de AWS Como este será un límite global, las solicitudes para ver, administrar o aumentar las cuotas de los perfiles de inferencia globales entre regiones se deben realizar a través de la consola Service Quotas o la interfaz de línea de AWS comandos (AWS CLI) de la fuente solicitada. Región de AWS

Complete los siguientes pasos para solicitar un aumento del límite:

Al calcular el aumento de cuota necesario, recuerda tener en cuenta la tasa de agotamiento, que se define como la velocidad a la que las fichas de entrada y salida se convierten en cuotas de uso simbólicas para el sistema de regulación. Los siguientes modelos tienen una tasa de agotamiento de 5 veces para las fichas de salida (1 ficha de salida consume 5 fichas de tus cuotas):

En todos los demás modelos, la velocidad de consumo es de 1:1 (1 token de salida consume 1 token de su cuota). En el caso de los tokens de entrada, la relación entre el token y la cuota es de 1:1. El cálculo del número total de tokens por solicitud es el siguiente:

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

Utilice la inferencia global entre regiones

Para utilizar la inferencia global entre regiones con el Claude Sonnet 4.5 de Anthropic, los desarrolladores deben completar los siguientes pasos clave:

Se admite la inferencia global entre regiones para:

Implemente la inferencia global entre regiones

Implementar la inferencia global entre regiones con el Claude Sonnet 4.5 de Anthropic es sencillo y solo requiere algunos cambios en el código de la aplicación existente. El siguiente es un ejemplo de cómo actualizar el código 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'])