Cloud

Azure Front Door : qualifier la santé d’une origin avant failover

Un runbook de production pour qualifier la santé d’une origin Azure Front Door avec probes, routage, DNS, TLS, preuves WAF, logs backend, validation et rollback avant de forcer un failover.

21 juil. 2026 azureazure-front-doorfront-doorwaforigindnstlshealth-probeobservabilitykqlrunbookrollbackproduction

Quand Azure Front Door marque une origin comme non saine, le réflexe le plus rapide consiste souvent à forcer le trafic vers une autre région, désactiver l’origin en défaut ou assouplir le WAF jusqu’à ce que l’application réponde. Cela peut rétablir le service. Cela peut aussi masquer la vraie frontière : une probe qui cible un chemin supprimé, un certificat origin incohérent, une dérive DNS, du throttling backend, un faux positif WAF ou une release qui casse seulement une route.

Le cas d’usage est une application externe publiée via Azure Front Door sur app.example.com. L’origin group actif pointe vers app-west.example.net et app-north.example.net. Après une release, les utilisateurs reçoivent des 503 intermittents et Front Door indique l’origin west comme dégradée. L’objectif du runbook est de décider s’il faut basculer, corriger l’origin, ajuster la probe, rollbacker la release ou conserver un trafic partagé pendant la collecte de preuves.

Geler le contrat de trafic

Commencez par écrire comment la route est censée fonctionner. Front Door n’est pas seulement un point d’entrée global. C’est un contrat entre hostname, route, origin group, health probe, policy WAF, attentes TLS et readiness backend.

yaml front-door-origin-contract.yml

front_door:
profile: afd-prod-global
endpoint: afd-app-prod
hostname: app.example.com
route: app-main
origin_group: og-app-prod

origins:
- name: app-west
  host: app-west.example.net
  region: westeurope
  priority: 1
  weight: 1000
- name: app-north
  host: app-north.example.net
  region: northeurope
  priority: 2
  weight: 1000

probe_contract:
path: /health/ready
protocol: HTTPS
expected_status: 200
host_header: app.example.com

rollback_reference:
last_known_good_route: app-main@2026-07-21T09:00Z
last_known_good_release: app-api-20260721.3

Si ce contrat est inconnu, la première action est la découverte, pas le failover. Sinon, l’équipe peut déplacer le trafic hors d’une origin saine simplement parce que la probe est mal alignée.

Séparer chemin utilisateur, chemin probe et chemin backend

Une health probe en échec ne signifie pas toujours que le chemin utilisateur est indisponible. Une probe saine ne prouve pas toujours que la route applicative est utilisable. Vérifiez les trois chemins séparément.

text front-door-path-matrix.txt

Chemin utilisateur
Host: app.example.com
Path: /checkout/confirm
Objectif: prouver l'impact utilisateur via Front Door et WAF

Chemin probe
Host header: app.example.com
Path: /health/ready
Objectif: decider si Front Door doit garder l'origin en rotation

Chemin backend
Host: app-west.example.net ou hostname backend interne
Path: /health/ready et une vraie route applicative
Objectif: prouver si l'origin elle-meme est joignable et ready

Interpretation
Chemin utilisateur en echec, probe OK: suspecter WAF, route, cache, route applicative ou dependance
Probe en echec, backend OK: suspecter host header, config probe, TLS ou endpoint de probe
Backend en echec en direct: suspecter deploiement, service origin, dependance, DNS ou certificat
Une seule region en echec: garder le failover possible mais prouver l'ecart regional d'abord

Cette séparation évite une erreur classique : traiter la santé Front Door comme unique source de vérité pendant un incident applicatif.

Lire les preuves Front Door d’abord

Utilisez les logs pour vérifier si Front Door voit des erreurs origin, des blocages WAF, des changements de routage ou seulement des erreurs côté utilisateurs. Gardez une fenêtre étroite autour du premier signal dégradé.

kusto 01-front-door-origin-health.kql

let StartTime = datetime(2026-07-21T09:10:00Z);
let EndTime = datetime(2026-07-21T09:40:00Z);
AzureDiagnostics
| where TimeGenerated between (StartTime .. EndTime)
| where ResourceProvider == "MICROSOFT.CDN"
| where Category in ("FrontDoorAccessLog", "FrontDoorHealthProbeLog", "FrontDoorWebApplicationFirewallLog")
| extend host = tostring(requestUri_s)
| extend origin = coalesce(tostring(originName_s), tostring(BackendHostname_s))
| summarize requests=count(),
          failures=countif(toint(httpStatusCode_s) >= 500),
          wafBlocks=countif(action_s in ("Block", "Blocked")),
          sampleStatus=make_set(httpStatusCode_s, 8),
          sampleRules=make_set(ruleName_s, 8)
by Category, origin, bin(TimeGenerated, 5m)
| order by TimeGenerated asc

Adaptez les noms de tables et de champs à vos diagnostics. La question utile n’est pas seulement “l’origin est-elle unhealthy ?”, mais “quelle couche produit la première preuve ?”.

Valider DNS et TLS avant de déplacer le trafic

La santé d’une origin dépend du hostname exact, du certificat et du host header vus depuis le chemin Front Door. Une rotation de certificat, une mise à jour DNS ou un changement de hostname origin peut casser les probes sans casser un test interne direct.

bash 02-origin-dns-tls-checks.sh

FRONTDOOR_HOST="app.example.com"
ORIGIN_HOST="app-west.example.net"
PROBE_PATH="/health/ready"

dig +short "$FRONTDOOR_HOST"
dig +short "$ORIGIN_HOST"

