La adopción e implementación de la inferencia generativa de IA ha aumentado a medida que las organizaciones crean más cargas de trabajo operativas que utilizan capacidades de IA en la producción a escala. Para ayudar a los clientes a alcanzar la escala de sus aplicaciones de IA generativa, Amazon Bedrock ofrece perfiles de inferencia entre regiones (CRIS), una característica poderosa que las organizaciones pueden utilizar para distribuir sin problemas el procesamiento de inferencia en múltiples regiones de AWS. Esta capacidad le ayuda a obtener un mayor rendimiento mientras construye a escala y ayuda a mantener sus aplicaciones de IA generativa receptivas y confiables incluso bajo cargas pesadas.
En esta publicación, exploramos las consideraciones de seguridad y las mejores prácticas para implementar perfiles de inferencia entre regiones de Amazon Bedrock. Ya sea que esté creando una aplicación de IA generativa o necesite cumplir con requisitos de cumplimiento regionales específicos, esta guía lo ayudará a comprender la arquitectura segura de Amazon Bedrock CRIS y cómo configurar correctamente su implementación.
Los perfiles de inferencia operan sobre dos conceptos clave:
Región de origen: la región desde la que se realiza la solicitud de API. Región de destino: una región a la que Amazon Bedrock puede enrutar la solicitud de inferencia.
Cuando invoca un perfil de inferencia entre regiones en Amazon Bedrock, su solicitud sigue una ruta de enrutamiento inteligente. La solicitud se origina en su región de origen donde realiza la llamada API y se enruta automáticamente a una de las regiones de destino definidas en el perfil de inferencia. La inferencia entre regiones opera a través de la red segura de AWS con cifrado de extremo a extremo para los datos en tránsito.
La distinción clave es que CRIS no cambia el lugar donde se almacenan los datos: ninguno de los datos del cliente se almacena en ninguna región de destino cuando se utiliza la inferencia entre regiones, los registros administrados por el cliente (como el registro de invocación de modelos), las bases de conocimiento y las configuraciones almacenadas permanecen exclusivamente dentro de la región de origen. La solicitud de inferencia viaja a través de la red global de AWS administrada por Amazon Bedrock y las respuestas se devuelven cifradas a su aplicación en la región de origen.
Amazon Bedrock proporciona dos tipos de perfiles de inferencia entre regiones:
Inferencia geográfica entre regiones: Amazon Bedrock selecciona automáticamente la región óptima dentro de una geografía definida (como EE. UU., UE, Australia y Japón) para procesar su solicitud de inferencia. Este perfil mantiene el procesamiento de inferencia dentro de límites geográficos específicos, lo que puede ayudar a las organizaciones a abordar los requisitos de residencia de datos regionales. Inferencia global entre regiones: Global CRIS mejora aún más la inferencia entre regiones al permitir el enrutamiento de solicitudes de inferencia a regiones comerciales admitidas en todo el mundo, optimizando los recursos disponibles y permitiendo un mayor rendimiento del modelo. Este perfil enruta solicitudes a todas las regiones comerciales admitidas a nivel mundial sin restricciones geográficas.
Si tiene requisitos estrictos de cumplimiento o residencia de datos, debe evaluar cuidadosamente si la inferencia entre regiones se alinea con sus políticas y regulaciones, ya que sus datos de inferencia se pueden procesar en múltiples regiones preconfiguradas como se define en el perfil de inferencia.
Requisitos de permisos de IAM y consideraciones sobre políticas de control de servicios (SCP)
De forma predeterminada, los usuarios y roles dentro de su cuenta de AWS no tienen permiso para crear, modificar o utilizar recursos de Amazon Bedrock. El acceso se puede controlar a través de dos mecanismos principales: políticas de AWS Identity and Access Management (IAM) para permisos detallados de usuarios y roles, y SCP para medidas de seguridad y restricciones en toda la organización. Para utilizar Amazon Bedrock CRIS, los usuarios deben tener los permisos de IAM necesarios. Si hay SCP adjuntos a su cuenta, también deben permitir las acciones requeridas. Esta sección explica el resumen de los requisitos específicos para cada tipo de CRIS, para que pueda equilibrar la seguridad, el cumplimiento y las necesidades operativas. La siguiente tabla compara el CRIS geográfico y el CRIS global, destacando sus ventajas clave y las diferencias de alto nivel en los requisitos de IAM y SCP.
Tipo de inferencia Ventaja clave Cuándo utilizar IAM SCP
Inferencia geográfica entre regiones
Regiones y modelos admitidos para perfiles de inferencia
Todas las solicitudes de inferencia y procesamiento de datos permanecen dentro de las regiones de destino especificadas para los límites geográficos. Cuando invoca un CRIS geográfico, su solicitud se origina en una región de origen y se enruta automáticamente a una de las regiones de destino definidas en ese perfil, optimizando el rendimiento.
Para clientes que tienen requisitos de residencia de datos y necesitan mantener todas las solicitudes de inferencia y procesamiento de datos dentro de límites geográficos específicos (como EE. UU., UE, AU, JP). Adecuado para organizaciones que necesitan cumplir con las regulaciones regionales de residencia de datos.
Nota importante: CRIS geográfico enruta solicitudes a través de múltiples regiones dentro de la geografía especificada. Si necesita que todo el procesamiento de inferencia permanezca en una única región específica, utilice la invocación directa del modelo en esa región.
Políticas de IAM para permisos específicos de usuarios o roles. Debe permitir el acceso para invocar los siguientes recursos: El perfil de inferencia entre regiones específico de la geografía. Estos perfiles tienen prefijos geográficos (como “nosotros”, “au”, “jp”, “eu”) El modelo básico en la región de origen El modelo básico en todas las regiones de destino en el perfil de inferencia geográfica.
Para obtener un ejemplo detallado de la política de IAM, consulte la sección Requisitos de la política de IAM para CRIS geográfico más adelante en esta publicación.
Puede utilizar SCP para controles de toda la organización, incluidas condiciones específicas de la región.
Debe actualizar el SCP de condiciones específicas de la región para permitir todas las regiones de destino enumeradas en el perfil de inferencia geográfica.
Para obtener más detalles y una política de muestra, consulte Habilitar la inferencia entre regiones de Amazon Bedrock en entornos de múltiples cuentas.
Inferencia global entre regiones
Regiones y modelos admitidos para perfiles de inferencia
– Mayor rendimiento: enrutamiento inteligente que distribuye el tráfico dinámicamente en todas las regiones comerciales compatibles de AWS en todo el mundo.
Para clientes que desean una cobertura más amplia y un mayor rendimiento a un costo menor. Adecuado para organizaciones que buscan optimizar costos y al mismo tiempo maximizar el rendimiento y la resiliencia en toda la infraestructura global de AWS.
Nota importante: CRIS global enruta solicitudes en todas las regiones comerciales compatibles de AWS en todo el mundo. Utilice esta opción únicamente si sus requisitos de cumplimiento y gobernanza de datos permiten el procesamiento de inferencias en cualquier región comercial de AWS.
Políticas de IAM para permisos específicos de usuarios o roles. Debe permitir el acceso para invocar los siguientes recursos: El perfil de inferencia global en la región de origen. Estos perfiles tienen un prefijo "global" en el ID del modelo. El modelo de base en la región de origen El modelo de base global (arn:aws:bedrock:::foundation-model/MODEL-NAME ). Para este recurso, puede utilizar la condición "aws:RequestedRegion" con el valor "unspecified" para controlar el enrutamiento dinámico.
Para obtener un ejemplo detallado de la política de IAM, consulte la sección Requisitos de la política de IAM para Global CRIS más adelante en esta publicación.
Puede utilizar SCP para controles en toda la organización. Si su organización utiliza SCP específicas de una región, asegúrese de que "aws:RequestedRegion": "unspecified" no esté incluido en la lista de regiones denegadas porque las solicitudes CRIS globales utilizan este valor de región.
Esto es necesario para permitir que Global CRIS enrute solicitudes entre regiones comerciales de AWS admitidas y funcione correctamente.
Para obtener un ejemplo detallado de política de IAM, consulte la sección Requisitos de SCP para Global CRIS más adelante en esta publicación.
Comprender los requisitos de SCP para CRIS geográfico y CRIS global
En esta sección, describimos los requisitos de SCP y describimos las principales diferencias en el comportamiento de las condiciones de SCP específicas de la región entre los perfiles CRIS geográfico y CRIS global.
Requisitos de SCP para CRIS geográfico
Muchas organizaciones implementan controles de acceso regionales a través de SCP en AWS Organizations por razones de seguridad y cumplimiento. Si su organización utiliza SCP para bloquear regiones no utilizadas, debe asegurarse de que las condiciones de SCP específicas de su región permitan el acceso a los permisos mínimos requeridos de Amazon Bedrock en todas las regiones enumeradas en el perfil geográfico CRIS para que funcione correctamente. Por ejemplo, la inferencia entre regiones geográficas antrópicas de Claude Sonnet 4.5 de EE. UU. requiere acceso a us-east-1, us-east-2 y us-west-2. Si un SCP restringe el acceso solo a us-east-1, la solicitud de inferencia entre regiones fallará. Por lo tanto, debe permitir el acceso a las tres regiones de su SCP específicamente para el acceso al perfil de inferencia entre regiones de Amazon Bedrock. Para mejorar la seguridad, considere usar la condición bedrock:InferenceProfileArn para limitar el acceso a perfiles de inferencia específicos. Consulte Habilitar la inferencia entre regiones de Amazon Bedrock en entornos de cuentas múltiples para obtener una política de ejemplo.
Requisitos de SCP para CRIS global
Puede utilizar SCP como controles para toda la organización. Si su organización utiliza SCP específicas de una región, asegúrese de que "aws:RequestedRegion": "unspecified" no esté incluido en la lista de regiones denegadas porque las solicitudes CRIS globales utilizan este valor de región. Esta condición es específica de la inferencia entre regiones de Amazon Bedrock Global y no afectará a otras llamadas a la API del servicio de AWS.
Por ejemplo, si tiene un SCP que bloquea el acceso a todas las regiones de AWS excepto a algunas regiones aprobadas, como us-east-1, us-east-2 o ap-southeast-2, según sus requisitos de cumplimiento. En este escenario, para permitir la funcionalidad de inferencia global entre regiones y al mismo tiempo mantener restricciones regionales para otros servicios, debe incluir "no especificado" en su lista de regiones permitidas específicamente para acciones de Amazon Bedrock. Para este propósito, primero excluya las llamadas a la API de Amazon Bedrock del SCP específico de la región más amplia y agregue una declaración separada para las acciones de Amazon Bedrock que amplíe la lista de regiones permitidas para incluir "no especificadas".
El siguiente ejemplo de SCP demuestra este enfoque con dos declaraciones:
La primera declaración niega todos los servicios de AWS fuera de las tres regiones aprobadas (ap-southeast-2, us-east-1, us-west-2), excepto Amazon Bedrock (especificado en la lista NotAction). Esta exclusión significa que Amazon Bedrock no está sujeto a las mismas restricciones regionales que otros servicios, lo que le permite regirse por su propia declaración de política específica.
La segunda declaración se ocupa específicamente de Amazon Bedrock, lo que le permite operar en las tres regiones aprobadas más "no especificadas" para la funcionalidad CRIS global.
Debe actualizar la lista de regiones permitidas para que coincida con las regiones aprobadas de su organización y eliminar los comentarios en línea (//) antes de usar esta política.
Requisitos de política de IAM para la inferencia geográfica y global entre regiones
En esta sección, describimos los requisitos de la política de IAM para la inferencia entre regiones tanto geográfica como global.
Requisitos de la política IAM para CRIS geográfico
Para permitir que un usuario o rol de IAM invoque un perfil de inferencia entre regiones geográficas, puede utilizar la siguiente política de ejemplo. Esta política de muestra otorga los permisos necesarios para utilizar el modelo básico (FM) de Claude Sonnet 4.5 con un perfil de inferencia geográfica entre regiones para EE. UU., donde la región de origen es EE. UU. Este (Norte de Virginia) – us-east-1 y las regiones de destino en el perfil son EE. UU. Este (Norte de Virginia) – us-east-1, EE. UU. Este (Ohio) –
us-east-2 y EE. UU. Oeste (Oregón) – us-west-2. Para ver la lista completa de todos los perfiles de inferencia entre regiones disponibles, modelos admitidos, regiones de origen y regiones de destino, consulte Regiones y modelos admitidos para perfiles de inferencia en la Guía del usuario de Amazon Bedrock.
La primera declaración otorga acceso a la API Bedrock:InvokeModel a la inferencia entre regiones geográficas para solicitudes que se originan en la región solicitante (us-east-1). La segunda declaración otorga acceso a la API Bedrock:InvokeModel al FM tanto en la región solicitante como en todas las regiones de destino enumeradas en el perfil de inferencia (us-east-1, us-east-2 y us-west-2).
Debe reemplazar el marcador de posición con su ID de cuenta de AWS real. Confirme que los códigos de región (us-east-1, us-east-2, us-west-2), los identificadores de modelo (anthropic.claude-sonnet-4-5-20250929-v1:0) y los nombres de recursos de Amazon (ARN) del perfil de inferencia coincidan con sus requisitos de implementación específicos y los modelos disponibles en sus regiones de destino.
Requisitos de la política IAM para Global CRIS
Tanto las políticas geográficas como las globales de CRIS IAM requieren acceso al perfil de inferencia y a los modelos básicos en la región de origen. Sin embargo, para CRIS global, se utiliza "aws:RequestedRegion": "unspecified" en la condición para el acceso al modelo básico de la región de destino, mientras que CRIS geográfico requiere enumerar explícitamente todas las regiones de destino enumeradas en el perfil de inferencia geográfica entre regiones.
Para permitir que un usuario o rol de IAM invoque un perfil de inferencia global entre regiones, puede utilizar la siguiente política de ejemplo. Esta política de muestra otorga los permisos necesarios para utilizar Claude Sonnet 4.5 FM con un perfil de inferencia global entre regiones, donde la región de origen es us-east-1.
En esta política, la primera declaración otorga permiso para invocar el recurso de perfil de inferencia global entre regiones en la región de origen us-east-1. Este perfil utiliza el prefijo global para indicar enrutamiento entre regiones. La segunda declaración permite invocar el modelo de base global en la región us-east-1, pero solo cuando la llamada se realiza a través del perfil de inferencia global especificado. La tercera declaración permite invocar el modelo de base global en cualquier región comercial de AWS compatible utilizando el patrón de ARN sin una región específica "arn:aws:bedrock:::foundation-model/anthropic.claude-sonnet-4-5-20250929-v1:0". Para restringir el acceso a la inferencia global entre regiones, puede usar la condición "aws:RequestedRegion": "unspecified", que admite el enrutamiento dinámico de regiones en solicitudes de inferencia globales entre regiones. Además, para confirmar que el permiso se aplica solo a un perfil de inferencia global entre regiones específico, puede usar la condición base:InferenceProfileArn con el valor de ARN del perfil de inferencia global entre regiones. Para obtener una explicación más detallada de la política de IAM, consulte Desbloquear la escalabilidad de inferencia global de IA utilizando la nueva inferencia global entre regiones en Amazon Bedrock con Claude Sonnet 4.5 de Anthropic.
Debe reemplazarlo con su ID de cuenta de AWS real. Confirme que el identificador del modelo (anthropic.claude-sonnet-4-5-20250929-v1:0) y el ARN del perfil de inferencia coincidan con sus requisitos específicos y los modelos disponibles para la inferencia global entre regiones.
Deshabilitar la inferencia entre regiones
Las organizaciones con requisitos de cumplimiento o residencia de datos deben evaluar si la inferencia global entre regiones o la inferencia geográfica entre regiones se ajusta a su marco de cumplimiento porque las solicitudes se pueden procesar en otras regiones de AWS admitidas fuera de su región operativa principal. Para las organizaciones que necesitan deshabilitar la inferencia geográfica o global entre regiones, pueden elegir entre los siguientes enfoques.
Restringir la inferencia geográfica entre regiones
Implemente un SCP de denegación para restringir el acceso a todos los usuarios y roles de IAM dentro de las cuentas de AWS en una organización de AWS que se dirija a perfiles de inferencia geográficos entre regiones específicos. Este método proporciona control en toda la organización y bloquea perfiles de inferencia geográfica entre regiones específicos en todas las cuentas de la unidad organizativa, incluso si más adelante se agregan políticas de permiso de IAM individuales.
El siguiente SCP de ejemplo niega explícitamente todas las invocaciones de perfiles de inferencia de Amazon Bedrock que utilizan perfiles geográficos fuera de EE. UU. La política utiliza la condición Null establecida en "falso" para garantizar que solo se aplique cuando se utiliza un perfil de inferencia, y la condición ArnNotLike en la base: InferenceProfileArnkey bloquea todos los perfiles entre regiones, excepto aquellos con el prefijo de EE. UU. (us.*). Ambas condiciones deben ser verdaderas para que se aplique la denegación, lo que significa que la política solo bloquea las solicitudes que utilizan un perfil de inferencia Y ese perfil no es un perfil geográfico de EE. UU.
Para restringir la inferencia geográfica entre regiones para usuarios o roles de IAM específicos, evite asignar políticas de IAM con permisos de inferencia geográfica entre regiones a usuarios o roles de IAM específicos.
Deshabilitar la inferencia global entre regiones
Implemente un SCP de denegación para restringir el acceso a todos los usuarios y roles de IAM dentro de las cuentas de AWS en una organización de AWS dirigida a perfiles de inferencia globales entre regiones. Este método proporciona control en toda la organización y bloquea la funcionalidad de inferencia global entre regiones en todas las cuentas de la unidad organizativa, incluso si más adelante se agregan políticas de permiso de IAM individuales. El siguiente SCP de ejemplo niega explícitamente la inferencia global entre regiones con "aws:RequestedRegion": "unspecified" y la condición "ArnLike" apunta a perfiles de inferencia con el prefijo global en el ARN.
Para restringir la inferencia global entre regiones para usuarios o roles de IAM específicos, evite asignar políticas de IAM con permisos de inferencia global entre regiones a usuarios o roles de IAM específicos.
Auditoría y seguimiento
Todas las llamadas entre regiones se registran en la región de origen. Las entradas de AWS CloudTrail incluyen un campo EventData adicional para el seguimiento. El siguiente es un ejemplo de registro de CloudTrail para la API InvokeModel utilizando una inferencia global entre regiones, donde la región solicitante es ap-southeast-2 y la región de inferencia es ap-southeast-4.
Implementación avanzada con AWS Control Tower
Si utiliza AWS Control Tower, debe actualizar su SCP para controlar la inferencia entre regiones en su organización.
Importante: Se desaconseja enfáticamente editar manualmente los SCP administrados por AWS Control Tower porque puede causar "desviación". En su lugar, debe utilizar los mecanismos proporcionados por AWS Control Tower para gestionar estas excepciones.
Habilitar o deshabilitar la inferencia geográfica entre regiones
Para habilitar o deshabilitar la inferencia geográfica entre regiones, consulte Habilitar la inferencia entre regiones de Amazon Bedrock en entornos de múltiples cuentas.
Cómo deshabilitar la inferencia global entre regiones
Para deshabilitar el servicio de inferencia global entre regiones a nivel de organización, debe modificar los SCP que AWS Control Tower crea automáticamente. Utilice Personalizaciones para AWS Control Tower (CfCT) para denegar acciones de Amazon Bedrock a regiones con nombres no especificados, como se muestra en el siguiente ejemplo.
Cómo habilitar la inferencia global entre regiones
Para habilitar la inferencia global entre regiones mediante AWS Control Tower, debe modificar los SCP que AWS Control Tower crea automáticamente. Utilice CfCT para esta modificación porque AWS Control Tower no admite inherentemente la habilitación de la región denominada "no especificada".
El siguiente es un ejemplo de un SCP que se modificó para agregar "sin especificar" para permitir la inferencia global entre regiones:
Habilitación de regiones de AWS
Amazon Bedrock utiliza perfiles de inferencia para enrutar solicitudes de invocación de modelos en todas las regiones enumeradas en el perfil, ya sea que esas regiones estén habilitadas de forma predeterminada o requieran una suscripción manual en su cuenta de AWS. No es necesario que se registre manualmente en Regions. Este enfoque reduce la complejidad operativa al eliminar la necesidad de habilitar múltiples regiones individualmente y administrar controles de seguridad separados para cada una. Por ejemplo, si utiliza una inferencia entre regiones específica de la geografía para el perfil de Australia con Claude Sonnet 4.5 de la región de origen Sídney, sus solicitudes se enrutarán tanto a Sídney como a Melbourne. De manera similar, con la inferencia global entre regiones, las solicitudes se pueden enrutar a cualquier región comercial de AWS admitida, incluidas aquellas que no están habilitadas en las regiones comerciales de AWS en su cuenta de AWS.
Hay dos tipos de regiones comerciales de AWS. Hay regiones que están habilitadas de forma predeterminada para las cuentas de AWS (como Virginia del Norte, Irlanda y Sídney) y hay regiones que requieren la suscripción manual antes de su uso (como Melbourne, Emiratos Árabes Unidos y Hyderabad). Estas regiones habilitadas manualmente son más nuevas y se introdujeron después del 20 de marzo de 2019. Para obtener más detalles, consulte Regiones de AWS.
Conclusión
La inferencia entre regiones de Amazon Bedrock ofrece potentes capacidades para crear aplicaciones de IA generativa escalables y resilientes. Al comprender las interacciones fundamentales entre la inferencia entre regiones y los controles de seguridad y al implementar excepciones condicionales precisas utilizando herramientas como políticas de IAM y SCP, puede desbloquear esta función de forma segura mientras mantiene su postura de seguridad. Al seguir las estrategias y las mejores prácticas descritas en esta publicación de blog, sus equipos pueden innovar con inferencia entre regiones mientras su postura de gobernanza y cumplimiento se mantiene sólida.
Recursos adicionales
Para obtener más información, consulte la documentación oficial:
Sobre los autores
Zohreh Norouzi es arquitecto de soluciones de seguridad en Amazon Web Services. Ayuda a los clientes a tomar buenas decisiones de seguridad y acelerar su viaje a la nube de AWS. Ha participado activamente en iniciativas de seguridad de IA generativa en APJ, utilizando su experiencia para ayudar a los clientes a crear soluciones seguras de IA generativa a escala.
Satveer Khurpa es arquitecto senior de soluciones especializado en WW, Amazon Bedrock en Amazon Web Services. En este puesto, utiliza su experiencia en arquitecturas basadas en la nube para desarrollar soluciones innovadoras de IA generativa para clientes de diversas industrias. El profundo conocimiento de Satveer de las tecnologías de IA generativa le permite diseñar aplicaciones escalables, seguras y responsables que abren nuevas oportunidades de negocio e impulsan valor tangible.
Melanie Li, PhD, es arquitecta sénior de soluciones especializada en IA generativa en AWS con sede en Sydney, Australia, donde se centra en trabajar con los clientes para crear soluciones utilizando herramientas de IA/ML de última generación. Ha participado activamente en múltiples iniciativas de IA generativa en APJ, aprovechando el poder de los LLM. Antes de unirse a AWS, el Dr. Li ocupó puestos de ciencia de datos en las industrias financiera y minorista.
Saurabh Trikande es gerente senior de productos de Amazon Bedrock y Amazon SageMaker Inference. Le apasiona trabajar con clientes y socios, motivado por el objetivo de democratizar la IA. Se centra en los desafíos principales relacionados con la implementación de aplicaciones complejas de IA, la inferencia con modelos multiinquilino, la optimización de costos y hacer más accesible la implementación de modelos generativos de IA. En su tiempo libre, Saurabh disfruta hacer senderismo, aprender sobre tecnologías innovadoras, seguir TechCrunch y pasar tiempo con su familia.
Jan Catarata es un ingeniero de software que trabaja en Amazon Bedrock, donde se enfoca en diseñar sistemas distribuidos robustos. Cuando no está creando soluciones de IA escalables, puedes encontrarlo elaborando estrategias para su próximo movimiento con amigos y familiares en la noche de juegos.
Harlan Verthein es un ingeniero de software que trabaja en Amazon Bedrock, donde se enfoca en mejorar la disponibilidad y el rendimiento para los clientes a través de inferencia entre regiones. Fuera del trabajo, le encanta probar comida nueva, jugar fútbol y ver deportes electrónicos profesionales.