Sitecore op Azure en Front Door mooi snel tot front door faalt

Als je Sitecore host op Azure, is Azure Front Door vaak de standaard keuze voor global routing, WAF, caching en geoptimaliseerde edge delivery. Logisch ook: één entrypoint, wereldwijd PoP-netwerk, lekker veel knopjes voor performance en security. Maar het blijft wel een afhankelijkheid. Enals die afhankelijkheid omvalt, valt je hele site mee om.

Op 29 oktober 2025 zagen we dat weer keihard toen Azure Front Door eruit klapte. Niet een beetje haperen, gewoon wereldwijd gedoe met timeouts, DNSissues en latency. Sitecore-diensten (incl. XM Cloud) kregen daar directe last van: builds die faalden, deploys die soms wel/soms niet doorkwamen, requests die in timeouts verdwenen.

En nee, voor wie al klaarstond om naar partners te wijzen: dit zat volledig aan de Azure-kant. 

Wat er precies gebeurde (kort, want je wil bouwen)

Microsoft heeft in Azure Front Door een configuratiewijziging doorgevoerd die fout uitpakte. Daardoor werden AFD-nodes in meerdere regio’s ongezond of gingen ze verkeer verkeerd routeren, met als resultaat:

• Connection timeouts en DNS-resolution failures voor AFD/CDN klanten. 
• Verhoogde latency door traffic rerouting langs minder gezonde paden. 
• Grote kettingreactie: Microsoft 365, Azure Portal, en een berg klantapplicaties gingen mee om. 

Microsoft heeft uiteindelijk de change teruggedraaid en traffic stap voor stap teruggerouteerd. Rond 30 oktober 2025, 06:13 UTC was de boel weer stabiel. 

Impact op Sitecore (aka: waarom je build ineens stuk ging)

Sitecore’s SaaS-producten draaien óók op Azure en gebruiken Front Door in hun delivery-keten. Dus als AFD kuren heeft krijg je:

• Service degradation in o.a. XM Cloud.
• Intermittent build/deploy failures (de irritantste soort: soms werkt het, soms niet).
• Request failures/timeouts richting delivery en management endpoints.
• Latency spiking in regio’s waar rerouting noodzakelijk was. 

“Maar wij hosten toch goed?” — ja, maar je stack is zo sterk als je zwakste dependency

Front Door is een single global ingress. Dat is z’n kracht en z’n achilleshiel.
Je availability-keten ziet er meestal ongeveer zo uit:

Client → Azure Front Door → (WAF/caching/routing) → App Service / AKS / VM → Sitecore roles / Edge / APIs

Als Front Door eruit ligt, kom je nooit bij de rest. Hoe robuust je Sitecore-setup daarachter ook is.
Dus dit incident is geen “Sitecore-probleem” en ook geen “partner-probleem”. Het is het klassieke cloud-ding: shared responsibility + shared blast radius. 

Twee keer Front Door-issues in korte tijd = tijd voor failover-seriousness

Als je één keer geraakt wordt: pech.
Als je twee keer in korte tijd geraakt wordt: architectuuractie.

Microsoft heeft hier zelf een best duidelijke lijn voor: bouw global routing redundancy, zodat je een alternatief pad hebt als Front Door niet beschikbaar is. Hun referentie-architectuur gebruikt bijvoorbeeld Azure Traffic Manager als fallback router. 

Wat bedoelen ze praktisch?

Je maakt twee ingress-paden:
1. Primair: Azure Front Door
2. Fallback: Traffic Manager (of een tweede edge-pad) die direct naar je origins kan routeren

Traffic Manager checkt health probes en kan (DNS-based) overschakelen als AFD faalt. 
Belangrijk: dit werkt alleen als je origins ook multi-region / redundant zijn. Anders failover je naar… dezelfde kapotte achterdeur.

Concrete failover-opties (zonder een thesis)

Optie A — Front Door + Traffic Manager fallback (Microsoft-canonical)

• AFD blijft je main edge layer
• Traffic Manager staat klaar om om te schakelen naar je origins als AFD down is
• Beste voor: websites met mission-critical uptime en redelijk voorspelbaar verkeer Microsoft Learn

Optie B — Dual-Front Door (actief/passief)

• Twee AFD-profiles in verschillende “rings” of subscriptions
• Failover via DNS / Traffic Manager
• Beste voor: organisaties die Front Door features absoluut nodig hebben (WAF, rules engine) maar redundantie willen

Optie C — Multi-CDN/Edge strategie

• AFD als primary, andere CDN/edge als backup
• Complexer qua config, maar minder “één-vendor-blast-radius”
• Beste voor: echt grote omgevingen waar edge-availability > eenvoud

Wat we nu doen (en wat jij ook zou moeten doen)

Onderzoek de mogelijkheden voor een fallback mechanisme. De richting is duidelijk:

• Front Door niet als single point of failure laten bestaan
• Fallback routering testen (niet alleen tekenen in een diagram)
• Runbooks klaarleggen voor “AFD down-scenario’s”
• Monitoring op dependency-niveau (niet alleen “site down?” maar “waarom down?”)

Want het doel is simpel:
als Front Door weer faalt, blijven wij langer in de lucht dan Microsoft zelf.

TL;DR – Samengevat voor drukke mensen

• Azure Front Door outage op 29 okt 2025 veroorzaakte brede storing, inclusief Sitecore SaaS degrade + build/deploy issues. 
• Root cause was Azure configuratiefout, dus uxbee/Sitecore-partners geen schuld. 
• Front Door is een krachtige maar centrale dependency.
• Microsoft raadt expliciet global routing redundancy aan met o.a. Traffic Manager als fallback. 
• Twee incidenten kort na elkaar = tijd om failover serieus te bouwen en te testen.