11 — Global Load Balancing and Security

Distribuer le trafic entre plusieurs régions pour la HA mondiale → Traffic Manager (DNS), Front Door (proxy edge L7 + CDN) et le WAF qui protège les applis.

A. Vue d'ensemble — les options de load balancing global

🎯 Règle : HTTP/S global + WAF + CDN → Front Door. Non-HTTP global ou backend hors Azure ou geo-routing strict → Traffic Manager. Non-HTTP global avec failover instant → Cross-Region LB.

B. Traffic Manager

B.1 Concept : DNS-based

Traffic Manager (TM) n'est PAS un proxy. C'est un load balancer au niveau DNS :

1. L'utilisateur résout app.trafficmanager.net
2. TM répond à la requête DNS en renvoyant l'IP du meilleur endpoint (selon la routing method)
3. L'utilisateur se connecte directement au backend avec cette IP (TM n'est plus dans le chemin)

Conséquence majeure : TM ne voit jamais le trafic applicatif, seulement les requêtes DNS. Pas de SSL, pas de WAF, pas de CDN.

B.2 Architecture

B.3 Types d'endpoints

Les endpoints sont des services internet-facing (tout protocole), de trois types :

B.4 Routing Methods

MultiValue expliqué

Au lieu de renvoyer une seule IP, TM renvoie plusieurs IPs healthy en une seule réponse DNS. Le client choisit laquelle utiliser (et peut retry sur une autre si la première échoue).

Use case : apps avec logique de retry côté client (résilience supplémentaire). Marche uniquement avec des endpoints de type External (IPs).

Subnet expliqué

Mappe des plages d'IPs source (celles du resolver DNS du client) → un endpoint spécifique.

Use case :

• Les employés du siège (IPs corp connues, ex 203.0.113.0/24) → routés vers un endpoint interne (version admin)
• Tout le reste d'internet → endpoint public (version standard)

B.5 Health Monitoring

• Protocole : HTTP / HTTPS / TCP
• Path (pour HTTP/S) : /health
• Intervalle : 30s par défaut
• Failures tolerated : 3 par défaut
• Un endpoint unhealthy est sorti des réponses DNS

B.6 Limites (vs Front Door)

• Failover lent : dépend du TTL DNS (default 60s) + le cache du resolver client. Un client qui a caché l'IP continue d'aller au backend mort jusqu'à expiration du TTL.
• Pas de SSL termination, pas de WAF, pas de CDN, pas de session affinity (pas un proxy)
• Geographic routing utilise l'IP du resolver DNS (pas du client) → imprécis avec Google DNS 8.8.8.8
• Toujours définir un endpoint Default sinon NXDOMAIN

B.7 Quand préférer Traffic Manager à Front Door ?

• Trafic non-HTTP (TCP/UDP, gaming, IoT custom)
• Backend hors Azure (on-prem, autres clouds)
• Geographic routing strict (compliance data residency)
• Active-passive cross-region simple, failover lent acceptable

C. Azure Front Door

C.1 Concept : L7 global anycast + CDN + WAF

Front Door (AFD) = service edge global de Microsoft. Il combine :

1. Global Load Balancing : route les users vers le backend le plus proche/rapide (anycast, 100+ POPs)
2. Accelerated Delivery : CDN (cache static + dynamic content), compression
3. Secure Connectivity : WAF, bot protection, threat intelligence, SSL offload, Private Link

Anycast : une seule IP publique répliquée sur tous les POPs MS dans le monde. BGP route le client vers le POP le plus proche (Paris → POP Paris ~5ms, Tokyo → POP Tokyo).

C.2 SKUs / Tiers

🚨 Distinction clé : Standard ne supporte que les custom WAF rules. Pour les managed rules (DRS) + Bot Manager + Private Link → Premium.

C.3 Architecture

C.4 Routing Flow (sélection du backend)

Quand une requête arrive, Front Door sélectionne l'origin dans cet ordre :

1. Available backends : ne considère que les origins healthy (health probe)
2. Priority : les origins de priorité la plus haute (1 = primaire). Active-passive : priority 1 = actif, priority 2 = backup
3. Latency : parmi les origins de même priorité, choisit le plus rapide (dans une fenêtre de latence tolérée)
4. Weighted : répartit le trafic selon les poids (A/B testing)
5. Session Affinity : si activée, un client reste sur le même origin (cookie)

