4 — Virtual Networking

Couche réseau privée d'Azure → permet aux ressources de communiquer entre elles, avec internet, et avec on-prem (via fiche 5).

💡 Azure DNS — délégation de sous-domaine (mini-section, niche AZ-104 mais peut tomber) : pour déléguer portal.tutorialsdojo.com à une autre Azure DNS zone, tu crées un NS record (Name Server) dans la zone parente tutorialsdojo.com qui pointe vers les 4 nameservers de la zone enfant portal.tutorialsdojo.com. Pas CNAME, pas TXT, pas PTR. NS = délégation, c'est la règle DNS standard.

Virtual Network (VNet)

Réseau privé régional isolé dans Azure → contient des ressources organisées en subnets.

Caractéristiques

• Régional : un VNet existe dans une seule région (mais peering possible cross-region).
• Address space : un ou plusieurs CIDR (RFC1918 : 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). Pas d'overlap avec les VNets peerés.
• Subnets : sous-divisions du address space, chaque subnet peut avoir un NSG / route table / service endpoint propre.
• 5 IP réservées par subnet : .0 (network), .1 (default gateway), .2/.3 (Azure DNS), .255 (broadcast). Donc un /24 = 251 IP utilisables.

Connectivité par défaut

• ✅ Communication entre subnets d'un même VNet (route system par défaut)
• ✅ Accès outbound internet par défaut (IP éphémère MS)
• ❌ Accès inbound : non par défaut (sauf Public IP attachée + NSG ouvert)
• Le VNet peering ajoute automatiquement les routes vers le VNet peer

Subnets réservés (noms exacts)

⚠️ Modifier un VNet/subnet n'est pas possible si des ressources existantes sont impactées (ex: changer le CIDR avec des subnets actifs, redimensionner un subnet plein).

IP Addressing

Private IP

• Attribuée automatiquement aux ressources dans le subnet (DHCP Azure).
• 2 modes : Dynamic (par défaut, peut changer après stop/dealloc) / Static (fixée, recommandée pour DC, FW, DNS internes).
• Pour la plupart des ressources : portée par la NIC. Pour LB / App Gateway : configurée sur la ressource elle-même (frontend IP).

Public IP

• Ressource séparée créée à part puis associée à VM, LB, App GW, VPN GW, NAT GW, Bastion, Firewall…
• 2 modes : Static (recommandé prod) / Dynamic (libre après dissociation).

Pour AZ-104 : retenir Standard SKU = inbound bloqué par défaut (zero-trust). Le SKU de la Public IP doit matcher celui du LB / VPN GW associé.

🚨 Standard SKU Public IP = Static allocation OBLIGATOIRE (pas Dynamic). Dynamic n'existait que sur Basic (retiré sept 2025). Donc tout nouveau Public IP = Standard + Static. Conséquence : pour associer une Public IP à un LB Standard, elle doit forcément être Standard + Static.

Outbound vers internet — 4 options (ordre de priorité Azure)

1. Public IP attachée à la VM (frontend IP)
2. NAT Gateway sur le subnet (recommandé pour multi-VM)
3. Public LB avec règles outbound
4. Default outbound IP Azure (éphémère, en cours de retrait pour les nouveaux VNets — MS recommande NAT GW)

💡 SNAT (Source NAT) : quand une VM en IP privée sort vers internet, sa private IP est traduite en Public IP au passage (sinon internet ne sait pas où renvoyer la réponse). Chaque connexion sortante consomme 1 port SNAT (sur ~64k dispos par Public IP). Trop de connexions simultanées → SNAT exhaustion = nouvelles sorties internet échouent.

NAT Gateway : pose 1+ Public IPs en sortie, attaché au subnet. Toutes les VMs du subnet sortent par ces IPs. SNAT scalable : jusqu'à 16 IPs ou Public IP Prefix → ~1M ports total → résout les soucis de SNAT exhaustion du default outbound (limité à ~1024 ports/VM). Pas de connexion inbound (sortie uniquement). 1 seule IP = SPOF possible → préférer plusieurs IPs pour HA.

