AWS Local Zones: arquitectura global explicada

Las AWS Local Zones son extensiones de una región principal de AWS que acercan cómputo, almacenamiento y base de datos a los usuarios finales para correr aplicaciones sensibles a la latencia. No son regiones independientes ni Availability Zones clásicas: son satélites de una región que permiten llegar a milisegundos de distancia del usuario, sin abandonar la VPC existente.

¿Qué son las AWS Local Zones?

Una AWS Local Zone es una infraestructura de AWS desplegada físicamente en una ciudad distinta a la región principal, conectada a esa región por una red redundante de alta velocidad. No reemplaza a las Availability Zones: las complementa. Si tu región es us-east-1 (Virginia del Norte), podés tener Local Zones en Boston, Chicago y Dallas, según la documentación oficial de AWS.

La diferencia clave con una AZ tradicional es el objetivo. Las AZs apuntan a alta disponibilidad dentro de una región. Las Local Zones apuntan a reducir la latencia para usuarios en una ciudad concreta, cumplir requisitos de residencia de datos, o correr workloads de edge computing sin montar infraestructura propia.

Eso sí: no todos los servicios de AWS están disponibles en Local Zones. El subconjunto es específico y conviene revisarlo antes de diseñar la arquitectura.

Cómo habilitar y usar AWS Local Zones

El proceso de habilitación es sencillo pero hay que saber dónde buscar. Entrás al EC2 Dashboard, vas a Settings dentro de Account Attributes y desde ahí habilitás la Local Zone que necesitás. Una vez activada, aparece como opción disponible al momento de crear subredes dentro de tu VPC.

Fijate que no se crea una VPC separada: es una extensión de la VPC existente. Eso simplifica la gestión de red porque las reglas de seguridad, tablas de ruteo y configuraciones que ya tenés aplican también a los recursos en la Local Zone (con algunas restricciones según el servicio).

La conectividad funciona así: la Local Zone tiene su propia conexión a internet y también soporte para Direct Connect, más una red de alta velocidad redundante hacia la región principal. Esa conexión con la región madre es lo que permite que los datos sean accesibles globalmente aunque el cómputo esté en el edge. Relacionado: pipelines de CI/CD en AWS.

Servicios disponibles en Local Zones

No es todo AWS en miniatura. Según AWS, los servicios disponibles en Local Zones incluyen:

• Cómputo: EC2 (con tipos de instancia seleccionados), ECS, EKS
• Almacenamiento: EBS, S3 (acceso vía región principal)
• Base de datos: RDS
• Redes y entrega: Application Load Balancer, Direct Connect, Route 53, AWS Shield Standard
• Caché: ElastiCache

Para gaming en tiempo real, streaming de video o aplicaciones financieras con requisitos de latencia menores a 10ms, esa combinación cubre la mayoría de los casos. Para cargas de trabajo más complejas que necesitan servicios como Lambda, Step Functions o SageMaker, todavía tenés que quedarte en la región principal.

Patrones de arquitectura global: de Single AZ a Multi-Region

Ponele que necesitás decidir cómo desplegar tu aplicación para usuarios en distintas partes del mundo. Hay cuatro patrones principales, cada uno con un trade-off diferente entre disponibilidad, latencia y complejidad.

Patrón	Alta disponibilidad	Latencia global lecturas	Latencia global escrituras	Complejidad
Single Region, Single AZ	No	No	No	Baja
Single Region, Multiple AZs	Sí	No	No	Media
Multi-Region Active-Passive	Sí	Sí	No	Media-Alta
Multi-Region Active-Active	Sí	Sí	Sí	Alta

Single Region, Single AZ es básicamente inviable para cualquier aplicación que importe. Un corte de luz en el datacenter y chau. Nadie que haya perdido datos en producción vuelve a confiar en un solo punto de falla.

Single Region, Multiple AZs ya es el mínimo razonable: distribuís las instancias en dos o tres AZs dentro de la misma región, ponés un Load Balancer adelante y si una AZ cae, las otras absorben el tráfico. El problema es que todos los usuarios siguen tirando contra la misma región, así que alguien en Europa accediendo a us-east-1 va a notar la latencia.

