El 29 de octubre de 2025, Microsoft Azure experimentó una interrupción global en Azure Front Door (AFD) causada por un cambio de configuración que afectó a la distribución de configuración desde su plano de control.
Un cambio de configuración inadvertido provocó que numerosos edge nodes no pudieran aplicar la nueva configuración, afectando de forma generalizada la operación global.
La modificación provocó que los nodos no pudiesen cargar la nueva configuración distribuida, lo que resultó en un estado inconsistente y fallos funcionales críticos (enrutamiento, terminación TLS y degradación puntual en autenticación, reportada por algunos clientes que usan Entra ID).
Cronología operacional (hechos verificados)
- ≈15:45–16:00 UTC (29 cctubre 2025): Observatorios externos (ThousandEyes, Downdetector) reportaron latencias, timeouts y errores en servicios frontados por AFD
- 17:26 UTC: Microsoft registra que el Azure Portal “fell away from Azure Front Door” y bloquea nuevos cambios para contener el impacto.
- 17:40 UTC: Se inicia despliegue de la configuración “last known good”.
- ≈18:30 UTC – 00:05 UTC (30 de octubre): Despliegue global del fix y recuperación progresiva, según el historial de estado de Azure y observadores externos.
Qué es Azure Front Door y por qué su fallo impactó tanto
Azure Front Door es un servicio global que combina edge routing, WAF, CDN y terminación TLS para aplicaciones públicas y privadas. Actúa como plano de entrega (ingress) global: las rutas, certificados y reglas WAF se gestionan desde un control plane que empuja configuración a una flota global de edge nodes. Por su naturaleza, cualquier problema en el pipeline de configuración o en el control plane puede afectar simultáneamente a productos internos y a clientes que usan AFD como fronting.
Causa raíz técnica: el significado del “inadvertent tenant configuration change”
- Trigger: Un commit/configuración aplicada al tenant de AFD contenía parámetros que, en la agregación o despliegue, resultaron inválidos o produjeron condiciones no manejadas por los checks automáticos.
- Efecto en control plane: La orquestación inició un despliegue global; al encontrar configuraciones no aplicables, algunos edge nodes no completaron correctamente la actualización, quedando en estado inconsistente.
- Manifestación externa: Desde la perspectiva del cliente final el síntoma fue variado: timeouts HTTP(S), errores TLS/handshake, fallos de autenticación y peticiones que “resuelven” DNS pero no obtienen respuesta útil (por tanto, se observó “aparente” problema de resolución aunque el origen fuera el enrutamiento/edge).
Conclusión técnica: según análisis técnicos externos, el evento refleja un fallo en pipelines de despliegue del control plane donde la validación previa fue insuficiente y los mecanismos de canary/gating no limitaron el impacto.
Mecanismo de propagación: un mapa paso a paso
- Commit/Push de configuración en el control plane AFD.
- Despliegue automático: propagación hacia miles de edge nodes (modelo push).
- Cheques insuficientes: validaciones automáticas no detectan la inconsistencia o lo hacen demasiado tarde.
- Edge nodes que no aplicaron la configuración correctamente dejaron de servir rutas, no realizaron terminación TLS o devolvieron errores 5xx/timeouts.
- Impacto a servicios dependientes: Microsoft 365, Xbox y otras aplicaciones que usan AFD experimentaron fallos funcionales; algunos usuarios también reportaron incidencias en autenticación (Entra ID), sin confirmación oficial
- Respuesta: bloqueo de cambios, rollback a “last known good”, push del fix y recuperación node-by-node.
Análisis técnico de los controles que fallaron
- Aislamiento Canary insuficiente: Los despliegues no aplicaron gating progresivo con métricas de salud exigentes (p. ej. tasa de conexión TLS exitosa, éxito en token retrieval contra Entra ID).
- Validators semánticos incompletos: Faltó validación que modele combinaciones de SNI + certificados + rutas custom domains, capaces de detectar escenarios de incompatibilidad.
- Telemetry/observability inadecuada para el plano de entrega: Muchas organizaciones monitorizan el endpoint público, pero no la integridad del pipeline de despliegue del proveedor; esto retrasó la detección temprana del root cause.
- Política de cambios tardía: El bloqueo de cambios se aplicó tras la propagación; una política más restrictiva (o gates automáticos) podría haber reducido el blast radius.
Impacto técnico por componente (qué falló y por qué importa)
- Control Plane AFD: Orquestación de cambios; su fallo amplifica el impacto global. Edge Nodes / CDN: puntos de terminación TLS y balanceo — si no cargan la configuración, interrumpen la entrega de tráfico.
- Servicios que dependen de autenticación (incluidos aquellos basados en Entra ID) mostraron fallos y latencias, según reportes de usuarios y análisis externos, aunque Microsoft no confirmó afectación directa.
- Aplicaciones dependientes (Microsoft 365, Xbox, clientes): pérdida de continuidad funcional y sesiones, con impacto directo en usuarios finales y operaciones comerciales.
Recomendaciones técnicas detalladas (implantables por una consultora)
Controles de despliegue (control plane)
- Implementar canary progressive deployment con gating por métricas reales: TLS handshake success rate, Entra ID token retrieval success, 5xx/4xx ratios y latencias P95.
- Añadir validators semánticos en CI/CD que simulen combinaciones SNI+certificados+routes y fallen el CI si hay inconsistencias.
- Definir blast radius limits: por ejemplo, máximo 5% de la flota edge en primera fase, con rollback automatizado si se exceden thresholds.
Observabilidad y pruebas externas
- Configurar synthetic transactions desde múltiples geolocalizaciones y resolvers independientes; comprobar no solo latencia, sino flujo completo (TLS + token retrieval + request→origin).
- Mantener un dashboard de salud independiente del proveedor que combine synthetics, RUM y telemetría server-side.
Estrategias de fallback / arquitectura
- Tener fallback edge (otro CDN/edge propio o de terceros) que pueda ser activado por DNS o por conmutación a nivel de BGP/Anycast si AFD falla.
- Evitar que la finalización TLS + lógica crítica de autenticación residan exclusivamente en el proveedor sin opciones alternativas.
- Establecer TTL DNS bajos y procedimientos para conmutación rápida cuando sea viable.
Operaciones y gobernanza
- Runbooks claros: Bloqueo de cambios, activación de last-known-good, rollback y comunicación con clientes.
- Simulacros periódicos: Cut-the-wire tests en entornos no productivos que validen failover del plano de entrega.
- Revisar contratos y SLAs: Exigir transparencia en los procesos de despliegue y notificaciones de cambios que afecten control plane.
Playbook de respuesta (resumen operativo rápido)
- Detección (0–5 min): Synthetic probes alertan; activar on-call SRE.
- Contención (5–30 min): Bloquear despliegues; desviar tráfico a fallback/otro CDN si existe.
- Mitigación (30–120 min): Rollback a last-known-good; activar circuit breakers en llamadas dependientes.
- Recuperación (2–12 h): Push del fix y recuperación por zonas; comprobar TLS, token flows y SLOs.
- Post-mortem (24–72 h): RCA con artifacts CI/CD y remediaciones (validators, canaries, etc.).
Comparativa técnica con el incidente de AWS (20-10-2015)
Origen y vector primario
- Azure (AFD, 29 octubre): Control-plane configuration change que provocó que edge nodes no aplicaran configuración (fallo de despliegue). El vector fue el pipeline de configuración global.
- AWS (DynamoDB, 20-octubre): Un problema en la automatización del DNS interno afectó la resolución de DynamoDB en la región us-east-1, provocando errores intermitentes de conectividad y afectando servicios dependientes, según AWS y Reuters.
Mecanismo de propagación y razón por la que se amplificó
- Azure: Propagación por push desde el control plane hacia una flota global de edge nodes; el blast radius depende de la política de despliegue. Si las validaciones fallan, muchos edges resultan afectados simultáneamente.
- AWS: Propagación por dependencias lógicas internas (p. ej. DynamoDB como servicio transversal); el blast se amplificó por el uso intensivo de ese servicio como backend de múltiples sistemas y la falla en los mecanismos automatizados de reparación.
Observabilidad crítica
- Azure/AFD: Monitorizar TLS handshakes, SNI, token retrieval (Entra ID), estado de aplicación de configuraciones en edge y métricas de success rate post-deploy.
- AWS/DynamoDB: Monitorizar latencias y errores del servicio database, resoluciones DNS a nivel interno/externo y health probes de los NLB/EC2 que soportan endpoints críticos.
Diferencias en mitigación y arquitectura de defensa
- Azure necesita reforzar: Validación del control plane, canary deployments de configuración y fallback en el plano de entrega (edge).
- AWS requiere: Separación de dependencias críticas (replicación/redistribución de servicios como DynamoDB), redundancia regional y mecanismos para proteger automatizaciones de DNS/infra-management.
Convergencia de lecciones — aquello que ambos fallos confirman
- No existe sustituto para la observabilidad independiente del proveedor.
- Resiliencia = arquitectura + gobernanza: controles de cambio, validaciones y drills son tan importantes como la replicación de datos.
- Diseñar para degradación controlada (bulkheads, queues, caches) es esencial independientemente del proveedor.
Checklist operativo para implementación inmediata
- (P1) Detectar qué apps usan AFD y clasificarlas por criticidad.
- (P1) Synthetic tests: Añadir probes TLS + token retrieval en 3 regiones.
- (P2) Canary gating: Limitar despliegues en AFD al 5% inicial con rollback automático.
- (P2) Fallback CDN/edge: Preparar activación por DNS/Anycast.
- (P3) Validators CI: Linting semántico para combos SNI+cert+route.
- (P3) Cut-the-wire DR drills: Validar failover del plano de entrega en entornos staging.
- (P4) Revisar SLAs/contratos: Cláusulas de transparencia y notificación de cambios.
