1 — Virtual Network Essentials

Réseau privé régional d'Azure → on y place ses ressources, découpées en subnets, avec contrôle du trafic via NSG, ASG et NAT Gateway.

A. Virtual Network (VNet)

Réseau privé régional isolé dans Azure → contient des ressources organisées en subnets. Permet aux ressources de communiquer entre elles, avec internet, et avec on-prem (VPN/ER).

A.1 Caractéristiques fondamentales

• Régional : un VNet existe dans une seule région (mais peering possible cross-region).
• Span toutes les AZ de la région : VNet et subnets sont automatiquement étendus sur toutes les Availability Zones (≠ NAT Gateway qui elle peut être zonale).
• Address space : un ou plusieurs CIDR. Recommandation 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.

A.2 Rappel CIDR

💡 Plus le préfixe est petit (/16), plus le réseau est grand. Plus le préfixe est grand (/32), plus c'est spécifique.

A.3 5 IP réservées par subnet

Azure réserve 5 IPs dans chaque subnet (donc /24 = 256 - 5 = 251 IPs utilisables) :

A.4 Connectivité par défaut

• ✅ Communication entre subnets d'un même VNet (system route par défaut)
• ✅ Accès outbound internet par défaut (IP éphémère MS — en cours de retrait, voir §C)
• ❌ 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

A.5 Subnets réservés (noms exacts)

⚠️ Le nom doit être exact (sensible à la casse). Pas de NSG sur AzureBastionSubnet (ou très limité). Pas de ressources tierces dans ces subnets dédiés.

