Azure Front Door : diagnostiquer une origine avant de changer le WAF ou le routage

Quand Azure Front Door renvoie des 502, 503 ou des erreurs intermittentes, la tentation est forte de modifier le WAF, de retirer une origine du pool, de changer une règle de routage ou de relancer le backend. Ces actions peuvent rétablir un symptôme, mais elles mélangent souvent plusieurs couches : edge, health probe, origine, DNS, TLS, Private Link, policy WAF et application.

Le cas d’usage est un service exposé par Azure Front Door Standard ou Premium, avec un origin group pointant vers une application Azure ou un backend interne. L’objectif du runbook est de décider si l’incident vient d’une origine réellement indisponible, d’un probe mal interprété, d’un problème TLS, d’un chemin Private Link, d’un blocage WAF, d’une règle de routage ou d’un changement applicatif qui doit être rollbacké.

Figer le contrat d’entrée

Commencez par nommer le chemin attendu. Front Door est une interface de production : hostname public, route, origin group, origine, protocole, health probe, policy WAF, logs et rollback. Sans ce contrat, chaque équipe regarde son morceau et le diagnostic devient circulaire.

Service expose
Hostname public: api.contoso.example
Front Door profile: afd-prod-global
Route: route-api-prod
Origin group: og-api-prod
Origines: app-api-weu, app-api-neu
Protocole vers origine: HTTPS 443
Health probe: GET /health/live toutes les 30s
WAF policy: waf-api-prod-prevention
Chemin prive: Private Link active ou non

Questions avant changement
Quelle route a servi la requete ?
L'origine est-elle unhealthy ou seulement non joignable par le probe ?
Le certificat presente par l'origine correspond-il au host header attendu ?
Le WAF bloque-t-il la requete avant l'origine ?
Le probleme touche-t-il une region, une route ou un type de requete ?
Le rollback connu est-il une route, une origine, une policy WAF ou une revision applicative ?

Cette étape évite de traiter un 502 comme un blocage WAF ou un probe défaillant comme une panne applicative.

Séparer edge, route et origine

Validez d’abord que la requête arrive sur le bon profil Front Door et qu’elle emprunte la route attendue. Une règle de routage, un ruleset, un domaine custom ou une priorité peut envoyer une partie du trafic vers un mauvais origin group.

SUBSCRIPTION="00000000-0000-0000-0000-000000000000"
RG="rg-edge-prod"
PROFILE="afd-prod-global"
ENDPOINT="afd-prod-endpoint"
ROUTE="route-api-prod"

az account set --subscription "$SUBSCRIPTION"

az afd route show --resource-group "$RG" --profile-name "$PROFILE" --endpoint-name "$ENDPOINT" --route-name "$ROUTE" --query "{enabled:enabledState,patterns:patternsToMatch,domains:customDomains,originGroup:originGroup.id,forwardingProtocol:forwardingProtocol,httpsRedirect:httpsRedirect}" --output json

az afd origin-group show --resource-group "$RG" --profile-name "$PROFILE" --origin-group-name "og-api-prod" --query "{probeSettings:healthProbeSettings,loadBalancing:loadBalancingSettings,sessionAffinity:sessionAffinityState}" --output json

Si la route est désactivée, si le pattern ne correspond pas ou si le ruleset réécrit le chemin avant l’origine, ne touchez pas au WAF. Le diagnostic est encore dans la couche de routage.

Lire les health probes comme un signal, pas comme une vérité

Un origin unhealthy ne signifie pas automatiquement que l’application est indisponible pour les utilisateurs. Le probe peut viser un endpoint trop profond, exiger une authentification, dépendre d’une base de données, échouer sur un host header ou traverser un chemin réseau différent de la requête réelle.

Qualifier le health probe
Endpoint sonde: /health/live ou /health/ready
Methode: GET ou HEAD
Code attendu: 200 a 399 selon le contrat
Host header attendu par l'origine
Certificat presente par l'origine
Dependances incluses dans le probe
Comportement par region et par origine

Bloquer les changements quand
Le probe teste une dependance non critique
Le probe exige une authentification
Le host header ne correspond pas au certificat
Une seule origine est unhealthy mais le load balancing continue correctement
L'application est saine en direct mais pas depuis Front Door

Le bon correctif peut être de simplifier le probe, de corriger le host header ou de sortir une origine du pool. Ce n’est pas forcément une modification applicative.

Vérifier TLS et host header avant le backend

Front Door peut joindre l’origine en HTTPS avec un host header spécifique. Une rotation de certificat, un changement de domaine interne, une bascule de slot ou une configuration App Service peut casser cette relation sans que l’application soit réellement en panne.

ORIGIN_HOST="app-api-prod.azurewebsites.net"
EXPECTED_HOST="api.internal.contoso.example"

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

curl -I --resolve "$EXPECTED_HOST:443:10.20.30.40" "https://$EXPECTED_HOST/health/live"

Dans un environnement privé, adaptez le test depuis un point réseau autorisé. L’important est de prouver le couple SNI, certificat et host header avant d’accuser le WAF ou le code.

Qualifier Private Link, DNS et origine privée

Avec Front Door Premium et Private Link, une origine peut être correcte côté application mais non joignable côté edge si l’approbation Private Link, le DNS, la cible ou le routage interne ont dérivé. Le rôle de Private Link est de porter le chemin privé vers l’origine, pas d’expliquer tous les échecs.

RG="rg-edge-prod"
PROFILE="afd-prod-global"
ORIGIN_GROUP="og-api-prod"
ORIGIN="app-api-weu"

