La mañana del lunes, 20 de octubre de 2025 dejó una escena difícil de olvidar: webs, apps y redes sociales que no cargaban, inicios de sesión fallidos, pagos que no pasaban y asistentes como Alexa en silencio. El motivo fue una incidencia global en Amazon Web Services (AWS), la mayor plataforma de infraestructura cloud del mundo. El impacto alcanzó a servicios como Amazon, Prime Video, Canva, Duolingo, Crunchyroll, Snapchat, Goodreads y juegos online como Fortnite, Roblox o Clash Royale. En Europa, el efecto fue desigual por regiones, pero palpable.
Más allá del susto, la caída expone una verdad incómoda: gran parte de Internet comparte capas invisibles (cómputo, almacenamiento, identidad, DNS, CDN…) que viven en AWS o dependen de proveedores que, a su vez, se apoyan en AWS. Cuando falla una de esas capas y no hay arquitectura multirregión ni plan de contingencia, la experiencia de cargar, entrar, pagar o publicar se cae en cascada.
Por qué una incidencia en AWS paraliza a tantos a la vez
Internet funciona gracias a capas compartidas. Muchas empresas no solo alojan sus aplicaciones en EC2, EKS o Lambda; también consumen servicios base en AWS y terceros integrados con AWS:
- Identidad (Cognito, STS/AssumeRole, SSO).
- Datos (RDS/DynamoDB/S3) y búsqueda (OpenSearch).
- Red (Route 53, CloudFront, API Gateway).
- Orquestación y mensajería (Step Functions, SQS/SNS, EventBridge).
Si estas piezas se degradan, es habitual ver:
- APIs y feeds que no responden o lo hacen con errores 5xx.
- Logins que no emiten tokens o expiran sin renovar.
- Páginas que no resuelven porque el DNS no responde o el CDN no puede llegar al origen.
- Subidas que se quedan a medias por fallos en firmas o en multipart.
- Servicios “no-AWS” que caen porque su proveedor sí está en AWS.
La cadena rompe por donde menos margen hay: si todo está en la misma región, cuenta o proveedor, el fallo único se convierte en apagón total.
El ángulo más crítico: quedarse “ciego” durante la caída
Hay un riesgo menos visible pero igual de grave: cuando las métricas, logs y alertas dependen de la misma región o misma nube que la app, el equipo se queda sin observabilidad justo cuando más la necesita. Si CloudWatch, CloudTrail, GuardDuty, el SIEM, los dashboards, las alertas por SNS/SES o incluso el SSO viven en el mismo dominio de fallo, el equipo no ve ni puede entrar con credenciales válidas. La exposición aumenta.
Cómo evitarlo: saca telemetría, identidad y acceso de emergencia fuera de la misma zona de fallo (otra región, cuenta o incluso otro proveedor). Mantén al menos un panel “desacoplado” y cuentas de break-glass con MFA fuera del perímetro afectado.
El error humano bajo presión (y cómo limitarlo)
En incidentes así, algunos equipos, con la presión de “levantar”, acaban abriendo Security Groups, desactivando WAF o ampliando permisos IAM “temporalmente”. Es comprensible; también peligroso: rompe defensas y deja la app vulnerable. La salida debe estar preparada antes: runbooks claros, toggles de modo degradado y guardrails que impidan “arreglos” que abren agujeros.
¿Por qué no había Plan B? (y cómo construirlo sin duplicar tu factura)
Tres razones se repiten: no se incentiva, parece caro y da pereza técnica. El negocio premia lanzar rápido, se confía en que “esto no me pasará” y se asume que el SLA cubrirá el daño (no lo hará: compensa servicio, no negocio). La alternativa a la reacción improvisada es diseñar resiliencia desde el primer día.
A continuación, un plan pragmático por capas para resistir la próxima:
1) Arquitectura (disponibilidad y datos)
- Multi-AZ como base (varias zonas dentro de la misma región) y Multi-Región donde el negocio lo exija. Define RTO/RPO realistas y diseña para ellos.
- Datos:
- Lectura pesada / Escritura moderada → replicación asíncrona multirregión (aceptas RPO>0).
- RPO≈0 / RTO bajo → replicación síncrona para el core (acotando qué es “core” para no disparar latencias/costes).
- Identidad: copia catálogos y metadatos OIDC/JWKS con cache y TTL razonables; contempla modo local para validar tokens si el emisor se degrada.
2) Red y entrega (DNS, CDN, balanceo)
- DNS con health checks orientados a servicio (no solo TCP/443) y failover definido.
- CDN con orígenes alternativos y grace en caché; no “pinches” a una sola región.
- Limitadores (rate limits) y back-pressure para evitar auto-DDoS por reintentos.
3) Observabilidad y acceso
- Logs y métricas enviados en paralelo a otra región o proveedor (y retenidos).
- SIEM/SOAR con salida de emergencia fuera del dominio de fallo.
- Break-glass accounts con MFA offline (YubiKey, TOTP en bóveda) y runbooks de acceso.
4) Seguridad por diseño (no reactiva)
- Guardrails: service control policies, IAM mínimo necesario, infra-as-code revisada, plantillas “seguras por defecto”.
- WAF/WAF-CDN con reglas modulables (endurecer/desendurecer por flag), nunca “todo o nada”.
- Segregación de cuentas y entornos (prod/stage/dev) para que un fallo o “fix rápido” no contamine el resto.
5) Operación durante el incidente (playbook corto)
- Congela deploys y cambios de red.
- Activa modo degradado (lectura-only donde aplique, stale cache, desactivar cargas pesadas).
- Aplica backoff con jitter e idempotencia en reintentos; toca límite de concurrencia si las colas crecen.
- Mantén un war room único, status page honesta y mensajes claros en la app.
6) Ensayo general (lo que diferencia un plan de un deseo)
- Gamedays trimestrales: simula caída de identidad, latencia de S3/DNS, throttling de colas, failover de región.
- Mide p95/p99, tiempos de recuperación, cuellos de botella y “trampas” de permisos. Ajusta SLOs y alertas.
RTO/RPO: números que mandan sobre arquitectura y presupuesto
RTO (Recovery Time Objective) es el tiempo máximo que puedes estar caído; RPO (Recovery Point Objective) es la cantidad de datos (en tiempo) que puedes perder al recuperar. Si el negocio no tolera minutos ni pérdida de datos, necesitas dos sistemas capaces de seguir sin depender uno del otro, y probarlos. Si el negocio tolera RTO 15–30 min / RPO 5–15 min, puedes optar por asíncrono multirregión, hot-standby y reprovisión rápida. En ambos casos, el presupuesto debe reflejar esos objetivos: la continuidad se presupuesta, no se desea.
Buenas prácticas que marcan la diferencia en una caída
- Corta bien: usa circuit breakers por dependencia (latencia/error). Decide qué se desactiva y qué se mantiene antes del incidente.
- Evita arreglos peligrosos: no abras SG ni quites WAF “por un rato”. Usa feature flags y toggles de modo degradado preparados.
- Separa identidad y telemetría: que tu SSO y tus dashboards no caigan con la app.
- Cuida el DNS: es la primera impresión en cualquier failover. Si falla, nadie verá tus arreglos.
- Comunica: decir qué pasa y cuándo actualizas baja presión interna y ansiedad del cliente.
Preguntas frecuentes
¿Por qué una app “no alojada” en AWS también cayó?
Porque suele depender de piezas que sí viven en AWS (identidad, CDN, DNS, pagos, logging…). La cadena se rompe por el proveedor común.
¿Multi-AZ no bastaba para evitar el corte?
Multi-AZ protege de fallos de instalación dentro de una región. Incidencias como la de US-EAST-1 pueden afectar planos de control regionales, por lo que hace falta multi-región para aislarse de verdad.
¿El SLA de AWS cubre mis pérdidas de negocio?
No. El SLA ofrece créditos sobre servicio, no compensa ingresos perdidos ni daño reputacional. La única cobertura real es tu propia resiliencia.
¿Cómo empiezo a montar un Plan B sin duplicar costes?
Prioriza por RTO/RPO: saca observabilidad e identidad fuera de la zona de fallo, pon DNS/CDN con orígenes alternativos, mueve datos críticos a replicación multirregión y prepara runbooks y gamedays. Añade modo degradado y circuit breakers. Paso a paso, con métrica y retorno.
En síntesis: la caída de AWS no es un “caso raro”: es un evento de referencia para evaluar dependencias y resiliencia. Quien tenga multi-región real, telemetría fuera de la zona de fallo y runbooks practicados, sufrirá menos y volverá antes. Quien concentre todo en un único punto aprenderá la lección de la forma más cara: apagón, presión y pérdida. Diseñar para fallar siempre es más barato que explicar por qué tu servicio desapareció.
vía: pandasecurity
