{"id":"IL-0226","org":"Microsoft Azure","date":"2025-10-29","docs":["https://aka.ms/AzureFrontDoor/Resiliency-Part1","https://aka.ms/air/YKYN-BWZ","http://aka.ms/AFD_FAQ","https://learn.microsoft.com/azure/architecture/guide/networking/global-web-applications/mission-critical-global-http-ingress"],"title":{"en":"Azure Front Door edge servers crashed worldwide on incompatible configuration metadata, causing timeouts and DNS errors","ko":"호환되지 않는 설정 메타데이터가 전 세계로 퍼져 Azure Front Door 와 Azure CDN 엣지 서버가 크래시했다."},"domain":["azure","networking"],"impact":{"scope":"Azure Front Door and Azure CDN and the Azure and Microsoft services behind them, including Azure Portal, App Service, SQL Database, Microsoft 365, Entra ID, Dynamics 365, Power Platform and support case creation","users":"unknown","region":"global"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"Microsoft describes configuration propagation risk as inherent to a global Content Delivery Network, in which route, WAF and origin changes must be deployed quickly worldwide. Both this incident and the 9 October AFD incident came from that risk. This time the incompatible metadata passed a protection system that advances only on healthy data plane signals, because the crash came later from delayed asynchronous processing. Some learnings and repair items from the earlier incident applied here as well. Microsoft advises customers to build a resilient global HTTP ingress layer that stays available during regional or network disruptions, to manage resources through the REST API or PowerShell when management portals are unavailable, and to configure Azure Service Health alerts so the right people hear about service issues.","ko":"Microsoft 는 라우팅, WAF, 오리진 변경을 전 세계에 빠르게 배포해야 하는 전 세계 CDN 에는 설정 전파 위험이 따른다고 봤다. 이번 사고와 10월 9일의 AFD 사고는 모두 이 위험에서 나왔다. 설정 보호 시스템은 데이터 플레인의 정상 신호를 보고 다음 단계로 넘긴다. 이번에는 크래시가 나중에 도는 비동기 처리에서 늦게 드러나, 문제 메타데이터가 보호 시스템을 통과했다. 앞선 사고에서 얻은 교훈과 개선 항목 일부가 이번 사고에도 들어맞았다. Microsoft 는 고객에게 리전 장애나 네트워크 장애 때도 가용성을 지키는 전 세계 HTTP 진입 계층을 만들라고 권했다. 관리 포털을 쓸 수 없을 때는 REST API 나 PowerShell 로 리소스를 관리하고, 알맞은 사람이 서비스 문제를 알 수 있도록 Azure Service Health 알림을 설정하라고도 권했다."},"related":[],"sources":[{"url":"https://azure.status.microsoft/en-us/status/history/?trackingId=YKYN-BWZ","kind":"official-status","archived":"https://web.archive.org/web/20260527151609/https://azure.status.microsoft/en-us/status/history/?trackingId=YKYN-BWZ"}],"summary":{"en":"The AFD control plane generates customer configuration metadata that the data plane on globally distributed edge sites consumes, and every customer change is deployed to all edge sites. The incompatible metadata exposed a latent bug in the data plane, which crashed during asynchronous processing. The defect was not caught because pre-production validation does not test all features across different control plane build versions. AFD's configuration protection system advances a change stage by stage, waiting about a minute between stages and moving on only after healthy signals from the data plane, and after a successful rollout it updates a Last Known Good (LKG) snapshot of healthy configurations for automatic rollback.\n\nThe change reached a pre-production stage at 15:36 UTC and the health signals stayed good, because the crash came asynchronously about five minutes later. By then the configuration had passed the safeguards, reached most edge sites by 15:39 UTC, and been written into the LKG snapshot. When the crashes started, the protection system blocked all new and in-flight configuration changes at 15:43 UTC. Because the latest LKG held the bad metadata, the team did not revert to it or to older LKG versions; from 17:10 UTC it removed the problematic customer configurations from the latest LKG by hand, blocked all customer configuration propagation at 17:30 UTC and began deploying the edited LKG at 17:40 UTC. Every edge site had to reload all customer configurations and traffic was rebalanced gradually to avoid overload: AFD DNS servers recovered at 18:30 UTC and traffic was moved by hand to a few healthy edge sites, automatic traffic management resumed at 20:20 UTC, and impact was mitigated at 00:05 UTC on 30 October.\n\nAfter mitigation, AFD customer configuration changes were blocked at the Azure Resource Manager level until new safeguards were in place, and the block was lifted on 5 November 2025. Microsoft states that this incident was not directly related to the AFD incident of 9 October (QNBQ-5W8): the failure mode was similar but the defects were different.","ko":"Azure Front Door 와 Azure CDN 은 전 세계에 흩어진 엣지 사이트로 고객과 Microsoft 서비스의 트래픽을 보낸다. AFD 컨트롤 플레인이 고객 설정 메타데이터를 만들면 데이터 플레인이 이를 받아 쓴다. 설정 변경은 전 세계의 모든 엣지 사이트에 배포된다. 배포는 여러 단계로 나뉘고, 설정 보호 시스템이 단계마다 데이터 플레인의 정상 신호를 받은 뒤에만 다음 단계로 넘긴다. 배포가 성공하면 정상 설정의 주기적 스냅샷인 Last Known Good, 줄여서 LKG 도 갱신해 문제가 생기면 자동으로 롤백할 수 있게 한다.\n\n2025-10-29 에 두 컨트롤 플레인 빌드 버전에 걸친 특정 순서의 고객 설정 변경이 호환되지 않는 메타데이터를 만들었다. 변경 자체는 정상적이고 악의가 없었지만, 이 메타데이터가 데이터 플레인의 잠재 버그를 건드려 비동기 처리 중 크래시를 일으켰다. 모든 기능을 서로 다른 컨트롤 플레인 빌드 버전에 걸쳐 검증하지는 않았기 때문에 사전 운영 검증에서 이 결함을 잡지 못했다. 변경은 15:35 UTC 에 들어갔다. 크래시는 약 5분 뒤에 비동기로 드러났고, 그동안 보호 시스템은 정상 신호를 받아 15:39 UTC 까지 엣지 사이트 대부분에 설정을 퍼뜨리고 LKG 도 이 설정으로 갱신했다. 15:41 UTC 부터 사전 운영 환경에서 시작해 15:45 UTC 까지 전 세계 엣지 사이트의 서버가 크래시했고, 엣지 사이트에 있는 AFD 내부 DNS 서비스도 영향을 받았다. 15:43 UTC 에 보호 시스템이 모든 설정 변경의 배포를 막았다. 이 사고는 10월 9일의 AFD 사고와 같은 설정 전파 위험에서 나왔지만 원인이 된 결함은 달랐다.\n\n최신 LKG 에 문제 메타데이터가 들어 있어 팀은 LKG 로도, 그 이전 버전으로도 되돌리지 않았다. 대신 17:10 UTC 부터 최신 LKG 에서 문제 고객 설정을 손으로 지웠다. 17:30 UTC 에 고객 설정 전파를 모두 막고 17:40 UTC 에 고친 LKG 를 전 세계에 배포하기 시작했다. 엣지 사이트마다 고객 설정을 모두 다시 읽어야 했고, 돌아오는 엣지 사이트가 과부하에 걸리지 않도록 트래픽을 천천히 재분배했다. 18:30 UTC 에 AFD DNS 서버가 회복하자 소수의 정상 엣지 사이트로 트래픽을 손으로 돌렸다. 20:20 UTC 에 자동 트래픽 관리로 바꿨고, 10월 30일 00:05 UTC 에 완화를 확인했다. 그 뒤 Azure Resource Manager 수준에서 AFD 고객 설정 변경을 임시로 막았다가 안전장치를 모두 넣은 11월 5일에 풀었다."},"trigger":{"en":"At 15:35 UTC a specific sequence of valid customer configuration changes, made across two different AFD control plane build versions, produced incompatible customer configuration metadata that was deployed to the edge sites.","ko":"두 컨트롤 플레인 빌드 버전에 걸쳐 이뤄진 특정 순서의 고객 설정 변경이 호환되지 않는 고객 설정 메타데이터를 만들었다. 15:35 UTC 에 들어간 이 메타데이터가 엣지 사이트 서버에 배포되면서 데이터 플레인의 잠재 버그가 드러났고, 데이터 플레인 서비스가 비동기 처리 중에 크래시했다."},"severity":"unknown","symptoms":["intermittent-timeouts","dns-resolution-failures","service-unavailable","high-latency"],"timeline":{"detected_after":"7m","resolved_after":"8h 24m"},"date_kind":"incident","detection":{"en":"The configuration protection system detected the data plane impact and blocked configuration changes at 15:43 UTC, and monitoring alerts started the investigation at 15:48 UTC.","ko":"장애는 15:41 UTC 에 시작됐고 15:48 UTC 에 모니터링 알림이 울려 조사가 시작됐다. 그보다 앞선 15:43 UTC 에 설정 보호 시스템이 넓은 데이터 플레인 문제를 감지해 설정 배포를 자동으로 막았다."},"components":["cdn","dns-server"],"root_cause":"software-bug","remediation":[{"text":{"en":"The configuration protection system automatically blocked all new and in-flight configuration changes worldwide","ko":"15:43 UTC 에 설정 보호 시스템이 넓은 데이터 플레인 문제에 반응해 새 설정 변경과 진행 중인 설정 변경의 전 세계 배포를 자동으로 막았다."}},{"text":{"en":"Removed the problematic customer configurations from the latest LKG snapshot by hand","ko":"최신 LKG 에 문제 메타데이터가 들어 있어 LKG 로도 그 이전 버전으로도 롤백하지 않았다. 대신 17:10 UTC 부터 최신 LKG 에서 문제 고객 설정을 손으로 지웠다."}},{"text":{"en":"Blocked all customer configuration changes from propagating to the data plane","ko":"복구하는 동안 같은 문제가 다시 들어오지 않도록 17:30 UTC 에 모든 고객 설정 변경이 데이터 플레인으로 전파되지 않게 막았다."}},{"text":{"en":"Deployed the updated LKG configuration across the global fleet","ko":"17:40 UTC 에 고친 LKG 설정을 전 세계 엣지 서버에 배포하기 시작했다. 엣지 사이트마다 모든 고객 설정을 다시 읽었고, 돌아오는 엣지 사이트가 과부하에 걸리지 않도록 트래픽을 천천히 재분배했다."}},{"text":{"en":"Moved Azure Portal away from Azure Front Door","ko":"17:26 UTC 에 Azure Portal 이 표준 복구 절차에 따라 Azure Front Door 를 거치지 않는 경로로 failover 했다."}},{"text":{"en":"Rebalanced traffic by hand to a few healthy edge sites, then switched back to automatic traffic management","ko":"18:30 UTC 에 AFD DNS 서버가 회복하자 소수의 정상 엣지 사이트로 트래픽을 손으로 재분배했다. 20:20 UTC 에 충분한 엣지 사이트가 회복하자 자동 트래픽 관리로 바꿨다."}},{"text":{"en":"Blocked all AFD customer configuration changes at the Azure Resource Manager level until safeguards were in place","ko":"완화 뒤 데이터 플레인을 지키려고 Azure Resource Manager 수준에서 모든 AFD 고객 설정 변경을 임시로 막았다. 2025년 11월 2일부터 고객 설정 큐를 비우기 시작했고, 안전장치를 모두 넣은 뒤 11월 5일에 이 제한을 풀었다."}}],"action_items":[{"text":{"en":"Fix the control plane incompatibility and the data plane bug","ko":"원래의 컨트롤 플레인 비호환 문제와 데이터 플레인 버그를 둘 다 고쳤다. 완료됐다."}},{"text":{"en":"Process each customer configuration completely and synchronously before production stages","ko":"운영 단계로 넘어가기 전에 고객 설정마다 동기 처리를 끝까지 마치도록 강제한다. 완료됐다."}},{"text":{"en":"Add stages to the phased configuration rollout, with longer bake time between them","ko":"단계적 설정 롤아웃에 단계를 더 넣고 단계마다 배포 뒤 지켜보는 시간인 bake time 을 늘려 설정 문제를 잡게 했다. 완료됐다."}},{"text":{"en":"Move configuration processing on data plane servers into isolated worker processes","ko":"데이터 플레인 서버의 설정 처리를 트래픽을 받는 인스턴스에서 떼어 별도 워커 프로세스 인스턴스로 옮겨, 설정 결함이 데이터 플레인 처리에 영향을 주지 않게 한다. 2026년 1월에 끝낼 예정이다."}},{"text":{"en":"Reduce configuration propagation time from 45 minutes to about 15 minutes","ko":"이 설정 파이프라인의 사전 검증이 갖춰지면 전파 시간을 45분에서 약 15분으로 줄인다. 2026년 1월에 끝낼 예정이다."}},{"text":{"en":"Test backwards compatibility with configurations generated by earlier control plane builds","ko":"이전 컨트롤 플레인 빌드 버전에서 만든 설정과의 하위 호환성을 보장하도록 시험과 검증 체계를 강화한다. 2026년 2월에 끝낼 예정이다."}},{"text":{"en":"Move critical first-party infrastructure to an active-active setup with fail away","ko":"Azure Portal, Azure Communication Services, Marketplace, Linux Software Repository for Microsoft Products, 지원 티켓 생성 같은 핵심 자체 인프라를 active-active 구성으로 바꿔, AFD 를 거치지 않는 경로로 옮겨 갈 수 있게 했다. 완료됐다."}},{"text":{"en":"Isolate customer configuration and traffic with micro cell segmentation of the AFD data plane","ko":"AFD 데이터 플레인을 'micro cell' 로 나눠 고객 설정과 트래픽 격리를 강화하고, 한 고객의 트래픽이나 설정 문제가 다른 고객에게 영향을 주지 않게 한다. 2026년 6월에 끝낼 예정이다."}},{"text":{"en":"Restore customer configurations within one hour by using the local configuration cache","ko":"로컬 고객 설정 캐시를 더 잘 써서 데이터 플레인 복구 시간을 줄여, 고객 설정을 한 시간 안에 복원하게 했다. 완료됐다."}},{"text":{"en":"Cut data plane recovery further, to about 10 minutes","ko":"데이터 플레인 복구 시간을 더 줄여 고객 설정을 약 10분 안에 복원하게 한다. 2026년 3월에 끝낼 예정이다."}},{"text":{"en":"Remove delays in Azure Service Health alerts by raising resource thresholds","ko":"리소스 한도를 올려 Azure Service Health 로 영향받은 고객에게 가는 알림이 늦게 전달되던 문제를 해결했다. 완료됐다."}},{"text":{"en":"Extend automated Azure Service Health alerts to similar classes of service degradation","ko":"Azure Service Health 의 자동 고객 알림 범위를 비슷한 종류의 서비스 저하까지 넓혀 영향받은 고객에게 더 빨리 알린다. 2025년 11월에 끝낼 예정이다."}},{"text":{"en":"Fail over support request systems faster so Premier and Unified customers can always open requests","ko":"Premier 와 Unified 고객이 지원 요청을 만들지 못하게 한 기술과 인력 문제를 해결하고, 백업 시스템으로 더 빨리 failover 할 수 있게 한다. 2025년 11월에 끝낼 예정이다."}}],"contributing":["test-coverage-gap","delayed-effect-change","revert-did-not-restore","blast-radius-too-wide"],"recurrence_of":null,"symptoms_text":{"en":"From 15:41 UTC on 29 October 2025, customers and Microsoft services using Azure Front Door (AFD) and Azure Content Delivery Network (CDN) got connection timeout errors and DNS resolution issues. Monitoring alerts started the investigation at 15:48 UTC.\n\nAFD edge servers crashed as they processed an incompatible customer configuration, first in the pre-production environment at 15:41 UTC and on all edge sites worldwide by 15:45 UTC. AFD's internal DNS service is hosted on the edge sites, so a subset of AFD customer requests also got intermittent DNS resolution errors.\n\nConfiguration propagation monitoring had kept receiving healthy signals after the problematic metadata went in, because the data plane crash surfaced asynchronously about five minutes later; by then the configuration had passed the protection safeguards and reached most edge sites by 15:39 UTC. From 16:15 UTC the investigation focused on AFD configuration changes.\n\nThe affected services included Azure Portal, Azure App Service, Azure SQL Database, Azure Active Directory B2C, Azure Databricks, Microsoft 365, Microsoft Entra ID, Dynamics 365 and Power Platform, and customers could not open support cases in the Azure Portal or by phone. Some services, such as the Entra and Intune portals, failed over away from AFD; Azure Portal moved away from AFD at 17:26 UTC, but parts of it without a fallback, such as Marketplace, kept failing.\n\nFrom 18:30 UTC availability improved gradually, with higher latency, and availability and latency were back at pre-incident levels at 00:05 UTC on 30 October.\n\nThe first communication went to the public status page at 16:18 UTC and targeted communications to impacted customers to Azure Service Health at 16:20 UTC. Alerts delivered through Azure Service Health to impacted customers were delayed.","ko":"2025-10-29 15:41 UTC 부터 Azure Front Door 와 Azure CDN 을 쓰는 고객과 Microsoft 서비스에서 연결 타임아웃 오류와 DNS 해석 문제가 났다. 15:48 UTC 에 모니터링 알림이 울려 조사가 시작됐다.\n\n영향은 15:41 UTC 에 사전 운영 환경에서 시작해 15:45 UTC 까지 전 세계 모든 엣지 사이트로 번졌다. 엣지 서버가 호환되지 않는 고객 설정을 처리하다 크래시했다. Azure Front Door 엣지 사이트에서 도는 AFD 내부 DNS 서비스도 영향을 받아 AFD 고객 요청 일부에서 간헐적인 DNS 해석 오류가 났다.\n\n영향받은 Azure 서비스에는 Azure Active Directory B2C, Azure AI Video Indexer, Azure App Service, Azure Communication Services, Azure Databricks, Azure Healthcare APIs, Azure Maps, Azure Marketplace, Azure Media Services, Azure Portal, Azure Sphere Security Service, Azure SQL Database, Azure Static Web Apps 가 있었다. Microsoft 365, Microsoft Communication Registry 웹사이트, Microsoft Copilot for Security, Microsoft Defender External Attack Surface Management, Microsoft Dragon Copilot, Microsoft Dynamics 365, Power Platform, Microsoft Entra ID 의 Mobility Management Policy Service 와 Identity & Access Management 와 User Management, Microsoft Purview, Microsoft Sentinel Threat Intelligence, Visual Studio App Center 도 영향을 받았다. Azure Portal 과 전화로 지원 케이스를 여는 것도 막혔다.\n\n설정 전파 모니터링은 문제 메타데이터가 들어간 뒤에도 정상 신호를 받았다. 데이터 플레인 크래시가 비동기로 약 5분 뒤에 드러났기 때문에, 설정은 보호 장치를 통과해 15:39 UTC 까지 엣지 사이트 대부분에 퍼졌다. 조사팀은 16:15 UTC 부터 AFD 설정 변경을 집중해서 살폈다.\n\nMicrosoft Entra 와 Intune 포털, Azure Active Directory B2C 처럼 AFD 를 쓰는 여러 서비스는 failover 해 고객 영향을 줄였다. Azure Portal 은 17:26 UTC 에 Azure Front Door 를 거치지 않는 경로로 failover 했다. 하지만 대체 경로가 없던 Marketplace 같은 Portal 안의 일부 서비스는 Portal 이 회복한 뒤에도 계속 실패했다. 18:30 UTC 부터 가용성이 나아지기 시작했지만 지연은 높았고, 00:05 UTC 에 가용성과 지연이 사고 전 수준으로 돌아왔다.\n\n고객 공지는 16:18 UTC 에 공개 상태 페이지에, 16:20 UTC 에 Azure Service Health 에 올라갔다. Azure Service Health 로 영향받은 고객에게 가는 알림은 늦게 전달됐다."},"updated_at":"2026-11-14T05:53:44.314027Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0226","org_slug":"microsoft-azure"}