Regiones y zonas de disponibilidad

El centro de datos que nunca falla no existe

Imagina la tienda en línea de una empresa corriendo sus servidores desde un solo edificio. Ese edificio pierde energía justo el día de la venta más grande del año, y cada servidor adentro se apaga al mismo instante. No importa qué tan bueno sea el código ni cuánto tráfico pudieran manejar esos servidores en otras condiciones: la tienda queda fuera de línea hasta que alguien restaure la energía en ese único lugar. Los proveedores de nube enfrentan exactamente la misma física que ese edificio. Un solo centro de datos también se puede incendiar, inundar o quedarse sin energía, sin importar de quién sea el logo en la puerta. Lo que los proveedores construyeron en su lugar es una estructura que evita que un mal día en una ubicación se convierta en un mal día para todos: regiones y zonas de disponibilidad.

Regiones: en qué parte del mundo viven tus recursos

Una región es un área geográfica separada, por ejemplo US East (Virginia del Norte) o Europa (Irlanda). Cuando lanzas una máquina virtual o creas un bucket de almacenamiento, eliges una región, y esa elección decide qué país o continente aloja físicamente tus datos y qué tan lejos tiene que viajar el tráfico de red para llegar a tus usuarios. Solo AWS opera cerca de 39 regiones en todo el mundo, cada una diseñada para estar totalmente aislada de las demás, de modo que una falla en una región no tenga forma de alcanzar a las otras.

Las regiones existen por 2 razones prácticas: latencia y legislación. Un usuario en Singapur recibe respuestas más rápidas desde una región en Singapur que desde una en Virginia, y algunas industrias y gobiernos exigen que ciertos datos nunca salgan de las fronteras de un país específico. Elegir una región es tu primera decisión de infraestructura en cualquier plataforma de nube, y casi siempre está guiada exactamente por esas 2 restricciones.

Zonas de disponibilidad: aislamiento dentro de la región

Una región por sí sola no te protege de nada, es solo una ubicación. La protección viene un nivel más abajo, dentro de la región, donde los proveedores tallan varias zonas de disponibilidad. Cada zona es 1 o más centros de datos discretos, cada uno con su propia energía, enfriamiento y seguridad física redundantes, alojados en una instalación físicamente separada de las demás zonas de la misma región. AWS garantiza un mínimo de 3 zonas por región. Las zonas siguen lo bastante cerca entre sí, generalmente dentro de 100 km, para que una conexión de fibra dedicada de baja latencia y alto ancho de banda mantenga rápido el tráfico entre ellas.

AWS nombra sus zonas a partir de la región: us-east-2a, us-east-2b y us-east-2c son las 3 zonas de la región us-east-2. Esa letra final es lo único que cambia: todo antes de ella identifica la región, y la letra elige la zona específica.

Ejemplo trabajado: 1 zona contra 3

Digamos que un retailer corre su servicio de checkout en 6 máquinas virtuales. Pon las 6 en una sola zona, y un corte de energía en ese único centro de datos las tumba a todas en el mismo instante, exactamente como el edificio del escenario inicial. Reparte esas mismas 6 máquinas entre 3 zonas, 2 por zona, y el panorama cambia por completo: si 1 zona pierde energía, las otras 4 máquinas en las 2 zonas restantes siguen atendiendo las solicitudes de checkout. La zona que falló queda fuera de línea, pero el servicio de checkout, como conjunto, no.

Nada del código cambió entre esos 2 escenarios. La única diferencia es dónde están físicamente ubicadas las 6 máquinas, que es la razón completa de que las zonas de disponibilidad existan como concepto, no como algo que programas, sino como una decisión que tomas al desplegar.

El error de concepto: multi-AZ no es multi-región

Es tentador tratar "repartido entre zonas de disponibilidad" y "protegido contra cualquier interrupción" como lo mismo. No lo son. Multi-AZ te protege de una falla local a 1 ubicación de centro de datos, energía, enfriamiento, incendio, inundación. No hace nada contra un evento que afecte a toda un área geográfica a la vez, un desastre natural mayor o una falla de red a nivel región. Sobrevivir a eso exige correr en más de 1 región, replicando datos y tráfico a través de una distancia mucho mayor, un compromiso mayor en costo y complejidad que multi-AZ. La mayoría de las aplicaciones solo necesita multi-AZ. Multi-región es para cargas donde perder toda un área geográfica, por el tiempo que sea, no es aceptable.

Cómo se comparan los 3 proveedores principales

El concepto es universal, aunque el vocabulario cambie ligeramente entre proveedores.

Vale la pena conocer una diferencia estructural: si toda una región de Azure sufre una falla, cada zona de disponibilidad dentro de ella puede verse afectada, porque Azure construye una región a partir de sus zonas. AWS y Google Cloud diseñan sus regiones para estar aisladas entre sí, así que una falla específica de 1 región no debería propagarse a otra región distinta. Es un detalle de diseño, no algo que cambie cómo usas multi-AZ en el día a día, pero explica por qué "qué regiones usar" a veces también es una decisión de disponibilidad, no solo de latencia.

Dónde te deja esto

Una región elige dónde viven tus recursos, y las zonas de disponibilidad dentro de ella son lo que realmente te protege del mal día de un solo centro de datos. Despliega en al menos 2, idealmente 3, zonas siempre que una aplicación necesite mantenerse en línea, y recurre a varias regiones solo cuando perder toda un área geográfica sea un riesgo que no puedas aceptar. Ahora que sabes cómo organizan los proveedores el mapa físico debajo de la nube, la siguiente lección cubre qué es lo que realmente alquilas dentro de ese mapa: cómputo.