Multi-AZ y arquitecturas tolerantes a fallos

Todo lo del tema anterior daba por sentado que la infraestructura se queda donde la pusiste. Escalar una flota, agregar readers, calentar una caché: nada de eso sirve si el edificio donde viven las instancias se queda sin energía. La habilidad 2.2 del examen trata justamente sobre ese supuesto, y arranca por la unidad de fallo más chica a la que AWS le puso nombre.

Una zona de disponibilidad es un lugar real

Una zona de disponibilidad es uno o más centros de datos discretos dentro de una región, con su propia infraestructura eléctrica, su refrigeración, su red y su conectividad física. No es una partición lógica ni una etiqueta de rack. AWS opera más de 100 en todo el mundo.

Dos números definen cómo se comportan las AZ, y los dos son decisiones de diseño, no accidentes:

• Hasta unos 100 km de separación. Suficiente para que una inundación, un incendio, un tornado, una caída de la red eléctrica o un corte de fibra difícilmente golpeen dos a la vez. Las AZ no comparten generadores, equipos de refrigeración ni subestaciones, y AWS escalona sus propios despliegues de servicios entre las AZ de una región para que un rollout malo no aterrice en todas al mismo tiempo.
• Latencia de milisegundos de un dígito entre ellas. Lo bastante cerca como para replicar una escritura de base de datos de forma síncrona a otra zona y aun así confirmarla rápido para una carga OLTP.

Ese par de números es toda la razón por la que Multi-AZ funciona. Si las AZ estuvieran a 5 km, una tormenta regional se llevaría varias juntas. Si estuvieran a 1.000 km, la replicación síncrona sumaría decenas de milisegundos a cada commit y nadie la habilitaría. La distancia está elegida para que la redundancia entre zonas sea a la vez significativa y pagable.

El nombre de una AZ además es por cuenta. us-east-1a en tu cuenta y us-east-1a en la de un colega suelen ser zonas físicas distintas, porque AWS aleatoriza el mapeo para repartir la carga. El identificador estable es el AZ ID (use1-az1), que es lo que comparas cuando compartes subnets entre cuentas con AWS RAM.

Zonal, regional, global: la clasificación que decide todo

Acá está la idea equivocada que causa más caídas por sorpresa: "AWS es de alta disponibilidad, así que mi carga de trabajo es de alta disponibilidad." AWS corre sus servicios repartidos entre AZ. Eso no significa que los recursos concretos que creaste vivan en más de una.

Cada recurso de AWS está exactamente en uno de tres alcances, y el alcance te dice qué le hace la caída de una AZ.

Lee esa tabla como una checklist operativa, no como datos sueltos. Cada recurso zonal de tu arquitectura es una pregunta: ¿qué pasa cuando su AZ desaparece? Un servicio regional ya te respondió esa pregunta. Uno zonal no.

Dos entradas merecen mirarse de cerca porque son trampa:

• Un volumen EBS es zonal, pero su snapshot es regional. No puedes adjuntar un volumen de us-east-1a a una instancia de us-east-1b. Sí puedes crear un volumen nuevo en us-east-1b a partir del snapshot de ese volumen, porque los datos del snapshot están replicados en todas las AZ de la región. Esa asimetría es la forma de mover almacenamiento en bloques entre zonas, y es un detalle favorito del examen.
• Un load balancer es regional, pero sus nodos son zonales. Habilitas un ALB o un NLB en subnets específicas, y AWS pone un nodo del load balancer en cada una de esas AZ. Habilítalo en una sola AZ y armaste una dependencia de una zona con nombre de recurso regional. Un ALB exige subnets en al menos 2 AZ justamente por eso.

Que la capa de cómputo sobreviva: enrutar no es capacidad

Pon un Auto Scaling group en tres AZ detrás de un ALB y resolviste el problema de enrutamiento. Cuando una zona cae, el ALB deja de mandar pedidos a sus targets unhealthy y el ASG marca esas instancias como unhealthy y las reemplaza. Esa parte es automática.

