Lectura de 6 minActualizado: 18 de octubre de 2026
La región AWS México (Mexico Central, mx-central-1) opera desde enero de 2025 con tres zonas de disponibilidad. Para una plataforma de comunicaciones críticas —OTP, alertas de seguridad, notificaciones transaccionales— lo que habilita va bastante más allá de “está más cerca”. Y también tiene límites que conviene decir en voz alta antes de mover nada.
Latencia: el problema no es el salto, es la acumulación
Para tráfico transaccional que va y vuelve varias veces —autenticación, validación, confirmación— los milisegundos se acumulan. No es lo mismo un salto interno que salir del país y volver. En un flujo de OTP típico hay consulta de riesgo, generación, encolado, envío, recepción de acuse y actualización de estado. Si cada uno de esos pasos cruza frontera, el usuario percibe una demora que nadie diseñó explícitamente: apareció sumando.
El efecto más incómodo no es el promedio, es la cola. Los percentiles altos —el p95 y el p99— son los que determinan cuántos usuarios abandonan un alta o vuelven a pedir el código. Y son justamente los que más sufren cuando el camino de red es largo y tiene más puntos donde algo puede congestionarse.
Residencia de datos: lo que destraba conversaciones
El contenido almacenado en la región no sale de México salvo que uno decida moverlo. En conversaciones con áreas de cumplimiento, esa frase resuelve discusiones que antes se estiraban meses.
Hay una tercera ventaja que se menciona menos y que en mi experiencia pesa igual: la conversación con un área de riesgo cambia de tono cuando la infraestructura está en el mismo marco jurídico que el negocio. No porque el control técnico sea distinto, sino porque la pregunta “¿a qué jurisdicción responde este proveedor?” deja de tener una respuesta larga.
La parte honesta: región local no es automáticamente mejor
- No todos los servicios llegan a todas las regiones al mismo tiempo. Antes de mover una arquitectura completa conviene revisar servicio por servicio, incluidos los que se usan sin pensar: colas, notificaciones, gestión de claves, bases administradas, caché.
- Tres zonas de disponibilidad alcanzan para alta disponibilidad, no para recuperación regional. Sobreviven a la caída de un centro de datos; no a un evento que afecte la región entera. Si el negocio exige continuidad ante ese escenario, sigue haciendo falta una estrategia entre regiones.
- La cercanía geográfica no arregla un diseño acoplado. Latencia baja sobre una arquitectura con dependencias mal pensadas sigue siendo una arquitectura con dependencias mal pensadas.
- El costo no siempre baja. Los precios varían por región y la transferencia entre regiones se paga. Vale la pena modelarlo antes, no después.
Qué sí resuelve la región AWS México en mensajería
En plataformas de mensajería hay tres componentes donde la proximidad cambia el comportamiento observable del sistema:
| Componente | Qué mejora | Qué no mejora |
|---|---|---|
| API de ingesta de envíos | Tiempo de respuesta al cliente que integra; menos timeouts en integraciones bancarias | La velocidad con la que el operador entrega el mensaje |
| Colas y workers de procesamiento | Ciclos más cortos, menos acumulación en picos | El diseño de reintentos, si está mal pensado |
| Base de datos transaccional y reportería | Consultas de estado y trazabilidad más ágiles para el cliente | Consultas mal indexadas o tablas sin particionar |
Cómo evaluarlo sin migrar por moda
El error más común que veo es plantear la decisión como un todo o nada. No lo es. Una arquitectura de mensajería se puede mover por partes, y normalmente conviene:
- Medir primero. Latencia real desde donde están tus clientes hasta tu API actual, en percentiles, durante al menos una semana con picos incluidos. Sin ese número, la discusión es una opinión.
- Mover lo que es sensible a latencia y poco acoplado. Típicamente la capa de ingesta y los workers, antes que la base de datos histórica.
- Revisar servicio por servicio la disponibilidad en la región. Un solo servicio faltante puede obligar a una arquitectura híbrida que anula la ganancia.
- Diseñar la vuelta. Si algo sale mal, cómo se regresa. Una migración sin camino de retorno no es una migración, es una apuesta.
- Documentar la decisión, aunque sea quedarse. “Lo evaluamos y decidimos no mover, por estas razones” es una respuesta perfectamente válida en una auditoría. “No lo miramos” no lo es.
Mi lectura
Para plataformas de comunicaciones críticas que operan en México, la región local es hoy una opción que debería estar sobre la mesa en cada revisión de arquitectura, aunque la conclusión sea quedarse donde se está. Lo que cambió no es que ahora haya que migrar: es que ya no se puede decir que no existía la opción.
¿Ya evaluaron mover parte de su plataforma, o el tema sigue en el backlog?
Residencia de datos: lo que la región resuelve y lo que no
La pregunta que más me hacen sobre la región de México no es de latencia, es de cumplimiento: “¿con esto ya tengo los datos en México?”. La respuesta corta es que la región permite elegir dónde se almacenan y se procesan, pero no convierte por sí sola a una plataforma en cumplidora.
- El dato en reposo se queda donde se configura. El dato en tránsito puede seguir cruzando fronteras si la arquitectura lo manda a un servicio global, a un proveedor externo o a un respaldo en otra región.
- Los servicios globales por diseño —DNS, gestión de identidades, algunos servicios de borde— no se regionalizan porque cambies de región.
- Las copias de seguridad y los ambientes de prueba suelen ser el punto ciego: se configuran una vez y nadie vuelve a mirarlos.
- El marco mexicano sigue en movimiento: el reglamento de la nueva ley de protección de datos personales todavía no se publica, y el país aún no tiene ley federal de ciberseguridad aprobada. Diseñar para el escenario más exigente sale más barato que rehacerlo después.
Qué le pido a una arquitectura multirregión
Tener dos regiones no es tener continuidad. Lo que hace la diferencia es haber decidido de antemano tres cosas: qué se replica, cuánto se puede perder y cuánto se puede tardar en volver.
| Decisión | Qué defino antes de un incidente |
|---|---|
| Objetivo de recuperación (RTO) | Cuánto tiempo puede estar caído cada flujo, no el sistema completo |
| Punto de recuperación (RPO) | Cuánto dato se puede perder en la conmutación, por tipo de dato |
| Alcance de la réplica | Qué se replica en caliente, qué se reconstruye y qué simplemente se pierde |
| Criterio de conmutación | Quién decide, con qué métrica y en cuánto tiempo |
| Vuelta atrás | Cómo se regresa cuando la región principal se recupera, sin duplicar envíos |
En mensajería hay un detalle propio: la conmutación no puede duplicar mensajes. Un OTP enviado dos veces desde dos regiones no es un problema estético, es un usuario con dos códigos válidos y un flujo de verificación que deja de ser confiable. La idempotencia por operación es parte del plan de continuidad, no un detalle de implementación.
Fuentes
- AWS News Blog: Now open: AWS Mexico (Central) Region (14 de enero de 2025).
- Blog de AWS en español: AWS expande su presencia en América Latina con nueva región en México (14 de enero de 2025).
- Amazon Web Services: Data Privacy FAQ.
Seguir leyendo
- Agentes de IA en producción: el problema es la arquitectura — las capas que separan un piloto de un sistema en producción.
- SMS bidireccional: el canal de vuelta que casi nadie configura — las cuatro definiciones previas a habilitarlo.
- Network APIs de GSMA Open Gateway: SIM Swap y Number Verification — señales de red para el análisis de riesgo antes del OTP.
