En el subcapítulo anterior vimos las regiones. Ahora bajamos un nivel para descubrir uno de los conceptos más importantes de toda la nube: las Availability Zones (Zonas de Disponibilidad, o «AZ»). Son la base para que tus aplicaciones no se caigan aunque falle un datacenter entero.

Cada región de AWS está formada internamente por varias Availability Zones. Una AZ es uno o más datacenters físicos, con su propia energía, refrigeración y red, independientes de las demás AZ de la región.

Piensa en ello así:

Las AZ de una misma región están:

• Lo bastante lejos unas de otras para que un desastre local (incendio, inundación, corte eléctrico) no las afecte a todas a la vez.
• Lo bastante cerca para estar conectadas por redes muy rápidas, de modo que trabajen juntas casi como si fueran una sola.

Suelen nombrarse añadiendo una letra al código de región: eu-south-2a, eu-south-2b, eu-south-2c.

La idea es simple pero poderosa: si repartes tu aplicación entre varias AZ, el fallo de una no tumba tu servicio.

Analogía: Imagina que tienes una tienda importante. En lugar de poner todo tu stock en un único almacén (que podría incendiarse), lo repartes en tres almacenes en barrios distintos. Si uno se quema, los otros dos siguen sirviendo pedidos. Pierdes un tercio de capacidad, pero no cierras.

Eso es exactamente lo que hacen las AZ: te permiten diseñar sistemas que sobreviven a la caída de un datacenter entero.

Imagina una tienda online bien diseñada:

• El tráfico de los usuarios llega a un balanceador de carga (lo veremos en el Capítulo 13).
• El balanceador reparte las peticiones entre servidores que están en AZ distintas.
• Si la AZ-b sufre un corte de luz, el balanceador deja de enviarle tráfico y usa solo AZ-a y AZ-c.
• Los usuarios no se enteran de nada. La web sigue funcionando.

Esto es lo que significa «alta disponibilidad desde el diseño»: la resiliencia no es un añadido, sino parte de cómo construyes desde el principio.

En la nube se asume que el hardware fallará tarde o temprano. No es pesimismo, es realismo: con millones de componentes, siempre hay algo rompiéndose. La estrategia ganadora no es evitar que nada falle (imposible), sino diseñar para que, cuando algo falle, no importe.

Por eso una de las primeras buenas prácticas que aprenderás es:

Nunca pongas toda tu aplicación en una sola AZ. Reparte siempre en al menos dos.

Servicios como las bases de datos gestionadas (RDS Multi-AZ, Capítulo 8) o los grupos de autoescalado (Capítulo 13) están pensados precisamente para distribuirse entre AZ con muy poco esfuerzo por tu parte.

Es importante distinguir dos niveles de resiliencia:

Para la mayoría de aplicaciones, multi-AZ es suficiente y mucho más sencillo y barato. Multi-región se reserva para sistemas críticos que no pueden permitirse ni el más mínimo tiempo de caída (lo veremos en el Capítulo 26 sobre recuperación ante desastres).

• Una región se divide en varias Availability Zones (AZ), que son datacenters independientes (energía, red y refrigeración propias).
• Las AZ están aisladas entre sí pero conectadas por redes rápidas.
• Repartir tu aplicación en varias AZ la hace tolerante al fallo de un datacenter completo.
• Regla de oro: diseña para el fallo y nunca uses una sola AZ en producción.
• Multi-AZ protege contra fallos de datacenter; multi-región protege contra fallos de una región entera (más caro y complejo).

En el siguiente subcapítulo veremos un tercer nivel de presencia de AWS, aún más cercano al usuario: las edge locations y el servicio CloudFront.