Incluso el servicio Service Health Dashboard se vio afectado por la falla, lo que impidió a Amazon informar sobre el error a sus clientes, según el procedimiento ordinario. La falla se presentó a las 17:45 GMT en el centro de datos US-East-1, desde donde también afectó a otros servicios de AWS, situados en otras partes de su infraestructura.
Los problemas de funcionamiento y conectividad tuvieron una duración de cuatro horas y afectaron a diversos servicios y plataformas, incluidos Docker, Trello, GitHub, Signal, Slack, Expedia, Bitbucket, Flipboard, Tinder, Strava y Yahoo Mail. También los servicios del proveedor IoT Nest presentaron cierta intermitencia.
Aunque se desconoce el número total de clientes de Amazon S3, una lista incompleta y no oficial estimaría el total en 150.000. Diario TI utiliza el servicio S3 mediante el centro datos de AWS en Sao Paulo para presentar material audiovisual de nuestros clientes, especialmente vídeo, a lectores en América Latina.
Según la consultora Gartner, S3 de Amazon es 1,6 veces mayor que todos los demás servicios de almacenamiento de objetos, combinados.
Amazon garantiza en el mejor de los casos una disponibilidad mensual del 99,9% para su servicio S3. Esto implica que en un período de 30 días S3 puede estar caído durante aproximadamente 43 minutos, sin que Amazon esté obligada a pagar compensación alguna a sus clientes.
Aunque un gran número de clientes se ven afectados cada vez que ocurre un error en los servicios de Amazon, por infrecuentes que éstos sean, no puede darse por descontado que el tiempo de caída tota de los servicios afectados habría sido inferior si éstos hubiesen estado distribuidos entre varios proveedores de nube pública.
Una medida que indudablemente ayudaría es que los clientes tengan la posibilidad de recurrir a soluciones de reserva, contratadas a otros proveedores, al menos para sus servicios de misión crítica. Con todo, muchas empresas llegan a la conclusión de que es más costo-eficaz experimentar una caída de 43 minutos mensuales como máximo, que pagar por redundancia.
En comunicación con Diario TI, Puneet Chawla, Chief Technology Officer y cofundador del proveedor DaaS Workspot, se refirió al apagón de S3 señalando:
“Es muy sencillo, los proveedores SaaS deben asumir que la infraestructura Cloud se caerá unas cuantas veces al año. Los servicios nativos de la nube deben agregar disponibilidad multi zona, y además replicación multirregional si quieren conmutar sus servicios sin interrupciones en caso de tales caídas. En Workspot hemos dedicado los últimos cuatro años a asegurarnos de que nuestro servicio es agnóstico en cuanto a la región y la nube, lo que nos permite cambiarnos de lugar cuando ocurre un desastre”.
Por su parte, James Sivis, vicepresidente de Nerdio, proveedor ITaaS, comentó: “La lección que nos puede dejar este apagón de AWS bien puede ser la habilitación de redundancia para apps de misión crítica a través de múltiples nubes”.