Lo que no es automático es tener a dónde mandar el tráfico. Haz las cuentas.

Corres 6 instancias en 3 AZ, 2 por zona, y cada instancia absorbe el 20 por ciento del tráfico pico. En el pico estás usando 6 x 20 = 120 por ciento de lo que necesitas, que se siente como un margen cómodo. Ahora cae AZ-B:

Instancias sobrevivientes: 4
Capacidad:                 4 x 20% = 80% del pico
Faltante:                  20% del pico, hasta que los reemplazos arranquen y pasen los health checks

Durante varios minutos estás descartando o demorando uno de cada cinco pedidos. El load balancer hizo su trabajo perfecto y el sitio igual quedó degradado.

La regla general es dimensionar para la pérdida de una AZ completa, que la gente escribe como AZ+1:

Esta es la razón concreta por la que AWS recomienda tres AZ y no dos. Dos zonas hacen que la redundancia te cueste el doble; tres, que te cueste la mitad más.

El principio de fondo detrás de la tabla es la estabilidad estática: el sistema debería seguir funcionando bien sin necesidad de cambiar nada cuando ocurre un fallo. Lanzar instancias de reemplazo durante un evento de AZ es una operación del control plane, y los control planes tienen objetivos de disponibilidad más bajos que los data planes, precisamente porque hacen un trabajo más complejo. Peor todavía: la caída de una AZ es justo el momento en que todos los demás clientes de esa región también están pidiendo capacidad. Un diseño que necesita escalar para sobrevivir puso su recuperación a depender del minuto más ocupado en la vida del control plane. Un diseño estáticamente estable ya tiene la capacidad prendida.

Dos configuraciones deciden qué tan pareja cae la carga:

• El cross-zone load balancing deja que un nodo del load balancer en una AZ mande tráfico a targets de todas las AZ, y no solo a los de la suya. Viene activado por defecto en ALB (se puede desactivar por target group) y desactivado por defecto en NLB. Con esto apagado y cantidades de targets desparejas por zona, una AZ con 2 targets recibe la misma porción de tráfico que una con 8, y cada uno de esos 2 targets trabaja cuatro veces más.
• Health checks del ELB contra health checks del ASG. Por defecto un Auto Scaling group solo mira los status checks de EC2, que dicen que la instancia está prendida, no que tu aplicación responda. Activa los health checks del ELB en el ASG para que un target que falla el chequeo HTTP del load balancer sea reemplazado en vez de quedarse ahí devolviendo errores.

La capa de datos: tres formas de sobrevivir a una zona

El cómputo es reemplazable. Los datos no, así que la capa de base de datos tiene su propia respuesta, y RDS te da tres formas con propiedades muy distintas.

El despliegue Multi-AZ DB instance es el clásico y el más evaluado. RDS mantiene un standby en una segunda AZ, le replica cada commit de forma síncrona y, ante un fallo, cambia el CNAME de DNS que hay detrás de tu endpoint para que apunte al standby promovido. Tu aplicación conserva la misma cadena de conexión y solo tiene que reconectarse. De "síncrona" se desprenden dos consecuencias:

• La latencia de escritura y de commit sube frente a Single-AZ, porque cada commit espera a la segunda zona. Ese es el precio que pagas por la durabilidad.
• El standby no es un servidor de repuesto que puedas usar. No acepta conexiones. Si un escenario pide descargar lecturas, la respuesta es una read replica o un Multi-AZ DB cluster, nunca el standby.

Aurora va por otro camino: el volumen del cluster abarca tres AZ y guarda seis copias de tus datos, así que la replicación entre instancias directamente no existe. Perder una AZ te quita instancias pero no el almacenamiento, y por eso un reader de Aurora se puede promover tan rápido.

Las dependencias de una sola AZ que la gente deja pasar

Hasta una arquitectura multi-AZ armada con cuidado suele tener algunos cuellos zonales. Estos son los que vale la pena auditar:

