¡Kia ora!
Los clientes de Nueva Zelanda han estado solicitando acceso a modelos básicos (FM) en Amazon Bedrock desde su región local de AWS.
Hoy, nos complace anunciar que Amazon Bedrock ya está disponible en la región de Asia Pacífico (Nueva Zelanda) (ap-sureste-6). Los clientes de Nueva Zelanda ahora pueden acceder a los modelos Anthropic Claude (Claude Opus 4.5, Opus 4.6, Sonnet 4.5, Sonnet 4.6 y Haiku 4.5) y Amazon (Nova 2 Lite) directamente en la región de Auckland con inferencia entre regiones.
En esta publicación, exploramos cómo funciona la inferencia entre regiones desde la región de Nueva Zelanda, los modelos disponibles a través del enrutamiento geográfico y global, y cómo comenzar con su primera llamada API. Cubrimos tres áreas clave:
Cómo Amazon Bedrock en ap-southeast-6 utiliza la inferencia entre regiones para brindarle acceso a FM, con la configuración de enrutamiento geográfico ANZ en Auckland, Sydney y Melbourne, modelos compatibles, permisos de IAM y cómo realizar su primera llamada de inferencia desde la región de Auckland Administración de cuotas, consideraciones de seguridad y elección entre inferencia entre regiones geográfica y global para sus cargas de trabajo
Comprender la inferencia entre regiones
La inferencia entre regiones es una capacidad de Amazon Bedrock que distribuye el procesamiento de inferencia entre varias regiones de AWS para ayudarle a lograr un mayor rendimiento a escala.
Cuando invoca un perfil de inferencia entre regiones, Amazon Bedrock enruta su solicitud desde la región de origen (donde inicia la llamada API) a una región de destino (donde se produce el procesamiento de inferencia). Todos los datos transmitidos durante las operaciones entre regiones permanecen en la red de AWS y no atraviesan la Internet pública, y los datos se cifran en tránsito entre regiones de AWS. Todas las solicitudes de inferencia entre regiones se registran en AWS CloudTrail en su región de origen. Si configura el registro de invocación de modelo, los registros se publican en Amazon CloudWatch Logs o Amazon Simple Storage Service (Amazon S3) en la misma región.
Amazon Bedrock proporciona dos tipos de perfiles de inferencia entre regiones:
Inferencia geográfica entre regiones: enruta las solicitudes dentro de un límite geográfico específico. Por ejemplo, con el perfil AU y Auckland como región de origen, solicita la ruta a Auckland, Sydney y Melbourne. Diseñado para organizaciones con requisitos de residencia de datos que necesitan procesamiento de inferencia para permanecer dentro de Australia y Nueva Zelanda. Inferencia global entre regiones: enruta las solicitudes a regiones comerciales de AWS admitidas en todo el mundo, proporcionando el mayor rendimiento disponible. Diseñado para organizaciones sin requisitos estrictos de residencia de datos.
Novedades: Nueva Zelanda como región fuente para inferencias entre regiones
Con este lanzamiento, Auckland (ap-sureste-6) se convierte en una nueva región fuente para la inferencia entre regiones geográfica y global de la UA sobre Amazon Bedrock. Esto significa que ahora puede realizar llamadas a la API de Amazon Bedrock desde la región de Nueva Zelanda y la inferencia entre regiones enruta sus solicitudes a las regiones de destino donde los FM procesan la inferencia.
Configuración de inferencia geográfica entre regiones de la UA
El perfil interregional de la UA ahora abarca tres regiones en Australia y Nueva Zelanda. La siguiente tabla detalla el enrutamiento de las regiones de origen y destino.
Región de origen Regiones de destino Descripción Auckland (ap-southeast-6) ap-southeast-6, ap-southeast-2, ap-southeast-4 Nuevo: las solicitudes de Auckland se pueden enrutar a Sydney, Melbourne o Auckland Sydney (ap-southeast-2) ap-southeast-2, ap-southeast-4 Las solicitudes de Sydney se pueden enrutar a Sydney o Melbourne Melbourne (ap-southeast-4) ap-southeast-2, ap-southeast-4 Las solicitudes desde Melbourne se pueden enviar a Sydney o Melbourne
Hay dos detalles importantes a tener en cuenta:
Los perfiles de inferencia entre regiones de la UA para Sydney y Melbourne continúan enrutando entre Sydney y Melbourne únicamente. La incorporación de Auckland no cambia las regiones de destino para las configuraciones de regiones de origen australianas existentes. Las solicitudes que se originan en Auckland pueden atenderse localmente o enrutarse a cualquiera de las regiones australianas, lo que proporciona tres regiones de destino para la distribución de capacidad.
Inferencia global entre regiones desde Nueva Zelanda
Para las organizaciones sin requisitos estrictos de residencia de datos, la inferencia global entre regiones desde la región de Auckland proporciona acceso a la capacidad de inferencia en todas las regiones comerciales de AWS admitidas en todo el mundo. La inferencia global entre regiones ofrece dos ventajas clave:
Mayor rendimiento: el enrutamiento inteligente distribuye el tráfico dinámicamente entre todas las regiones comerciales admitidas, lo que reduce la probabilidad de que se produzcan limitaciones durante los picos de tráfico. Resiliencia incorporada: las solicitudes se enrutan automáticamente a las regiones con capacidad disponible, lo que ayuda a que sus aplicaciones mantengan la continuidad operativa a medida que cambian los patrones de demanda.
Empezando
Modelos compatibles e ID de perfil de inferencia
La inferencia entre regiones de la región de Nueva Zelanda admite modelos básicos de múltiples proveedores en perfiles de inferencia entre regiones tanto geográficos como globales de la UA. La siguiente tabla muestra ejemplos de los últimos modelos disponibles en el lanzamiento.
Tipo de inferencia entre regiones Modelos de ejemplo AU Inferencia geográfica entre regiones Antrópico Claude Opus 4.6, Claude Sonnet 4.6, Claude Sonnet 4.5, Claude Haiku 4.5 Inferencia global entre regiones Antrópico Claude Opus 4.6, Claude Sonnet 4.6, Claude Opus 4.5, Claude Sonnet 4.5, Claude Haiku 4.5
La inferencia geográfica entre regiones de la UA actualmente admite modelos de Claude antrópico, manteniendo el procesamiento de inferencia dentro de la geografía de la ANZ. La inferencia global entre regiones brinda acceso a un conjunto más amplio de modelos básicos de múltiples proveedores. Para utilizar un perfil de inferencia entre regiones, reemplace el ID del modelo fundamental con el prefijo geográfico (au.) o global (global.); por ejemplo, anthropic.claude-sonnet-4-6 se convierte en au.anthropic.claude-sonnet-4-6 o global.anthropic.claude-sonnet-4-6.
Para obtener la lista completa y actualizada de modelos admitidos e ID de perfiles de inferencia, consulte Regiones y modelos admitidos para perfiles de inferencia.
Los perfiles de inferencia entre regiones funcionan con las API InvokeModel, InvokeModelWithResponseStream, Converse y ConverseStream. La API de Converse proporciona un formato de solicitud y respuesta coherente en diferentes modelos básicos, lo que facilita el cambio entre modelos sin tener que volver a escribir el código de integración.
Configurar permisos de IAM
Para invocar modelos básicos a través de la inferencia geográfica entre regiones de la UA desde la región de Auckland, su política de AWS Identity and Access Management (IAM) necesita dos declaraciones:
Otorgar acceso al perfil de inferencia en la región de origen Otorgar acceso al modelo básico en todas las regiones de destino enumeradas en el perfil de inferencia entre regiones de AU.
El siguiente ejemplo de política de IAM otorga acceso para invocar Anthropic Claude Sonnet 4.6 a través de la inferencia geográfica entre regiones de la UA desde Auckland. Reemplace con su ID de cuenta de AWS.
La primera declaración permite invocar el perfil de inferencia de la UA de la región fuente de Auckland. La segunda declaración permite invocar el FM en las tres regiones de destino, pero solo cuando la solicitud se enruta a través del perfil de inferencia de AU. Esto sigue el principio de privilegio mínimo al evitar la invocación directa del modelo en esas regiones.
El mismo patrón de dos declaraciones se aplica a cualquier modelo en el perfil de inferencia entre regiones de AU: reemplace el ID del modelo en los ARN del recurso. Para obtener políticas de IAM de inferencia global entre regiones, configuraciones de políticas de control de servicios (SCP) y patrones de seguridad avanzados, consulte Protección de la inferencia entre regiones de Amazon Bedrock: geográfica y global.
Consideraciones de seguridad y cumplimiento
La inferencia entre regiones está diseñada teniendo en cuenta la seguridad. Todas las solicitudes viajan exclusivamente a través de la red global de AWS con cifrado de extremo a extremo y sus datos en reposo permanecen en la región de origen.
Para las organizaciones que utilizan SCP para restringir el acceso a regiones de AWS específicas, tengan en cuenta lo siguiente cuando llamen desde la región de origen de Auckland (ap-southeast-6):
La inferencia geográfica entre regiones de la UA requiere permitir ap-southeast-2, ap-southeast-4 y ap-southeast-6 para las acciones de Amazon Bedrock en sus SCP, porque el perfil de la AU de Auckland se dirige a las tres regiones ANZ. La inferencia global entre regiones requiere además permitir no especificado como valor de región para las acciones de Amazon Bedrock, porque las regiones de destino se determinan dinámicamente.
El siguiente ejemplo de SCP restringe los servicios a la región de Auckland, con excepciones para Amazon Bedrock y servicios globales como IAM. Limita Amazon Bedrock a las tres regiones de ANZ y requiere que el acceso a Amazon Bedrock en Sydney y Melbourne pase por perfiles de inferencia entre regiones en lugar de una invocación directa del modelo:
En la política anterior:
La primera declaración restringe todos los servicios a la región de Auckland, excepto Amazon Bedrock y servicios globales como IAM, AWS Organizations y AWS Support que operan independientemente de las restricciones de la región. La segunda declaración restringe Amazon Bedrock a las tres regiones ANZ, lo cual es necesario para que la inferencia entre regiones de la UA pueda enrutar solicitudes desde Auckland a Sydney y Melbourne. La tercera declaración utiliza la condición Null en bedrock:InferenceProfileArn para denegar cualquier solicitud de Amazon Bedrock en Sydney o Melbourne que no se enrute a través de un perfil de inferencia entre regiones. Esto evita la invocación directa del modelo en las regiones de destino y al mismo tiempo permite que la inferencia entre regiones funcione normalmente.
Para obtener ejemplos detallados de configuración de SCP, políticas de IAM de inferencia global entre regiones, deshabilitar tipos de inferencia entre regiones específicos y orientación de integración de AWS Control Tower, consulte Protección de la inferencia entre regiones de Amazon Bedrock: geográfica y global.
Auditoría y seguimiento
AWS CloudTrail registra todas las llamadas de inferencia entre regiones en la región de origen. El campo adicionalEventData.inferenceRegion registra dónde se procesó cada solicitud, para que pueda auditar exactamente dónde ocurrió la inferencia:
Para el monitoreo operativo en tiempo real, Amazon CloudWatch proporciona métricas para solicitudes de inferencia entre regiones en su región de origen. Las métricas clave incluyen:
InvocationCount: número total de solicitudes de inferencia InvocationLatency: tiempo de respuesta de extremo a extremo, incluido el enrutamiento entre regiones InvocationClientErrors: solicitudes fallidas, incluida la limitación (los picos indican que se está acercando a los límites de cuota) InputTokenCount y OutputTokenCount: consumo de tokens para el seguimiento de cuota
Gestión de cuotas
Las cuotas de servicio de Amazon Bedrock se administran a nivel de región de origen. Los aumentos de cuota solicitados a la región de Auckland (ap-sureste-6) se aplican únicamente a las solicitudes que se originan en Auckland.
Las cuotas se miden en dos dimensiones:
Tokens por minuto (TPM): la cantidad máxima de tokens (entrada + salida) procesadas por minuto Solicitudes por minuto (RPM): la cantidad máxima de solicitudes de inferencia por minuto
Al calcular su cuota requerida, tenga en cuenta la tasa de consumo de tokens. Para Anthropic Claude Opus 4.6, Sonnet 4.6 y Sonnet 4.5, los tokens de salida consumen cinco veces más cuota que los tokens de entrada (tasa de combustión de 5:1). Para los modelos Claude Haiku 4.5 y Amazon Nova, la tasa de combustión es 1:1.
Fórmula de consumo de cuota:
Consumo de cuota = Tokens de entrada + Tokens de escritura de caché + (Tokens de salida x Tasa de burndown)
Para solicitar aumentos de cuota, navegue hasta la consola AWS Service Quotas en su región de origen, seleccione Amazon Bedrock y busque la cuota de inferencia entre regiones relevante para su modelo.
Conclusión
En esta publicación, presentamos el soporte de inferencia entre regiones de la región de Nueva Zelanda en Amazon Bedrock. Los clientes de Nueva Zelanda ahora pueden realizar llamadas API desde Auckland y acceder a modelos básicos a través de perfiles de inferencia geográficos y globales entre regiones. Conclusiones clave:
Auckland es ahora una región de origen para la inferencia entre regiones: los clientes de Nueva Zelanda pueden realizar llamadas a la API de Amazon Bedrock desde su región local, y los registros y configuraciones permanecen en Auckland. La inferencia geográfica entre regiones de la UA mantiene los datos dentro de ANZ: solicitudes de inferencia desde la ruta de Auckland a tres destinos (Auckland, Sydney y Melbourne), lo que proporciona modelos antrópicos de Claude dentro de los límites geográficos de ANZ. La inferencia global entre regiones amplía el acceso al modelo, proporcionando el mayor rendimiento disponible al enrutar solicitudes a regiones comerciales de AWS admitidas en todo el mundo. La ruta australiana existente no ha cambiado: las regiones de origen de Sydney y Melbourne continúan realizando rutas entre sí únicamente.
Puede comenzar con la inferencia entre regiones desde la región de Nueva Zelanda con los siguientes pasos:
Inicie sesión en la consola de Amazon Bedrock en la región de Auckland (ap-sureste-6). Configure los permisos de IAM y SCP utilizando el ejemplo de política de esta publicación. Realice su primera llamada API utilizando au. ID del perfil de inferencia. Solicite aumentos de cuota a través de la consola de Cuotas de servicio según su carga de trabajo esperada.
Para obtener más información, consulte:
Sobre los autores
Melanie Li
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
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.
James Zheng
James Zheng es gerente de desarrollo de software en Amazon Web Services.
William Yap
William Yap es director principal de productos de Amazon Bedrock.
julia bodia
Julia Bodia es directora principal de productos de Amazon Bedrock.