AWS GovCloud y la nube comercial tras la caída de us-east-1
El lunes, varias partes de internet sufrieron un mal día por culpa de otra caída de AWS. Esta vez le tocó a us-east-1, la región más antigua y conocida de Amazon, que se apagó por momentos. Los servicios se saturaron, las pantallas de inicio de sesión se congelaron y reinó una breve confusión en las aplicaciones y sistemas que dependen de la nube comercial de AWS.
Un grupo de usuarios apenas se inmutó: quienes operan en AWS GovCloud.
Cuando las aguas se calmaron, surgió una intensa conversación entre ingenieros de nube, contratistas del gobierno y curiosos que intentaban entender qué había ocurrido exactamente y por qué los usuarios de GovCloud parecían inmunes al fallo.
¿Qué es exactamente GovCloud?
Primero, un repaso rápido para quien no lo conozca.
AWS GovCloud es la versión aislada y centrada en cumplimiento que Amazon ofrece frente a su nube comercial. Está diseñada para agencias del gobierno de Estados Unidos y contratistas con cargas de trabajo confidenciales que exigen cumplir con normativas como FedRAMP High, ITAR o CJIS, entre otras. Opera en regiones aisladas, us-gov-west-1 y us-gov-east-1, y no comparte infraestructura con el entorno estándar de AWS.
Ese aislamiento demostró ser algo más que una casilla de verificación en una auditoría. Marcó toda la diferencia esta semana.
¿Qué falló en us-east-1?
La región comercial us-east-1, ubicada en el norte de Virginia, ha sido durante años el caballo de batalla de AWS. Es la opción predeterminada para muchos servicios y clientes, y alberga partes del plano de control global de AWS, como IAM (Identity and Access Management). Por eso, cuando tropezó, incluso los servicios alojados en otras regiones sintieron el impacto.
Los usuarios informaron de fallos de acceso, tiempos de espera agotados e interrupciones en cadena en múltiples aplicaciones. GovCloud, que tiene su propio IAM y plano de control en us-gov-west-1, no se vio afectado en absoluto, y el motivo reside en su arquitectura.
Separación física y lógica en GovCloud
Varios profesionales del sector señalaron que GovCloud y la nube comercial de AWS están separadas tanto en la práctica como en la teoría. Son infraestructuras físicamente distintas con planos de control independientes, calendarios de despliegue de software propios y modelos de cumplimiento separados.
Un ingeniero lo resumió de esta manera:
"GovCloud está aislado físicamente de las regiones comerciales como us-east-1, con un plano de control independiente, por lo que no se vio afectado por la cascada de fallos."
Otros añadieron que las particiones de AWS funcionan como si fueran proveedores totalmente distintos. GovCloud no se comunica con las regiones comerciales a menos que un cliente configure túneles VPN o enlaces de red a medida. Incluso los servicios globales de AWS, que en la parte comercial suelen residir en us-east-1, tienen equivalentes independientes en GovCloud, alojados en su propia región "global", habitualmente us-gov-west-1.
Esa división física y lógica está hecha a propósito, y funcionó.
¿Por qué algunos empleados federales tuvieron problemas?
Aunque los servicios centrales de GovCloud se mantuvieron intactos, algunos empleados federales tuvieron dificultades para acceder a aplicaciones o iniciar sesión en plataformas, lo que generó confusión. La respuesta está en los detalles de la arquitectura de despliegue.
No todas las cargas de trabajo del gobierno se ejecutan en GovCloud. Muchas agencias alojan aplicaciones menos críticas en regiones comerciales de AWS para ahorrar dinero y reducir la complejidad. Las cargas con nivel FedRAMP Moderate, por ejemplo, pueden operar legalmente en regiones estándar como us-east-1.
Si una agencia mantenía su servicio de autenticación, parte de su aplicación o un SaaS de terceros en la nube comercial, tuvo problemas cuando us-east-1 cayó.
Un usuario lo explicó así:
"Es posible que algunos empleados federales tuvieran problemas con AWS el lunes, porque no todas las soluciones del gobierno federal en AWS se ejecutan en GovCloud… GovCloud solo debería usarse cuando un requisito específico lo exija; es más caro, requiere más trámites y las funciones tardan más en llegar."
Otro lo resumió con una analogía sobre Netflix:
"Es como decir que Netflix estaba caído cuando el fallo era de tu proveedor de internet local. Netflix no estaba caído, pero para el usuario final la sensación era esa."
¿Una red de seguridad engañosa?
El aislamiento de GovCloud es su gran punto fuerte, pero también una fuente de malentendidos.
Desde el punto de vista puramente de infraestructura, cumplió su cometido manteniéndose activo cuando us-east-1 se cayó. Eso no significa que todas las aplicaciones federales alojadas en AWS estuvieran a salvo. Las dependencias en servicios comerciales, los despliegues híbridos o los proveedores compartidos sin aislamiento provocaron que el efecto dominó alcanzara a los usuarios.
Incluso dentro de GovCloud, las aplicaciones podían fallar si tenían dependencias externas, como una API o un recurso que apuntaba a us-east-1. GovCloud siguió técnicamente operativo, pero según la arquitectura empleada, los usuarios podían tropezar con obstáculos.
Por qué GovCloud nunca será la opción por defecto
Visto el buen rendimiento durante la caída, cabe preguntarse por qué más agencias federales no trasladan todo a GovCloud. La respuesta corta es que resulta caro, recibe funciones con lentitud y añade complejidad.
Los costes más altos y el acceso restringido suponen una barrera importante para agencias pequeñas o cargas menos críticas. Las revisiones de cumplimiento hacen que los nuevos servicios de AWS lleguen tarde a GovCloud, o a veces nunca. Además, solo ciudadanos estadounidenses verificados pueden acceder a él, por lo que gestionar y mantener cargas en GovCloud implica más burocracia.
Por esa razón GovCloud se utiliza de forma selectiva. Las agencias evalúan costes, riesgos y requisitos normativos antes de decidir dónde alojar cada carga de trabajo.
Conclusión: la separación importa, pero la arquitectura también
La caída de us-east-1 puso de relieve la doble identidad de AWS. GovCloud se mantuvo en pie gracias a una partición deliberada, aunque no todos los que se creían a salvo lo estaban en realidad. El aislamiento ayuda, pero el mapa de dependencias pesa todavía más.
Si buscas resiliencia, ya sea en el sector privado o público, confiar ciegamente en que tus servicios centrales están en una región "segura" no basta. Necesitas saber dónde residen tus dependencias, cómo se gestiona tu autenticación y si tus mecanismos de failover funcionan de verdad.
AWS puede ofrecerte las herramientas, pero la resiliencia es responsabilidad tuya.