• NAT gateway. Se crea en una subnet, o sea en una AZ. Enruta cada subnet privada por un único NAT gateway y la caída de una zona corta la salida a internet de toda la VPC. Despliega uno por AZ y dale a cada subnet privada una route table que apunte al gateway de su propia zona. Esto además elimina los cargos de transferencia entre AZ, así que el diseño resiliente suele ser el más barato.
• EFS One Zone. Clase de almacenamiento más barata, y el nombre es la advertencia. EFS Standard replica entre AZ; One Zone no.
• Volúmenes instance store. Físicamente adjuntos al host. No solo son zonales, sino que duran lo que dura la instancia. Detener la instancia pierde los datos.
• Una instancia RDS Single-AZ con una read replica en otra AZ. En un diagrama esto parece Multi-AZ, pero la réplica es asíncrona y la promoción es una operación manual de varios minutos. Es un plan de recuperación, no un mecanismo de failover.
• Un load balancer habilitado en una sola subnet. Ya lo vimos arriba, y es fácil de crear sin querer en un ambiente de prueba que después se vuelve producción.

Lo que Multi-AZ no hace

Multi-AZ protege contra fallos de infraestructura dentro de una zona. Es una promesa concreta y limitada. No hace nada frente a:

• Corrupción lógica. Un DELETE sin cláusula WHERE se replica de forma síncrona al standby en milisegundos. Ahora las dos copias están igual de mal. Recuperarse implica point-in-time recovery o un snapshot.
• Borrado accidental. Borrar la instancia de base de datos borra también su standby.
• Eventos de región completa. Cada AZ de la tabla de arriba vive en una región. Sobrevivir a la pérdida de una región es otra arquitectura, y la última lección de este tema cubre las cuatro formas de construirla.
• Un despliegue defectuoso. Código nuevo que devuelve HTTP 500 lo devuelve idéntico en las tres zonas.

Esta es la forma más limpia de sostener el límite en la cabeza: Multi-AZ es alta disponibilidad y protege contra que las cosas se rompan. Los respaldos y la replicación entre regiones son recuperación ante desastres y protegen contra que las cosas estén mal. El examen los separa de forma consistente, y tu diseño también debería.

Consejos para el examen

• Las frases "sobrevivir a la caída de una zona de disponibilidad", "alta disponibilidad" y "failover automático" apuntan a Multi-AZ. Las frases "borrado accidental", "corrupción de datos", "restaurar a un punto en el tiempo" y "caída de región" apuntan a respaldos o a una estrategia de DR, y ahí Multi-AZ es la respuesta equivocada aunque suene protectora.
• Cualquier respuesta que lea desde el standby de un Multi-AZ DB instance es incorrecta. La opción existe para ser descartada. Descargar lecturas es una read replica o un Multi-AZ DB cluster.
• Números para llevarte: failover de Multi-AZ DB instance de 60 a 120 segundos, failover de Multi-AZ DB cluster en general menos de 35 segundos, almacenamiento de Aurora con 6 copias en 3 AZ, ALB con mínimo 2 AZ.
• Cuando un enunciado describe una caída que afectó a todo pese a tener varias AZ, busca una dependencia zonal compartida. Un único NAT gateway es la clásica; un load balancer en una sola subnet es la otra.
• Cross-zone load balancing: activado por defecto en ALB, desactivado por defecto en NLB. Cantidades desparejas de targets por AZ más cross-zone apagado da carga despareja.
• Si una pregunta indaga cuánta capacidad correr en cada AZ, la respuesta buscada es la suficiente para que las zonas restantes carguen todo sin escalar. Eso es estabilidad estática, y su justificación es que Auto Scaling es una operación del control plane.

La regla para llevarte: por cada recurso de tu arquitectura, nombra su alcance. Los recursos zonales necesitan un hermano en otra zona y algo que esquive el fallo; los regionales ya lo resolvieron. Todo lo de esta lección mantiene una carga de trabajo en pie durante un fallo de infraestructura, y nada de eso ayuda cuando los datos en sí están mal. Para eso es la lección siguiente, que arranca por el mecanismo que hay debajo de cada respaldo en AWS: el snapshot.