Amazon Bedrock llega a Nueva Zelanda: cómo usar inferencia cross-Region para IA generativa

Introducción

Kia ora! Amazon Web Services anunció la disponibilidad de Amazon Bedrock en la región Asia Pacific (Nueva Zelanda) —ap-southeast-6—, lo que permite a clientes en Nueva Zelanda invocar modelos fundacionales (FMs) desde su región local usando inferencia cross‑Region. Este cambio facilita acceso a modelos de Anthropic y Amazon en Auckland, con opciones para mantener el procesamiento dentro de Australia y Nueva Zelanda o distribuirlo globalmente para mayor capacidad.

En este artículo describimos cómo funciona la inferencia cross‑Region en Bedrock, las rutas geográficas disponibles desde Auckland, los modelos soportados en el lanzamiento, consideraciones de seguridad y cumplimiento, y recomendaciones prácticas para equipos en Latinoamérica que estén evaluando arquitecturas multi‑región o requisitos de residencia de datos.

Qué es la inferencia cross‑Region en Amazon Bedrock

La inferencia cross‑Region es una capacidad de Amazon Bedrock que distribuye la ejecución de inferencia entre varias regiones de AWS para ofrecer mayor rendimiento y resiliencia. Cuando invocan un perfil de inferencia cross‑Region, Bedrock enruta la solicitud desde la región de origen (donde se hace la llamada API) a una región destino donde se realiza el procesamiento del modelo.

Aspectos clave:

• Todo el tráfico entre regiones viaja por la red interna de AWS y no por internet pública; además, los datos se cifran en tránsito entre regiones.
• Las solicitudes de cross‑Region se registran en AWS CloudTrail en la región de origen. Si activan el registro de invocación de modelos, esos logs se publican en CloudWatch Logs o en Amazon S3 en la misma región.
• Bedrock ofrece dos perfiles de inferencia: geográfico (limitado a una región administrativa) y global (distribuye tráfico entre todas las regiones comerciales soportadas).

Nueva Zelanda como región de origen: qué cambia

Con este lanzamiento, Auckland (ap-southeast-6) se convierte en región de origen para los perfiles AU (geográfico) y global. Es decir, pueden hacer llamadas a la API de Bedrock desde la región de Nueva Zelanda y Bedrock enruta esas solicitudes a regiones destino según el perfil elegido.

Para organizaciones que requieren residencia de datos en la zona ANZ (Australia y Nueva Zelanda), el perfil geográfico AU mantiene el procesamiento de inferencia dentro de ese límite. Para quienes buscan la máxima capacidad y resiliencia, el perfil global permite distribuir la carga entre regiones comerciales soportadas a nivel mundial.

Configuración AU: rutas entre Auckland, Sídney y Melbourne

El perfil geográfico AU ahora abarca tres regiones en ANZ. Las rutas relevantes al momento del lanzamiento son:

• Desde Auckland (ap-southeast-6): las solicitudes pueden procesarse en ap-southeast-6 (Auckland), ap-southeast-2 (Sídney) o ap-southeast-4 (Melbourne).
• Desde Sídney (ap-southeast-2): las solicitudes quedan entre ap-southeast-2 y ap-southeast-4 (Sídney o Melbourne).
• Desde Melbourne (ap-southeast-4): las solicitudes quedan entre ap-southeast-2 y ap-southeast-4 (Sídney o Melbourne).

Nota importante: la incorporación de Auckland como origen no altera la configuración existente entre Sídney y Melbourne; simplemente agrega a Auckland como punto adicional de origen y destino dentro del perfil AU. Para orígenes en Auckland, Bedrock puede servir la inferencia localmente o enrutarla a cualquiera de las dos regiones australianas para balanceo de capacidad.

Modelos compatibles y perfiles de inferencia

En el lanzamiento, desde la región de Nueva Zelanda se puede acceder a modelos de Anthropic y Amazon mediante profiles geográficos y globales. Ejemplos incluidos en el anuncio:

• Modelos Anthropic: Claude Opus 4.6, Claude Opus 4.5, Claude Sonnet 4.6, Sonnet 4.5 y Haiku 4.5.
• Modelos Amazon: Nova 2 Lite (mencionado como accesible en Auckland con cross‑Region).

