El anuncio pasó casi desapercibido en la prensa general, pero para cualquier arquitecto de soluciones en Centroamérica debería cambiar la conversación sobre dónde vive la infraestructura: AWS Transform for Migrations —la herramienta asistida de AWS para migraciones— ahora soporta todas sus regiones comerciales como destino, incluyendo México (Central), en Querétaro, con código mx-central-1. Antes de este cambio, mover cargas hacia la región mexicana era técnicamente posible, pero no estaba formalmente soportado como flujo de destino dentro de las herramientas nativas de migración de AWS. Este artículo cubre qué cambió en la práctica y qué preguntas de arquitectura hay que responder antes de mover una carga hacia mx-central-1.
Lo esencial
- AWS Transform for Migrations agregó soporte para todas sus regiones comerciales como destino en junio de 2026 — México (Querétaro) incluida.
- La región mx-central-1 opera desde enero de 2025 con tres zonas de disponibilidad, pero el soporte de tooling de migración es reciente.
- La decisión de migrar no es solo de latencia — residencia de datos, marco regulatorio y paridad de servicios pesan igual o más.
Qué cambió técnicamente (y qué no)
AWS Transform es la herramienta de AWS para modernizar y migrar aplicaciones asistida por IA — analiza código, dependencias y arquitectura, y genera un plan de migración ejecutable. Hasta la actualización de junio de 2026, la lista de regiones destino disponibles en el flujo de migración no incluía todas las regiones comerciales de AWS. La actualización agregó 15 regiones nuevas como destino válido, entre ellas México (Querétaro), además de Asia Pacífico (Bangkok, Hong Kong, Hyderabad, Yakarta, Kuala Lumpur), Europa (Milán, España, Zúrich) y otras.
Lo que no cambió: la región mx-central-1 en sí misma ya llevaba operando año y medio, con tres zonas de disponibilidad, procesadores Graviton, Trainium e Inferentia, y conectividad directa vía AWS Direct Connect en Querétaro. Lo que cambió es que ahora se puede planificar y ejecutar la migración usando el mismo flujo asistido que ya se usa para otras regiones — sin tener que construir el runbook de migración a mano. <div class=”pull-quote”> <p>La pregunta ya no es si podés migrar a México — es si tu arquitectura actual te lo permite sin reescribir media infraestructura.</p> </div>
Las tres preguntas de arquitectura antes de migrar a Querétaro
Residencia de datos y marco regulatorio. mx-central-1 almacena y procesa datos bajo jurisdicción mexicana, sujeta a la LFPDPPP. Para una empresa panameña o centroamericana, esto no resuelve automáticamente el cumplimiento con la Ley 81 de Panamá u otros marcos locales — sigue siendo responsabilidad del arquitecto mapear qué datos pueden vivir fuera del país de origen y bajo qué acuerdo de transferencia. El soporte de AWS Transform acelera la ejecución técnica de la migración; no sustituye el análisis legal previo.
Latencia real, no la de marketing. AWS documenta “latencia optimizada” para tráfico dentro de México, pero no publica cifras específicas de latencia desde Centroamérica. La única forma confiable de saber si mx-central-1 mejora tu latencia frente a sa-east-1 (São Paulo) es medirlo con pruebas propias —traceroute, benchmarking real desde tu proveedor de tránsito— antes de comprometerte con una migración. Las cifras genéricas de “menor latencia” en material de marketing rara vez reflejan tu ruta específica de tránsito hacia Panamá o el resto de Centroamérica.
Paridad de servicios. sa-east-1 opera desde 2011 y tiene un catálogo de servicios más maduro. mx-central-1, con poco más de año y medio de operación, todavía tiene brechas en algunos servicios especializados. Antes de planificar la migración, verificar en la consola de AWS qué servicios específicos de tu stack están disponibles en la región de destino — no asumir paridad completa solo porque la región existe.
Punto clave
El soporte de AWS Transform resuelve la ejecución técnica de la migración. No resuelve el análisis de compliance, ni garantiza paridad de servicios, ni confirma la latencia real desde tu ubicación — esas tres verificaciones siguen siendo tuyas antes de mover una sola carga.
Si este análisis te resulta útil, recíbelo cada semana: 👉 Suscríbete al newsletter de DacmosGroup
São Paulo vs. México Central — criterios de decisión, no preferencia
Para una empresa centroamericana que ya opera en AWS, la pregunta rara vez es “¿cuál región es mejor?” — es “¿qué carga de trabajo específica se beneficia de cuál región?”. Esta tabla resume los criterios objetivos, sin asumir un ganador:
| Criterio | São Paulo (sa-east-1) | México Central (mx-central-1) |
|---|---|---|
| Antigüedad / madurez | Operativa desde 2011 — mayor paridad de servicios | Operativa desde enero 2025 — catálogo en expansión |
| Zonas de disponibilidad | 3 AZs | 3 AZs |
| Soporte AWS Transform como destino | Sí, desde el lanzamiento de la herramienta | Sí, agregado en la actualización de junio 2026 |
| Marco de residencia de datos | Brasil (LGPD) | México (LFPDPPP) |
| Cercanía física a Centroamérica | Mayor distancia | Menor distancia — a validar con pruebas de latencia propias |
Ninguna fila de esta tabla decide por vos. Lo que sí determina la decisión es cuál de estos criterios pesa más para tu carga de trabajo específica — un servicio con requisitos de compliance mexicano no tiene la misma ecuación que un servicio que solo busca menor latencia para usuarios en Panamá.
Preguntas frecuentes
¿Qué es AWS Transform for Migrations?
Es la herramienta de AWS que usa IA para analizar código y arquitectura existente y generar un plan de migración ejecutable hacia una región destino. Desde junio de 2026 soporta todas las regiones comerciales de AWS como destino, incluyendo México (Querétaro).
¿Puedo migrar directamente a mx-central-1 hoy?
Sí, técnicamente. La región está operativa desde enero de 2025 y AWS Transform ya la soporta como destino de migración. Pero “poder” no es lo mismo que “deber” — hay que verificar paridad de servicios y requisitos de compliance antes de ejecutar.
¿mx-central-1 tiene menor latencia que sa-east-1 para usuarios en Centroamérica?
Probablemente, por cercanía geográfica, pero AWS no publica cifras específicas para rutas centroamericanas. La única forma confiable de confirmarlo es con pruebas de latencia propias desde tu infraestructura actual, no con material de marketing.
La infraestructura de nube en LATAM dejó de ser una elección entre “Estados Unidos o nada”. Con Chile como tercera región LATAM ya anunciada para fin de 2026, la pregunta de arquitectura para cualquier empresa centroamericana no es si hay opciones regionales — es cuál de ellas responde mejor a los requisitos específicos de cada carga de trabajo.
¿Ya evaluaste qué cargas de trabajo de tu stack tendrían sentido en mx-central-1 frente a mantenerlas en sa-east-1, o seguís asumiendo que la región más antigua es automáticamente la mejor opción?
Si querés profundizar en arquitectura cloud y las otras tres megatendencias TIC, suscribite al newsletter semanal de DacmosGroup.
Este artículo se conecta con otra decisión de arquitectura que todo CIO centroamericano debería tener resuelta: cuándo repatriar cargas desde la nube pública. Podés leer más en El 83% de los CIOs ya planea repatriar cargas de la nube pública.