5 — Networking Extended

Routing avancé, connectivité inter-VNet, accès aux services PaaS en privé, hybride (on-prem ↔ Azure), DNS.

A. Routing — User Defined Routes (UDR)

Routes système par défaut (Azure crée auto)

• VNet local : trafic intra-VNet
• VNet peering : trafic vers VNet peerés
• 0.0.0.0/0 → Internet (next hop = Internet)
• Réservées : 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 100.64.0.0/10 → Drop si non utilisées

Route Table (UDR)

• Ressource Azure régionale → contient des routes custom.
• Associée au subnet (pas au VNet, pas à la NIC). Une route table peut être associée à plusieurs subnets.

Composition d'une route

Pour qu'une NVA route le trafic : activer IP forwarding sur sa NIC (sinon le paquet est droppé).

Précédence des routes (la plus spécifique gagne, sinon par type)

1. UDR (Custom)        ← gagne toujours
2. BGP (ExpressRoute, VPN dynamic)
3. System routes       ← fallback Azure

Cas typique : forcer le trafic via un Firewall NVA → UDR 0.0.0.0/0 → 10.0.0.4 (NVA) sur le subnet à filtrer.

💡 Service chaining (hub-spoke + NVA) : pattern où le trafic est routé à travers une séquence de NVAs (firewall, IDS) avant d'atteindre la destination. Setup :

1. NVA déployée dans VNet hub (peered aux spokes).
2. UDR sur subnets spokes : next hop = IP NVA dans hub, avec AddressPrefixes du LAN/VNet cible (ex: trafic on-prem 10.50.0.0/16 → NVA).
3. IP forwarding activé sur la NIC de la NVA.
4. Peering options : Allow forwarded traffic côté hub (sinon NVA peut pas relayer entre spokes).

Use case : trafic VPN/ER on-prem → spoke doit traverser NVA hub pour inspection avant d'atteindre les VMs spokes. Minimise les coûts (1 seul VPN GW + 1 NVA dans hub, pas besoin de GW par spoke).

B. VNet Peering

Connecte 2 VNets en privé via le backbone Azure → low latency, haute bande passante, pas de gateway requise.

💡 Perspective : le peering est config 2 fois (1 par côté A→B et B→A). Les 4 options se règlent par côté. Quand tu configures depuis VNet-A, "le peer" = VNet-B. Le portail crée souvent les 2 sens d'un coup si tu as les droits sur les 2 VNets.

Caractéristiques

• ✅ Cross region / subscription / tenant
• ❌ Pas d'overlap d'IP autorisé
• ❌ Pas de transitivité : A↔B et B↔C n'implique pas A↔C → pour ça, hub-spoke avec NVA ou Azure Firewall, ou Virtual WAN
• ❌ Pas chiffré par défaut (privé sur backbone MS, mais clair) — option Encryption disponible si les 2 VNets le supportent
• Bilatéral : configurer A→B et B→A (sinon "Disconnected")
• 📊 Limite : 500 peerings max par VNet → au-delà, passer sur Azure Virtual WAN (transitivité native)

💡 Peering en état Disconnected = l'un des 2 liens (A→B ou B→A) a été supprimé. Procédure de réparation : delete le peer restant + recréer les 2 (pas de "reconnect" in-place possible). Toucher au gateway transit / address space / subnet ne résout pas le Disconnected.

⚠️ Sync after address change : si tu modifies l'address space d'un VNet déjà peered, le peering peut passer en Disconnected ou LocalNotInSync. Solution : Peering > Sync (pas besoin de delete + recreate). À ne PAS confondre avec le Disconnected "lien supprimé" qui exige delete + recreate des 2 côtés.

Options de peering

💡 Couple Allow gateway transit ↔ Use remote gateways : les 2 vont toujours ensemble en miroir :