C.5 Origin type

L'origin type = la catégorie de ressource backend :

• App Service / Web App
• Storage (static website, blob)
• Cloud Service
• API Management
• Application Gateway (combo Front Door + AGW)
• Public IP
• Static Web App, Container Apps, Container Instances, Spring Apps
• Custom (FQDN non-Azure : on-prem, autre cloud)

L'origin host name = le FQDN réel que Front Door va joindre.

C.6 Caching & Acceleration

Comment ça marche

Le cache se configure au niveau de la Route. Quand activé :

• La 1ère requête pour une ressource → Front Door va chercher à l'origin → met en cache au POP edge le plus proche du client
• Les requêtes suivantes (mêmes ou autres clients de la même région) → servies depuis le cache du POP → latence quasi nulle, l'origin n'est pas sollicité

Avantages

• Latence réduite (le contenu est au POP proche du client)
• Charge réduite sur l'origin (moins de requêtes remontent)
• Bande passante économisée
• Idéal pour les assets statiques (images, CSS, JS, vidéos)

Query string caching behavior

Comment Front Door traite les query strings (?id=123&color=red) pour le cache :

Exemple : un CDN d'images où ?width=200 change le rendu → Use query string (sinon tous les clients reçoivent la même taille).

Compression

Front Door compresse les réponses (Brotli, gzip) à la volée pour les types de contenu éligibles (text, JSON, CSS, JS) → réduit la taille transférée → plus rapide.

C.7 Traffic acceleration (Dynamic Site Acceleration)

Objectif AZ-700 distinct du caching : Front Door accélère aussi le contenu NON-cachable — API, contenu dynamique, réponses personnalisées par utilisateur. Ce n'est pas du cache, c'est une optimisation du transport réseau de bout en bout.

Les 3 mécanismes (chemin user → POP → origin) :

• Le trafic POP↔origin emprunte le backbone Microsoft (WAN privé), pas l'internet public → chemin plus rapide et stable.
• En anycast, l'IP est répliquée sur tous les POPs et BGP choisit le plus proche. (NB : la doc Standard/Premium parle techniquement d'unicast côté routage interne via l'architecture type Traffic Manager, mais le résultat fonctionnel — atteindre le POP optimal — est identique.)

🚨 Caching ≠ Acceleration : le caching stocke du statique au POP (l'origin n'est plus sollicité). L'acceleration optimise le transport (TLS/split TCP/backbone) et bénéficie même au dynamique non-cachable où le contenu DOIT remonter à l'origin à chaque fois.

💡 Pas de config dédiée : l'acceleration est toujours active sur tout trafic Front Door (statique comme dynamique). Le caching, lui, s'active explicitement par route.

C.8 Front Door + Private Link (Premium)

Le principe

Par défaut, Front Door joint ses origins via leur endpoint public. Avec Private Link (Premium uniquement), Front Door peut joindre un backend privé (sans IP publique), via le backbone Microsoft.

Distinction Private Link vs Private Endpoint (rappel fiche 2) :

• Private Endpoint = la NIC privée créée dans le VNet pour joindre un PaaS
• Private Link Service = ce qu'on déploie pour exposer un service à des consommateurs
• Front Door + Private Link = Front Door (le consommateur) crée une connexion Private Link vers le backend privé. La connexion est approuvée côté backend.

Backend privé via Internal LB

Front Door fonctionne normalement avec des adresses publiques. Pour cibler un backend privé : on place un Load Balancer interne avec un Private Link Service activé dessus, l'ILB pointe vers les VMs, puis Front Door pointe vers l'ILB via Private Link.

Flux :

Client → Front Door Premium (anycast public)
            ↓ Private Link (backbone MS, approuvé)
         Internal LB (Standard, avec Private Link Service)
            ↓
         VMs backend (aucune IP publique)

• Le backend (VMs) n'est jamais exposé publiquement
• Front Door joint l'Internal LB via Private Link
• Il faut approuver la connexion Private Link côté service

Option by ID / by alias

Lors de l'ajout d'un origin Private Link dans Front Door :

• By resource ID : on sélectionne la ressource Azure directement (même tenant, avec les droits)
• By alias : on utilise l'alias du Private Link Service (cross-tenant, ou quand seul l'alias fourni par le propriétaire du service est disponible)

