Resumen

  • Un cambio de capacidad desvió tráfico de EBS hacia una red de replicación de menor capacidad; al volver la conectividad, las búsquedas simultáneas de réplicas agotaron el margen libre y generaron una tormenta de resincronización.
  • La lección de responsabilidad no es atribuir culpa sin pruebas, sino exigir que la recuperación tenga un límite operativo medible: reserva suficiente, retroceso de solicitudes, aislamiento, visibilidad y criterios verificables de cierre.

El alcance correcto del incidente

La interrupción comenzó el 21 de abril de 2011 en una zona de disponibilidad de la región US East de AWS. Según el informe posterior del operador, EBS organizaba entonces el almacenamiento en clústeres contenidos dentro de una zona de disponibilidad. Los nodos mantenían copias mediante una red primaria de gran ancho de banda y una red de replicación secundaria de menor capacidad, mientras un plano de control regional coordinaba operaciones como la creación de volúmenes.

Esa descripción importa porque fija dos límites. Primero, se trata de la arquitectura divulgada para 2011, no de una afirmación sobre la arquitectura actual de AWS. Segundo, el núcleo del fallo de almacenamiento estuvo concentrado en una zona de disponibilidad, aunque durante periodos acotados hubo errores y latencia de la API de EBS en otras partes de la región. La evidencia no permite llamarlo una caída global de AWS ni una indisponibilidad uniforme de todos los volúmenes de US East.

Del cambio de red al aislamiento

A las 12:47 a. m. PDT del 21 de abril, durante una modificación de capacidad en la red primaria, el tráfico se desplazó de manera incorrecta hacia la red de replicación. Esa ruta secundaria no estaba dimensionada para absorber la carga desviada. Muchos nodos de EBS quedaron sin conectividad efectiva ni por el camino primario ni por el secundario.

El cambio de red fue el desencadenante, pero no explica por sí solo la duración ni la amplitud de la degradación. Un análisis responsable distingue tres capas. El desencadenante fue el desvío incorrecto de tráfico. La condición inmediata fue el aislamiento de nodos. La dinámica sistémica apareció después, cuando el mecanismo protector de replicación intentó restablecer simultáneamente demasiadas copias con recursos insuficientes.

Cuando se recuperó la conectividad, numerosos nodos buscaron una nueva réplica al mismo tiempo. Las solicitudes consumieron rápidamente la capacidad libre. Un retroceso insuficiente y una condición de carrera de baja probabilidad intensificaron el proceso. En lugar de converger con calma, el sistema entró en una tormenta de re-mirroring: cada intento de restaurar redundancia competía por el mismo margen que necesitaban otros intentos para terminar.

Esta es la paradoja central del incidente. La replicación no era el problema en abstracto; era una defensa necesaria. El riesgo surgió porque la recuperación masiva carecía de un sobre operativo suficientemente acotado. Una defensa que funciona bien ante fallos aislados puede comportarse como multiplicador de carga cuando muchos componentes se recuperan a la vez.

La propagación al plano de control

La presión no quedó confinada al movimiento de datos. Las llamadas prolongadas de creación de volúmenes ocuparon un conjunto de hilos del plano de control regional. Al agotarse esos hilos, clientes fuera de la zona directamente afectada también observaron errores y latencia en la API de EBS. AWS aisló después el clúster degradado y aplicó limitación de carga para reducir esa propagación.

Aquí conviene separar dependencia de identidad causal. El fallo físico o lógico del almacenamiento afectó directamente a una zona; la escasez de hilos en un servicio regional transmitió efectos de control más allá de esa frontera. No todos los usuarios ni todos los servicios experimentaron el mismo mecanismo, la misma duración o el mismo resultado. La extensión regional de algunos errores de API no convierte el evento en un fallo regional uniforme de volúmenes.

La recuperación requirió añadir capacidad física, restaurar réplicas por etapas, procesar colas atrasadas y atender manualmente casos residuales. Son hitos diferentes. Detener una nueva degradación no equivale a recuperar todas las réplicas; restaurar la API no equivale a resolver todos los volúmenes; y recuperar un volumen no demuestra por sí solo que su estado sea consistente.

Impacto medido y límites de los porcentajes

AWS informó de que, una vez estabilizado el clúster, aproximadamente el 13% de los volúmenes de la zona de disponibilidad afectada permanecían atascados. El denominador es esencial: no era el 13% de los clientes, de toda la región US East ni de todos los volúmenes de AWS. La restauración de réplicas, el vaciado de colas y la recuperación manual continuaron durante varios días.