az afd origin show --resource-group "$RG" --profile-name "$PROFILE" --origin-group-name "$ORIGIN_GROUP" --origin-name "$ORIGIN" --query "{enabled:enabledState,hostName:hostName,originHostHeader:originHostHeader,httpPort:httpPort,httpsPort:httpsPort,priority:priority,weight:weight,privateLink:sharedPrivateLinkResource}" --output json

az network private-endpoint-connection list --id "/subscriptions/$SUBSCRIPTION/resourceGroups/rg-app-prod/providers/Microsoft.Web/sites/app-api-prod" --query "[].{name:name,status:privateLinkServiceConnectionState.status,description:privateLinkServiceConnectionState.description}" --output table

Une connexion Private Link en attente, rejetée ou recréée récemment suffit à expliquer un incident edge-to-origin. À l’inverse, si Private Link est sain, continuez vers WAF, route et application.

Chercher le WAF avec des preuves KQL

Ne désactivez pas le WAF pour voir si cela passe. Cherchez d’abord les blocages qui correspondent au hostname, à la route, à l’URI, au client et à la fenêtre de l’incident. Un 403 explicite et un 502 d’origine ne demandent pas la même action.

let StartTime = datetime(2026-07-06T07:00:00Z);
let EndTime = datetime(2026-07-06T08:00:00Z);
let Hostname = "api.contoso.example";
AzureDiagnostics
| where TimeGenerated between (StartTime .. EndTime)
| where ResourceProvider == "MICROSOFT.CDN"
| where host_s == Hostname or requestUri_s has Hostname
| project TimeGenerated,
        Category,
        trackingReference_s,
        httpStatusCode_d,
        clientIp_s,
        requestUri_s,
        ruleName_s,
        action_s,
        details_msg_s,
        backendHostname_s,
        originName_s
| order by TimeGenerated desc

Si les logs montrent une règle WAF en mode Block sur une URI précise, préparez une modification WAF ciblée. Si les statuts sont surtout 502 ou 503 avec une origine identifiée, restez sur le chemin origin group, TLS, probe ou application.

Corréler avec la révision applicative

Front Door peut révéler une régression backend sans en être la cause. Comparez l’incident avec les déploiements, swaps, changements de configuration, rotations de certificat et modifications d’infrastructure.

let StartTime = datetime(2026-07-06T06:30:00Z);
let EndTime = datetime(2026-07-06T08:30:00Z);
AppRequests
| where TimeGenerated between (StartTime .. EndTime)
| summarize Requests=count(), Failures=countif(Success == false), P95=percentile(DurationMs, 95) by bin(TimeGenerated, 5m), AppRoleName, ResultCode
| order by TimeGenerated asc

Si l’application ne voit aucune requête pendant que Front Door renvoie des 502, le problème est avant le runtime. Si l’application voit les requêtes et échoue en 5xx, le rollback doit probablement viser la révision, la configuration ou une dépendance.

Décider : route, origine, WAF ou rollback applicatif

Formulez une décision exploitable et réversible. Le pire résultat est un cumul de petites corrections non tracées : désactiver le WAF, baisser un probe, ajouter une origine et redéployer l’application dans le même incident.

Changer la route
Le hostname ou le pattern ne matche pas le contrat
Le ruleset reecrit vers un mauvais chemin
Le changement est reversible par retour a la route precedente

Retirer ou desactiver une origine
Une origine est unhealthy et les autres sont saines
L'impact est regional ou lie a une revision precise
Le poids et la priorite permettent une sortie controlee

Modifier le WAF
Les logs prouvent un blocage WAF cible
La requete legitime est identifiee
L'exclusion ou custom rule est minimale et rollbackable

Rollback applicatif
L'origine recoit les requetes et produit les erreurs
La regression coincide avec une revision ou configuration
Les probes et Front Door sont conformes au contrat

Chaque décision doit citer les preuves utilisées : tracking reference, origin name, probe status, certificat, logs WAF, logs applicatifs et changement récent.

Valider après correction

Validez le chemin complet, pas seulement le code HTTP d’une requête manuelle. La correction doit prouver que Front Door route, que l’origine répond, que le WAF garde sa protection et que les métriques reviennent à un état normal.

validation:
edge:
  - hostname_public_resout
  - route_attendue_active
  - tracking_reference_capturee
origin:
  - origin_group_sain
  - health_probe_stable_sur_deux_fenetres
  - certificat_et_host_header_valides
security:
  - waf_policy_reste_active
  - aucune_exclusion_large_ajoutee_sans_preuve
application:
  - requetes_vues_par_le_backend
  - taux_5xx_revenu_au_niveau_attendu
  - probe_synthetique_ok_depuis_regions_utiles
rollback:
  - changement_documente
  - retour_arriere_teste_ou_immediatement_disponible

Gardez la validation sur plusieurs fenêtres de probe. Une origine peut redevenir saine quelques secondes puis retomber si le problème est lié à la charge, au certificat, au warm-up ou à une dépendance.

Conclusion

Un incident Azure Front Door se traite comme une chaîne de livraison, pas comme une page d’erreur isolée. La bonne question n’est pas “faut-il désactiver le WAF ?”, mais “où le contrat edge-to-origin s’est-il rompu ?”.

En séparant route, origin group, probes, TLS, Private Link, WAF et logs applicatifs, l’équipe peut choisir une action limitée : corriger le routage, sortir une origine, ajuster un probe, préparer une règle WAF ciblée ou rollbacker la révision applicative. C’est cette décision bornée, validée et réversible qui transforme Front Door en composant exploitable plutôt qu’en boîte noire devant la production.