Qué hacer si cae tu proveedor cloud: guía de contingencia (con el caso AWS 2025)
Cómo prepararte y reaccionar cuando falla AWS, Azure o Google Cloud: qué medidas reducen el impacto, qué hacer durante la caída y qué aprender del apagón de AWS de octubre de 2025.
Elaborado con apoyo de IA y revisado manualmente antes de publicarse — más en nuestro proceso editorial.
El apagón de AWS que lo puso en evidencia
El 20 de octubre de 2025, un fallo de resolución DNS en la región us-east-1 de AWS —relacionado con el endpoint de la API de DynamoDB— tumbó durante varias horas una parte enorme de internet. Según distintos análisis del incidente, afectó a más de 3.500 empresas en más de 60 países, y arrastró consigo a aplicaciones tan dispares como Snapchat, Fortnite, Duolingo, Signal, timbres Ring y varias apps bancarias. El servicio no se restableció del todo hasta las 18:01 hora del Este (22:01 UTC). No fue un fallo exótico: fue un recordatorio de que us-east-1 concentra tanta infraestructura de AWS que un fallo ahí se convierte en un fallo de internet en general.
Por qué "está en la nube" no significa "no puede caerse"
Un error habitual es asumir que delegar la infraestructura en AWS, Azure o Google Cloud elimina el riesgo de caída. En realidad lo traslada: sigues expuesto, solo que a una caída que no controlas y de la que te enteras al mismo tiempo que tus usuarios. La pregunta correcta no es "puede caerse mi proveedor" —puede, y lo hará en algún momento— sino cuánto tiempo tardas en darte cuenta, reaccionar y minimizar el daño. Eso es lo que decide la diferencia entre una incidencia de 10 minutos y una de varias horas.
Antes de la caída: lo que se prepara con calma, no en caliente
La contingencia se construye cuando todo funciona, no durante el incidente. Los puntos que marcan más diferencia: backups verificados —no solo configurados— en otra región o proveedor; un plan de recuperación documentado y accesible sin depender de la propia infraestructura caída; DNS con TTL bajo y una ruta de failover ya probada; y monitorización con alertas que no dependan exclusivamente del proveedor que podría fallar. Si tu sistema de alertas vive en la misma nube que se ha caído, es posible que ni te enteres a tiempo.
Durante la caída: qué hacer en la primera hora
Primero, confirma que el problema es del proveedor y no tuyo: consulta su status page oficial y, si la tienes, tu propia status page alojada fuera de esa infraestructura. Segundo, activa la comunicación a clientes cuanto antes con una plantilla ya preparada — el silencio durante una caída genera más quejas que la caída en sí. Tercero, ejecuta el failover si tu arquitectura lo permite; si no lo permite, no improvises una migración de emergencia en mitad del incidente: suele generar más problemas de los que resuelve. Cuarto, documenta la cronología mientras ocurre — la necesitarás para el post-mortem y, si aplica, para justificar créditos de servicio ante tu proveedor.
Después de la caída: el post-mortem que sí sirve
Un post-mortem útil no busca culpables, busca huecos concretos en tu contingencia: ¿qué dependencia externa no tenías documentada? ¿Cuánto tardó en dispararse la primera alerta? ¿El plan de comunicación funcionó o se improvisó? Convierte cada hueco en una acción con fecha, no en una nota genérica de "mejorar la resiliencia". Y si la caída te ha costado tiempo de negocio real, revisa el SLA de tu proveedor: la mayoría ofrece créditos de servicio, pero rara vez se aplican automáticamente — hay que reclamarlos.
¿Multi-cloud o multi-región es la solución?
Depende de tu tamaño. Una arquitectura multi-cloud completa (repartir cargas activas entre AWS, Azure y Google Cloud simultáneamente) es cara y compleja de mantener, y solo se justifica para negocios donde cada minuto de caída cuesta mucho dinero. Para la mayoría de empresas, el equilibrio correcto es más modesto: multi-región dentro del mismo proveedor para las cargas críticas, backups verificados fuera de esa infraestructura, y un plan de recuperación que no dependa del proveedor caído para ser consultado. Si tu arquitectura actual ya te preocupa, compara alternativas en nuestra guía de alternativas a AWS y revisa el coste de una migración parcial en nuestra calculadora de coste de migración.
Comprueba tu propia preparación
Usa la herramienta de abajo para evaluar, con las mismas ocho medidas que separan una recuperación rápida de una lenta, cómo de preparada está tu empresa ante la próxima caída — porque habrá una próxima.
¿Estás preparado para una caída de tu proveedor cloud?
Marca las medidas de contingencia que ya tienes implementadas —backups fuera de la región, plan de recuperación, failover de DNS, monitorización independiente— y la herramienta calcula tu porcentaje de preparación y qué te falta antes de la próxima caída.
| Característica | Recuperación rápida | Recuperación lenta |
|---|---|---|
| Backups | Verificados, fuera de la región afectada | Configurados pero nunca probados |
| Plan de recuperación | Documentado, accesible sin el proveedor caído | Existe pero vive en la misma nube caída |
| DNS / failover | TTL bajo, ruta ya configurada | Se configura durante la crisis |
| Alertas | Monitorización externa independiente | Depende del propio proveedor caído |
| Comunicación a clientes | Plantilla lista, primer mensaje en minutos | Se redacta en caliente, tarda horas |
| Tiempo típico de recuperación | Minutos a 1-2 horas | Varias horas, como muchas de las 3.500 empresas afectadas en octubre de 2025 |
Preguntas frecuentes
Un fallo en la resolución DNS del endpoint de la API de DynamoDB en la región us-east-1, provocado por un registro DNS vacío y una actualización de automatización incorrecta. Como muchos otros servicios de AWS dependen de DynamoDB en esa región (incluidas actualizaciones de IAM y tablas globales), el fallo se propagó mucho más allá de la base de datos en sí.
us-east-1 (Norte de Virginia) fue la primera región de AWS y sigue concentrando la mayor cantidad de infraestructura y el precio más competitivo, así que muchas empresas la usan como región única por defecto, sin plantearse una arquitectura multi-región hasta que un incidente como este lo hace evidente.
Para la mayoría de empresas, no. Multi-cloud completo es caro y complejo de mantener. Casi siempre basta con multi-región dentro del mismo proveedor para las cargas críticas, backups verificados fuera de esa región y un plan de recuperación accesible sin depender de la infraestructura caída.
Depende del SLA contratado: los principales proveedores cloud ofrecen créditos de servicio cuando la disponibilidad cae por debajo de un umbral pactado, pero casi nunca se aplican automáticamente — hay que reclamarlos aportando evidencia del impacto, por eso conviene documentar la cronología durante el incidente.
Las medidas más críticas (verificar backups fuera de la región, documentar el plan en un sitio accesible, bajar el TTL del DNS) se pueden implementar en días, no meses. Lo que más tiempo lleva es el primer simulacro real, porque suele revelar huecos que el papel no muestra.