El perfil AU (geográfico) soporta los modelos de Anthropic manteniendo el procesamiento dentro de ANZ. El perfil global ofrece acceso a un conjunto más amplio de modelos desde múltiples proveedores.

Para invocar un modelo con un perfil de inferencia, deben anteponer el prefijo geográfico o global al identificador del modelo. Por ejemplo:

• anthropic.claude-sonnet-4-6 → au.anthropic.claude-sonnet-4-6
• antroplic.claude-sonnet-4-6 → global.anthropic.claude-sonnet-4-6

(Ver la documentación oficial de AWS para la lista completa y actualizada de IDs de modelos y perfiles.)

Seguridad, cumplimiento y registro

Al planear despliegues que usen inferencia cross‑Region consideren lo siguiente:

• Tráfico interno y cifrado: las solicitudes entre regiones permanecen en la red de AWS y se cifran en tránsito, lo que reduce riesgos asociados a enviar datos por internet pública.
• Auditoría y registros: todas las solicitudes cross‑Region se registran en CloudTrail en la región de origen. Si activan el registro de invocación, esos eventos se almacenan en CloudWatch Logs o S3 en la misma región, lo cual es útil para cumplimiento y auditoría.
• Residencia de datos: si su organización tiene requisitos legales o internos sobre dónde deben procesarse datos, utilicen el perfil geográfico AU para garantizar que la inferencia permanezca dentro de Australia y Nueva Zelanda.
• Permisos IAM: aseguren que las políticas de IAM permitan invocar modelos en Bedrock y acceder a los recursos de registro que vayan a usar (CloudWatch, S3, CloudTrail). Revisen las guías de AWS para configurar permisos mínimos necesarios.

Consideraciones operativas y para equipos en Latinoamérica

Aunque la noticia es específica para Nueva Zelanda, hay lecciones útiles para organizaciones en Latinoamérica:

• Arquitectura multi‑región: si su operación requiere baja latencia local, consideren desplegar servicios en regiones cercanas o usar perfiles geográficos que respeten límites administrativos de datos.
• Escalabilidad: el perfil global ayuda a manejar picos de tráfico al distribuir solicitudes entre regiones con capacidad disponible, lo cual es relevante para aplicaciones que requieren alta concurrencia (chatbots, análisis en tiempo real, etc.).
• Evaluación de proveedor y modelo: revisar qué modelos están disponibles en cada perfil es clave antes de diseñar la solución; algunos modelos pueden estar disponibles solo vía perfil global.

Cómo empezar desde Auckland (y qué revisar primero)

1. Revisen en la consola de AWS o en la documentación la lista actualizada de modelos y los IDs de inferencia con los prefijos au. o global.
2. Configuren permisos IAM mínimos para invocar modelos de Bedrock y para escribir registros en CloudWatch o S3 según su estrategia de auditoría.
3. Decidan el perfil de inferencia según requisitos de residencia y rendimiento: AU para mantener procesamiento en ANZ; global para máxima capacidad.
4. Prueben llamadas de inferencia con cargas de prueba observando latencia, throughput y logs en CloudTrail/CloudWatch para ajustar quotas y límites.

Amazon Bedrock soporta llamadas de invocación de modelo (por ejemplo, InvokeModel) usando estos perfiles; consulten la documentación de API para ejemplos y parámetros.

Conclusión

La disponibilidad de Amazon Bedrock en la región de Auckland abre posibilidades para que organizaciones en Nueva Zelanda (y por extensión, para quienes trabajan con socios en ANZ) ejecuten inferencia de modelos fundacionales desde una región local, con opciones para mantener el procesamiento dentro de la geografía o distribuirlo globalmente para mayor capacidad. Para equipos en Latinoamérica que diseñan soluciones distribuidas o multirregionales, este lanzamiento es un recordatorio de la importancia de evaluar perfiles de inferencia, requisitos de residencia de datos y capacidades de registro y seguridad antes de producción.

Para detalles técnicos y la lista completa de modelos compatibles, consulten la documentación oficial de Amazon Bedrock y las páginas de soporte de modelos y regiones.