Introducción
A las 01:45 PDT (09:45 UTC) del 16 de julio de 2025, AWS inició una interrupción no programada en CloudFront que afectó a clientes que usaban VPC Origins, una funcionalidad relativamente nueva que permite exponer aplicaciones internas tras load balancers privados a través de CloudFront sin exponer la infraestructura backend directamente a Internet. En lugar de servir contenido, CloudFront comenzó a devolver errores genéricos 5xx, dejando fuera de línea servicios como Hugging Face, la National Lottery del Reino Unido y los servidores de juegos de Bethesda. El incidente duró aproximadamente 1 hora y 23 minutos, tiempo en el que miles de distribuciones quedaron inaccesibles mientras AWS trabajaba en la recuperación.
Lo crítico del caso no fue solo la magnitud del impacto —múltimo reporte de AWS indicó que el 92% de las distribuciones afectadas correspondían a VPC Origins—, sino que el problema se originó en un subsistema interno de procesamiento de paquetes encargado de enrutar solicitudes desde los edge locations de CloudFront hacia los recursos dentro de las VPC privadas de los clientes. Hasta entonces, no había registros públicos de fallos similares en este componente, lo que lo convirtió en un caso de estudio sobre cómo un error de routing en la capa de aplicación puede cascadear hacia la experiencia del usuario final.
Qué ocurrió
AWS confirmó en su AWS Service Health Dashboard que el problema comenzó a las 09:45 UTC y se extendió hasta las 11:08 UTC, momento en que se implementó la mitigación. Según el reporte técnico posterior, la raíz del problema fue un límite interno en la flota de gestión de conexiones a orígenes VPC privados. Cuando este límite se alcanzó, el sistema encargado de distribuir la configuración de routing a los network processors falló al cargar los datos actualizados, lo que afectó directamente el enrutamiento de las conexiones VPC Origin.
El fallo no fue aleatorio: ocurrió bajo condiciones de alta carga en regiones específicas (us-east-1 y eu-west-1, según reportes de usuarios en Reddit), donde el tráfico superó el umbral de conexiones simultáneas que el subsistema podía manejar. Como consecuencia, los network processors no recibieron la configuración actualizada y comenzaron a devolver errores 502 Bad Gateway o 503 Service Unavailable. Los usuarios no vieron errores de CloudFront genéricos, sino mensajes como:
> «No podemos conectarnos al servidor de esta aplicación o sitio web en este momento. Puede que haya demasiado tráfico o un error de configuración. Inténtelo más tarde o contacte al sitio.»
Ejemplo de respuesta afectada (capturada por un usuario en X):
HTTP/1.1 502 Bad Gateway
Content-Type: text/html
Server: CloudFront
<html><body><h1>502 Bad Gateway</h1></body></html>AWS aisló el problema a un solo tipo de configuración (VPC Origins) y aclaró que los clientes con otros tipos de origen (S3, ALB, EC2, etc.) no se vieron afectados. Sin embargo, el impacto en servicios dependientes de CloudFront fue masivo: Hugging Face reportó indisponibilidad global, la National Lottery del Reino Unido admitió la caída de su sitio y app móvil, y jugadores de Fallout 76 reportaron que el juego se volvió inaccesible.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
Para equipos de DevOps e Infraestructura
- Alcance: 92% de las distribuciones afectadas usaban VPC Origins, según datos de AWS. Esto sugiere que muchas organizaciones ya habían migrado sus orígenes privados a CloudFront para aprovechar la capa de caching y seguridad adicional.
- MTTR: La recuperación tomó 1 hora y 23 minutos, un tiempo crítico para servicios con SLA estrictos (ej: APIs de pago, plataformas de IA).
- Regiones afectadas: Principalmente us-east-1 y eu-west-1, con caída intermitente en otras regiones según la carga de tráfico.
- Servicios impactados:
– National Lottery (Reino Unido): Sitio y app móvil inaccesibles para jugadores.
– Bethesda: Servidores de Fallout 76 afectados, generando quejas en Reddit.
– Otros: Empresas con APIs públicas (ej: procesamiento de pagos) vieron errores 5xx en sus endpoints expuestos vía CloudFront.
Para equipos de Seguridad
- Vector de ataque indirecto: Aunque el fallo no fue explotado maliciosamente, la indisponibilidad masiva de servicios expuso a organizaciones a riesgos de «fail-open» donde los equipos de seguridad no pudieron acceder a logs o herramientas basadas en la nube durante el incidente.
- Recomendación inmediata: Validar que los logs de CloudFront estén centralizados en un sistema externo (ej: SIEM) y no dependan de la disponibilidad del servicio.
Métricas clave
| Métrica | Valor |
|---|---|
| Duración del incidente | 1h 23min |
| % distribuciones afectadas (VPC Origins) | 92% |
| Regiones críticas | us-east-1, eu-west-1 |
| Servicios de alto impacto | Hugging Face, National Lottery, Bethesda |
| Tipo de error | 5xx (502/503) |
Componentes afectados
- CloudFront VPC Origins: Funcionalidad introducida en 2023 que permite conectar distribuciones de CloudFront a recursos internos tras un Application Load Balancer (ALB) o Network Load Balancer (NLB) privado. Requiere configurar:
– Un ALB/NLB interno con reglas de routing hacia los backends.
– Una distribución de CloudFront con origen tipo Custom Origin apuntando a la IP del VPC Endpoint.
- Subsistema de routing: Componente interno de CloudFront responsable de:
– Enrutarlas al VPC Endpoint correspondiente.
– Gestionar la configuración de routing en los network processors.
- Falla crítica: Según el reporte de AWS, cuando el límite de conexiones simultáneas a VPC Origins se alcanzó, el sistema falló al cargar la configuración actualizada en los network processors, lo que provocó que estos devolvieran errores 5xx.
Comandos de verificación inmediata
Para confirmar si una distribución está afectada, los equipos pueden usar la AWS CLI:
# Listar distribuciones con origen VPC Origin
aws cloudfront list-distributions --query "DistributionList.Items[?Origins.Items[?OriginPath==''].DomainName].Id" --output text
# Verificar errores 5xx en logs de CloudFront
aws logs start-query \
--log-group-name "/aws/cloudfront/${DISTRIBUTION_ID}" \
--start-time $(date -d "1 hour ago" +%s%3N) \
--end-time $(date +%s%3N) \
--query-string "filter @message like /5[0-9]{2}/ | stats count(*) by bin(5m)"¿Por qué no afectó a otros tipos de origen?
- S3/ALB/EC2: Estos orígenes no dependen del subsistema de VPC Origins. S3 usa endpoints públicos, ALB puede estar público o privado pero no requiere VPC Endpoint, y EC2 puede exponerse directamente.
- CloudFront Functions/Lambdas@Edge: Aunque usan CloudFront, no dependen del routing a VPC Origins, por lo que no se vieron afectadas.
Qué deberían hacer los administradores y equipos técnicos
Acciones inmediatas (durante el incidente)
- Cambiar temporalmente el tipo de origen (si es posible):
– Ejemplo de cambio en Terraform:
resource "aws_cloudfront_distribution" "example" {
origin {
domain_name = "mi-alb-publico-123456789.us-east-1.elb.amazonaws.com"
origin_id = "alb-publico"
# Cambiar de VPC Origin a Custom Origin
}
}
– Nota: Este cambio requiere actualizar la configuración DNS y puede tardar minutos en propagarse.
- Monitorear métricas de CloudFront:
– 5xxErrorRate (debe estar en 0%).
– RequestCount (debe ser estable).
– Latency (debe ser < 200ms en condiciones normales).
aws cloudwatch get-metric-statistics \
--namespace AWS/CloudFront \
--metric-name 5xxErrorRate \
--dimensions Name=DistributionId,Value=${DISTRIBUTION_ID} \
--start-time $(date -d "5 minutes ago" +%Y-%m-%dT%H:%M:%SZ) \
--end-time $(date +%Y-%m-%dT%H:%M:%SZ) \
--period 60 \
--statistics Average
- Validar dependencias:
– Revisar CloudFront Functions/Lambdas@Edge para descartar conflictos.
Acciones post-incidente
- Revisar límites de conexiones:
– ActiveConnectionCount en CloudWatch.
– ConcurrentConnections en el VPC Endpoint.
– Si el límite se acerca, escalar con AWS Support o ajustar configuraciones de keep-alive.
- Automatizar failover:
resource "aws_route53_record" "failover" {
zone_id = aws_route53_zone.example.zone_id
name = "mi-sitio.example.com"
type = "A"
alias {
name = aws_cloudfront_distribution.example.domain_name
zone_id = aws_cloudfront_distribution.example.hosted_zone_id
evaluate_target_health = true
}
failover_routing_policy {
type = "PRIMARY"
}
set_identifier = "cloudfront-primary"
}
- Documentar el incidente:
– Hora de inicio/fin del incidente.
– Regiones afectadas.
– Servicios impactados y métricas clave.
– Pasos de mitigación aplicados.
Recomendaciones a largo plazo
- Diversificar orígenes: No depender de un solo tipo de origen en CloudFront. Mantener al menos un origen secundario (ej: S3 + CloudFront) como respaldo.
- Monitoreo proactivo:
5xxErrorRate > 0.1%.– Usar AWS X-Ray para rastrear solicitudes desde el edge hasta el backend.
- Pruebas de fallas:
Conclusión
El incidente del 16 de julio de 2025 en AWS CloudFront VPC Origins expuso una debilidad crítica en el subsistema de routing interno de CloudFront: un límite de conexiones no documentado que, al alcanzarse, impidió la carga de configuraciones de routing en los network processors, generando errores 5xx masivos. Aunque AWS resolvió el problema en 1h 23min, el impacto en servicios globales como Hugging Face y la National Lottery demostró la fragilidad de depender de configuraciones complejas en la nube sin planes de contingencia claros.
Para equipos de DevOps e Infraestructura, este evento refuerza la importancia de:
- Diversificar orígenes en CloudFront (evitar depender al 100% de VPC Origins).
- Automatizar failovers a orígenes secundarios ante fallos.
- Monitorear proactivamente métricas de routing y conexiones activas.
El caso también sirve como recordatorio para que los equipos de seguridad validen que sus logs y herramientas de monitoreo no dependan de la disponibilidad de los servicios afectados, ya que un fallo en la capa de aplicación puede dejar ciegas a las defensas.
Fuentes
- The Register: AWS CloudFront outage serves errors instead of websites
- AWS Service Health Dashboard – July 16, 2025
- AWS Documentation: VPC Origins for CloudFront
- Reddit: Fallout 76 outage reports