Active-Passive: cuándo tiene sentido

En Multi-Region Active-Passive usás dos regiones, cada una con múltiples AZs. La región activa maneja todas las lecturas y escrituras. La pasiva está en standby: replica los datos vía replicación asincrónica (RDS cross-region replica, por ejemplo) y solo recibe tráfico si la región principal falla, usando failover con Route 53.

Las lecturas globales ya mejoran porque podés redirigir tráfico de lectura a la región pasiva sin failover completo. Pero las escrituras siguen yendo a la región activa, así que si tu usuario está en São Paulo y la región activa es us-east-1, cada write cruza el Atlántico (o casi). Más contexto en elegir entre herramientas CI/CD.

¿Cuándo conviene? Disaster recovery tradicional. Si tu requisito es un RTO de horas y un RPO razonable, Active-Passive tiene una complejidad manejable y costos mucho menores que Active-Active. Para compliance donde necesitás tener una copia geográficamente separada, también zafa.

Active-Active: máxima resiliencia, máxima complejidad

En Multi-Region Active-Active ambas regiones manejan lecturas y escrituras. No hay región “maestra”: cualquier región puede atender cualquier request. Eso resuelve el problema de latencia de escritura global que Active-Passive no podía.

Para lograrlo necesitás replicación bidireccional. Los servicios que la soportan nativamente en AWS son DynamoDB Global Tables, Aurora Global Clusters y ElastiCache Global Datastore. RDS estándar no está pensado para escritura bidireccional sin trabajo extra de tu parte.

El precio a pagar es doble: consistencia eventual y costos. Si un usuario escribe en us-east-1 y otro lee en eu-west-1 medio segundo después, puede que vea el dato viejo. Dependiendo del dominio (e-commerce, finanzas, salud), eso puede ser aceptable o directamente inaceptable. Y el costo de correr infraestructura completa en dos regiones más los mecanismos de replicación no es menor.

Ojo con esto: Active-Active no es “Active-Passive pero mejor”. Es un modelo diferente que requiere que tu aplicación esté diseñada desde el principio para manejar consistencia eventual. Si la aplicación asume consistencia fuerte en lecturas, migrarla a Active-Active implica rediseño, no solo infraestructura.

Casos de uso reales para Local Zones

Las Local Zones aparecen en escenarios concretos donde la latencia no es un nice-to-have sino un requisito duro.

Gaming en tiempo real: servidores de juego corriendo en EC2 dentro de una Local Zone en la ciudad del jugador. La diferencia entre 5ms y 80ms es la diferencia entre el juego siendo jugable o no. En optimizar contenido a nivel global profundizamos sobre esto.

Streaming y AR/VR: aplicaciones de realidad aumentada que necesitan procesar video antes de devolver la respuesta al headset. Con una Local Zone en la ciudad del usuario, el round trip baja drásticamente.

Aplicaciones financieras: trading y transacciones donde cada milisegundo importa, más requisitos regulatorios de residencia de datos en una jurisdicción específica.

IoT edge computing: procesar datos de sensores cerca de donde se generan, sin mandar todo a una región centralizada que puede estar a miles de kilómetros.

Si tu empresa tiene operaciones en Argentina y necesitás infraestructura cloud con baja latencia, donweb.com tiene soluciones de hosting y cloud pensadas para el mercado local, mientras AWS sigue expandiendo su red de Local Zones en la región.

Errores comunes al trabajar con Local Zones y arquitecturas multi-región

Error 1: confundir Local Zone con Availability Zone. Una AZ es parte constitutiva de la región. Una Local Zone es un satélite con un subconjunto de servicios. Si diseñás como si fueran equivalentes, vas a descubrir en producción que el servicio que necesitás no existe en la Local Zone.