Network Security Group (NSG)

Firewall stateful L3/L4 → règles allow/deny basées sur source/dest IP + port + protocole.

Composition d'une règle

Règles par défaut (non supprimables, priority 65000+)

Inbound :

• AllowVNetInBound (65000) — trafic interne au VNet et VNets peerés
• AllowAzureLoadBalancerInBound (65001) — health probes
• DenyAllInBound (65500)

Outbound :

• AllowVNetOutBound (65000)
• AllowInternetOutBound (65001)
• DenyAllOutBound (65500)

Association : Subnet vs NIC

• NSG associé à un subnet OU à une NIC (ou les deux en même temps).
• ⚠️ Les deux s'appliquent en série (pas l'un qui prend le dessus) :
  • Inbound : Subnet NSG → puis NIC NSG
  • Outbound : NIC NSG → puis Subnet NSG
• Si l'un des deux bloque, le trafic est bloqué → le plus restrictif gagne.
• Stateful : si inbound autorisé, le retour outbound l'est automatiquement (et inversement).

Limites

• Pas d'inspection L7 (pour ça → Azure Firewall ou App Gateway WAF, voir fiche 5).
• Évalué uniquement pour le trafic IP, pas pour les flux east-west déjà autorisés par le système.

Augmented Security Rules (ASR)

Simplifient les règles NSG en évitant les listes d'IP à rallonge.

Service Tags

Étiquettes gérées par Microsoft représentant des plages IP de services Azure (mises à jour auto).

Exemples utiles :

• Internet, VirtualNetwork, AzureLoadBalancer
• Storage, Storage.WestEurope (régionalisable)
• AzureCloud, AzureActiveDirectory, AzureKeyVault, AzureBackup
• Sql, AzureMonitor, EventHub

❌ Pas de Service Tag custom. Tout est géré par MS.

Application Security Groups (ASG)

Groupes logiques de NICs → permettent d'écrire des règles NSG par "rôle" (ex web-asg, db-asg) au lieu d'IPs.

Règles à connaître :

• ASG attaché à des NICs, pas directement à des VMs (mais ça revient au même).
• Toutes les NICs d'un ASG doivent être dans le même VNet.
• Quand un ASG est utilisé en source ET destination dans une règle, les ressources doivent être dans le même VNet.
• Une NIC peut appartenir à plusieurs ASGs.

Combo gagnant : NSG avec règle web-asg → db-asg port 1433 Allow au lieu de gérer des plages IP.

DEMO — chemins portail & pièges

Créer un VNet

1. Virtual networks > Create
2. Onglet IP addresses : définir address space + premier subnet (au moins un avant la création).
3. Modifier après coup : VNet > Address space ou Subnets > Add (impossible si overlap avec ressources actives).

Public IP + NAT Gateway

Public IP > Create
  SKU: Standard, Static, regional ou zonal
NAT Gateway > Create
  Associer la Public IP créée
  Onglet "Subnets" : sélectionner les subnets concernés

Une seule Public IP attachée = pas de SLA. Pour la prod : prefix /28 = 16 IPs ou plusieurs Public IPs.

NSG basique (RDP autorisé)

1. Network security groups > Create
2. Associer au subnet ou à la NIC de la VM (Subnets ou Network interfaces dans le NSG, ou Networking côté ressource)
3. Inbound security rules > Add :
   • Source: Any (ou IP perso pour limiter)
   • Destination: Any
   • Service: RDP (port 3389) — Azure pré-remplit
   • Action: Allow, Priority: 300

Best practice : restreindre source à ton IP, ou utiliser Azure Bastion au lieu d'exposer 3389/22 sur internet.

NSG + ASG