C.9 Rule Set (Rules Engine) : conditions, actions, rewrite & redirect

Le Rule Set est le moteur de règles de Front Door : il transforme la requête au POP edge, avant le routage vers l'origin. C'est un mécanisme propre à Front Door, distinct du rewrite d'Application Gateway (comparaison en §C.9.6).

C.9.1 Anatomie d'une règle

Un Rule Set = un ensemble de règles, attaché à une ou plusieurs routes. Chaque règle = des conditions de match + des actions.

💡 Une règle sans condition s'applique à toutes les requêtes de la route (utile pour ajouter un header de sécurité partout).

C.9.2 Match conditions (liste vérifiée — Standard/Premium)

19 conditions disponibles. À retenir pour l'AZ-700, les libellés exacts du portail :

🔎 Front Door n'a pas de condition "response header" en match — on agit sur les réponses via les actions (Modify response header), pas en condition.

C.9.3 Actions (liste vérifiée)

C.9.4 URL rewrite (Front Door)

Réécrit le path en interne : l'origin reçoit le path réécrit, l'URL ne change pas dans le navigateur. 3 paramètres :

Exemple : Source /application/ → Destination /app/, Preserve unmatched path = Yes → /application/page.html est servi en interne comme /app/page.html. Avec Preserve = No → tout /application/... devient simplement /app.

💡 Pour retirer complètement le segment /pattern-to-match de la route, on met l'origin path du route à / (plutôt qu'un rewrite).

C.9.5 URL redirect (Front Door)

