El diseño de Availability Zones de AWS - La diferencia en confiabilidad que genera la separación física y el aislamiento de fallos
Explicamos la filosofía de diseño de las AZ de AWS como grupos de centros de datos físicamente independientes, comparándolas con las zonas de disponibilidad de Azure y GCP, y las examinamos a partir de los criterios de diseño publicados y de incidentes reales.
Las zonas de disponibilidad existen en todas las nubes, pero no son iguales
Todos los principales proveedores de nube ofrecen el concepto de "zonas de disponibilidad" (Availability Zones). Sin embargo, la implementación física, el grado de aislamiento de fallos y la madurez operativa difieren significativamente entre proveedores. AWS comenzó a ofrecer AZ en marzo de 2008, dos años después del lanzamiento de EC2 en 2006, como una función añadida junto con las direcciones Elastic IP. A lo largo de la operación hasta 2026 se han ido consolidando los criterios de diseño de la separación y un conjunto de servicios que presuponen múltiples AZ. Azure hizo disponibles de forma general las Availability Zones en 2018, con una diferencia de 10 años en el inicio de la oferta. Sin embargo, haber empezado antes no significa por sí mismo un diseño superior. Este artículo ordena qué diferencias pueden confirmarse realmente, a partir de los criterios de diseño que publica cada proveedor y de la información primaria sobre los incidentes ocurridos.
El diseño de AZ de AWS - Separación física exhaustiva
Cada AZ de AWS consiste en uno o más centros de datos físicamente independientes. Cada AZ tiene alimentación eléctrica independiente (con múltiples fuentes de energía y generadores de respaldo), refrigeración independiente, redes independientes y está ubicada en una zona de inundación diferente. La distancia entre AZ es de varios kilómetros a decenas de kilómetros, lo suficientemente lejos para que un desastre natural que afecte a una AZ no impacte a otra, pero lo suficientemente cerca para mantener una latencia de red inferior a 2ms. Esta separación física está diseñada para que un fallo de energía, un incendio, una inundación o un fallo de red en una AZ no se propague a otras AZ, y cada AZ opera como un dominio de fallo independiente. La propia descripción primaria de AWS está redactada como objetivo de diseño ("cada AZ está diseñada para estar aislada de los fallos de las demás AZ") y no garantiza que ningún evento se extienda a otras AZ. En el diseño de la disponibilidad hay que decidir el alcance de la redundancia teniendo en cuenta esta diferencia entre "objetivo de diseño" y "garantía". AWS no divulga públicamente las ubicaciones exactas de sus centros de datos, y los ID de AZ (us-east-1a, us-east-1b, etc.) se mapean aleatoriamente para cada cuenta, distribuyendo la carga entre AZ.
Availability Zones de Azure - Contexto de su introducción y qué comprobar
Azure hizo disponibles de forma general las Availability Zones en 2018. Las zonas de disponibilidad se describen como "uno o más centros de datos con alimentación, refrigeración y red independientes", y la idea de distribuir los recursos entre varias zonas para eliminar puntos únicos de fallo es común con AWS. Lo que difiere es la trayectoria. Azure usaba originalmente los Availability Sets (separación lógica mediante dominios de fallo y de actualización) como unidad básica de disponibilidad, y las zonas de disponibilidad se añadieron después como concepto, desplegándose de forma gradual mientras se mantenía la coherencia con los servicios existentes. Por ello, al diseñar es necesario comprobar en la lista oficial de regiones de Microsoft y en la documentación de cada servicio si la región objetivo admite zonas de disponibilidad y cómo trata cada servicio las zonas (redundancia zonal o fijación a una zona concreta). Como la cobertura se amplía continuamente, es más seguro no fijar las decisiones a partir de una tabla de compatibilidad de un momento dado. Además, cuánto publica cada proveedor sobre la distancia entre AZ y los criterios de separación de energía y refrigeración varía. Aunque se hable con el mismo término de "zona de disponibilidad", la granularidad que el usuario puede verificar no es uniforme, y la comparación debe partir de esa premisa.
El diseño de zonas de GCP - Un enfoque diferente
GCP adopta un enfoque diferente al de AWS para las zonas. Las zonas de GCP son similares a las AZ de AWS en concepto, pero GCP pone mayor énfasis en la redundancia a nivel de región que en la redundancia a nivel de zona. Servicios como Cloud Spanner y BigQuery están diseñados para ser regionales por defecto, abstrayendo la existencia de zonas del usuario. Este enfoque tiene la ventaja de simplificar la arquitectura para los desarrolladores, pero la desventaja de ofrecer menos control granular sobre la ubicación de los recursos. Por otro lado, en GCP predominan las regiones de 3 zonas, y las regiones en las que se pueden elegir 4 o más zonas, como la región de Tokio de AWS (4 AZ), son limitadas; no obstante, existen regiones de 4 zonas, como us-central1. Lo que conviene comprobar al diseñar no es el número total de zonas de cada proveedor, sino cuántas zonas se pueden elegir realmente en la región que se quiere usar y si es posible repartir la capacidad entre ellas.
La efectividad del aislamiento de AZ vista desde incidentes reales
La verdadera prueba del aislamiento de AZ se revela durante los fallos reales. En el corte de energía de us-east-1 de 2019, el evento quedó contenido en una sola AZ. Sin embargo, los entornos que solo tenían recursos en esa AZ sí se vieron afectados. Una configuración multi-AZ no sale indemne automáticamente: superar el evento como un incidente de una sola AZ depende de que la aplicación esté configurada para seguir procesando en las AZ restantes. AWS publica resúmenes posteriores para algunos incidentes de gran escala, pero no para todos los eventos, por lo que el diseño debe apoyarse en los objetivos de diseño y en las especificaciones de comportamiento de cada servicio, no en informes publicados individuales. Otros proveedores también han tenido eventos de este tipo. En el incidente de la región Australia East de agosto de 2023, una caída de tensión detuvo los equipos de refrigeración, y la revisión posterior publicada por Microsoft sitúa el alcance en un subconjunto dentro de una de las tres zonas de disponibilidad. El grado de aislamiento de un proveedor frente a otro no puede deducirse a partir del incidente de una sola empresa. Lo que sirve de criterio son los criterios de diseño que publica cada proveedor y la actitud operativa sobre con qué granularidad se publican las revisiones posteriores a los incidentes.
Mejores prácticas de diseño multi-AZ
Para aprovechar al máximo el aislamiento de AZ de AWS, se deben seguir varias prácticas. Primero, desplegar recursos en al menos 2 AZ (preferiblemente 3) para cada componente crítico. Segundo, usar Elastic Load Balancing para distribuir el tráfico entre las AZ habilitadas; el valor predeterminado del cross-zone load balancing difiere según el tipo de balanceador (activado por defecto en Application Load Balancer y desactivado por defecto en Network Load Balancer), por lo que en NLB hay que activarlo explícitamente o colocar el mismo número de destinos en cada AZ. Tercero, configurar Auto Scaling Groups para que lancen instancias en múltiples AZ. Cuarto, para bases de datos, usar Multi-AZ deployments de RDS o Aurora con réplicas en diferentes AZ. Quinto, diseñar la aplicación para ser stateless o usar almacenamiento compartido (como ElastiCache o DynamoDB) que sea accesible desde cualquier AZ. La clave es que cada AZ debe poder operar de forma independiente si las otras AZ fallan.
Baja latencia entre AZ - Compatibilizando separación y conectividad
Un logro notable del diseño de AZ de AWS es mantener una latencia de red inferior a 2ms entre AZ dentro de la misma región, a pesar de la separación física de kilómetros. Esto se logra mediante fibra óptica dedicada de alta capacidad que conecta las AZ. Esta baja latencia permite que las aplicaciones distribuidas entre múltiples AZ funcionen como si estuvieran en el mismo centro de datos, mientras mantienen el beneficio del aislamiento de fallos. La replicación síncrona de bases de datos entre AZ (como Aurora Multi-AZ) es posible gracias a esta baja latencia. Si la latencia entre AZ fuera de decenas de milisegundos, la replicación síncrona sería impráctica y se perdería la capacidad de failover automático sin pérdida de datos.
Resumen
El diseño de AZ de AWS se ha ido consolidando desde el inicio de la oferta en marzo de 2008 mediante la publicación de criterios de diseño de la separación física, mejoras derivadas de los incidentes y la acumulación de servicios que presuponen múltiples AZ. Azure hizo disponibles de forma general las zonas de disponibilidad en 2018, y GCP tiene un diseño de zonas que refleja la experiencia de Google en sistemas distribuidos a gran escala. La comparación directa es difícil porque tanto la granularidad de los criterios de diseño publicados como el alcance de las revisiones posteriores a incidentes varían según el proveedor. Por ello, en la selección de la nube lo práctico no es preguntarse si existe el término "zona de disponibilidad", sino comprobar individualmente cuántas zonas se pueden elegir realmente en la región deseada, cómo se comportan por defecto entre zonas los servicios que se van a usar y hasta qué punto se publican las revisiones posteriores cuando ocurre un fallo. Sobre esa base, lo que cuenta al final es que la aplicación esté construida presuponiendo múltiples AZ para aprovechar el diseño de aislamiento de la nube elegida.
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 EC2 (página oficial)
- Amazon VPC (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.