• Hub (qui a la GW) → Allow gateway transit = "je prête ma GW"
• Spoke (qui veut l'utiliser) → Use remote gateways = "j'emprunte celle du Hub" Les 2 doivent être ON pour que ça fonctionne.

💡 Allow forwarded traffic : autorise le trafic relayé (transité par une NVA / Azure Firewall) à entrer dans le VNet, pas juste le trafic émis directement par les VMs du peer. Indispensable quand Hub-Spoke avec NVA centrale qui route entre spokes.

💡 Désactiver Allow VNet access = aucun trafic VM↔VM, dans aucun sens (pas de "single direction"). Cas légitime rare : peering uniquement pour gateway transit (Spoke utilise VPN du Hub sans pouvoir taper sur les VMs du Hub). Pour du blocage à sens unique → utilise des NSG, pas le peering.

⚠️ Gateway transit incompatible avec le VPN Gateway Basic SKU (Standard min). Spoke ne peut consommer qu'1 remote gateway à la fois.

Config typique Hub-and-Spoke (Spoke utilise GW + Firewall du Hub) :

→ Symétrie miroir entre chaque paire Hub↔Spoke.

C. Accès privé aux services PaaS

Service Endpoint

Permet à un subnet d'accéder à un service PaaS public (Storage, SQL…) via le backbone MS au lieu d'internet, sans IP publique côté ressource.

• Configuré au niveau du subnet : Subnet > Service endpoints > Microsoft.Storage
• Active pour tous les comptes du même type (Storage, Sql, KeyVault…) → granularité limitée
• Du côté du service : ajouter le subnet dans Networking > Selected networks > Virtual networks
• Service Endpoint Policy : optionnelle, restreint à des comptes spécifiques (ex: seul mystorage accessible, pas les autres)
• ❌ Ne fonctionne pas pour on-prem (le subnet doit être dans Azure)

Private Endpoint & Private Link

Approche plus moderne et puissante :

• Private Link = la techno qui permet d'exposer un service Azure (ou tiers) avec une IP privée dans ton VNet.
• Private Endpoint = la NIC concrète déployée dans ton subnet, qui porte l'IP privée vers le service.

Comparaison clé

Pour Private Endpoint : intégrer une Private DNS Zone (privatelink.blob.core.windows.net, privatelink.database.windows.net, etc.) sinon la résolution renvoie l'IP publique.

D. Resource Firewalls

Pour les ressources avec public endpoint (Storage, SQL, KeyVault, App Service…) → restreindre qui peut s'y connecter, côté ressource :

• Resource > Networking > Public network access
  • Disabled : accès uniquement via Private Endpoint
  • Enabled from selected virtual networks and IP addresses : whitelist VNets (Service Endpoint) + IP/CIDR
  • Enabled from all networks : ouvert (par défaut historique, à éviter en prod)
• L'accès via Private Endpoint continue de fonctionner même si public access disabled.

E. Hybrid Connectivity

E.1 VPN Gateway

VNet Gateway en mode VPN → tunnel IPsec/IKE entre on-prem et Azure ou entre VNets/clients.

Site-to-Site (S2S)

• 1 VPN device on-prem (firewall, routeur compatible IKEv2)
• 1 Local Network Gateway (objet Azure qui décrit l'on-prem : IP publique + plages d'adresses)
• 1 VPN Gateway dans le GatewaySubnet
• 1 VPN Connection entre les deux

🚨 Ordre exact S2S avec BGP (drag-and-drop tutorialdojo), en supposant le VNet déjà déployé :

1. Deploy GatewaySubnet (/27 minimum, nom exact obligatoire)
2. Deploy VPN Gateway BGP-enabled (route-based, SKU VpnGw1AZ+)
3. Deploy Local Network Gateway (représente l'on-prem)
4. Deploy VPN Connection (relie VPN GW + Local GW, shared key)

Mnémo : GS → VPN GW → Local GW → Connection. Le LNG vient APRÈS la VPN GW (pas avant) car la connection a besoin des 2 endpoints créés. BGP doit être activé sur la VPN GW pour que le routing soit dynamique (auto-adapt aux changements topologie chez le branch office).

Point-to-Site (P2S)

• 1 VPN Client sur un poste utilisateur (pas de matériel on-prem)
• Authentification : Certificat, Entra ID (OpenVPN), RADIUS
• Protocoles : OpenVPN (TCP/UDP, recommandé), IKEv2, SSTP

🚨 Piège exam — re-télécharger le client config : à chaque changement de topologie du VNet (ajout d'un peering, gateway transit, nouveau subnet routé) → le VPN client config existant ne contient pas les nouvelles routes. Action obligatoire : VPN Gateway > Point-to-site configuration > Download VPN client → réinstaller le package sur les postes. Le tunnel marche pour TDVnet1 mais pas TDVnet2 nouvellement peeré tant que le client n'est pas mis à jour. Pas besoin de redémarrer la GW ni de toucher transit gateway.

🚨 Piège exam : VPN type policy-based vs route-based

Type	Protocole	Supporte P2S ?	Supporte multi-tunnels S2S ?
Policy-based (static)	IKEv1	❌ NON	❌ Un seul tunnel
Route-based (dynamic) ⭐	IKEv2	✅ OUI	✅ Multi-tunnels, BGP

Pour P2S il FAUT route-based. Si ton VPN GW est policy-based → il faut le supprimer + recréer en route-based (pas de conversion in-place possible). Le type est figé à la création.

SKUs (à jour 2026)

Pour AZ-104 : retenir Basic limité (pas de transit, pas de BGP, pas d'AZ) + AZ SKUs = recommandés.

HA

• Active-Standby (par défaut) : 1 instance active, 1 passive (failover ~10s).
• Active-Active : 2 instances actives, 2 tunnels → bande passante doublée + plus de résilience.

E.2 ExpressRoute

Liaison privée dédiée entre on-prem et Azure via un partenaire connectivity (FAI ou exchange provider). Ne traverse jamais l'internet.

Composants

• ExpressRoute Circuit : la liaison logique (SKU, bandwidth, billing model)
• Peering :
  • Private peering : accès aux VNets Azure (cas le plus courant)
  • Microsoft peering : accès aux services PaaS publics (M365, Azure SQL public, etc.) via ExpressRoute
• ExpressRoute Gateway : déployée dans GatewaySubnet, attachée au circuit
• BGP obligatoire pour le routage

Modèles de billing

• Metered : forfait + facturation du trafic sortant
• Unlimited : forfait fixe, pas de coût trafic
• Local : moins cher, limité aux régions proches de la peering location

Variantes

• ExpressRoute Direct : connexion directe sans partenaire (10/100 Gbps, gros clients)
• ExpressRoute Global Reach : interconnecte 2 sites on-prem via le backbone Azure (entre 2 circuits)
• FastPath : bypass de la gateway pour data plane (latence réduite)

E.3 Virtual WAN (vWAN)

Service global managé qui simplifie la connectivité multi-sites/multi-VNets en hub-spoke à grande échelle.

• 1 Virtual WAN = ressource globale
• 1+ Virtual Hub par région (hub managé par MS, contient les gateways VPN/ER + routing)
• Connexions supportées par hub : VNets, VPN S2S, VPN P2S (User), ExpressRoute, inter-hub
• Hubs interconnectés automatiquement (any-to-any par défaut)

Use case : entreprise multi-régions/multi-sites → vWAN évite de monter 50 peerings + 10 VPN Gateways manuellement.

F. DNS

Public DNS Zone (Azure DNS)

• Pour résoudre tes domaines publics achetés chez un registrar.
• Process :
  1. Acheter le domaine chez un Registrar (GoDaddy, OVH, Azure App Service Domains…)
  2. Créer une DNS Zone dans Azure → Azure fournit 4 NS records
  3. Configurer ces 4 NS records chez le Registrar pour déléguer
  4. Ajouter les records dans la zone (A, CNAME, MX, TXT, SRV…)

🚨 Import de zone file (BIND) : pour migrer une zone DNS existante vers Azure DNS, l'import de zone file est supporté UNIQUEMENT via :

• Azure CLI (az network dns zone import -g rg -n zone.com -f zonefile.txt)
• Portail Azure (DNS zone > Import zone file)

❌ Pas supporté : Azure PowerShell (pas de cmdlet d'import bulk), ARM templates (déploient l'infra, n'ingèrent pas de fichier), Azure Cloud Shell en tant qu'outil distinct (Cloud Shell exécute la CLI, mais c'est la CLI qui est l'outil — piège classique du QCM "Select TWO" qui propose Cloud Shell séparément).

Private DNS Zone

• Résolution interne aux VNets (sans serveur DNS perso).
• Lien avec un VNet via Virtual Network Link :
  • Registration enabled : les VMs du VNet enregistrent auto leur record (un seul VNet par zone peut avoir l'auto-registration).
  • Resolution only : les VMs résolvent mais n'enregistrent pas.
• Use case clé : intégration avec Private Endpoints. Zone à créer = privatelink.<service> selon le type (ex: privatelink.blob.core.windows.net, privatelink.database.windows.net, privatelink.azurewebsites.net).

💡 VNet ↔ Private DNS zones — règles complètes (piège exam) :

• Côté VNet : 1 VNet peut être lié à plusieurs Private DNS zones (résolution multi-domaines), mais max 1 seul lien en auto-registration (les autres zones liées au même VNet doivent être en mode "Resolution only").
• Côté zone : 1 zone = max 1 VNet en auto-registration. Plusieurs VNets supplémentaires en "Resolution only" possibles.
• Cross-region : un VNet peut être lié à une zone d'une autre region (même sub OK ; cross-sub avec prereqs).
• Modifier un lien existant pour activer/désactiver auto-reg = OK (pas besoin de delete + recreate).

Azure DNS Private Resolver (awareness AZ-104, deep dive AZ-700)

Service managé pour résolution DNS hybride (on-prem ↔ Azure) — remplace les DNS forwarder VMs custom.

💡 Doit être déployé dans un VNet : le Private Resolver n'a pas sa propre connectivité, il s'appuie sur la connectivité existante du VNet (VPN Gateway / ExpressRoute) pour atteindre l'on-prem. Pré-requis : tunnel VPN ou ER déjà établi entre Azure et on-prem.

2 types d'endpoints (déployés dans un subnet dédié au sein du VNet) :

DNS Forwarding Ruleset :

• Container de règles (jusqu'à 1000 par ruleset) : domain → IP DNS server cible.
• Liée à 1 ou plusieurs outbound endpoints + linkable à plusieurs VNets.
• Exemple : corp.contoso.com → 10.1.0.10 (DC on-prem).

Architecture typique hybride :

On-prem DNS  ──forward──>  Inbound endpoint (IP privée Azure)  →  résout privatelink.* zones
Azure VM   ──query──>  Outbound endpoint  ──ruleset──>  on-prem DNS

Subnets dédiés : 1 par endpoint, délégués à Microsoft.Network/dnsResolvers. /28 minimum. Pas d'autres ressources dedans.

DEMO — DNS Private Resolver (hors AZ-104, utile AZ-700)

Pré-requis : VNet Azure + tunnel VPN Gateway (ou ExpressRoute) actif vers on-prem. Sinon, le Resolver ne pourra pas parler à l'on-prem.

Phase 1 : Créer le DNS Private Resolver

1. Create > DNS Private Resolver
2. VNet : sélectionner le VNet hybride (où vit la VPN GW ou qui est peered au Hub).
3. Région : même que le VNet.

Phase 2 : Inbound Endpoint (on-prem → Azure)

Sert quand tes serveurs on-prem doivent résoudre des Private DNS Zones Azure (ex privatelink.blob.core.windows.net pour un Storage en Private Endpoint).

1. Dans le Resolver → Inbound endpoints > + Add
2. Subnet : créer un subnet dédié (ex subnet-dns-inbound, /28) → délégué à Microsoft.Network/dnsResolvers
3. IP allocation : Dynamic → Azure assigne une IP privée (ex 10.2.99.4)
4. Save → l'endpoint reçoit son IP privée Inbound (à noter, c'est elle qu'on configure côté on-prem)

Côté on-prem :

• Configurer le serveur DNS on-prem (Windows DNS / BIND) avec une Conditional Forwarder :
  • Domaine : privatelink.blob.core.windows.net (ou autre Private DNS Zone à résoudre)
  • Target : 10.2.99.4 (l'IP de l'Inbound Endpoint)
• Test depuis un PC on-prem : nslookup mystorage.privatelink.blob.core.windows.net → doit retourner l'IP privée du Private Endpoint

Phase 3 : Outbound Endpoint + Ruleset (Azure → on-prem)

Sert quand tes VMs Azure doivent résoudre des domaines hébergés on-prem (ex internal.acme.local).

1. Dans le Resolver → Outbound endpoints > + Add
2. Subnet : créer un 2ème subnet dédié (ex subnet-dns-outbound, /28) → délégué pareil
3. Save → l'endpoint reçoit son IP privée Outbound (ex 10.2.98.4)

Créer le DNS Forwarding Ruleset : 4. DNS forwarding rulesets > Create ruleset 5. Outbound endpoint : sélectionner celui créé à l'étape 1 6. Add rule :

• Domain name : acme.local (ou plus précis : internal.acme.local)
• Destination IP : 10.1.0.10 (IP du DNS server on-prem)
• Enabled ✅

7. Virtual Network Links : lier le ruleset aux VNets dont les VMs doivent résoudre acme.local (le VNet où vit le Resolver + Spokes peerés si besoin)

Côté VNet Azure :

• Les VMs des VNets liés au ruleset utilisent par défaut le DNS Azure (168.63.129.16)
• Quand une VM query myserver.acme.local → Azure DNS voit le ruleset → forward vers 10.1.0.10 via l'Outbound Endpoint → traverse le VPN/ER → atteint le DNS on-prem → résout → réponse remonte
• Pas de config DNS custom sur le VNet : tu laisses "Azure-provided DNS" (le Resolver s'intercale automatiquement via les rulesets)

Test bout-en-bout

Architecture finale

ON-PREM                                      AZURE
┌─────────────────────┐                     ┌──────────────────────────────────┐
│ DNS Server          │                     │ VNet (10.2.0.0/16)               │
│ 10.1.0.10           │                     │  ┌──────────────────────────┐    │
│   │                 │                     │  │ DNS Private Resolver     │    │
│   │ ┌─ Cond Fwder ──┼─ via VPN ──────────►│  │  Inbound: 10.2.99.4      │    │
│   │ │ privatelink.*  │                    │  │  Outbound: 10.2.98.4     │    │
│   │ │ → 10.2.99.4   │                     │  └──────────┬───────────────┘    │
│   │ │               │                     │             │                    │
│   │ ▼               │                     │     ┌───────▼──────────┐         │
│   └─ resolve local  │◄── via VPN ─────────┼─────┤ Ruleset:         │         │
│      domains        │                     │     │ acme.local →     │         │
└─────────────────────┘                     │     │  10.1.0.10       │         │
                                            │     └───────▲──────────┘         │
                                            │             │                    │
                                            │     ┌───────┴──────────┐         │
                                            │     │ VM Azure         │         │
                                            │     │ query acme.local │         │
                                            │     └──────────────────┘         │
                                            └──────────────────────────────────┘

💡 Recommandation : 2 subnets distincts (un pour Inbound, un pour Outbound), chacun /28. Pas mettre d'autres VMs dans ces subnets — délégués au service.

DEMO — chemins portail & commandes

UDR

1. Route tables > Create (région du VNet)
2. Routes > Add : Address prefix = 0.0.0.0/0, Next hop = Virtual appliance, IP NVA
3. Activer IP forwarding sur la NIC de la NVA (NIC > IP configurations > Enable IP forwarding)
4. Route table > Subnets > Associate → choisir le subnet à forcer

VNet Peering

Setup basique (VNet A ↔ VNet B simple) :

1. VNet A > Peerings > + Add
2. 2 sections à remplir d'un coup (Azure crée les 2 sens si tu as les droits sur les 2 VNets) :
   • This virtual network (= peering côté A vers B) : nom du peering, options côté A
   • Remote virtual network (= peering côté B vers A) : sélectionner VNet-B, nom du peering, options côté B
3. Vérifier : status Connected des 2 côtés (sinon Initiated = un côté manque)

Setup Hub-and-Spoke complet (Hub avec VPN GW + Spoke1 + Spoke2) :

1. Créer le VNet-Hub avec une VPN Gateway dans le GatewaySubnet (SKU ≥ Standard, pas Basic).
2. Peering Hub ↔ Spoke1 : VNet-Hub > Peerings > Add →
   • Côté Hub→Spoke1 : ✅ Allow VNet access | ✅ Allow forwarded traffic | ✅ Allow gateway transit (Hub prête sa GW)
   • Côté Spoke1→Hub : ✅ Allow VNet access | ✅ Allow forwarded traffic | ✅ Use remote gateways (Spoke1 emprunte la GW)
3. Répéter pour Spoke2 avec les mêmes options en miroir.
4. (Optionnel) Pour routage Spoke1 ↔ Spoke2 via NVA centrale dans le Hub :
   • Déployer une NVA ou Azure Firewall dans le Hub
   • Créer une UDR sur les subnets des Spokes : 0.0.0.0/0 ou 10.0.0.0/16 (range Spokes) → next hop = NVA dans le Hub
   • Activer IP forwarding sur la NIC de la NVA
   • L'option Allow forwarded traffic déjà activée laisse passer le trafic relayé

Exemples d'options par scénario :

Tester :

• Depuis VM dans Spoke1 → ping VM dans Hub ✅
• Depuis VM dans Spoke1 → ping IP on-prem (via VPN GW du Hub) ✅
• Si KO → vérifier le couple Gateway transit (Hub) + Use remote gateways (Spoke), tester avec Effective routes sur la NIC (NIC > Help > Effective routes)

Service Endpoint

1. Subnet > Service endpoints > Add Microsoft.Storage
2. Côté Storage : Networking > Selected networks > Add existing virtual network

Private Endpoint

1. Storage Account > Networking > Private endpoint connections > + Private endpoint
2. Choisir VNet/subnet + sub-resource (blob, file…)
3. Cocher "Integrate with private DNS zone" (sinon résolution KO)
4. Tester : depuis VM dans le VNet → nslookup mystorage.blob.core.windows.net doit renvoyer l'IP privée

S2S VPN

1. Virtual network gateway > Create (VNet, GatewaySubnet créé d'abord, SKU VpnGw1AZ+, Public IP Standard)
2. Local network gateway > Create (IP publique on-prem + address space LAN on-prem — plusieurs préfixes possibles : 192.168.1.0/24, 192.168.10.0/24, etc.)
3. VPN Gateway > Connections > Add (type Site-to-site, shared key, BGP optionnel)
4. Configurer le device on-prem côté FAI/firewall

💡 Pour plusieurs sites on-prem → 1 seule VPN Gateway + N Local Network Gateways (1 par site) + N Connections. Limite : 10-100 tunnels selon SKU.

P2S VPN

💡 P2S ≠ S2S : connecte des users individuels (laptops télétravail), pas un site entier. Pas de Local Network Gateway, pas de Connection — tout est config sur la VPN Gateway directement.

1. GatewaySubnet créé d'abord (/27 min, nom exact obligatoire)
2. Virtual network gateway > Create : Type VPN, VPN type Route-based (obligatoire, policy-based ne supporte PAS P2S), SKU VpnGw1+ (pas Basic), Public IP Standard
3. Configurer P2S sur la VPN GW : VPN Gateway > Point-to-site configuration > Configure now :
   • Address pool : range d'IPs distribuées aux clients (ex 172.16.0.0/24) — pas d'overlap avec VNet ni on-prem
   • Tunnel type : OpenVPN (SSL) ⭐ cross-platform / IKEv2 (Win/Mac) / SSTP (Windows legacy)
   • Authentication type :
     • Azure certificate : upload la clé publique de ta CA root → génère un cert client par user, à installer sur leurs machines
     • Microsoft Entra ID (OpenVPN only) : login Entra + MFA via Conditional Access possible
     • RADIUS : pointe vers serveur RADIUS on-prem
4. Download VPN client : VPN Gateway > Point-to-site configuration > Download VPN client → package zip avec profil pré-configuré
5. Installer côté user : importer le profil dans Azure VPN Client (Win/Mac/Android/iOS) ou OpenVPN GUI selon tunnel type. Si cert auth → installer aussi le cert client.
6. Connect : client se logge → reçoit IP de l'address pool → accède aux VMs du VNet.

🚨 Piège AZ-104 : si tu modifies la topologie (ajout peering, gateway transit, nouveau subnet routé) → le profil VPN client existant ne connaît pas les nouvelles routes. Action : re-download le client + ré-installer sur les postes. Pas besoin de redémarrer la GW ou toucher le gateway transit.

⚠️ Limite users connectés simultanément : ~128 (Basic SKU non supporté pour OpenVPN), jusqu'à 10 000 (SKU VpnGw5).

Storage Account Firewall

1. Storage > Networking > Public network access > Enabled from selected VNets and IPs
2. Add VNet (active Service Endpoint si pas déjà fait) + IPs autorisées
3. Onglet Exceptions : "Allow trusted Microsoft services" → laisser activé pour Backup/Monitor

Private DNS Zone

1. Private DNS zones > Create (ex privatelink.blob.core.windows.net)
2. Virtual network links > Add → choisir VNet, cocher auto-registration si besoin
3. Records ajoutés auto par le Private Endpoint

🏢 Scenarios d'entreprise réels — pensée d'architecte

Comment ces services s'utilisent dans la vraie vie. Pour chaque scenario : contexte business → choix techniques (uniquement les services traités dans la fiche) → pièges typiques.

Scenario 1 : Banque de détail — datacenter on-prem + Azure pour analytics

Contexte business : Banque retail française, core banking on-prem (mainframe + Oracle), Azure utilisé pour analytics (Synapse), reporting réglementaire et apps mobiles. PII et données financières doivent jamais traverser internet. Latence stable et SLA contractuel exigés. Choix techniques : ExpressRoute (pas VPN) en dual-circuit + Private peering + Hub-Spoke + Azure Firewall + Private Endpoints sur tout PaaS (Storage, SQL, KeyVault). Architecture / pattern :

• 2× ExpressRoute Circuits chez 2 partenaires différents (Equinix + Interxion) → résilience opérateur
• Billing Unlimited (trafic montant en TB/jour, le metered coûterait trop)
• Hub VNet contient : ExpressRoute Gateway (GatewaySubnet /27), Azure Firewall (AzureFirewallSubnet /26), Azure Bastion (AzureBastionSubnet /26)
• Spokes (analytics, reporting, mobile-backend) peerés au Hub avec Use remote gateways + Allow forwarded traffic
• Private DNS Zones liées au Hub (privatelink.database.windows.net, .blob.core.windows.net) → DNS Private Resolver pour que l'on-prem résolve les Private Endpoints
• UDR sur subnets spokes : 0.0.0.0/0 → Azure Firewall (forced tunneling pour inspection) Pièges à éviter :
• 1 seul circuit ExpressRoute = SPOF. La doc MS recommande 2 circuits actifs/actifs pour le SLA 99.95%
• Oublier la Private DNS Zone sur les Private Endpoints → l'on-prem tape l'IP publique du PaaS, bloquée par le firewall → 2h de debug pour une nslookup qui retourne la mauvaise IP
• Microsoft peering activé sans besoin → expose M365 sur ER alors qu'il peut sortir sur internet régulier. Garder ER uniquement pour le Private peering sauf use case précis
• Basic SKU VPN Gateway en backup ER → pas de gateway transit, pas de BGP → impossible de coexister proprement

Scenario 2 : Manufacturier multinational — 12 usines + IT central

Contexte business : Industriel (équipementier auto), 12 sites usine répartis sur 4 continents, IoT en bord usine (capteurs SCADA), backoffice IT (ERP, RH) à part. Trafic OT (operational tech) doit être strictement isolé du trafic IT corporate. Croissance : 2-3 nouveaux sites/an. Choix techniques : Azure Virtual WAN Standard (Secured Hub avec Azure Firewall) + ExpressRoute des grosses usines + S2S VPN des petits sites + 2 hubs régionaux (EMEA + APAC). Architecture / pattern :

• vWAN global avec 2 Virtual Hubs : hub-eu (West Europe) et hub-apac (Southeast Asia) → inter-hub auto any-to-any
• Sites usine HQ (Allemagne, USA, Chine) → ExpressRoute sur le hub régional le plus proche
• Petits sites (~50p) → S2S VPN route-based, BGP activé, 2 tunnels en active-active pour HA
• VNets OT (IoT, SCADA) et VNets IT (ERP, RH) sur le même hub mais routing custom : pas de route entre eux, sauf via le Firewall du Secured Hub
• P2S User VPN sur le hub EU pour télétravail Pièges à éviter :
• Partir en hub-spoke classique → à 12 sites + plusieurs VNets, on dépasse vite 500 peerings/VNet. vWAN native transitivité résout ça
• Mettre OT et IT dans le même VNet "parce que c'est plus simple" → un ransomware sur l'ERP atteint les automates. Toujours VNets séparés + Firewall obligatoire entre eux
• VPN policy-based (IKEv1) sur un vieux firewall on-prem → pas de multi-tunnel, pas de BGP, pas compatible vWAN. Forcer route-based
• vWAN Basic au lieu de Standard → pas d'ExpressRoute, pas d'inter-hub. Coup classique sur les démos qui ne scalent jamais

Scenario 3 : SaaS B2B — exposer ton service en privé à 200 clients enterprise

Contexte business : Éditeur SaaS B2B (HR-tech) qui sert des grands comptes (banques, assurances). Les clients exigent que leur trafic vers l'app ne traverse jamais internet. Modèle : 1 tenant logique = 1 client. Choix techniques : Azure Private Link Service côté producer + clients consomment via Private Endpoint dans leur propre VNet + Standard LB devant. Architecture / pattern :

• Côté SaaS (toi) : Standard LB avec frontend privé + Private Link Service attaché → expose un alias pls.saasco.com.privatelink.<region>... aux clients
• Côté client : ils créent un Private Endpoint dans leur VNet ciblant ton alias → IP privée dans leur address space (pas le tien, donc CIDR overlap entre clients = aucun souci, NAT transparente)
• TCP Proxy Protocol v2 activé pour récupérer la vraie source IP du client (sinon tu vois la NAT IP du PE et plus l'identité du tenant)
• Approval workflow : tu valides manuellement chaque demande de PE (auto-approbation possible via subscription whitelisting) Pièges à éviter :
• Croire qu'un Private Endpoint classique suffit → non, Private Link Service est pour exposer ton service à des clients tiers (Azure tiers ou autres tenants)
• Oublier le Proxy Protocol → impossible d'identifier le client en aval (tous arrivent avec la même IP NAT) → audit & per-tenant rate limiting cassés
• Faire 200 Private Endpoints depuis ton VNet vers chaque client → c'est l'inverse : eux créent le PE chez eux vers ton PLS
• Limite PLS : 8 frontend IPs par LB Standard, 1000 PE connexions max. Au-delà, plusieurs LBs ou repartir vers du DNS + TLS mutual

Scenario 4 : Santé / Hôpital régional — PHI sous HIPAA + télétravail médecins

Contexte business : GHT (Groupement Hospitalier de Territoire), 4 hôpitaux interconnectés. PHI (données patient) doivent rester en privé total. Médecins en astreinte se connectent depuis chez eux pour consulter le DPI (Dossier Patient Informatisé). Choix techniques : Hub-Spoke avec S2S VPN entre les 4 sites + P2S VPN Entra ID pour télétravail + Private Endpoints sur tout PaaS (SQL, Storage, KeyVault) + Azure Bastion pour accès admin VMs. Architecture / pattern :

• Hub VNet : VPN Gateway (VpnGw2AZ, active-active), Azure Bastion (/26), 4 S2S Connections (1 par site = 1 Local Network Gateway)
• 1 Spoke "DPI" : VMs apps + SQL Server avec Private Endpoint → résolution via Private DNS Zone privatelink.database.windows.net liée au hub
• 1 Spoke "Imagerie" : Storage Account avec PE + zone privatelink.blob.core.windows.net
• P2S VPN avec auth Entra ID + Conditional Access (MFA, device compliance) → médecins se connectent via Azure VPN Client → reçoivent IP du pool 172.16.50.0/24
• Tous PaaS : Public network access = Disabled (uniquement via PE) Pièges à éviter :
• Garder un Service Endpoint au lieu de PE → Service Endpoint ne marche pas depuis on-prem via VPN (le subnet doit être dans Azure). Le médecin en P2S ne pourrait pas accéder au Storage. PE obligatoire pour scénarios hybrides
• Cocher "Allow trusted Microsoft services" sur le Storage alors qu'on a passé tout le boulot à fermer le public → trou de sécurité. Sauf besoin précis (Backup), désactiver
• Ajouter un nouveau spoke peered → le profil VPN P2S sur les laptops médecins n'a pas les nouvelles routes. Action : re-download + ré-installer le client sur chaque poste (oubli classique → tickets support)
• DNS Private Resolver oublié → on-prem ne peut pas résoudre privatelink.*. Sans lui, l'app PACS on-prem cherche le Storage et reçoit l'IP publique (bloquée) → faux positif "Azure est down"

Scenario 5 : Fintech / paiement — multi-région isolée gov-grade

Contexte business : Fintech traitement de paiements (PSD2 + PCI-DSS). Production cloisonnée région-par-région (data residency UE), comm inter-services uniquement via backbone Azure, jamais internet. Audits Banque de France réguliers. Choix techniques : Hub-Spoke par région + Global VNet Peering avec Encryption + Private Endpoints partout + Azure Firewall en hub + UDR forced tunnel + pas d'internet sortant depuis les subnets prod. Architecture / pattern :

                ┌─────────── France Central ──────────┐
                │  Hub  ── Spoke prod-FR             │
                │   │                                 │
ER on-prem ─────┤   │ ── Azure FW ── UDR 0.0.0.0/0   │
                │   │                                 │
                └───┼─────────────────────────────────┘
                    │  Global VNet Peering (encrypted)
                ┌───┴─── West Europe ─────────────────┐
                │  Hub  ── Spoke prod-EU             │
                └─────────────────────────────────────┘

• Public network access = Disabled sur 100% des PaaS (SQL, Storage, KeyVault, Service Bus)
• Outbound prod : UDR 0.0.0.0/0 → Azure Firewall → AzFW applique FQDN filtering (whitelist *.visa.com, *.mastercard.com)
• Service Endpoint Policy sur le subnet apps : seuls les Storage Accounts du tenant accessibles (bloque exfiltration vers un Storage externe) Pièges à éviter :
• Global Peering activé sans cocher Encryption → backbone MS = privé mais pas chiffré. PCI-DSS le tolère, mais le RSSI le veut quand même
• AzFW en hub mais pas d'UDR sur les spokes → trafic shortcut direct internet via system route. L'UDR sur le subnet spoke est obligatoire pour forcer le passage
• ExpressRoute Standard au lieu de Premium → pas de Global Reach, pas d'accès cross-region depuis on-prem. Limite à la peering location locale
• Penser que Allow forwarded traffic se règle d'un seul côté → c'est par-côté dans le peering. Vérifier les 2 sens

Scenario 6 : Gov / défense — environnement isolé sans internet

Contexte business : Agence publique (régalien), workload classifié. Aucun accès internet entrant ni sortant. Admin via postes de travail dédiés sur LAN gov. Liaison vers Azure uniquement via ExpressRoute du tenant gov. Choix techniques : ExpressRoute Direct (10 Gbps physique sans partenaire) + Microsoft peering désactivé + Azure Firewall forced tunnel vers on-prem + Bastion pour admin VMs (pas d'IP publique) + Service Endpoint au lieu de PE quand suffisant (gratuit) — sinon PE. Architecture / pattern :

• ExpressRoute Direct : ports physiques 100 Gbps en colocation gov → pas de partenaire tiers (souveraineté)
• Microsoft peering OFF, Private peering ON uniquement → aucun trafic public via ER
• UDR : 0.0.0.0/0 → 10.0.x.x (IP de l'on-prem firewall via ER GW) = forced tunneling vers on-prem pour tout outbound, où l'admin filtre et logue
• Azure Bastion Standard (pas Basic) → support du shareable link, session recording, just-in-time via PIM
• VMs : aucune Public IP, ASG mgmt-asg, NSG Source: AzureBastionSubnet > 3389/22 Allow Pièges à éviter :
• ExpressRoute classique avec partenaire opérateur → la souveraineté exige Direct (pas d'intermédiaire qui voit le trafic). Premier réflexe à challenger
• VPN Gateway en backup → policy gov refuse souvent toute connectivité internet, même IPsec chiffré. Mieux : 2ème circuit ER Direct
• Bastion Basic déployé alors qu'il faut PIM + session recording (audit gov) → Standard SKU obligatoire
• Oublier que AzureBastionSubnet ne tolère aucun NSG (sauf rules spécifiques très strictes) — historiquement source de tickets "Bastion ne déploie pas"