Error 2: implementar Active-Active sin rediseñar la aplicación. Mover la infraestructura a dos regiones con replicación bidireccional y dejar la aplicación asumiendo consistencia fuerte es una receta para bugs difíciles de reproducir. La consistencia eventual tiene que estar en el modelo de datos desde el diseño.

Error 3: olvidar habilitar la Local Zone antes de intentar crear subredes en ella. Si no la habilitaste en Account Attributes del EC2 Dashboard, no aparece como opción. Parece obvio, pero genera confusión cuando alguien ve documentación que menciona una Local Zone y no la encuentra disponible en su cuenta. Ya lo cubrimos antes en ejecutar agentes sin dependencias externas.

Error 4: asumir que Active-Passive resuelve escrituras globales. En Active-Passive, las escrituras van a la región activa. Si tus usuarios están en otra geografía, las escrituras tienen latencia alta. Eso es por diseño, no un bug a resolver con configuración.

Preguntas Frecuentes

¿Qué son las AWS Local Zones?

Son extensiones físicas de una región de AWS ubicadas en ciudades distintas a los datacenters principales, conectadas a la región madre por red de alta velocidad. Permiten correr cómputo, almacenamiento y base de datos más cerca del usuario final para reducir latencia. No son regiones independientes: se integran como extensión de la VPC existente.

¿Cómo habilitar AWS Local Zones en mi cuenta?

Entrás al EC2 Dashboard, vas a Settings dentro de Account Attributes y activás la Local Zone deseada. Una vez habilitada, aparece como opción disponible al crear subredes en tu VPC. No requiere crear una VPC nueva.

¿Cuál es la diferencia entre Active-Passive y Active-Active en AWS?

En Active-Passive, una región maneja lecturas y escrituras mientras la otra está en standby y solo recibe tráfico ante failover; las lecturas globales mejoran pero las escrituras siguen atadas a la región activa. En Active-Active ambas regiones manejan lecturas y escrituras simultáneamente usando replicación bidireccional (DynamoDB Global Tables, Aurora Global Clusters), lo que resuelve la latencia de escritura global a costa de consistencia eventual y mayor complejidad operativa.

¿Qué servicios funcionan en AWS Local Zones?

Los servicios disponibles incluyen EC2, ECS, EKS, EBS, RDS, ElastiCache, Application Load Balancer, Direct Connect, Route 53 y Shield Standard. No todos los tipos de instancia EC2 están disponibles y servicios como Lambda o SageMaker no tienen soporte en Local Zones. La lista varía por ubicación.

¿Cuándo necesito arquitectura multi-región en AWS?

Cuando tenés usuarios distribuidos geográficamente con requisitos de baja latencia, cuando necesitás recuperación ante desastres con RTO bajo, o cuando regulaciones exigen residencia de datos en jurisdicciones específicas. Para la mayoría de las aplicaciones con usuarios concentrados en una región, Single Region con Multiple AZs cubre la alta disponibilidad sin la complejidad operativa de multi-región.

Conclusión

Las AWS Local Zones resuelven un problema específico: llevar infraestructura cloud a metros (bueno, kilómetros) del usuario final sin montar una región completa. Para gaming, streaming, AR/VR o edge computing con requisitos de latencia menores a 10ms, son la herramienta correcta. Para el resto de los casos, la decisión real está entre los cuatro patrones de arquitectura global.

Si estás preparando la certificación Cloud Practitioner o diseñando tu primera arquitectura multi-región, la tabla comparativa de este artículo te da el marco. El salto de Single AZ a Multiple AZs es el primero y más importante. El salto a Active-Active es el más costoso en complejidad, plata y rediseño de aplicación. Hacelo solo cuando los requisitos lo justifiquen, no porque suene bien en una presentación.

Fuentes

• AWS Documentation — How Local Zones Work (guía técnica oficial)
• AWS — Global Infrastructure: Local Zones (lista de ubicaciones disponibles)
• AWS Architecture Blog — Multi-site Active-Active DR
• Dev.to — AWS Certified Cloud Practitioner Series Part 4
• AWS en Español — Arquitecturas híbridas: Outposts, Local Zones y más