Renvoie une réponse de redirection au client (l'URL change dans le navigateur). Paramètres :

C.9.6 URL Rewrite vs URL Redirect

C.9.7 Server variables Front Door

Front Door a sa propre liste de server variables (syntaxe {variable}, différente d'App Gateway qui utilise {var_...}). Elles sont supportées dans les actions (rewrite, redirect, modify request/response header) — Front Door supporte aussi les server variables en condition de match (contrairement à la note "actions only" héritée du classic).

Variables vérifiées (liste MS Learn) :

Capture / casse : {url_path:seg#} capture un segment du path (ex extraire un tenantID de /abc/<tenantID>/...), {url_path.tolower} / {url_path.toupper} changent la casse.

🔎 Ne pas confondre avec App Gateway : là-bas c'est {var_uri_path}, {var_request_uri}, {var_host}, {var_client_ip}… (préfixe var_). Front Door n'utilise pas ce préfixe.

C.9.8 Ordre d'évaluation

Au POP edge, l'ordre est : WAF → route (dont le/les rule sets) → origin.

1. Le WAF est évalué en premier, puis les paramètres de la route, dont ses rule sets.
2. Plusieurs rule sets sur une route → traités dans l'ordre où ils apparaissent sous la route.
3. Plusieurs règles dans un rule set → traitées dans l'ordre d'affichage (haut→bas, priority ascendante, la 1ère listée = la plus prioritaire). Réordonnable avec les flèches.
4. Pour qu'une règle s'exécute, toutes ses conditions doivent matcher (AND). Si rien ne matche → seuls les réglages par défaut de la route s'appliquent.
5. Stop evaluating remaining rules (matchProcessingBehavior = Stop, défaut Continue) : si coché et la règle matche → toutes les règles restantes du rule set ET tous les rule sets suivants de la route sont ignorés.

💡 Le Rules Engine n'a pas de if/elseif/else natif (toutes les règles sont des if indépendants). On émule un if/elseif/else en mettant Stop evaluating sur chaque règle (la plus spécifique en premier) — uniquement si ce rule set est le dernier de la route.

🚨 Paths case-sensitive : dans le Rules Engine, les paths sont sensibles à la casse (utiliser {url_path.tolower} pour normaliser si besoin).

C.9.9 Front Door Rules Engine vs Application Gateway rewrite (2 mécanismes distincts)

Ce sont deux moteurs différents, pas la même fonctionnalité à 2 échelles.

🚨 Piège examen : un rewrite/redirect "au plus près de l'utilisateur, avant la région" → Front Door Rules Engine. Un rewrite avec re-routage vers un backend pool différent selon le path réécrit (Reevaluate path map) ou des variables de certificat client mTLS → App Gateway rewrite. Les deux peuvent coexister (Front Door en edge devant un App Gateway origin).

C.10 TLS sur Front Door : termination & end-to-end

Objectif AZ-700 : configurer la TLS termination et le chiffrement TLS end-to-end.

Front Door gère le TLS à 2 endroits distincts qu'il faut bien séparer :

Client ──TLS (HTTPS public)──► Front Door [termine le TLS] ──TLS ou HTTP──► Origin
        (1) côté frontend                                    (2) côté origin

(1) TLS termination (côté client → Front Door)

• Front Door termine toujours le TLS au POP edge (pour pouvoir cacher, inspecter WAF, router).
• Configuré au niveau endpoint / custom domain :
  • Certificat managé Front Door (gratuit, auto-renouvelé) — le plus simple
  • Certificat depuis Key Vault (ton propre cert, via Managed Identity)
• Sur la route : Accepted protocols = HTTPS only (+ redirect HTTP→HTTPS recommandé).
• Minimum TLS version : 1.2 par défaut (recommandé).

(2) End-to-end TLS encryption (Front Door → Origin)

Pour que le trafic soit chiffré jusqu'au backend (pas seulement jusqu'au POP), il faut configurer l'origin en HTTPS :

• Sur l'origin : Origin protocol / Forwarding protocol = HTTPS only (ou "Match incoming request")
• Front Door re-chiffre vers l'origin → end-to-end TLS
• Certificate subject name validation : Front Door valide que le certificat de l'origin correspond bien à son host name (protection contre le MITM). Désactivable pour les origins avec IP/cert auto-signé, mais déconseillé en prod.
• L'origin doit présenter un certificat valide signé par une CA trustée (sinon échec, sauf si validation désactivée).

Les 3 combinaisons

🚨 Piège : "Accepted protocols HTTPS only" sur la route ne concerne que le côté client (1). Pour le end-to-end, il faut aussi mettre l'origin en HTTPS (2). Les deux sont indépendants.

💡 Forwarding protocol "Match incoming request" : Front Door utilise le même protocole que celui reçu du client (HTTPS client → HTTPS origin). Pratique mais préférer HTTPS only explicite pour garantir le end-to-end.

D. Web Application Firewall (WAF)

D.1 Concept

Le WAF protège les apps web contre les attaques au niveau applicatif (L7), avant qu'elles atteignent le backend :

• OWASP Top 10 : injection SQL, XSS, etc.
• Geographic & IP filtering : bloquer/autoriser par pays ou IP
• Bot protection : bloquer les mauvais bots (scrapers, scanners)
• Rate limiting : limiter le débit de requêtes (protection DoS L7)

D.2 WAF Policy — ressource indépendante

Le WAF est une WAF Policy (ressource Azure séparée) qui contient les règles. Elle s'attache à un Front Door OU à un Application Gateway.

🚨 1 WAF policy = 1 type de service (Front Door OU App Gateway, jamais réutilisable entre les deux). Defense-in-depth = 2 policies distinctes.

D.3 WAF Front Door vs WAF App Gateway

Une WAF policy est soit globale (Front Door) soit régionale (App Gateway), et peut être attachée à plusieurs Front Door ou App Gateway du même type. Sur App Gateway, l'attache se fait au niveau listener ou path pour une granularité plus fine.

💡 WAF Front Door = bloque au plus proche de l'attaquant (avant qu'il atteigne l'Europe). WAF App Gateway = granularité fine par path/listener.

D.4 Managed Rules vs Custom Rules

Managed Rule Sets (versions à jour 2026)

Front Door (DRS) — ⚠️ toutes les managed rules DRS sont Premium uniquement (le tier Standard ne supporte QUE les custom rules) :

• DRS 2.2 : dernière version (GA fév. 2026), baselined sur OWASP CRS 3.3.4 + protections propriétaires Microsoft Threat Intel. Recommandée pour les nouvelles policies
• DRS 2.1 : baselined CRS 3.3.2 — reste la version affichée par défaut dans le portail Front Door
• 🚨 Ne pas dire "DRS 2.1 = Premium only" comme si la 2.2 ne l'était pas : 2.1 ET 2.2 sont Premium-only sur Front Door
• Bot Manager 1.0 / 1.1 : catégorise les bots (Good / Bad / Unknown), Bot Manager 1.1 = protection renforcée (Premium)

App Gateway (CRS) :

• CRS 3.2 / 3.1 / 3.0 (OWASP Core Rule Set)
• DRS aussi supporté dans les versions récentes

D.5 Custom Rules — types

D.6 Modes WAF

🚨 Toujours démarrer en Detection (pour identifier les faux positifs), puis basculer en Prevention après tuning. Lancer directement en Prevention = risque de bloquer du trafic légitime.

🏢 Scénarios d'entreprise (CAF/WAF)

Scenario 1 : App SaaS globale — Front Door Premium multi-région

Contexte business : Un SaaS B2B sert des clients dans 30 pays. L'app est déployée dans 4 régions (WEU, EUS, SEA, BRS). Besoins : la meilleure latence selon la région, une bascule instantanée, un WAF géré, un CDN pour les fichiers statiques, et un backend jamais exposé. Choix architectural : Front Door Premium + WAF managé (DRS 2.2 + Bot Manager) + Private Link vers des App Services privées + cache sur les fichiers statiques. Architecture / pattern :

• Front Door Premium, endpoint app.saas.com (domaine perso + certificat géré)
• Un origin group avec les 4 App Services (un par région), routing Latency (le POP le plus proche du visiteur)
• Private Link vers chaque App Service (accès public désactivé, liaison approuvée)
• WAF Premium : DRS 2.2 (Prevention après réglage) + Bot Manager 1.1 + une limite de débit custom sur /api/*
• 2 routes : /static/* (cache activé + compression) et /api/* (cache désactivé)
• Une règle custom pour bloquer les pays sous sanctions Trade-offs assumés :
• Gain : meilleure latence par POP, bascule globale instantanée, WAF managé et origines jamais exposées.
• Perte : tier Premium requis (coût), routage par latence inadapté à une résidence des données stricte. Pièges à éviter :
• Le tier Standard → pas de règles managées ni de Private Link. Ici il faut Premium
• Mettre /api/* en cache → données périmées (on cache des réponses dynamiques). Ne cacher que le statique
• Laisser le backend public sans restriction par Service Tag → on peut contourner Front Door. Restreindre via AzureFrontDoor.Backend + l'en-tête X-Azure-FDID
• Lancer le WAF direct en Prevention → des faux positifs bloquent du trafic légitime. Rester en Detection 1-2 semaines d'abord

📐 Réf. CAF/WAF — Sécurité (protéger l'origine) : le pilier Sécurité du service guide Front Door recommande de protéger les origines via Private Link (pas d'IP publique) et de n'accepter que le trafic passant par Front Door. Lien

Scenario 2 : Failover Azure ↔ autre cloud — Traffic Manager Priority

Contexte business : Une entreprise multi-cloud a son app principale sur Azure (App Service) et un site de secours sur AWS (pour survivre à une panne du cloud entier). Elle veut basculer via DNS si Azure tombe complètement. Choix architectural : Traffic Manager en routing Priority (endpoint Azure en priorité 1, endpoint externe AWS en priorité 2). Architecture / pattern :

• Profil TM app-prod, routing Priority
• Endpoint 1 : Azure (App Service WEU), priorité 1
• Endpoint 2 : externe (le FQDN de l'ALB AWS), priorité 2
• Surveillance : HTTPS sur /health toutes les 30s, 3 échecs tolérés, TTL 30s
• DNS : www.app.com CNAME app-prod.trafficmanager.net
• Si Azure tombe (3 sondes en échec) → TM renvoie l'IP AWS → bascule Trade-offs assumés :
• Gain : failover cross-cloud (Azure → AWS) via DNS, secours qui survit à une panne du cloud entier.
• Perte : bascule DNS jamais instantanée (TTL + cache resolver), pas de WAF/cache au niveau du routage. Pièges à éviter :
• Penser à Front Door → il ne peut pas facilement prendre un backend AWS comme secours cloud (possible via Custom origin, mais TM est plus naturel pour une bascule DNS entre clouds)
• Bascule lente : un TTL de 60s + le cache du resolver client → certains utilisateurs restent sur l'Azure mort quelques minutes. TTL 30s réduit ça, mais ce n'est jamais instantané (c'est une limite du DNS)
• Oublier l'endpoint Default → NXDOMAIN si les 2 sont tombés
• Sonde sur / (toujours 200) au lieu de /health (vrai test)

📐 Réf. CAF/WAF — Architecture load balancing options (choix global LB) : le decision tree d'architecture place Traffic Manager (DNS-based) comme couche de routage global pour les topologies active-passive cross-region, y compris vers des backends hors Azure. Lien

Scenario 3 : Data residency GDPR — Traffic Manager Geographic

Contexte business : Une app européenne a une règle stricte : les données des utilisateurs UE doivent être traitées en UE, et celles des autres ailleurs (compliance GDPR, résidence des données). Le routing doit suivre la géographie de façon stricte. Choix architectural : Traffic Manager en routing Geographic (UE → backend UE, le reste → backend US). Architecture / pattern :

• Profil TM app-geo, routing Geographic
• Endpoint 1 : App Service WEU, zone géographique = Europe (tous les pays UE)
• Endpoint 2 : App Service EUS, zone géographique = World (tout le reste, sert de catch-all)
• Surveillance HTTPS
• Un utilisateur dont la requête vient d'une IP UE → routé vers WEU (les données restent en UE) Trade-offs assumés :
• Gain : routage géographique strict conforme GDPR (résidence des données UE vs reste du monde).
• Perte : routage basé sur l'IP du resolver DNS (et non du client), risque de mauvais routage via DNS public tiers. Pièges à éviter :
• Geographic se base sur l'IP du resolver DNS, pas du client → un utilisateur UE qui passe par Google DNS (US) peut être mal routé. À documenter
• Pas d'endpoint Default/catch-all → NXDOMAIN pour les pays non mappés
• Vouloir faire de la résidence des données avec Front Door → Front Door route par latence, pas par compliance géo stricte. Pour la compliance, c'est Traffic Manager Geographic
• Confondre Geographic (compliance, strict) et Performance (latence, au mieux)

📐 Réf. CAF/WAF — Fiabilité (méthodes de routage TM) : le service guide Traffic Manager recommande la méthode Geographic pour router selon l'origine géographique de la requête DNS, avec au moins un endpoint configuré sur All (World) pour couvrir toutes les régions. Lien

DEMO — chemins portail

1. DEMO — Configurer Traffic Manager

Reproduit ta démo. Weighted, 2 VMs.

Home > Traffic Manager profiles > + Create

1. Basics :
   • Name : myapp-prod (FQDN myapp-prod.trafficmanager.net)
   • Routing method : Weighted
   • RG, Subscription
2. Review + create

Configurer le monitoring :

myapp-prod > Configuration :

• Protocol : HTTP, Port : 80, Path : /health
• TTL : 30s (failover plus rapide)
• Interval : 30s, Tolerated failures : 3

Ajouter les endpoints :

myapp-prod > Endpoints > + Add

• Endpoint 1 : Type Azure endpoint, Target type Public IP, pip-vm1, Weight 50
• Endpoint 2 : pip-vm2, Weight 50

Test : ouvrir http://myapp-prod.trafficmanager.net → redirige vers une des 2 VMs (50/50).

💡 Certains changements de routing method nécessitent de retirer puis recréer les endpoints avant de pouvoir basculer.

2. DEMO — Configure Front Door pour WebApp

Reproduit ta démo. WebApps multi-régions.

Home > Front Door and CDN profiles > + Create > Custom create

1. Basics :
   • Profile name : afd-shop
   • Tier : Standard (ou Premium pour WAF managed + Private Link)
2. Endpoint :
   • + Add endpoint → name shop-prod → URL shop-prod-<hash>.azurefd.net
3. Origin group :
   • + Add → name og-webapp
   • Health probe : /health, HTTPS, 30s
   • Session affinity : Disabled
4. Origins (dans le groupe) :
   • + Add origin 1 : Origin type App Services, host webapp-eastus.azurewebsites.net, Priority 1, Weight 1000
   • + Add origin 2 : webapp-weu.azurewebsites.net, Priority 1, Weight 1000
5. Route :
   • + Add route → name route-default, Patterns /*, Protocols HTTPS only (redirect HTTP→HTTPS), Origin group og-webapp
6. Review + create

💡 Tu peux créer plusieurs endpoints (ex shop, admin, api) et plusieurs origin groups (un par rôle) dans le même profil.

3. DEMO — Front Door Caching & Acceleration

Reproduit ta démo. Activer le cache sur une route.

Front Door profile > Routes > route-default > Edit

• Caching : Enabled
• Query string caching behavior : Use query string (ou Ignore selon besoin)
• Compression : Enabled (Brotli/gzip)
• Save

Bonne pratique :

• Cache Enabled pour /static/*, /images/* (contenu statique)
• Cache Disabled pour /api/* (contenu dynamique → sinon stale data)

Pour gérer ça : 2 routes distinctes (/static/* avec cache, /api/* sans cache).

4. DEMO — Front Door avec routing & Private Link

Reproduit ta démo. Backend privé via Internal LB + Private Link.

Prérequis :

• Une WebApp ou des VMs derrière un Internal Standard LB
• Sur l'Internal LB : activer Private Link Service (le pointer vers le frontend de l'ILB)

Étape 1 — Upgrade Front Door en Premium (Private Link = Premium only) :

• Soit créer un profil Premium, soit upgrader le Standard existant

Étape 2 — Ajouter l'origin avec Private Link :

Front Door Premium > Origin groups > + Add an origin

• Origin type : Custom (ou la ressource)
• Enable Private Link : Yes
• Sélection : by resource ID (même tenant) ou by alias (cross-tenant, alias du PLS)
• Région, sub-resource

Étape 3 — Approuver la connexion Private Link :

Private Link Service (sur l'ILB) > Private endpoint connections → connexion Front Door Pending → Approve

Étape 4 — Route avec path spécifique :

Front Door Manager > Routes > + Add :

• Pattern : /app/*
• Origin group : celui avec le Private Link
• Save

Flux final : Client → Front Door (anycast public) → Private Link → Internal LB → VMs (aucune IP publique).

5. DEMO — Front Door URL Rules (Rewrite + Redirect)

Reproduit ta démo. /application → /app (rewrite) + un redirect.

Front Door profile > Rule sets > + Add rule set

1. Name : ruleset-shop
2. Rule 1 — URL Rewrite :
   • Name : rewrite-application
   • Condition : Request path Begins With /application/
   • Action : URL rewrite → Source pattern /application/, Destination /app/
   • → /application/xyz est servi en interne comme /app/xyz (transparent, l'URL ne change pas pour le client)
3. Rule 2 — URL Redirect :
   • Name : redirect-old-domain
   • Condition : Request path Begins With /old/
   • Action : URL redirect → 301 (Moved Permanently) → /new/
   • → le navigateur reçoit un 301, l'URL change vers /new/
4. Associer le rule set à la route

6. DEMO — Configure Global WAF (Front Door)

Reproduit ta démo. WAF Policy global associée au Front Door.

Home > WAF policies > + Create

1. Basics :
   • Policy for : Global WAF (Front Door)
   • Tier : Premium (match le tier du Front Door pour les managed rules)
   • Policy name : waf-global
   • Policy mode : Detection (audit avant Prevention)
2. Managed rules :
   • + Assign : Microsoft_DefaultRuleSet 2.2
   • + Assign : Microsoft_BotManagerRuleSet 1.1
3. Custom rules :
   • + Add : Name BlockNorthKorea, Priority 100, Match RemoteAddr GeoMatch KP, Action Block
   • + Add : Rate limit rule RateLimitAPI, Priority 200, threshold 1000/min, condition RequestUri contains /api/, Action Block
4. Association : associer au profil Front Door afd-shop (endpoint cible)
5. Review + create
6. Après tuning (1-2 semaines) → waf-global > Policy settings > Mode = Prevention > Save

💡 Matcher le tier : pour utiliser les managed rules (DRS) + Bot Manager, le Front Door doit être Premium et la WAF policy Premium. En Standard, seules les custom rules sont disponibles.

7. DEMO — WAF App Gateway (rappel, granularité path)

Application Gateways > Web Application Firewall > + Create policy

1. Policy for : Regional WAF (Application Gateway), Mode Detection
2. Managed rules : OWASP CRS 3.2
3. Custom rules : ex BlockGeo GeoMatch
4. Association : associer à l'App Gateway → au niveau listener ou path (granularité fine)