La última degradación a gran escala en AWS US-EAST-1 (N. Virginia) volvió a dejar claro que un fallo regional puede convertirse en un problema global: aumentos de latencia y errores en servicios base derivaron en inicios de sesión inestables, subidas bloqueadas, APIs que respondían a tirones y 5xx intermitentes en apps de consumo y SaaS corporativos. Esto no va de buscar culpables: es un playbook para sysadmins y equipos de fiabilidad. Cómo entender tu superficie de impacto, qué hacer durante el incidente y cómo arquitectar para cumplir los RTO/RPO que el negocio realmente exige.
Por qué US-EAST-1 “pega” tan fuerte (aunque tú vivas en otra región)
Incluso con cargas en Europa o APAC, es habitual tocar US-EAST-1 en la ruta de petición:
- Planos de control “globales” o pseudo-globales acaban resolviendo en endpoints de N. Virginia (STS/IAM/OIDC, catálogos, tooling legacy, pipelines).
- Servicios fundacionales (identidad, secretos/parámetros, colas, configuración) a veces están anclados en esa región por diseño histórico.
- Servicios internos multicliente (repos de artefactos, feature flags, licenciamiento, routing multi-tenant) se “aparcaron” en US-EAST-1 por conveniencia, y convierten una caída regional en modo de fallo global.
Efecto neto: una degradación en N. Virginia puede manifestarse como timeouts de autenticación en eu-west-1, backlogs de webhooks en ap-southeast-2 o cargas parciales allá donde tu frontend necesite tokens o assets que no puede obtener.
Patrones de síntoma (y qué significan aguas arriba)
- 5xx en lecturas “inocuas” → el frontend llega a su región, pero una llamada cross-region (identidad, flags, pricing, transformaciones) expira o reintenta mal.
- Login que “flapea” → minting de tokens, discovery OIDC o refresh anclados en un endpoint degradado; los clientes retroceden con backoff pobre y la capa de sesión cabecea.
- Subidas atascadas / multi-part fallando → almacenamiento de objetos o pre-signed URLs dependen de una autoridad degradada; partes OK, commit KO.
- Colas creciendo con consumers “marrones” → productores siguen publicando; los consumers se frenan (o fallan rápido) por dependencias que devuelven 5xx/429.
- Drift en batch/cron → llamadas a plano de control (lanzar/escala) topan con límites globales o IAM/STS lentos.
Los errores más caros no son los hard fails, sino los fallos lentos: consumen hilos, FDs, CPU y presupuestos de reintentos, colapsando la app desde los bordes hacia dentro.
Operar durante la incidencia: orden de batalla
No controlas el cloud subyacente; sí controlas cómo fallas. Triangula así:
- Reducir el radio de explosión
- Activa circuit breakers cuando una dependencia se sale del presupuesto (latencia/errores).
- Falla abierto/cerrado de forma explícita por capacidad (ej.: desactiva personalización, conserva checkout).
- Desprender carga con gracia
- Impón back-pressure: colas acotadas, límites de pools, fair scheduling.
- Cambia a modo degradado: contenido estático, caches más agresivas, recomendaciones precalculadas.
- Estabilizar identidad y sesiones
- Amplía TTL de tokens donde sea seguro; reduce round-trips a la autoridad; cachea discovery OIDC y JWKS con mayor frescura.
- Prefiere validación local de tokens frente a revalidación en cada salto.
- Reintentos baratos (y finitos)
- Backoff exponencial con jitter, tope de intentos e idempotency keys para colapsar duplicados.
- Promueve procesado asíncrono cuando la UX lo tolera (encola y notifica al completar).
- Comunicar
- Status page temprano; banners en la UI; un único war-room y fuente de verdad.
- Congela deploys y ruido de alertas; pasa a dashboards de incidente (RED/USE para trayectos críticos).
- Si lo tienes listo, úsalo: failover multi-región
- Desvía tráfico a región sana solo si el plano de datos está listo (estado replicado, health-checks que reflejan servicio real, capacidad caliente).
- Evita crear dos caídas repartiendo estampidas.
Post-mortem útil (preguntas que deben tener respuesta)
- ¿Qué llamadas a US-EAST-1 existen? Traza cada salto cross-region/API/control plane. Si no puedes, instrumenta ya.
- ¿Qué falló lento? Todo lo > P99 presupuesto es sospechoso. Cuenta hilos en I/O wait y pools agotados.
- ¿Cuál fue el coste de los reintentos? Tráfico extra, crecimiento de colas, cache churn, mini-DDoS propio.
- ¿Se cumplieron los SLO/SLAs? Si no, ¿qué suposiciones de diseño eran falsas? (Single-region con backups no es HA).
- ¿Qué cambia de forma permanente? Sin cambios de diseño, la repetición es cuestión de tiempo.
Diseñar para la próxima: patrones que funcionan
1) Contención > “todo más grande”
- Cell/shard: planos de control independientes por producto/tenant/región.
- Evita el singleton global (identidad/flags/precios). Clónalo por región.
2) Multi-AZ es nivel inicial; la palanca es multi-región
- Multi-AZ cubre fallos de instalación, no de región/control.
- Si el RTO son minutos, necesitas activo/activo o hot-standby con replicación continua.
3) Estado… sin autoengaño
- RPO bajo: replicación en streaming (lógica en Postgres, CRR en objetos con garantías claras).
- Define resolución de conflictos o vallas de escritura (contadores globales, CRDTs, merges deterministas) si puede haber doble punto de verdad.
4) Timeouts, presupuestos y bulkheads… escritos en piedra
- Timeouts por salto, derivados del SLO de usuario.
- Presupuestos por dependencia (si X consume 250 ms, te quedan 250 ms, no “ya veremos”).
- Bulkheads para que un feature moribundo no hunda el proceso (hilos/FDs/memoria aislados).
5) Idempotencia en todas partes
- POST re-ejecutable; PUT con clave estable; workers que toleren duplicados.
- Guarda resultados, no “lo intentamos”. Facilita la recuperación.
6) Observabilidad que baja el MTTR
- Trazas con grafo real de servicios; RED/USE en rutas doradas; black-box probes estilo usuario.
- Alarmas en síntomas (latencia/error) y causas (colas/saturación), con runbooks enlazados.
7) Practica el fallo
- Gamedays: rompe tokens, ralentiza DNS, estrangula colas, envenena caches. Primero en staging, luego en prod acotado.
- Verifica failover automático con tráfico en sombra antes de confiar.
RTO/RPO: la conversación incómoda que paga la arquitectura
Dos números mandan:
- RTO (Recovery Time Objective): cuánto tiempo puedes estar caído.
- RPO (Recovery Point Objective): cuántos datos puedes perder (en tiempo) al recuperar.
David Carrero, cofundador de Stackscale – Grupo Aire (cloud privado y bare-metal en Europa):
“Arquitectura al RTO/RPO que realmente puedes pagar. Si no toleras minutos u horas, necesitas dos sistemas capaces de seguir sin depender uno del otro. Eso es misión crítica y HA real, no una diapositiva. Y hay que probarlo. La HA que no se ensaya es un dibujo”.
Si tu RPO es 0 y el RTO es 0–minutos, las opciones se estrechan:
- Activo/activo multi-región con replicación síncrona o casi-síncrona para la fracción crítica (vigila presupuestos de latencia).
- Almacenamiento síncrono entre sitios para el hot-path (asume el coste de latencia de escritura o acota el hot set con CQRS/sagas).
- Planos de control independientes, no un “admin global” imprescindible; DNS/GTM probados bajo carga.
- Runbooks y personal alineados (guardias, playbooks, automatización testada).
Si el negocio tolera RTO 15–30 min / RPO 5–15 min, se abre el abanico: hot-standby con replicación asíncrona, reprovisión rápida (blue/green) y uso intensivo de colas para drenar tras el failback.
En cualquier caso, la cifra de la slide debe casar con presupuesto, latencia y equipo que comprometes en producción.
Checklist pragmático multi-región (AWS-centrado pero portable)
- Datos
- BBDD primaria con replicación lógica a región secundaria; plan de vallas/consistencia de escrituras.
- Objetos con replicación entre regiones (versionado + métricas de replicación).
- Secretos/config replicados (y cacheados localmente).
- Plano de control
- Auth (IdP/OIDC) por región; cache de discovery/JWKS; claves de emergencia si el marco legal lo permite.
- Feature flags/config con endpoints regionales y caches calientes; cero cold fetch en la ruta de petición.
- Tráfico
- GTM/DNS con health-checks que miden salud de servicio, no solo TCP/443.
- Tráfico en sombra continuo a la secundaria; promoción por señal, no por esperanza.
- Operación
- Pipelines (Terraform/Ansible) que materialicen la secundaria en minutos.
- Toggles de solo-lectura y modo degradado de un clic para features pesadas (subidas, búsqueda, multimedia).
- Personas y práctica
- Gamedays trimestrales: caída de auth, lentitud en objetos, colas, failover de región.
- On-call que enruta a quien posee la dependencia que falla, no solo a SRE.
Qué no hacer
- Reintentos infinitos: fabricarás el DDoS que temes.
- Confundir Multi-AZ con Multi-región. No lo son.
- Brincar a multi-cloud sin plan de competencias: duplicas modos de fallo si no inviertes de verdad en platform engineering.
- Mantener singletons globales (auth/flags/search control/licencias) en US-EAST-1 “porque empezamos ahí”.
Resumen ejecutivo para practicantes
- Una caída regional puede ser un fallo global si tu plano de control está centralizado.
- Prioriza contención; luego multi-región; multi-cloud solo con madurez suficiente.
- Tus RTO/RPO son restricciones de ingeniería, no deseos.
- Prueba el failover; si no lo practicas, no lo tienes.
Como insiste David Carrero: “La continuidad se presupuesta. Si el objetivo es cero interrupción y cero pérdida de datos, el diseño y el gasto deben estar a esa altura. No hay magia: ingeniería y prioridades”.
Apéndice: runbook durante una incidencia
Objetivo: estabilizar el servicio, contener el impacto, preservar datos y preparar la conmutación/recuperación sin crear un segundo fallo.
A. Preparación inmediata (T-0 a T+10 min)
- Congelar cambios: feature flags en freeze, pausas de despliegue/infra (IaC) y cron de mantenimiento.
- War-room único: canal dedicado, scribe asignado, reloj en UTC y timeline desde el minuto 0.
- Dashboards de incidente: latencia/error RED, saturación USE, colas (profundidad, lag), pool usage, GC/CPU steal, open FDs.
- Mensajería externa: status page y banner in-app con alcance, síntomas y próxima actualización.
B. Contención y degradación controlada (T+10 a T+30 min)
- Circuit breakers: cortar dependencias fuera de SLO (por latency budget o error budget).
- Back-pressure: límites de pools, tasas por cliente/endpoint, shed de rutas no críticas.
- Modo degradado (por toggle):
- Read-only cuando sea seguro (cestas, perfiles).
- Stale caches y TTLs ampliados en contenido no transaccional.
- Desactivar temporalmente subidas/transformaciones pesadas.
- Identidad y sesiones: cache de discovery/JWKS (TTL ↑), aumento razonable de TTL de tokens, validación local preferente.
- Reintentos: backoff exponencial con jitter, tope por operación, idempotency keys para colapsar duplicados.
C. Gestión de colas y trabajos (T+30 a T+60 min)
- Congelar productores no críticos; los críticos publican a tasa limitada.
- Consumidores con concurrencia fija y circuit breakers hacia dependencias.
- Drenaje controlado con ventanas (picos “en escalera”), evitando thundering herds.
D. Conmutación (si procede) y validación (T+60 min →)
- Criterios de failover definidos: umbrales de error/latencia, estado de datos en secundaria, capacidad caliente.
- Desvío de tráfico con GTM/DNS y health-checks orientados a servicio (no solo TCP/443).
- Smoke tests automatizados en la región de destino (rutas de usuario, escritura/lectura).
- Observabilidad reforzada tras el cut: latencia p95/p99, colas, tasas de error, cache hit ratio.
E. Cierre y aprendizaje (post-incidente)
- Restaurar flags y volver a deploy cadence normal solo tras estabilización sostenida.
- Timeline con decisiones, métricas y why detrás de cada acción.
- Post-mortem sin culpa en 5 días: causas, contribuyentes, qué funcionó, qué no, cambios de diseño/operación con responsables y fechas.
- Acciones preventivas: instrumentación faltante, SLOs ajustados, gamedays planificados, deuda saldada (p. ej., regionalizar feature flags o auth).
Plantillas rápidas (a adaptar):
- Breaker rule: “Si p95 > X ms o error rate > Y % durante Z min → abrir breaker 5 min, half-open 2 min, cerrar si p95 y error < 50 % de umbral”.
- Retry policy: 3 intentos, backoff 200/400/800 ms con jitter, idempotencia obligatoria.
- Token: Access TTL 30–60 min durante incidente; grace en refresh; cache de JWKS 15–30 min.
- GTM: desviación del 30 % → 60 % → 100 % en 10–15 min si health OK; rollback simétrico si KPIs se degradan.
Con este playbook, la próxima vez que US-EAST-1 carraspee tus usuarios deberían notar una brisa, no un temporal.
