Amazon CloudFront y VPC Origins: ¿qué nos enseña el incidente del 16 de julio de 2026?
El 16 de julio de 2026, un incidente de Amazon CloudFront provocó un aumento de los errores HTTP 5xx a nivel mundial. El problema no afectó a todas las distribuciones de CloudFront, sino solo a las que estaban configuradas para usar la función VPC Origins.
La interrupción del servicio duró unas tres horas y media: según las actualizaciones publicadas en elel AWS Health Dashboard, los fallos empezaron a las 00:45 PDT, que son las 09:45 en Italia, mientras que los primeros indicios de recuperación se observaron a las 04:18 PDT, las 13:18 en Italia. El restablecimiento siguió avanzando poco a poco.
Un caso concreto desde el punto de vista técnico, pero importante para entender hasta qué punto la disponibilidad de una aplicación depende no solo del proveedor de la nube, sino también de las decisiones que se toman al diseñar la arquitectura.
¿Qué son los VPC Origins de Amazon CloudFront?
Amazon CloudFront es el servicio CDN de AWS: distribuye contenidos y aplicaciones a través de una red global de puntos de borde, acercando los recursos a los usuarios finales y reduciendo la latencia y la carga en los sistemas de origen.
Con los CloudFront VPC Origins, CloudFront puede conectarse directamente a recursos alojados en subredes privadas de Amazon VPC, como:
- Equilibrador de carga de aplicaciones;
- Equilibrador de carga de red;
- instancias de Amazon EC2.
AWS también admite configuraciones en las que las distribuciones de CloudFront y los orígenes de VPC pertenecen a cuentas de AWS diferentes.
Esta configuración te permite mantener el origen sin exponerlo directamente en Internet y usar CloudFront como único punto de entrada público de la aplicación. Las solicitudes se redirigen desde la infraestructura de borde hacia el origen a través de una conexión privada gestionada por AWS.
La ventaja es importante, sobre todo en cuanto a la seguridad: los equilibradores de carga y los servidores de aplicaciones pueden quedarse en las subredes privadas, lo que reduce la superficie de ataque y simplifica la gestión de los accesos.
Precisamente el componente encargado de gestionar esta conectividad privada se vio implicado en el incidente del 16 de julio.
La cronología del incidente de Amazon CloudFront
AWS ha detectado un aumento de los errores HTTP 5xx en los clientes que usaban CloudFront con VPC Origins.
El primer comunicado público llegó a la 01:44 PDT, las 10:44 en Italia, cuando AWS dijo que había empezado a investigar. En la siguiente actualización, el proveedor aclaró que el problema llevaba ocurriendo desde las 00:45 PDT, las 09:45 en Italia, y que las distribuciones configuradas con otros tipos de origen no se veían afectadas.
Durante la investigación, AWS fue acotando poco a poco el alcance del problema:
- en un primer momento, hacia el subsistema de procesamiento de paquetes que se usa para enrutar las solicitudes desde las ubicaciones periféricas hasta las VPC de los clientes;
- luego, en cuanto a la capacidad de las tablas de enrutamiento que gestiona este subsistema;
- por último, hacia un límite interno de la flota encargada de las conexiones a los VPC privados de origen.
Las primeras medidas de mitigación se pusieron en marcha a las 03:52 PDT, las 12:52 en Italia. AWS observó los primeros indicios de recuperación a las 04:18 PDT, las 13:18 en Italia, y a continuación procedió a restablecer el servicio de forma progresiva.
La causa técnica de los errores 5xx
AWS ha explicado que la causa principal fue una limitación interna de capacidad en la flota que gestiona las conexiones hacia las VPC Origins privadas.
Una vez alcanzado este límite, el sistema encargado de distribuir las configuraciones de enrutamiento a los procesadores de red no ha podido cargar correctamente los datos actualizados.
El resultado fue un problema de enrutamiento: CloudFront seguía recibiendo las solicitudes de los usuarios en sus ubicaciones periféricas, pero algunas de ellas no se podían reenviar correctamente a los recursos privados que había en las VPC de los clientes.
Desde el punto de vista del usuario final, el problema se manifestaba mediante respuestas HTTP de la familia 5xx, que se usan para indicar errores del servidor o la imposibilidad temporal de completar una solicitud.
No ha sido un problema de los los equilibradores de carga de aplicaciones, ni de las instancias EC2 ni de las aplicaciones alojadas en las VPC de los clientes. El fallo se produjo en la capa de conectividad gestionada por AWS entre CloudFront y los orígenes privados.
¿Por qué no se han visto afectadas las demás fuentes de CloudFront?
El problema solo ha afectado a la ruta de red que usan los VPC Origins, sin afectar a las distribuciones configuradas con otros tipos de origen. Por eso, AWS ha podido confirmar desde las primeras actualizaciones que el impacto se limitaba a un ámbito específico.
Durante el problema técnico, se sugirió, siempre que fuera posible, cambiar temporalmente a un origen diferente. Una solución que no siempre es viable, sobre todo en arquitecturas diseñadas para exponer los recursos exclusivamente a través de conexiones privadas.
Esto demuestra lo importante que es conocer no solo los servicios que se utilizan, sino también las rutas de red y las dependencias gestionadas en las que se basa el funcionamiento de la aplicación.
Impacto selectivo y directrices arquitectónicas
A pesar de que se clasificó como «global», el incidente de Amazon CloudFront solo afectó a las distribuciones con VPC Origins: un recordatorio de que el impacto real depende de las dependencias específicas de la carga de trabajo.
Puntos clave
- Dependencias gestionadas: incluso los componentes totalmente gestionados siguen siendo puntos críticos. Hacer un mapa de las dependencias ayuda a aislar rápidamente los problemas.
- Rutas alternativas: evalúa los grupos de origen secundarios o los mecanismos de conmutación por error, como los grupos de origen, evitando dependencias comunes entre el primario y el secundario.
- Procedimientos de emergencia: prepara y prueba con antelación cualquier cambio de origen, prestando especial atención a la seguridad y la automatización.
- Supervisión de extremo a extremo: combinar las métricas internas con controles externos para detectar errores que se producen antes de que las solicitudes lleguen al origen.
La resiliencia en la nube sigue siendo una decisión arquitectónica
AWS ha identificado el problema, ha aplicado varias medidas de mitigación y ha restablecido el servicio. Los clientes que habían cambiado temporalmente el tipo de origen han podido restablecer posteriormente la configuración de VPC Origin.
Sin embargo, el incidente del 16 de julio demuestra una vez más que ningún servicio gestionado puede considerarse totalmente a salvo de fallos.
La cuestión no es eliminar todos los posibles fallos, algo difícil de conseguir en un sistema distribuido, sino diseñar aplicaciones capaces de absorber sus efectos.
Conocer las dependencias, distinguir los verdaderos ámbitos de error, preparar rutas alternativas y comprobar periódicamente los procedimientos de recuperación te permite convertir un incidente del proveedor de una interrupción crítica en un evento manejable.
En la nube, la disponibilidad no depende solo de la fiabilidad de cada servicio. Depende sobre todo de cómo se combinan esos servicios dentro de la arquitectura.