curl -I "https://$FRONTDOOR_HOST$PROBE_PATH" -H "x-correlation-id: afd-probe-check-20260721"

curl -I "https://$ORIGIN_HOST$PROBE_PATH" -H "Host: $FRONTDOOR_HOST" -H "x-correlation-id: origin-direct-check-20260721"

openssl s_client -connect "$ORIGIN_HOST:443" -servername "$FRONTDOOR_HOST" </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates

Si les tests directs origin ne passent qu’avec un autre host header, corrigez le contrat de route ou d’origin avant de forcer un failover global.

Capturer l’état de l’origin group et les derniers changements

Avant de modifier poids ou priorités, capturez l’état courant de l’origin group et le dernier changement de déploiement ou d’infrastructure.

bash 03-front-door-origin-state.sh

RESOURCE_GROUP="rg-edge-prod"
PROFILE="afd-prod-global"
ORIGIN_GROUP="og-app-prod"

az afd origin list --resource-group "$RESOURCE_GROUP" --profile-name "$PROFILE" --origin-group-name "$ORIGIN_GROUP" --query "[].{name:name,hostName:hostName,enabled:enabledState,priority:priority,weight:weight,originHostHeader:originHostHeader}" --output table

az afd origin-group show --resource-group "$RESOURCE_GROUP" --profile-name "$PROFILE" --origin-group-name "$ORIGIN_GROUP" --query "{name:name,probePath:healthProbeSettings.probePath,probeProtocol:healthProbeSettings.probeProtocol,probeRequestType:healthProbeSettings.probeRequestType,loadBalancing:loadBalancingSettings}"

La sortie doit être copiée dans la note d’incident avant tout failover. C’est la cible de rollback si l’équipe change les poids, désactive une origin ou édite la probe.

Corréler les logs backend avec la même requête

Front Door peut prouver qu’il a envoyé ou bloqué une requête. Le backend doit prouver s’il l’a reçue, quelle instance l’a traitée et quelle dépendance a échoué.

kusto 04-origin-backend-correlation.kql

let CorrelationId = "origin-direct-check-20260721";
AppRequests
| where TimeGenerated > ago(2h)
| where tostring(Properties["x-correlation-id"]) == CorrelationId
| project TimeGenerated,
        AppRoleName,
        OperationName,
        Url,
        ResultCode,
        Success,
        DurationMs,
        CloudRoleInstance,
        DependencyFailure = tostring(Properties["dependency_failure"])
| order by TimeGenerated asc

Si le backend ne voit jamais la requête, restez sur DNS, TLS, WAF, route et joignabilité origin. Si le backend voit la requête et retourne des erreurs, le failover peut être un contournement, mais la release ou la dépendance demande encore une décision.

Décider failover, correction, rollback ou maintien

Rendez la décision explicite. Un failover global est un changement de production, pas seulement une astuce de trafic.

text front-door-failover-decision.txt

Failover maintenant
La route utilisateur impactee echoue via l'origin active
L'origin secondaire est validee avec le meme hostname et le meme chemin
WAF et regles de routage ne sont pas la cause principale
Les preuves backend montrent une panne regionale ou une mauvaise release dans une region
Le retour aux poids ou priorites precedents est documente

Corriger l'origin ou la probe d'abord
La probe echoue mais le chemin utilisateur est sain
Le test direct origin ne passe qu'avec un autre host header
Le certificat TLS ne correspond pas au SNI attendu
L'endpoint de probe a change pendant la release
La sante origin ne correspond pas aux preuves de readiness backend

Rollbacker la release
Le routage Front Door est stable
La probe et la vraie route applicative atteignent l'origin
Les logs backend montrent des erreurs apres le nouveau deploiement
La release precedente est connue et restaurable

Maintenir le trafic partage
L'impact est intermittent et la capacite secondaire n'est pas prouvee
Les preuves divergent entre WAF, probe et logs backend
Un failover force pourrait deplacer les utilisateurs vers un chemin non valide

Cette table de décision évite d’utiliser le failover comme raccourci de diagnostic.

Valider après le changement

Après failover, correction de probe ou rollback, validez à nouveau la même chaîne. L’incident n’est pas clos quand le trafic bouge. Il est clos quand la route est explicable et réversible.

text post-failover-validation.txt

Validation apres action
La route Front Door retourne le statut attendu pour un vrai chemin utilisateur
La health probe correspond a la readiness backend
Les logs WAF montrent le comportement allow ou block attendu
Les logs backend contiennent le correlation ID sur l'origin selectionnee
Le taux d'erreur ne se deplace pas vers l'origin secondaire
Les poids, priorites et probe settings correspondent a la note d'incident
La commande de rollback ou la version de configuration reste disponible

Declencheur de rollback
L'origin secondaire retourne la meme erreur
Le WAF commence a bloquer un chemin plus large
La probe devient saine mais le chemin utilisateur echoue encore
Les logs backend montrent une dependance en echec sans lien regional

Si la validation échoue, revenez sur le changement de trafic ou gardez l’origin dégradée hors rotation seulement avec un propriétaire et une expiration explicites.

Conclusion

Le failover Azure Front Door doit partir de preuves, pas d’un indicateur de santé rouge seul. Séparez chemin utilisateur, chemin probe, DNS origin, TLS, WAF, routage et logs backend avant de déplacer du trafic global.

La décision sûre peut être le failover, mais aussi une correction de probe, un correctif certificat, un rollback de release ou un maintien temporaire pendant que le chemin secondaire est validé. La valeur opérationnelle reste la même : l’équipe sait ce qui a changé, pourquoi cela a changé, et comment revenir à l’état précédent.