Regiones y ubicaciones de borde de AWS - La ventaja física de 33 regiones y más de 600 PoP
Organizamos cómo están estructuradas las regiones, las Availability Zones y las ubicaciones de borde de AWS, y explicamos desde una perspectiva práctica el diseño de DR con las 2 regiones de Tokio y Osaka, la respuesta a los requisitos de soberanía de datos y la ejecución de procesamiento en el borde.
La competitividad del cloud se decide por la infraestructura física
En las comparaciones de servicios en la nube, la atención tiende a centrarse en la riqueza de funciones y los sistemas de precios. Sin embargo, lo que sustenta la base del cloud es la infraestructura física. Dónde están los centros de datos y cuántos hay. Cuán distribuidos están los puntos de conexión de red. Esta disposición física impacta directamente en la latencia, la disponibilidad, la soberanía de datos y la recuperación ante desastres. AWS ha invertido consistentemente en infraestructura global desde el inicio del servicio en 2006. A agosto de 2026, despliega 123 Availability Zones (AZ) en 39 regiones geográficas y, como red de distribución de CloudFront, cuenta con más de 750 PoP (Point of Presence) y 15 cachés de borde regionales. Ahora bien, las premisas para contar este tipo de ubicaciones difieren según el proveedor, por lo que la magnitud de las cifras no puede leerse directamente como superioridad. Lo que tiene sentido en la práctica es el contenido de la configuración: cómo están estructuradas las regiones, si la región elegida ofrece los servicios necesarios y hasta qué punto se puede acortar la distancia con el usuario final.
La estructura de regiones y AZ - Lo que hay que verificar antes de contar ubicaciones
Una región de AWS es una unidad que agrupa varias AZ. Cada AZ es un conjunto de centros de datos con alimentación eléctrica, refrigeración y seguridad física independientes, separados físicamente por una distancia significativa. La documentación de AWS explica que todas las AZ de una misma región se encuentran a menos de 100 km (60 millas) entre sí, y lo característico es que, pese a estar separadas, están conectadas por una red dedicada de baja latencia. Gracias a esta estructura, la replicación sincrónica entre AZ funciona con una latencia práctica y el fallo de un único centro de datos puede absorberse mediante el diseño. Como al abrir nuevas regiones se aplican los mismos estándares arquitectónicos, un diseño de disponibilidad basado en la distribución entre AZ puede reutilizarse de una región a otra. Sin embargo, también hay diferencias a tener en cuenta. Aunque la estructura de AZ y los estándares de diseño sean uniformes, los servicios ofrecidos varían según la región, y lo habitual es que los nuevos servicios y funciones se desplieguen primero en las regiones principales. Al decidir la región de destino de una migración o de DR, verifique siempre la disponibilidad de servicios por región. La misma perspectiva es necesaria al comparar el número de ubicaciones. Cómo se define el término región, si la ubicación siempre cuenta con particiones equivalentes a una AZ, si los clientes generales pueden utilizarla (¿se incluyen ubicaciones exclusivas para el gobierno u operadas por terceros?) y si los servicios que se quieren usar se ofrecen en esa ubicación. Alinear solo los totales sin igualar estos 4 puntos no constituye una comparación.
La configuración en Japón - Cómo usar las 2 regiones de Tokio y Osaka
Para los usuarios de Japón, lo importante es que dentro del país existen 2 regiones completas: la región de Tokio (ap-northeast-1) y la región de Osaka (ap-northeast-3). La región de Tokio se abrió en 2011 y tiene 4 AZ. La región de Osaka fue promovida a región completa en 2021 y cuenta con 3 AZ. Como ambas están separadas por aproximadamente 400 km en línea recta, es posible construir una configuración de DR que se complete dentro del país incluso frente a desastres de amplio alcance que la distribución entre AZ dentro de una misma región (menos de 100 km) no puede absorber. Satisfacer al mismo tiempo el requisito de no sacar los datos del país y la resiliencia mediante la dispersión geográfica es posible precisamente porque hay 2 regiones completas en el país. Aquí es fácil confundirse con las Local Zones. A agosto de 2026, AWS despliega 45 Local Zones, pero no hay ninguna Local Zone en Japón. La Local Zone cuya región principal es ap-northeast-1 (Tokio) es ap-northeast-1-tpe-1a en Taiwán (Taipéi); que la región principal sea Tokio y que la ubicación esté en Japón son cuestiones distintas. Si se necesita acercar la infraestructura a un lugar concreto dentro del país, la opción no son las Local Zones sino AWS Outposts y similares. Una precaución práctica es que los servicios ofrecidos en la región de Osaka no coinciden por completo con los de la región de Tokio. Antes de diseñar la configuración de DR, confirmar que los servicios previstos para el lado en espera y las funciones de replicación de datos entre regiones (replicación entre regiones de S3, Aurora Global Database, etc.) están disponibles en Osaka permite evitar retrocesos.
Densidad de ubicaciones de borde - La batalla de la última milla
Si las regiones son la base de procesamiento del backend, las ubicaciones de borde son el punto de contacto más cercano al usuario final. A agosto de 2026, AWS despliega como red de distribución de CloudFront más de 750 PoP (Point of Presence) y 15 cachés de borde regionales. Las cachés de borde regionales son una capa de caché intermedia entre los PoP y el origen: reciben el contenido que no cabe en cada PoP y reducen los viajes de ida y vuelta al origen. Cuanto mayor es la densidad de ubicaciones de borde, menor es la distancia física con el usuario final y menor la latencia de distribución de contenido. En cargas de trabajo donde la latencia impacta directamente en la experiencia del usuario, como streaming de video, juegos y sitios de comercio electrónico, esta diferencia se manifiesta notablemente. Además, las ubicaciones de borde de AWS no se limitan a ser simples cachés de CDN. Edge computing con Lambda@Edge y CloudFront Functions, resolución DNS con Route 53, protección DDoS con AWS Shield y protección de aplicaciones con AWS WAF se ejecutan todos en el borde. Como la autenticación, las redirecciones, la reescritura de encabezados y el bloqueo de ataques pueden completarse antes de llegar al origen, el borde ha ampliado su papel de "punto de distribución" a "punto donde se ejecuta el procesamiento". En el diseño, cuántas respuestas se pueden hacer cacheables y cuánto procesamiento se puede adelantar para completarlo en el borde determinan tanto la velocidad percibida como la carga del origen.
Libertad de selección de región y soberanía de datos
Para las empresas que utilizan la nube, en qué país se almacenan los datos es una cuestión legal y regulatoria importante. Las regulaciones que restringen la ubicación geográfica de los datos, como el GDPR, la Ley de Protección de Información Personal y las regulaciones financieras, se están fortaleciendo en todo el mundo. Las regiones de AWS son independientes entre sí de forma predeterminada, y los datos colocados en una región no se replican a otra sin instrucción del usuario. Este principio de "no cruzar regiones" es la base para gestionar la ubicación de los datos. A agosto de 2026 hay 39 regiones, y en Europa están disponibles Irlanda, Frankfurt, Londres, París, Milán, Estocolmo, España y Zúrich, entre otras. Además, en Europa se ha sumado como opción, aparte de las regiones habituales, la AWS European Sovereign Cloud (Brandeburgo, Alemania), operada de forma independiente dentro de la UE. Para requisitos aún más estrictos, también existen modalidades como Dedicated Local Zones y AWS Outposts, que colocan la infraestructura de AWS en un país concreto o en las instalaciones propias. Aunque la variedad de opciones es amplia, dejar abiertas todas las regiones utilizables complica la gestión. Cuando se quiere fijar la ubicación con certeza, la práctica habitual es restringir las propias regiones utilizables con la clave de condición de política de IAM aws:RequestedRegion o con las políticas de control de servicios de AWS Organizations. La soberanía de datos no se garantiza por "tener muchos lugares donde colocar los datos", sino por "poder fijar el lugar exactamente como se pretende".
Expansión de la infraestructura - Historial y planes anunciados
Al seleccionar un proveedor de nube, además de la escala actual de la infraestructura, el historial de expansión y los planes ya anunciados también son criterios de decisión. AWS mantiene la práctica de anunciar con antelación la apertura de nuevas regiones; recientemente, en 2024 entró en funcionamiento la región Asia Pacífico (Malasia) y en 2025 las regiones Asia Pacífico (Tailandia), México y Nueva Zelanda. Los planes de nuevas regiones anunciados a agosto de 2026 son 2 regiones en Arabia Saudita y Chile, con la incorporación prevista de 7 AZ en total. La apertura de una región implica asegurar terrenos, disponer de electricidad y conectividad, y cumplir con la regulación local, por lo que desde el anuncio hasta la puesta en marcha transcurren años. Por tanto, los planes anunciados deben tratarse como un indicio de que "en el futuro pueden ampliarse las opciones en esa zona", y es más seguro no elaborar un plan de migración que presuponga la fecha de apertura. A la inversa, el número y la distribución de las regiones ya en funcionamiento representan tal cual el rango que se puede elegir hoy. En la selección, evalúe por separado los planes anunciados y el historial en operación.
Beneficios prácticos de la estructura de la infraestructura física
Organizamos cómo la estructura de regiones y ubicaciones de borde afecta a la práctica. Primero, la optimización de la latencia. Al poder seleccionar regiones y bordes cercanos a los usuarios, se puede mejorar físicamente la velocidad de respuesta de las aplicaciones. Segundo, la flexibilidad del diseño de DR. Cuando hay varias regiones dentro del mismo país, es posible una configuración de DR geográficamente distribuida manteniendo la soberanía de datos. Tercero, la respuesta al cumplimiento normativo. Se puede seleccionar la región que cumple con los requisitos regulatorios y fijar la ubicación de los datos mediante políticas. Cuarto, la reutilización del diseño al expandirse. Como los estándares de diseño de las regiones son uniformes, un diseño de disponibilidad basado en la distribución entre AZ puede reutilizarse tal cual en una región nueva. Sin embargo, para obtener estos beneficios es necesario verificar las premisas. Como los servicios ofrecidos y las cuotas difieren según la región, conviene inventariar de antemano los servicios que se van a usar en el destino y preparar un diseño que absorba las diferencias funcionales respecto a la región inicial. En la selección de la nube y el diseño del despliegue, es importante tratar la estructura de la infraestructura física con el mismo peso que la comparación de funciones.
Resumen
La infraestructura global de AWS tiene, a agosto de 2026, una escala de 39 regiones, 123 AZ y más de 750 ubicaciones de borde, y sus características estructurales son que los estándares de diseño de las regiones son uniformes y que en el borde no solo se distribuye, sino que también se ejecuta procesamiento. Como el número de ubicaciones depende de la forma de contarlas, al comparar conviene verificar hasta si la ubicación cuenta con particiones equivalentes a una AZ, si los clientes generales pueden utilizarla y si se ofrecen los servicios necesarios. En el mercado japonés, el mayor valor práctico es que existen 2 regiones completas, Tokio con 4 AZ y Osaka con 3 AZ, separadas por aproximadamente 400 km, lo que permite compatibilizar la retención de datos en el país con la preparación ante desastres de amplio alcance. También conviene tener presente que no hay Local Zones en Japón y que la Local Zone cuya región principal es Tokio está en Taiwán (Taipéi). En la selección de la nube, además de comparar las funciones de software, es importante evaluar cómo encaja esta estructura de la infraestructura física con los requisitos propios.
Referencias (recursos oficiales de AWS)
Las fuentes primarias de esta página son el sitio web y la documentación oficiales de AWS. Consulta las páginas oficiales siguientes para conocer las especificaciones y los precios más recientes.
- Amazon CloudFront (página oficial)
- AWS Global Accelerator (página oficial)
- Amazon Route 53 (página oficial)
- Documentación de AWS (oficial)
Si esta página y la documentación oficial difieren, prevalece la documentación oficial.