AWS, Azure y Google en México: dónde corren tus datos y por qué importa para tu compliance

Dónde están tus datos cuando los pones en la nube

Cuando tu CFO pregunta '¿dónde están realmente nuestros datos?', la respuesta corta en 2026 es: los tres hyperscaler tienen presencia física en México, pero el detalle importa para temas de cumplimiento normativo, latencia y soberanía. Te lo desgrano región por región con datos verificados al cierre de este artículo.

Azure México Central — la región más madura

Microsoft lanzó la región México Central en Querétaro, disponible operacionalmente desde mayo de 2024. Opera con tres zonas de disponibilidad y está certificada para residencia de datos mexicana. Si tienes carga regulada por LFPDPPP (Ley Federal de Protección de Datos Personales), esta es la región que tu DPO va a pedirte por defecto. El detalle clave: NO todas las zonas de disponibilidad están físicamente separadas; algunas comparten infraestructura de soporte, así que el SLA del 99.99% aplica solo entre zonas dentro de la misma región.

Google Cloud México — single-region con tres zonas

Google designa la región simplemente como México y documenta que se compone de tres zonas dentro de uno o dos centros de datos físicos. Opera desde principios de 2024. Para efectos prácticos, GCP en México tiene menos redundancia geográfica que AWS México (que tiene tres AZs en Querétaro) pero más opciones de servicios administrados que Azure para cargas de machine learning (Vertex AI) y data analytics (BigQuery Omni). Si tu carga principal es analítica y no transaccional, GCP México es competitivo.

AWS México (Central) — Querétaro, anunciado en 2024 y con inicio de operaciones en 2025

Amazon Web Services llegó a México con la región Mexico (Central) en Querétaro, con tres zonas de disponibilidad independientes. Es la región más reciente de las tres, así que el catálogo de servicios disponibles es más acotado (algunas instancias especializado como las de la familia P4 todavía no están aquí). Para workloads de inferencia de IA que requieren GPUs, revisa bien el catálogo antes de comprometerte; muchos clientes terminan usando us-east-1 con interconexión para cargas GPU-intensive.

Qué significa esto para tu cumplimiento normativo

Si tu cliente te exige que los datos personales NO salgan del país, los tres hyperscaler cumplen la residencia de datos porque sus regiones mexicanas operan dentro del territorio nacional. El problema aparece con servicios globales (Azure Front Door, CloudFront, Route 53): ahí el routing puede pasar por infraestructura fuera de México aunque tus datos de origen estén aquí. Para cumplimiento normativo estricto, fuerza regiones fijas en Terraform con un data residency guard antes de pasar a producción.

Cuándo NO usar región mexicana

Tres casos donde conviene otra región aunque tu cliente esté en México:

• Catálogo de servicios incompleto: si necesitas una instancia o servicio que solo está en us-east-1 o europe-west, acepta la latencia.
• Multi-región activo-activo: necesitas una segunda región fuera de México para recuperación ante desastres geográfico; la más cercana geográficamente es south-us (Dallas) o southamerica-east (São Paulo).
• Soberanía de datos con retención específica: algunos sectores (financiero, salud) requieren que ciertos datos NO salgan del país ni siquiera para copia de seguridad. Ahí revisa contratos con tu DPO.

Fuentes

1. Microsoft Azure — Regions list (documentación oficial, actualizada 2026). https://learn.microsoft.com/en-us/azure/confiabilidad/regions-list
2. Google Cloud — Cloud Locations (documentación oficial, actualizada 2026). https://cloud.google.com/about/locations
3. Amazon Web Services — Global Infrastructure Regions and AZs (documentación oficial, actualizada 2026). https://aws.amazon.com/about-aws/global-infrastructure/regions_az/