El operador comunicó además que el 0,07% de los volúmenes de esa zona no pudo restaurarse en un estado consistente. Este porcentaje tiene el mismo límite geográfico, pero describe un resultado distinto del 13%. No debe convertirse en una estimación de bytes, registros, clientes o pérdidas económicas. El conjunto de fuentes no proporciona ninguna de esas magnitudes.

La distinción protege tanto al público como al operador frente a dos exageraciones opuestas. No permite minimizar la pérdida de consistencia como si fuera irrelevante, pero tampoco permite generalizar una fracción zonal a toda la plataforma. La rendición de cuentas comienza con denominadores explícitos y con una cronología que no mezcle contención, disponibilidad funcional y cierre íntegro.

RDS, Heroku y la cadena de dependencia

RDS utilizaba EBS para almacenar bases de datos y registros. AWS explicó que una condición no encontrada anteriormente impidió el failover automático de un subconjunto de instancias Multi-AZ, por lo que fue necesaria intervención manual. Esta observación no significa que todas las instancias Multi-AZ fallaran ni que las poblaciones Single-AZ, Multi-AZ y EBS fueran intercambiables.

La evidencia externa muestra efectos reales aguas abajo sin sustituir al informe interno. Heroku describió directamente una interrupción generalizada de aplicaciones en su plataforma. La cobertura contemporánea mencionó servicios públicos afectados y dificultades relacionadas con RDS. Esos testimonios demuestran dependencia y consecuencias visibles; no prueban que cada servicio compartiera una única ruta de fallo, duración, calidad de recuperación o desenlace de datos.

Esa separación también delimita responsabilidades. AWS controlaba la arquitectura de EBS de 2011, sus redes internas, la reserva de capacidad, los algoritmos de retroceso, el aislamiento del plano de control y los mecanismos de restauración. Los clientes controlaban decisiones de arquitectura de aplicación, copias, tolerancia a fallos y procedimientos de continuidad dentro de las opciones disponibles.

Pero la existencia de opciones para el cliente no desplaza al usuario la responsabilidad sobre controles internos que solo el proveedor podía observar y modificar. Tampoco puede afirmarse que una arquitectura Multi-AZ o multirregión elimine todos los efectos de plano de control o de aplicación.

Medidas anunciadas y evidencia pendiente

AWS anunció varias correcciones: mayores reservas de capacidad para recuperación, retroceso más agresivo, reparación de la condición de carrera, mejores tiempos de espera y descarga de carga, aislamiento zonal más fuerte, automatización de controles de recuperación, mejoras en herramientas Multi-AZ y comunicaciones más frecuentes.

Estas medidas responden de forma coherente a la cadena causal descrita. Sin embargo, el registro público analizado solo acredita que fueron anunciadas. No verifica de manera independiente su implementación, su eficacia posterior ni su vigencia actual. Esa diferencia entre promesa, ejecución y prueba es parte del problema de responsabilidad, no una nota secundaria.

Una conclusión prudente tampoco identifica a una persona culpable ni establece negligencia, responsabilidad jurídica, infracción contractual o incumplimiento regulatorio. Las fuentes públicas no revelan quién aprobó el cambio, qué información tenía cada decisor ni qué restricciones operativas enfrentaba. Sí permiten identificar la superficie de control institucional: capacidad, aislamiento, retroceso, observabilidad, automatización y comunicación.

Recuperar no es solo volver a encender

El criterio útil que deja el incidente es un «sobre de recuperación» medible. Un proveedor debería poder responder, antes de una crisis, cuántos componentes pueden buscar réplicas simultáneamente, qué reserva existe para completar el proceso, cómo se limita la presión, cuándo se aísla un clúster y qué señales distinguen una copia disponible de una copia consistente.

La capacidad ociosa destinada a recuperación puede parecer ineficiente en condiciones normales. Durante una perturbación correlacionada se convierte en un control de continuidad. El retroceso evita que las solicitudes de reparación compitan hasta bloquearse. El aislamiento impide que un dominio degradado consuma recursos regionales compartidos. Y la visibilidad por recurso permite comunicar a cada cliente el estado de su volumen sin reducir la realidad a un único indicador agregado.

La tormenta de 2011 demuestra que la responsabilidad operativa no empieza con la búsqueda de un culpable después del evento. Empieza al decidir cuánta capacidad reservar, qué límites imponer y qué evidencia conservar. Su prueba final no es que el panel vuelva a verde, sino que el operador pueda demostrar que el sistema dejó de degradarse, recuperó redundancia de forma controlada, cerró los casos residuales y declaró con precisión aquello que no pudo restaurar.

Fuentes