1. Créer l'ASG : Application security groups > Create (régional, sans VNet à la création)
2. VM > Networking > Application security groups > Configure ASGs → ajouter la VM dans l'ASG (ASG se "lock" sur le VNet de la première NIC)
3. Dans le NSG : règle Source: Subnet web > Destination: ASG mgmtservers > 3389 Allow
4. Outbound deny web sauf Azure Backup :
   • Rule 1: Destination: Service Tag AzureBackup > Allow
   • Rule 2: Destination: Service Tag Internet, ports 80,443 > Deny (priority plus haute que rule 1)

🏢 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 : SaaS B2B early stage — appli 3-tier monorégion

Contexte business : Startup SaaS RH (gestion paie) avec ~50 clients. 1 seule région (West Europe), équipe ops de 2 personnes. Besoin : isoler web / app / DB, exposer uniquement le frontend, simplifier les règles de sécurité. Choix techniques : 1 VNet /16 + 3 subnets (web, app, db) + 3 ASGs (web-asg, app-asg, db-asg) + 1 NSG par subnet. Pas de Public IP sur les VMs back/DB. Architecture / pattern :

• VNet 10.10.0.0/16 → subnets 10.10.1.0/24 (web), 10.10.2.0/24 (app), 10.10.3.0/24 (db)
• NSG-web : Internet → web-asg:443 Allow, deny le reste inbound
• NSG-app : web-asg → app-asg:8080 Allow (pas d'IPs, pas de plages — juste les ASGs)
• NSG-db : app-asg → db-asg:1433 Allow, deny VirtualNetwork sur le port 1433 sinon n'importe quelle VM du VNet pourrait taper
• Outbound web : NAT Gateway avec Static Public IP (whitelist côté partenaires de paiement) Pièges à éviter :
• Mettre les règles NSG par IP plutôt que par ASG → ingérable dès qu'on scale en VMSS
• Oublier de fermer le 1433 en VirtualNetwork → db-asg : un dev qui déploie une VM ad-hoc dans le subnet web peut alors taper la DB
• Ouvrir l'outbound Internet par défaut sur le subnet db → exfiltration possible. Bloquer outbound Internet sur app et db, n'autoriser que Service Tags spécifiques (AzureKeyVault, Storage.WestEurope)

Scenario 2 : E-commerce retail — DR cross-region actif/passif

Contexte business : Site e-commerce français (~2M visites/mois). Région primaire France Central, DR France South. RTO 1h, RPO 15min. Pas de connexion on-prem (full cloud). Choix techniques : 2 VNets sans overlap + Global VNet Peering + Private IP réservées Static pour les DBs (failover DNS plus simple). Architecture / pattern :

• VNet-Prod 10.20.0.0/16 (France Central) ↔ VNet-DR 10.30.0.0/16 (France South) en Global Peering
• CIDR distincts dès le départ (pas 10.0.0.0/16 partout, classique des PoCs qui finit en cauchemar)
• NAT Gateway dans chaque région avec Public IP Prefix /29 (8 IPs) → whitelist côté CDN et passerelles de paiement
• DBs en Static private IP (failover DNS pointe sur l'IP DR sans re-résoudre du dynamique) Pièges à éviter :
• CIDR overlap = le peering ne se fait jamais. Le réflexe "je copie le VNet prod en DR" plante direct
• Croire que Global Peering chiffre par défaut → non. Activer Encryption sur le peering si la donnée le justifie (compliance, PII)
• Public IP Basic sur le NAT GW : impossible depuis sept 2025 → forcément Standard + Static. Migrer les vieilles VMs qui ont encore une Basic IP

Scenario 3 : Studio gaming — backend multi-VMSS avec sortie internet massive

Contexte business : Studio gaming mobile, backend de matchmaking. ~30k connexions concurrentes en pic. Backend en VMSS qui appelle des APIs externes (Steam, Apple GameCenter, services de paiement). Choix techniques : NAT Gateway avec Public IP Prefix + Service Tags pour outbound restreint + NSG avec ASGs par micro-service. Architecture / pattern :

• VMSS dans subnet gameserv (/22 = ~1000 IPs utilisables pour le scale)
• NAT Gateway sur le subnet avec un Public IP Prefix /28 (16 IPs) → ~1M ports SNAT cumulés → résout le SNAT exhaustion typique des backends gaming
• ASGs : matchmaking-asg, lobby-asg, payment-asg. NSG outbound : payment-asg → Internet:443 Allow, le reste payment-asg → Internet Deny (PCI scope réduit)
• Service Tags pour outbound vers services Azure : AzureKeyVault, Storage.WestEurope, AzureMonitor Pièges à éviter :
• 1 seule Public IP sur NAT GW → ~64k ports → SNAT exhaustion en 10 min de prod. Prefix /28 obligatoire
• Laisser AllowInternetOutBound par défaut sur l'NSG du subnet payment → tout le scope PCI-DSS doit logger les flux internet, mieux vaut whitelist explicite par Service Tag
• Penser que le NAT GW gère l'inbound : non, sortie uniquement. Pour l'inbound LB Standard Public + NSG explicite

Scenario 4 : Cabinet d'architectes — agence à 30 personnes, dev test only

Contexte business : ESN qui héberge un environnement de test partagé entre devs. Pas de prod sur Azure. Budget serré. Choix techniques : 1 VNet simple, pas d'ASG (overkill ici), NSG sur la NIC des VMs sensibles + Service Tags pour Backup. Architecture / pattern :

• VNet 192.168.0.0/16 → 2 subnets : dev et shared-services (DC + file server)
• NSG sur NIC des serveurs sensibles (file server, DC) → règle inbound Source: subnet dev > Destination: Any > SMB/LDAP Allow
• Outbound : default Azure (acceptable en dev/test, à migrer vers NAT GW si volume monte)
• Règle outbound deny Internet sauf Service Tag AzureBackup + AzureUpdateDelivery (laisser Windows Update passer) Pièges à éviter :
• Multiplier les NSG (subnet + NIC) sans comprendre que les 2 s'additionnent → un dev passe 2h à debug "pourquoi le 3389 marche pas" alors que le NSG NIC bloque silencieusement
• Compter sur le "Default outbound IP" Azure → MS est en train de le retirer pour les nouveaux VNets. Anticiper : NAT GW même en dev
• Subnet /29 pour un AzureBastionSubnet futur : trop petit (/26 min). Penser l'address space dès le début, redimensionner un subnet plein est galère

Scenario 5 : Média / streaming — VNets régionaux pour edge processing

Contexte business : Plateforme de streaming vidéo (replay TV). Encodage à proximité des clients pour latence faible. 4 régions (West Europe, North Europe, France Central, UK South). Choix techniques : 4 VNets régionaux peerés en mesh partiel + Public IP zone-redundant pour les ingesters + NSG avec Service Tag régional Storage.WestEurope. Architecture / pattern :

• 4 VNets sans overlap : 10.40.0.0/16 (WEU), 10.41.0.0/16 (NEU), 10.42.0.0/16 (FRC), 10.43.0.0/16 (UKS)
• Mesh partiel : chaque VNet peered au "VNet central de catalogue" (PaaS metadata), pas entre eux (pas besoin)
• Public IP Standard zone-redundant sur les ingesters (résiste à une zone down)
• NSG outbound utilise les Service Tags régionalisés : Storage.WestEurope plutôt que Storage global → réduit la surface Pièges à éviter :
• Faire un full mesh 4×4 = 12 peerings inutiles. Hub-spoke ou mesh partiel selon le besoin réel
• Public IP zonal (1 zone) sur un ingester qui doit survivre à un zone outage → utiliser zone-redundant, pas zonal
• Service Tag Storage (global) au lieu de Storage.WestEurope → autorise tout Azure Storage du monde, élargit la surface d'attaque pour rien