El incidente del 28 de febrero de 2017 en AWS S3 us-east-1 fue provocado por un error humano durante una operación de mantenimiento rutinaria. Un operador ejecutó un comando con un error tipográfico, lo que resultó en la remoción de un número mucho mayor de servidores del subsistema de indexación de S3 de lo previsto. Este subsistema es crítico para la funcionalidad de S3, ya que gestiona los metadatos y la ubicación de los objetos, lo que significa que su degradación impactó directamente en la capacidad de realizar operaciones fundamentales como GET, LIST y PUT.
La propagación del fallo fue masiva debido a la posición de S3 como una dependencia fundamental para cientos de otros servicios de AWS. Servicios como EC2, EBS, Lambda, y muchos otros, utilizan S3 para almacenar logs, configuraciones, imágenes de disco, y datos de usuario. Cuando S3 se degradó, estos servicios no pudieron acceder a sus recursos críticos, lo que llevó a una cascada de fallos en toda la región us-east-1. La reconstrucción del índice de S3 es una operación inherentemente lenta debido a la vastedad de datos que maneja, lo que prolongó la duración del incidente.
Varias salvaguardas fallaron o fueron insuficientes. Primero, la validación del comando de mantenimiento no fue lo suficientemente robusta como para detectar el error tipográfico o para alertar sobre la magnitud del impacto potencial de la operación. Segundo, la arquitectura del subsistema de indexación, aunque distribuida, no pudo absorber la pérdida repentina de tantos nodos sin una degradación crítica. Finalmente, la interdependencia implícita de tantos servicios en S3, especialmente en la región más grande y popular de AWS, reveló una falta de aislamiento o mecanismos de "fail-fast" que pudieran haber contenido el impacto a un subconjunto de servicios o haber permitido una degradación más elegante en lugar de un fallo total para muchos.
Este incidente subrayó la importancia de la resiliencia en las dependencias críticas y la necesidad de una validación rigurosa de los cambios operativos, incluso los que parecen menores. También destacó la fragilidad que puede surgir de la centralización de servicios fundamentales, incluso en arquitecturas distribuidas a gran escala.