El apagón de AWS y el papel del load balancing
Cómo se distribuyen las solicitudes, qué comprueban los health checks y por qué varios servidores pueden seguir compartiendo un único punto de fallo.
en este artículo
Una aplicación puede tener varios servidores y seguir siendo vulnerable a un solo fallo. Si todos dependen del mismo servicio para resolver direcciones, crear capacidad o recibir tráfico, esa dependencia limita la recuperación.
El apagón
En octubre de 2025 falló el DNS de DynamoDB en us-east-1. La recuperación de EC2 acumuló demoras de red. Después, los health checks de NLB retiraron capacidad sana del servicio. El informe de AWS describe esa secuencia.
La distinción importa. La versión inicial de este artículo atribuía el inicio del fallo a la supervisión de los balanceadores. El informe posterior permite corregir esa explicación.
Para entender el papel del balanceo en esa cadena, conviene empezar por lo que hace en una aplicación común.
¿Qué es load balancing?
Imagina un restaurante con una sola caja. Si llegan 50 personas a la vez, se forma una fila. Abrir más cajas permite repartir el trabajo, siempre que alguien organice la distribución.
El load balancing, o balanceo de carga, distribuye tráfico entre servidores. En una aplicación web, el balanceador recibe solicitudes y elige un destino entre los disponibles. La distribución reduce la concentración de trabajo en una máquina, pero no crea capacidad ilimitada.
Cómo funciona
Una solicitud puede seguir este recorrido:
[Usuario] → [Load balancer] → [Servidor 1]
→ [Servidor 2]
→ [Servidor 3]
→ [Servidor 4]
La aplicación debe admitir esa distribución. Si la sesión existe solo en la memoria de un servidor, la siguiente solicitud enviada a otro podría no encontrarla. Decidir dónde guardar el estado forma parte de la arquitectura.
Estrategias de distribución
Round robin alterna destinos en secuencia. Least connections prefiere el servidor con menos conexiones activas. La elección depende del tráfico. Una conexión larga no representa el mismo trabajo que una respuesta corta.
Los pesos permiten enviar proporciones distintas a servidores con capacidades diferentes. Algunas estrategias usan la dirección IP del cliente para mantener afinidad con un destino. El enrutamiento geográfico toma otra decisión, elegir la región que recibe el tráfico. Las opciones disponibles dependen del balanceador.
Health checks
Los health checks comprueban periódicamente criterios definidos. En Application Load Balancer de AWS, los intervalos y umbrales de éxitos o fallos determinan cambios de estado. La retirada no es instantánea. Consulta la documentación de health checks.
También importa qué comprueba el test. Un endpoint que siempre responde con éxito puede ignorar un proceso incapaz de atender pedidos. En el extremo opuesto, exigir que funcione cada servicio externo puede retirar servidores que todavía realizan parte del trabajo.
¿Por qué usar un balanceador?
Permite añadir servidores y distribuir solicitudes nuevas entre ellos. También ayuda con el mantenimiento. Puedes dejar de enviar solicitudes nuevas a un destino y esperar a que termine el trabajo en curso antes de apagarlo.
Si un servidor falla, los demás pueden recibir solicitudes nuevas. Necesitan capacidad disponible. Si cuatro máquinas ya operan al límite, perder una aumenta la presión sobre las restantes.
La distribución tampoco transfiere automáticamente una operación que ya estaba en curso. La aplicación debe definir qué ve el usuario y si se puede reintentar sin duplicar efectos.
El efecto dominó
Los cuatro servidores del diagrama pueden esconder una única base de datos, una sola cola o una configuración compartida. Repetir los servidores no duplica esas dependencias.
Nuestra recomendación operativa es probar la recuperación con una dependencia indisponible. Crear más instancias durante un fallo solo ayuda si también funciona el camino de creación. Enviar todo a los destinos restantes exige saber cuánto trabajo soportan.
Qué probar en tu aplicación
Retira un servidor del servicio en un entorno controlado y observa las solicitudes en curso. Comprueba después si los destinos restantes soportan la carga y cuánto tarda la supervisión en detectar el cambio.
Prueba también una dependencia lenta. Registra cuándo deja de esperar la aplicación, cuántos reintentos hace y cómo impide que esas repeticiones aumenten la cola sin límite.
El balanceador resuelve la distribución del tráfico. La disponibilidad depende también de esas decisiones. Habla con Tucupy si necesitas revisar cómo responde tu sistema ante los fallos.
Texto revisado el 12 de septiembre de 2026 para corregir la explicación del incidente.