AWS us-east-1 outage masivo (7 dic): cómo arquitectura multi-región evita el desastre
El martes pasado, 7 de diciembre, la región us-east-1 de AWS, la más grande, antigua y crítica del proveedor, sufrió un outage de aproximadamente siete horas que tumbó una porción significativa del internet comercial estadounidense: Disney+, Netflix, Robinhood, Coinbase, Slack, Roku, varias plataformas de fintech y, con cierta ironía, también partes del propio Amazon (incluyendo Ring, Alexa y operación de almacenes en plena temporada navideña).
La causa raíz reportada por AWS fue una degradación de la red interna afectando los planos de control de varios servicios principales (EC2, RDS, IAM, entre otros). El plano de datos, en general, siguió operando para recursos ya provisionados, pero todo lo que requería gestión nueva (lanzar instancias, reconfigurar, escalar, autenticar) quedó comprometido por horas.
Y no fue el único. La región us-east-1 sufrió otro evento el 15 de diciembre y un tercero el 22 de diciembre, en un patrón que dejó a muchas organizaciones reevaluando supuestos arquitectónicos básicos.
Para empresas mexicanas que corren cargas significativas en AWS (la mayoría con presencia digital seria), esto deja lecciones que cuesta ignorar.
Por qué us-east-1 importa tanto
us-east-1 (Norte de Virginia) es la región más antigua de AWS y, por inercia histórica, también la más utilizada. Muchos servicios globales tienen ahí su plano de control: el endpoint público de IAM, partes de CloudFront, partes de Route 53. Eso significa que aunque su carga no esté en us-east-1, partes operativas de servicios que sí usa probablemente sí están.
Eso explica por qué un outage en una sola región puede tener efectos visibles en cargas que parecían "globales" o que estaban en otras regiones. La arquitectura de AWS no es perfectamente independiente entre regiones para todo: hay cordones umbilicales hacia us-east-1 que importan.
Lo que separó a quienes aguantaron de quienes no
Tres factores se notaron claramente esta semana en cómo distintas organizaciones manejaron el incidente.
Arquitectura multi-región real, no nominal. Tener recursos en dos regiones no es lo mismo que tener arquitectura multi-región. Lo que importa es: ¿el tráfico se desvía automáticamente cuando una región cae? ¿Los datos están replicados con consistencia adecuada? ¿La autenticación funciona si IAM en una región está degradado? ¿El equipo sabe ejecutar el failover sin necesidad de improvisación?
Dependencias operativas auditadas. Las organizaciones que aguantaron mejor habían identificado previamente qué servicios "globales" tenían realmente plano de control en us-east-1 y habían diseñado mitigaciones (caches, fallbacks, copias en otras regiones).
Comunicación con clientes preparada. Los equipos con runbook claro de comunicación de incidentes (status page actualizada, mensaje a clientes redactado, plantilla de comunicación interna) salieron mucho mejor parados que quienes improvisaron en el momento.
Active-active vs. active-passive: el debate honesto
La pregunta práctica que toda empresa mediana en AWS debería responder este trimestre es qué arquitectura adoptar. Los dos modelos principales:
Active-active. Cargas operando simultáneamente en dos o más regiones, con tráfico distribuido (típicamente vía Route 53 con health checks). Caída de una región significa que el tráfico se redirige automáticamente a la otra. Pros: menor RTO (recovery time objective), prácticamente cero. Contras: complejidad de datos (consistencia entre regiones), costo (dos veces la capacidad), y mayor exigencia operativa.
Active-passive. Carga principal en una región, copia en otra región lista para tomar el relevo. Failover requiere acción (manual o semi-automática). Pros: menor costo, menor complejidad de datos. Contras: RTO mayor (minutos a horas), riesgo de que el ambiente pasivo no esté realmente operacional cuando se necesita (si no se prueba, no funciona).
El falso ahorro. Muchas empresas tienen lo que en el papel parece active-passive pero en la práctica es "una región y, en algún lugar, snapshots". Cuando llega el incidente, el RTO real es de días, no horas. Esto es peor que ambas opciones porque combina costo con falsa seguridad.
La respuesta correcta depende del costo real de estar caído. Para una plataforma de pagos que pierde $500,000 pesos por hora caída, active-active se paga solo. Para una aplicación interna de RH, active-passive bien probado es razonable. Para muchas empresas, una mezcla por servicio es lo sensato: las cargas críticas en active-active, las menos críticas en active-passive.
Lo que conviene revisar este mes
Cinco preguntas para llevar a la junta de operaciones de fin de año:
- ¿Qué porcentaje de nuestras cargas en producción están en us-east-1 (o en una sola región, sea cual sea)? Si es alto, hay riesgo concentrado.
- ¿Cuál es nuestro RTO real, no el aspiracional? Probado con simulacro este trimestre, no asumido en una hoja de cálculo de hace dos años.
- ¿Tenemos identificadas las dependencias en servicios globales (CloudFront, IAM, Route 53) que tienen plano de control en us-east-1?
- ¿Cuándo fue la última vez que ejecutamos un failover de prueba? Si la respuesta es "nunca" o "hace años", el plan no es plan.
- ¿Tenemos multi-región o multi-cloud? Para cargas de criticidad muy alta, conviene considerar diversificación de proveedor (AWS + Azure, AWS + GCP). El costo es real, la justificación también.
El balance honesto del costo
La conversación de resiliencia siempre choca con la conversación de costo. Es legítimo. La forma adulta de tenerla es:
Cuantificar el costo de estar caído por hora, por día. No estimaciones gruesas: cálculo concreto considerando ingresos perdidos, costo de reputación, multas regulatorias aplicables, y tiempo de equipo dedicado a recuperación.
Cuantificar el costo de cada nivel de resiliencia. Multi-AZ (incluido en buena medida en AWS por defecto), multi-región active-passive (entre 30% y 60% más de costo de infraestructura), multi-región active-active (cerca de 100% adicional), multi-cloud (puede ser 2x o más).
Mapear servicio por servicio. No todo necesita multi-región active-active. La capacidad de hacer este análisis con datos reales, no por intuición, es lo que separa a las organizaciones maduras.
Para cerrar
Los outages de us-east-1 de diciembre van a ser referenciados en presentaciones de arquitectura por años. La narrativa "eso solo le pasa a Amazon" se vuelve insostenible cuando la propia Amazon no pudo entregar paquetes en plena temporada alta.
Para una empresa mexicana, la pregunta no es si habrá un próximo outage de proveedor cloud (lo habrá, en cualquier proveedor) sino qué tan preparada está para que el impacto al negocio sea contenido. Los próximos 30 días, antes de la siguiente temporada alta, son el momento natural para hacer esa evaluación con honestidad.
¿Tu arquitectura aguanta caída de región? Hagamos un assessment. En ALCA acompañamos a equipos cloud en México a evaluar arquitectura de resiliencia, ejecutar simulacros de failover y aterrizar planes multi-región sostenibles. Agenda una conversación.
