La región de AWS en México 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 una región local 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?