En el artículo anterior quedamos en que una región de AWS (Amazon Web Services) es una zona geográfica con centros de datos, y que en octubre de 2025 se cayó la de Virginia y se llevó a medio internet con ella.
Falta la pregunta incómoda: ¿y si el problema es más chiquito? Un centro de datos es un edificio físico, y a un edificio se le va la luz, se le inunda el sótano o se le incendia un cuarto de máquinas.
Si toda tu aplicación vive en ese edificio y el edificio falla, tu aplicación falla.
Para eso existen las zonas de disponibilidad, que son la pieza que le sigue a las regiones y la que de verdad explica por qué hay servicios que "nunca se caen".
Si llegaste directo aquí, el artículo de regiones es el que va antes.
Una región no es un edificio
A cada grupo de centros de datos aislados dentro de una región, AWS le llama una zona de disponibilidad. En inglés aparece como Availability Zone, y en la consola la vas a ver abreviada como AZ.
Cada región de AWS tiene al menos tres, y eso es el mínimo con el que abre una región nueva. Querétaro abrió con tres. En total hay 124 zonas repartidas en 39 regiones.
Lo que hace que una zona sea una zona, y no un pasillo del mismo edificio, es que tiene energía, enfriamiento y seguridad física independientes. No comparte el transformador ni la planta de emergencia con las otras.
Y en el código se nota poco: una zona es una letra pegada al nombre de la región.
us-east-1a, us-east-1b, mx-central-1a. Esa letra es la que decide en qué edificio
acaba tu servidor.
Por qué están lejos, pero no tanto
Aquí está la parte de ingeniería que me parece más bonita, porque es un equilibrio entre dos cosas que se pelean.
Si las zonas están muy juntas, un solo desastre se las lleva a todas y no sirvió de nada separarlas. Si están muy lejos, la distancia mete retraso y ya no pueden trabajar como si fueran una.
La solución de AWS es específica: las zonas están separadas por una distancia significativa, de varios kilómetros, y aun así todas quedan dentro de un radio de 100 kilómetros (unas 60 millas) entre ellas.
Están conectadas por fibra óptica dedicada, con rutas redundantes, y todo el tráfico entre zonas va cifrado. La red es lo bastante rápida para lo que en la documentación llaman replicación sincrónica, que es la parte importante: puedes escribir un dato en una zona y confirmar que también quedó escrito en la otra antes de responderle al usuario.
Eso es lo que permite que la copia de respaldo esté al día al segundo, y no al día de ayer.
Lo que pasa cuando se cae una sola zona
El caso mejor documentado es viejo y por eso mismo sirve, porque AWS publicó el detalle completo.
El 29 de junio de 2012, a las 7:24 de la noche, un pico de voltaje pegó en el equipo eléctrico de dos centros de datos que formaban una sola zona de Virginia. Las plantas de emergencia arrancaron, y ahí vino el problema: cada una falló por su cuenta al entregar voltaje estable.
Resultado: alrededor del 7% de las máquinas virtuales de toda la región se quedaron sin luz. La mayoría volvió entre las 11:15 de la noche y poco después de medianoche.
Ahora la parte que interesa. Las máquinas que estaban en otras zonas de la misma región siguieron trabajando como si nada. Y las bases de datos configuradas en varias zonas promovieron casi al instante su copia en una zona sana.
O sea, para dos clientes que rentaban en el mismo lugar, el mismo evento fue una noche de desastre o un correo automático de aviso. La diferencia no fue la suerte, fue una decisión de arquitectura tomada meses antes.
Tu "us-east-1a" no es el mismo que el de tu compa
Este detalle confunde a todo el mundo la primera vez, y no es un error de AWS, es a propósito.
AWS reparte las zonas físicas al azar entre las cuentas. Tu us-east-1a y el
us-east-1a de otra persona pueden ser edificios distintos.
¿Por qué esa maña? Porque si el nombre fuera fijo, medio mundo pondría sus servidores en la zona "a" por default y la saturaría, mientras las otras quedarían a medias. Es una forma de repartir la carga sin pedirle permiso a nadie.
Cuando de verdad necesitas saber de qué edificio estás hablando, existe el AZ ID, que
sí es consistente entre cuentas. Se ve así: use1-az1. Esa etiqueta apunta al mismo lugar
físico para todos, y la puedes consultar en la consola o con este comando:
aws ec2 describe-availability-zones --region us-west-2
Te devuelve el nombre que tú ves (ZoneName) junto al identificador real (ZoneId).
Importa sobre todo cuando compartes recursos entre cuentas, porque ahí sí necesitas que
los dos lados estén en el mismo edificio.
Cómo se usa esto en la práctica
La buena noticia es que casi nada de esto se programa a mano. Está en casillas de configuración que ya existen.
Reparte tus servidores. Al crear tu red privada en AWS, las subredes se crean por zona. Pones una en la zona A y otra en la zona B, y ya tienes tu aplicación en dos edificios. Si una máquina falla, la otra atiende las peticiones.
Pon un balanceador enfrente. Es el que recibe el tráfico y lo reparte entre las zonas. Cuando una deja de responder, manda todo a la que sigue viva.
Prende la casilla de varias zonas en la base de datos. En Amazon RDS (el servicio de bases de datos administradas) se llama Multi-AZ: AWS mantiene una copia sincronizada en otra zona de disponibilidad y cambia a ella sola si la principal se cae. El cambio tarda entre 60 y 120 segundos típicamente.
Dos advertencias sobre esa casilla, para que no te sorprenda. La copia de respaldo no atiende consultas, así que no la prendas esperando que tu base vaya al doble de rápido. Y como cada escritura tiene que confirmarse en las dos zonas, puedes ver un poquito más de retraso al escribir. Es el precio de no perder datos.
Hasta dónde te protegen, y dónde ya no
Aquí va el límite, que es justo donde se rompen las expectativas.
Las zonas te protegen de que se caiga un edificio. Un incendio, un apagón, una inundación, una planta de emergencia que no arranca.
Las zonas no te protegen de que falle la región completa. Eso fue lo de octubre de 2025 en Virginia: no se quemó un edificio, se rompió el sistema que traduce los nombres de una base de datos central, y con él se fueron los servicios que dependían de ese sistema en toda la región. Tener tus servidores en tres zonas no te habría salvado, porque el problema estaba un nivel arriba.
Para eso están las varias regiones, que es el siguiente escalón: más caro, más complejo, y con la complicación de mantener datos en dos lugares que no se hablan solos.
La escalera queda así: un servidor te protege de nada, varias zonas te protegen de un desastre local, varias regiones te protegen de que se caiga un pedazo entero de la nube.
En corto
- Si tu proyecto le importa a alguien, usa mínimo dos zonas. Suele ser una casilla, no un rediseño.
- No elijas la zona a mano al empezar. La documentación de AWS recomienda dejar que el sistema te asigne una según capacidad y salud, y especificarla solo cuando tengas una razón.
- Revisa si tu base de datos ya está en varias zonas. Es la pieza que más duele perder y la que más se deja en la configuración de default.
- Si compartes recursos con otra cuenta, habla en AZ ID, no en nombres de zona.
Las zonas de disponibilidad son de esas cosas que no se ven hasta que fallan. Cuando una aplicación aguanta un apagón y sus usuarios ni se enteran, casi siempre es porque alguien se tomó cinco minutos para repartirla en dos edificios.
Fuentes
- AWS, regiones y zonas de disponibilidad: mínimo tres zonas por región, energía y enfriamiento independientes, separación de varios kilómetros dentro de un radio de 100 km, fibra dedicada redundante, tráfico cifrado y replicación sincrónica
- AWS, infraestructura global: 39 regiones y 124 zonas de disponibilidad
- AWS, regiones y zonas en la guía de Amazon EC2: qué es una zona, cómo se nombra y la recomendación de dejar que AWS elija la zona al principio
- AWS, identificadores de zona de disponibilidad: el mapeo aleatorio de zonas físicas por cuenta y qué es un AZ ID
- AWS, resumen del evento del 29 de junio de 2012: el pico de voltaje, la falla de las plantas de emergencia, el 7% de las instancias afectadas y el comportamiento de las otras zonas
- AWS, despliegues Multi-AZ en Amazon RDS y el proceso de cambio automático: copia sincrónica en otra zona, entre 60 y 120 segundos de cambio, la copia no atiende lecturas
- AWS, resumen del evento del 20 de octubre de 2025: la falla de alcance regional en Virginia