🔑 Subnet dédié (exclusif) vs partageable : EXIGENT un subnet dédié sans aucune autre ressource → GatewaySubnet, AzureBastionSubnet, AzureFirewallSubnet, RouteServerSubnet, Application Gateway subnet, endpoints DNS Private Resolver, ainsi que certaines délégations strictes (ex SQL Managed Instance Microsoft.Sql/managedInstances). Partageables → subnets de VMs ordinaires, et délégations « tolérantes » qui acceptent la cohabitation VM/VMSS dans le même subnet (le service délégué déclare s'il veut un subnet shared ou dedicated).

A.6 Subnet delegation

Délégation d'un subnet à un service Azure (PaaS qui injecte ses ressources dans ton VNet) :

• Le service prend le contrôle exclusif du subnet
• Exemples : Microsoft.Web/serverFarms (App Service VNet integration), Microsoft.Sql/managedInstances, Microsoft.ContainerInstance/containerGroups, Microsoft.Network/dnsResolvers, Microsoft.DBforPostgreSQL/flexibleServers
• Un subnet peut avoir zéro, une ou plusieurs délégations ; le partage avec des VMs ad-hoc dépend du service délégué (certains exigent un subnet dédié, d'autres tolèrent la cohabitation)

B. IP Addressing

B.1 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, DBs
• Portée par la NIC (sauf LB / App GW où c'est sur la frontend IP de la ressource)

B.2 Public IP

Ressource séparée créée à part puis associée à VM, LB, App GW, VPN GW, NAT GW, Bastion, Firewall…

🚨 Standard SKU Public IP = Static allocation obligatoire (Dynamic n'existait que sur Basic, retiré sept 2025). Le SKU de la Public IP doit matcher celui du LB / VPN GW / NAT GW associé.

Configurations de zone (Standard) :

B.3 Public IP Prefix

Réserve une plage continue d'IPs publiques (/28 = 16 IPs, /29 = 8 IPs, /30 = 4 IPs, /31 = 2 IPs, /24 = 256 IPs).

Pourquoi ?

• Whitelist côté partenaires : tu communiques une seule plage 203.0.113.0/28 au lieu de 16 IPs unitaires.
• NAT Gateway scale : 1 Public IP = 64k ports SNAT. Avec un prefix /28 = 16 IPs × 64k = ~1M ports.
• Bring Your Own IP (BYOIP) / Custom IP Prefix : tu peux apporter ta propre plage IP publique (ASN à toi) → réutilises tes IPs réputées hors Azure.

Création : Public IP Prefixes > Create, choisir taille, zone éventuellement. Ensuite les Public IPs créées depuis ce prefix consomment automatiquement une IP de la plage.

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

1. Public IP attachée à la VM (frontend IP) → SNAT propre à la VM
2. NAT Gateway sur le subnet (recommandé multi-VM)
3. Public Load Balancer avec règles outbound
4. Default outbound IP Azure (éphémère — changement de comportement au 31 mars 2026 : les nouveaux VNets créés via l'API ont des subnets privés par défaut, plus d'outbound implicite ; MS recommande NAT GW partout)

B.5 SNAT et SNAT exhaustion

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.
• Cas typique : VMSS de backend qui appelle massivement une API externe.

B.6 IPv6 / dual-stack VNet

Azure VNet supporte le dual-stack : un VNet (et ses subnets) peut porter un range IPv4 + un range IPv6 simultanément. IPv4 et IPv6 coexistent → on migre progressivement sans recréer le déploiement.

• VNet/subnet dual-stack : on ajoute un bloc IPv6 à côté du bloc IPv4 existant. Le subnet IPv6 doit être exactement /64 (compatibilité routage on-prem futur).
• Private IPv6 : on applique un range IPv6 au VNet + subnets → les NICs reçoivent une IPv6 (statique ou dynamique).
• Public IP IPv6 : SKU Standard uniquement, gratuite (no charge, contrairement à l'IPv4). S'associe à NIC de VM, Standard Load Balancer (public/interne), App Gateway. DNS AAAA supporté.
• VM dual-stack obligatoire : 🚨 pas de VM/VMSS IPv6-only — chaque NIC doit avoir au moins une config IPv4. (IPv6 toujours en plus de l'IPv4.)
• NSG IPv6 : règles IPv4 et IPv6 dans le même NSG OK, mais ⚠️ on ne peut pas mélanger préfixe IPv4 + IPv6 dans une même règle. ICMPv6 non supporté dans les NSG. DDoS étendu aux Public IP IPv6.
• Ajout à un IPv4 existant : possible sans recréer, MAIS ⚠️ on ne peut pas ajouter un range IPv6 à un VNet ayant déjà des ressources avec resource navigation links en place.

🚨 Limitations (services NE supportant PAS l'IPv6) : VPN Gateway (sauf SKU AZ en preview ; un VNet IPv6-enabled ne peut pas avoir de VPN GW classique, ni peering UseRemoteGateway), Azure Firewall (le subnet Firewall doit rester IPv4-only ; le FW opère en IPv4 dans un VNet dual-stack), Route Server (IPv4 only), Virtual WAN (IPv4 only), conteneurs (ACI / Container Apps), PostgreSQL Flexible Server. Reverse DNS IPv6 non supporté.

C. NAT Gateway

Pose 1 ou plusieurs Public IPs en sortie, attaché au subnet. Toutes les VMs du subnet sortent par ces IPs.

C.1 Caractéristiques

• Sortie uniquement (aucune connexion inbound — pour ça utiliser LB Standard + NSG)
• 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)
• Attaché au subnet (pas à la NIC) — toutes les VMs du subnet bénéficient automatiquement
• Multiple subnets dans le même VNet : un NAT GW peut être attaché à plusieurs subnets simultanément
• Pas cross-VNet : un NAT GW est limité à 1 VNet (tu ne peux pas l'attacher à des subnets de VNets différents)
• Zone deployment : la NAT GW est déployée dans une zone précise (ex Zone 3) ou en no-zone

C.2 NAT Gateway et Availability Zones

🚨 VNet et subnet span sur toutes les AZ de la région. La NAT Gateway Standard (v1) est zonale : déployée dans une zone précise (ex Zone 1) ou en no-zone (Azure choisit la zone, sans visibilité). Le SKU StandardV2 est zone-redundant (réparti sur toutes les AZ, survit à une panne de zone).

Conséquence importante (SKU Standard zonal) : si la NAT GW est en Zone 1 et la VM en Zone 3, ça marche quand même (même région suffit). Mais si la Zone 1 tombe → ta NAT GW tombe → tes VMs de Zone 3 perdent le SNAT. Pour la HA → soit utiliser plusieurs NAT GW Standard dans plusieurs zones (zonal stacks : 1 subnet + 1 NAT GW zonale par AZ), soit choisir le SKU StandardV2 zone-redundant.

C.3 Priorité de routing outbound

Si une VM a à la fois :

• Une Public IP attachée à sa NIC
• Un NAT Gateway sur son subnet

➡️ La NAT Gateway gagne en outbound. La Public IP de la VM reste utilisable pour l'inbound, mais toute sortie passe par les IPs de la NAT GW.

C.4 NAT Gateway + Basic SKU

🚨 NAT Gateway (Standard et StandardV2) ne s'attache PAS à un subnet contenant des ressources Basic SKU (VMs avec Public IP Basic, Basic Load Balancer, etc.). Il faut migrer ces ressources vers Standard avant. C'est un piège classique sur les vieux environnements.

D. Network Security Group (NSG)

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

D.1 Composition d'une règle

D.2 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)

D.3 Association : Subnet vs NIC

• NSG associable à un subnet OU à une NIC (ou les deux en même temps).
• ⚠️ Les deux s'appliquent en série :
  • 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).

D.4 Limites

• Pas d'inspection L7 (pour ça → Azure Firewall ou App Gateway WAF)
• Pas de filtrage FQDN (Azure Firewall pour ça)
• Évalué uniquement pour le trafic IP

E. Augmented Security Rules (ASR)

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

E.1 Service Tags

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

Exemples utiles :

• Internet, VirtualNetwork, AzureLoadBalancer, AzureBastion
• Storage, Storage.WestEurope (régionalisable → meilleure granularité)
• AzureCloud, AzureCloud.WestEurope
• AzureActiveDirectory, AzureKeyVault, AzureBackup, AzureUpdateDelivery
• Sql, Sql.WestEurope
• AzureMonitor, EventHub, ServiceBus

❌ Pas de Service Tag custom. Tout est géré par MS — pour custom, utiliser ASG.

E.2 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 importantes :

• 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 (l'ASG se "lock" sur le VNet de la 1ère NIC ajoutée)
• 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

Cas d'usage typique : pour autoriser un ensemble de VMs à communiquer uniquement entre elles, on les regroupe dans un même ASG et on écrit une règle NSG Allow ayant cet ASG en source ET en destination (inbound et outbound).

ASG: app-asg → contient VM1, VM2, VM3
NSG rule: Source=app-asg, Destination=app-asg, Port=Any, Action=Allow

→ Les VMs du groupe communiquent librement entre elles, sans avoir à lister leurs IPs.

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

F. Azure Bastion & NSG pour l'administration distante

Objectif AZ-700 : "Configure an NSG for remote server administration, including Azure Bastion".

F.1 Le problème

Exposer RDP (3389) / SSH (22) sur internet = surface d'attaque majeure (brute-force, scans). On veut accéder aux VMs sans Public IP sur elles et sans VPN.

F.2 Azure Bastion

Bastion = service managé qui ouvre une session RDP/SSH vers tes VMs depuis le portail (HTML5/SSL) ou un client natif, en passant par une IP privée.

• Déployé dans un subnet dédié AzureBastionSubnet (nom exact, /26 minimum)
• Les VMs cibles n'ont pas besoin de Public IP → surface d'attaque réduite
• Accès à toutes les VMs des VNets peerés
• Auth : utilisateur local de la VM ou Entra ID (avec RBAC, en SKU Standard+)

F.3 SKUs Bastion

🚨 Piège : pour > 40 sessions RDP simultanées → upgrade Basic → Standard (host scaling) PUIS augmenter le nombre d'instances. ~20 RDP ou ~40 SSH par instance. ⚠️ Upgrade Basic → Standard = IRRÉVERSIBLE. Choisir Standard d'emblée si scaling/features prévus.

F.4 NSG pour l'administration distante (pattern sécurisé)

Le pattern attendu à l'examen pour sécuriser l'accès admin :

• NSG sur la VM : Deny RDP/SSH depuis Internet. Allow RDP/SSH uniquement depuis AzureBastionSubnet (ou le Service Tag) → seul Bastion peut atteindre la VM
• VMs sans Public IP → injoignables directement depuis internet
• Si pas de Bastion : restreindre la source NSG à ton IP perso (jamais Any sur 3389/22)

NSG VM (inbound) :
  - Allow RDP/SSH  Source=AzureBastionSubnet (ou VirtualNetwork)  → la VM accepte Bastion
  - Deny  RDP/SSH  Source=Internet                                → bloque l'exposition directe

💡 AzureBastionSubnet ne tolère quasi aucun NSG restrictif (Bastion gère sa propre sécurité — certaines règles spécifiques MS sont requises si on en met un). Le NSG restrictif va sur la NIC/subnet de la VM, pas sur le subnet Bastion.

F.5 DEMO — Déployer Bastion + NSG remote admin

Home > Bastions > + Create

1. Name bastion-hub, Region, SKU Standard (pour host scaling/Entra)
2. Virtual network : le VNet, subnet AzureBastionSubnet (/26, créé exprès)
3. Public IP : Standard (auto, pour le service Bastion lui-même)
4. (Standard) Instance count : 2-50, file transfer, native client
5. Review + create

NSG sur la VM cible : NSG > Inbound rules

• Allow RDP/SSH Source = VirtualNetwork (ou Service Tag) → Bastion passe
• Deny RDP/SSH Source = Internet, priority basse

Connexion : VM > Connect > Bastion → user/password, SSH key, ou Entra ID (Standard+).

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

Scenario 1 : SaaS multi-tenant — IP planning pour 200 clients enterprise

Contexte business : Un éditeur SaaS B2B doit héberger 200 clients, chacun dans son propre VNet (isolation exigée). Croissance : +50 clients/an. Tous les VNets se connectent à un hub partagé (auth, supervision). Choix architectural : Donner un /24 (256 IPs) à chaque client, un /22 au hub, et réserver un grand bloc global 10.100.0.0/14 (~260k IPs) pour tenir la croissance sans chevauchement. Architecture / pattern :

• Hub : 10.100.0.0/22 (sous-réseaux firewall /26, Bastion /26, services partagés /24).
• Spokes clients : 10.101.X.0/24 (un par client, jusqu'à 250+).
• Custom IP Prefix (BYOIP) pour les IPs publiques de prod → on garde les IPs déjà whitelistées par les partenaires.
• NAT Gateway avec un Public IP Prefix /28 par région → beaucoup de ports SNAT (~1M).
• Les mêmes ASG (web, app, db) répétés dans chaque spoke → règles NSG identiques partout. Trade-offs assumés :
• Gain : plan d'adressage propre, scalable à 200+ tenants, IPs stables.
• Perte : plus de rigueur à la conception ; un IPAM devient vite nécessaire. Pièges à éviter :
• Mettre des /16 "par sécurité" partout → on épuise le 10.0.0.0/8. Un /24 par client suffit.
• Utiliser 192.168.0.0/16 → conflit fréquent avec les LAN des clients en VPN.
• Oublier les 5 IPs réservées par subnet : un /29 n'offre que 3 IPs utilisables.
• IPs publiques sans Prefix → pas de plage stable à donner aux partenaires.

📐 Réf. CAF/WAF — Plan for IP addressing (landing zone, best practices) : structurer l'espace d'adressage par région et archétype de charge, sans overlap, en intégrant un IPAM pour le vending de souscriptions à 200+ tenants. Lien

Scenario 2 : Industrial IoT — usine 4.0 avec 3000 capteurs

Contexte business : Un équipementier auto déploie ~3000 capteurs SCADA/IoT sur un site pilote. Le réseau industriel (OT) doit rester totalement isolé de l'IT corporate. Budget serré, mais 10 sites prévus en 18 mois. Choix architectural : Un VNet /16 par usine (assez large pour 3000 devices et plus), des subnets séparés OT/management, des ASG pour isoler par criticité, et une NAT Gateway pour tout le trafic sortant. Architecture / pattern :

• VNet usine 10.50.0.0/16 → subnets iot-sensors /22 (1000+ IPs), gateways /24, mgmt /24, bastion /26.
• ASG critical-ot (PLC/automates) et monitor-ot (capteurs lecture). Règle NSG : monitor → critical = DENY (un capteur ne peut jamais écrire sur un automate).
• NAT Gateway avec 1 seule IP publique → tous les capteurs sortent avec la même IP, simple à whitelister.
• DNS custom vers le DC on-prem + Private Resolver pour les Private DNS Zones Azure. Trade-offs assumés :
• Gain : OT isolé, mouvement latéral bloqué, sortie internet maîtrisée.
• Perte : une seule IP de sortie = point unique si elle change ; VNet large à gérer. Pièges à éviter :
• Mettre les capteurs dans un /24 (251 IPs) → saturé à 3000 devices. Viser /22 minimum.
• NAT Gateway en Zone 1 sans secours → si la zone tombe, toute l'usine perd internet. Préférer "no zone" ou plusieurs NAT GW zonales.
• Pas d'ASG → règles NSG ingérables sur 10 sites.
• Mélanger OT et IT dans un même VNet → un ransomware sur l'ERP atteint les automates. VNets séparés obligatoires.

📐 Réf. CAF/WAF — Network Security (MCSB NS-1, segmentation boundaries) : isoler les workloads à haut risque (OT/PLC) dans des VNets dédiés et appliquer un NSG « deny by default » pour bloquer le mouvement latéral entre segments. Lien

Scenario 3 : Bring Your Own IP — migration FAI vers Azure

Contexte business : Un éditeur B2B possède une plage publique réputée (203.0.113.0/24, ASN à lui), whitelistée par 200+ partenaires depuis 10 ans. Il migre du FAI vers Azure. Perdre cette plage = 6 mois de re-whitelist côté partenaires. Choix architectural : Importer la plage dans Azure via Custom IP Prefix (BYOIP). Le /24 devient des IPs publiques Azure réutilisables sur LB, NAT GW, App Gateway → les partenaires n'ont rien à changer. Architecture / pattern :

• Dans Azure : Public IP Prefixes > + Create > Bring your own public IP prefix.
• Validation MS : une ROA (Route Origin Authorization) au RIR (RIPE/ARIN, Origin AS 8075) + un certificat X.509 auto-signé publié dans le WHOIS/RDAP + un message signé envoyé à Microsoft. (Pas de "LOA" : c'est ROA + signature RPKI/X.509.)
• Une fois validé, la plage 203.0.113.0/24 sert à créer des Public IPs Standard.
• Migration douce : la NAT Gateway de prod utilise ces IPs → le trafic sortant garde les IPs historiques. Trade-offs assumés :
• Gain : IPs historiques conservées, zéro impact sur les whitelists partenaires.
• Perte : validation lente et administrative ; fenêtre de bascule à planninger. Pièges à éviter :
• Importer un /24 partiel → BYOIP exige le prefix complet et contigu.
• Croire que la bascule est instantanée → validation asynchrone : ROA disponible ≥24 h après soumission au RIR, provisioning ~30 min, commissioning 3-4 h (annonce BGP progressive). Prévoir surtout le délai RIR en amont.
• Commissionner dans Azure alors que le FAI annonce encore la plage → double annonce BGP (même ASN 8075) → instabilité. Basculer en fenêtre de maintenance.
• Mixer IPs BYOIP et Azure sur la même NAT GW → impossible de garantir l'IP de sortie. Ne mettre que le BYOIP sur la NAT GW critique.
• Oublier la propagation BGP → en DR cross-region, la plage n'est annoncée qu'à la région d'origine.

📐 Réf. CAF/WAF — Custom IP address prefix (BYOIP), processus Validation → Provision → Commission : la plage reste sous ta propriété, doit être un /24 minimum enregistré au RIR, et n'est annoncée qu'au passage en état Commissioned (ASN 8075). Lien

DEMO — chemins portail

1. DEMO — Configuring a VNet

Chemin : Home > Virtual networks > + Create

1. Basics : Subscription, Resource group, Name, Region
2. IP addresses :
   • Address space : ex 10.10.0.0/16
   • Subnets : + Add subnet
     • Name : web-subnet
     • Subnet address range : 10.10.1.0/24
     • (Optionnel) NSG, Route table, Service endpoints, Delegation
   • Ajouter d'autres subnets : app-subnet 10.10.2.0/24, db-subnet 10.10.3.0/24
3. Security : (optionnel) Azure Bastion, DDoS, Firewall
4. Tags > Review + create

⚠️ Au moins un subnet doit être défini à la création. Le redimensionnement d'un subnet plein est galère après → bien penser l'address space dès le début.

2. DEMO — Create a Public IP Address and NAT Gateway

Étape 1 — Public IP :

Home > Public IP addresses > + Create

1. Basics :
   • SKU : Standard (Basic indisponible depuis sept 2025)
   • Tier : Regional
   • Name : pip-natgw-01
   • IP version : IPv4
   • Assignment : Static (forcé en Standard)
   • Availability zone : Zone-redundant ou Zone 1/2/3
2. Review + create

Étape 2 — NAT Gateway :

Home > NAT gateways > + Create

1. Basics :
   • Name : natgw-prod
   • Region : même que le VNet
   • Availability zone : No zone ou Zone 1/2/3 (choix structurel)
   • Idle timeout : 4 min (par défaut, ajustable 4-120 min)
2. Outbound IP : sélectionner la Public IP pip-natgw-01 (ou un Public IP Prefix)
3. Subnet : sélectionner le(s) subnet(s) à attacher (ex web-subnet, app-subnet)
4. Review + create

Vérification : depuis une VM du subnet, curl ifconfig.me → doit retourner l'IP du NAT GW.

3. DEMO — Configure a Zonal NAT Gateway with IP Prefix (AZ-700 specific)

Use case : on veut plusieurs IPs publiques pour la sortie d'un subnet (résoudre SNAT exhaustion sur un backend chargé) ET déployer la NAT GW dans une zone précise.

Étape 1 — Public IP Prefix :

Home > Public IP Prefixes > + Create

1. Basics :
   • Name : pipprefix-natgw
   • Region : même que le VNet
   • IP version : IPv4
   • Prefix size : /28 (= 16 IPs), /29 (= 8 IPs), /30 (4), /31 (2)
   • Availability zone : Zone 3 (par exemple) — la zone du prefix conditionne la zone des IPs
2. Review + create

Azure assigne une plage continue, par exemple 203.0.113.16/28.

Étape 2 — NAT Gateway zonale :

Home > NAT gateways > + Create

1. Basics :
   • Name : natgw-zone3
   • Region : même que le VNet
   • Availability zone : Zone 3 (matcher la zone du prefix)
2. Outbound IP : onglet Public IP prefixes → sélectionner pipprefix-natgw
3. Subnet : sélectionner le subnet
4. Review + create

🔑 NAT Gateway et VM n'ont pas besoin d'être dans la même AZ : une VM en Zone 1 sort correctement par une NAT GW en Zone 3, le seul prérequis étant la même région. Attention toutefois au SPOF zonal décrit en §C.2.

4. DEMO — Configure NSGs

Home > Network security groups > + Create

1. Basics : RG, Name nsg-web, Region
2. Review + create
3. Inbound security rules > + Add :
   • Source : Service Tag → Internet
   • Source port ranges : *
   • Destination : Any
   • Service : HTTPS (port 443 prérempli)
   • Action : Allow
   • Priority : 100
   • Name : allow-https-in
4. (Optionnel) Add more rules : RDP/SSH restreint à ton IP perso, etc.
5. Subnets > + Associate : choisir VNet + subnet web-subnet
   • OU côté NIC : Network interfaces > + Associate

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

5. DEMO — Configure an NSG to use Augmented Security Rules (ASG)

Étape 1 — Créer l'ASG :

Home > Application security groups > + Create

1. Basics : RG, Name asg-app, Region
2. Review + create

Un ASG n'est pas lié à un VNet à la création — il se "lock" sur le VNet de la première NIC ajoutée.

Étape 2 — Ajouter les VMs à l'ASG :

Home > Virtual machines > <vm> > Networking > Application security groups > Configure ASGs

• Sélectionner asg-app → Save
• Répéter pour chaque VM concernée

⚠️ Toutes les NICs d'un ASG doivent être dans le même VNet.

Étape 3 — Règle NSG basée sur ASG :

NSG > Inbound security rules > + Add

• Source : Application security group → sélectionner asg-web
• Destination : Application security group → sélectionner asg-app
• Port : 8080
• Protocol : TCP
• Action : Allow
• Priority : 200
• Name : web-to-app-8080

Avantages :

• Pas besoin de connaître les IPs des VMs
• Quand on ajoute une nouvelle VM dans l'ASG → règle appliquée auto
• Scale VMSS sans rien changer dans le NSG

Exemple Service Tag (outbound) :

• Rule 1 (priorité 100) : Destination AzureBackup, Allow
• Rule 2 (priorité 200) : Destination Internet, ports 80,443, Deny

Service Tag régionalisé Storage.WestEurope plutôt que Storage global → réduit la surface d'attaque.