📍 Article principal du cluster : Azure Solutions Architect Expert AZ-305 — guide complet 2026
Ce tutoriel fait partie du cluster certification AZ-305. Pour la vue d’ensemble, lisez d’abord le pilier.
Introduction
Le domaine 4 « Design infrastructure solutions » de l’AZ-305 inclut la conception réseau — sujet le plus dense en termes d’options Azure. Ce tutoriel construit la topologie hub-spoke de référence, le standard Microsoft pour les organisations qui scalent au-delà de 3-4 abonnements. Vous monterez un hub VNet centralisé hébergeant Azure Firewall et Bastion, deux spoke VNets peerés au hub pour les workloads, des Private Endpoints pour Storage et SQL, et une Application Gateway WAF v2 en frontend public. Toutes les configurations sont alignées avec le Cloud Adoption Framework Enterprise-Scale Landing Zone.
Prérequis
- Compte Azure et CLI configurés
- Tutoriels précédents AZ-305 terminés
- 50 minutes
Étape 1 — Créer le VNet hub central
Le hub centralise les services partagés (firewall, VPN gateway, Bastion, DNS Private Resolver). Pattern recommandé : un hub par région majeure, avec une plage d’adresses IP dédiée non chevauchante avec les spokes.
az group create --name rg-network-hub --location westeurope
az network vnet create \
--resource-group rg-network-hub \
--name vnet-hub-we \
--address-prefix 10.0.0.0/16 \
--location westeurope
# Subnet dédié à Azure Firewall (nom obligatoire AzureFirewallSubnet)
az network vnet subnet create \
--resource-group rg-network-hub \
--vnet-name vnet-hub-we \
--name AzureFirewallSubnet \
--address-prefix 10.0.1.0/26
# Subnet dédié à Bastion (nom obligatoire AzureBastionSubnet)
az network vnet subnet create \
--resource-group rg-network-hub \
--vnet-name vnet-hub-we \
--name AzureBastionSubnet \
--address-prefix 10.0.2.0/27
# Subnet dédié à VPN Gateway (nom obligatoire GatewaySubnet)
az network vnet subnet create \
--resource-group rg-network-hub \
--vnet-name vnet-hub-we \
--name GatewaySubnet \
--address-prefix 10.0.3.0/27
Les noms de subnet sont obligatoires pour Azure Firewall, Bastion et VPN Gateway — Azure les attend exactement. Mauvais nom = service refuse de se déployer. Erreur classique d’examen.
Étape 2 — Déployer Azure Firewall en hub
Azure Firewall Standard ou Premium est le pare-feu managé de Microsoft. Filtrage L3-L7, threat intelligence, TLS inspection (Premium), NAT règles. C’est le composant central du hub-spoke pour la sécurité.
# Public IP pour le firewall
az network public-ip create \
--resource-group rg-network-hub \
--name pip-azfw-hub \
--sku Standard \
--allocation-method Static \
--tier Regional
# Azure Firewall (Standard SKU)
az network firewall create \
--resource-group rg-network-hub \
--name azfw-hub-we \
--location westeurope \
--sku AZFW_VNet \
--tier Standard
# Configuration IP frontend
az network firewall ip-config create \
--firewall-name azfw-hub-we \
--resource-group rg-network-hub \
--name fw-config \
--public-ip-address pip-azfw-hub \
--vnet-name vnet-hub-we
FW_PRIVATE_IP=$(az network firewall show \
--name azfw-hub-we \
--resource-group rg-network-hub \
--query 'ipConfigurations[0].privateIPAddress' -o tsv)
echo "Firewall private IP: $FW_PRIVATE_IP"
Le coût Azure Firewall Standard est ~1,25 USD/heure soit ~900 USD/mois. Pour un labo non productif, on peut basculer sur l’Azure Firewall Basic (limité, 0,40 USD/heure). En production réelle, Standard ou Premium est obligatoire pour la threat intelligence.
Étape 3 — Créer les VNets spokes pour workloads
Les spokes hébergent les workloads applicatifs. Plages IP non chevauchantes avec le hub et entre spokes.
az group create --name rg-spoke-corp --location westeurope
az group create --name rg-spoke-online --location westeurope
# Spoke Corp — workloads internes
az network vnet create \
--resource-group rg-spoke-corp \
--name vnet-spoke-corp \
--address-prefix 10.10.0.0/16 \
--location westeurope
az network vnet subnet create \
--resource-group rg-spoke-corp \
--vnet-name vnet-spoke-corp \
--name subnet-app \
--address-prefix 10.10.1.0/24
az network vnet subnet create \
--resource-group rg-spoke-corp \
--vnet-name vnet-spoke-corp \
--name subnet-pe \
--address-prefix 10.10.2.0/24
# Spoke Online — workloads internet-facing
az network vnet create \
--resource-group rg-spoke-online \
--name vnet-spoke-online \
--address-prefix 10.20.0.0/16
az network vnet subnet create \
--resource-group rg-spoke-online \
--vnet-name vnet-spoke-online \
--name subnet-app \
--address-prefix 10.20.1.0/24
az network vnet subnet create \
--resource-group rg-spoke-online \
--vnet-name vnet-spoke-online \
--name AppGwSubnet \
--address-prefix 10.20.2.0/24
Le subnet `subnet-pe` est destiné aux Private Endpoints (étape 5). Le `AppGwSubnet` héberge l’Application Gateway WAF qu’on déploiera plus tard. Cette structure de subnets dédiés simplifie les NSG associations.
Étape 4 — VNet peering hub ↔ spokes
Le peering est la mécanique qui connecte les VNets entre eux. Bidirectionnel avec gateway transit pour permettre aux spokes d’utiliser le firewall et la gateway du hub.
HUB_ID=$(az network vnet show -g rg-network-hub -n vnet-hub-we --query id -o tsv)
CORP_ID=$(az network vnet show -g rg-spoke-corp -n vnet-spoke-corp --query id -o tsv)
ONLINE_ID=$(az network vnet show -g rg-spoke-online -n vnet-spoke-online --query id -o tsv)
# Hub vers Corp
az network vnet peering create \
--resource-group rg-network-hub \
--vnet-name vnet-hub-we \
--name hub-to-corp \
--remote-vnet $CORP_ID \
--allow-vnet-access \
--allow-forwarded-traffic
# Corp vers Hub avec use-remote-gateways
az network vnet peering create \
--resource-group rg-spoke-corp \
--vnet-name vnet-spoke-corp \
--name corp-to-hub \
--remote-vnet $HUB_ID \
--allow-vnet-access \
--allow-forwarded-traffic \
--use-remote-gateways
# Idem pour Online
az network vnet peering create \
--resource-group rg-network-hub \
--vnet-name vnet-hub-we \
--name hub-to-online \
--remote-vnet $ONLINE_ID \
--allow-vnet-access \
--allow-forwarded-traffic
az network vnet peering create \
--resource-group rg-spoke-online \
--vnet-name vnet-spoke-online \
--name online-to-hub \
--remote-vnet $HUB_ID \
--allow-vnet-access \
--allow-forwarded-traffic \
--use-remote-gateways
Les peerings ne sont PAS transitifs : Corp et Online ne peuvent pas se voir directement même peerés au hub commun. Pour permettre Corp → Online, il faudrait soit un peer direct, soit forcer le trafic via le firewall (recommandé).
Étape 5 — Forcer le trafic spoke→spoke via Azure Firewall
User Defined Routes (UDR) injectent une route 0.0.0.0/0 vers le firewall, ce qui force tout le trafic sortant du spoke à passer par le firewall pour inspection.
az network route-table create \
--resource-group rg-spoke-corp \
--name rt-spoke-corp
az network route-table route create \
--resource-group rg-spoke-corp \
--route-table-name rt-spoke-corp \
--name default-via-firewall \
--address-prefix 0.0.0.0/0 \
--next-hop-type VirtualAppliance \
--next-hop-ip-address $FW_PRIVATE_IP
# Associer la route table au subnet
az network vnet subnet update \
--resource-group rg-spoke-corp \
--vnet-name vnet-spoke-corp \
--name subnet-app \
--route-table rt-spoke-corp
Ce pattern « hub-spoke avec firewall central » est le standard Enterprise-Scale Landing Zone. Toutes les communications inter-spokes et toutes les sorties internet sont inspectées et logguées par le firewall.
Étape 6 — Private Endpoints pour Storage et SQL
Les Private Endpoints exposent des services PaaS (Storage, SQL, Cosmos, Key Vault) sur une IP privée dans votre VNet. Élimine l’exposition publique et permet l’accès depuis on-premise via VPN/ExpressRoute.
STORAGE_ID=$(az storage account show \
--name stdataaz305prod \
--resource-group rg-data \
--query id -o tsv 2>/dev/null)
az network private-endpoint create \
--resource-group rg-spoke-corp \
--name pe-storage \
--vnet-name vnet-spoke-corp \
--subnet subnet-pe \
--private-connection-resource-id $STORAGE_ID \
--connection-name pe-storage-conn \
--group-id blob
# Configurer le Private DNS Zone pour la résolution
az network private-dns zone create \
--resource-group rg-network-hub \
--name privatelink.blob.core.windows.net
az network private-dns link vnet create \
--resource-group rg-network-hub \
--zone-name privatelink.blob.core.windows.net \
--name link-corp \
--virtual-network vnet-spoke-corp \
--registration-enabled false
# Linker aussi au hub pour résolution centralisée
az network private-dns link vnet create \
--resource-group rg-network-hub \
--zone-name privatelink.blob.core.windows.net \
--name link-hub \
--virtual-network vnet-hub-we \
--registration-enabled false
Le Private DNS Zone `privatelink.blob.core.windows.net` est obligatoire pour que le nom du storage account résolve vers l’IP privée. Sans cette zone, l’application accède toujours au public endpoint. Configuration Private DNS centralisée dans le hub = pattern Enterprise-Scale.
Étape 7 — Application Gateway WAF v2 en frontend
Application Gateway est le load balancer L7 (HTTP/HTTPS) d’Azure avec WAF intégré (OWASP Core Rule Set). Frontend pour les apps internet-facing avec inspection des attaques web (SQL injection, XSS, etc.).
az network public-ip create \
--resource-group rg-spoke-online \
--name pip-appgw \
--sku Standard \
--allocation-method Static
az network application-gateway create \
--resource-group rg-spoke-online \
--name appgw-online \
--location westeurope \
--sku WAF_v2 \
--capacity 2 \
--vnet-name vnet-spoke-online \
--subnet AppGwSubnet \
--public-ip-address pip-appgw \
--priority 100 \
--waf-policy <(echo '{"properties":{"policySettings":{"state":"Enabled","mode":"Prevention"},"managedRules":{"managedRuleSets":[{"ruleSetType":"OWASP","ruleSetVersion":"3.2"}]}}}')
WAF v2 en mode Prevention = bloque les requêtes malveillantes (vs Detection qui ne fait que logger). En production, démarrer en Detection 2-3 semaines pour mesurer les faux positifs, puis basculer en Prevention.
Étape 8 — Bastion pour accès SSH/RDP sécurisé
Azure Bastion est un service jump host managé. Élimine le besoin d'IPs publiques sur les VMs — vous accédez via un client browser HTML5. Standard de fait pour la sécurité 2026.
az network public-ip create \
--resource-group rg-network-hub \
--name pip-bastion \
--sku Standard \
--allocation-method Static
az network bastion create \
--resource-group rg-network-hub \
--name bastion-hub \
--vnet-name vnet-hub-we \
--public-ip-address pip-bastion \
--location westeurope \
--sku Standard
Le Bastion en SKU Standard supporte le Shareable Link, le file copy, et les VNet peering — accessible depuis n'importe quel VNet peeré au hub. Coût ~150 USD/mois pour le Standard, mais élimine 100 % du risque RDP/SSH exposé.
Comprendre la différence ExpressRoute, VPN Gateway, Virtual WAN
Trois options pour connecter on-premise à Azure. VPN Gateway Site-to-Site = tunnel IPsec sur internet, débit jusqu'à 10 Gbps, latence variable, ~150 USD/mois pour VpnGw1. Idéal pour PME et démarrage. ExpressRoute = lien dédié physique via un opérateur (Orange, MTN, Sonatel pour l'Afrique de l'Ouest). Latence stable < 5ms, débit jusqu'à 100 Gbps, mais coûte 200-2000 USD/mois selon bande passante. Indispensable pour banques régulées et workloads gros volume. Virtual WAN = service managé qui orchestre VPN + ExpressRoute + SD-WAN à grande échelle. Idéal pour les organisations multi-sites avec 5+ branches.
Question type AZ-305 : « Une banque ouest-africaine avec 8 agences exige une connectivité avec SLA 99,9 % et latence stable ». Réponse : ExpressRoute avec opérateur local + Virtual WAN pour orchestration. Erreur classique : choisir VPN Site-to-Site qui ne tient pas le SLA strict.
Erreurs fréquentes
| Erreur | Cause | Solution |
|---|---|---|
| Subnet AzureFirewallSubnet introuvable | Mauvais nom de subnet | Le nom DOIT être exactement « AzureFirewallSubnet », case-sensitive |
| Spoke ne sort pas internet via firewall | UDR manquante | Créer route table avec 0.0.0.0/0 → firewall private IP, associer au subnet |
| Private Endpoint résout vers public IP | Private DNS Zone non liée | Lier la zone privatelink.X.windows.net au VNet du Pod |
| Peering ne propage pas BGP | --allow-gateway-transit pas configuré | Hub doit avoir allow-gateway-transit=true et spoke use-remote-gateways=true |
| WAF bloque trop de trafic légitime | Mode Prevention sans tuning | Démarrer en Detection 2-3 semaines, analyser logs, exclure faux positifs avant Prevention |
Adaptation au contexte ouest-africain
Pour les fintechs et banques de Dakar et Abidjan qui veulent une architecture conforme BCEAO, le pattern hub-spoke est obligatoire en pratique : il fournit la traçabilité et l'inspection nécessaires aux audits annuels. La connexion ExpressRoute via Sonatel ou Orange Business Services vers Frankfurt ou Marseille atteint typiquement 30-50 ms de latence — acceptable pour la majorité des workloads. Coût ExpressRoute 1 Gbps via opérateur local : 600-1200 USD/mois selon contrat. Pour les PME plus petites, VPN Gateway Site-to-Site sur fibre Sonatel/Orange à 80 USD/mois reste un excellent compromis.
Tutoriels frères
Pour aller plus loin
- 🔝 Retour au pilier : AZ-305 — guide complet
- Hub-spoke architecture : learn.microsoft.com/fr-fr/azure/architecture/networking/hub-spoke
- Azure Firewall : learn.microsoft.com/fr-fr/azure/firewall
- Private Endpoints : learn.microsoft.com/fr-fr/azure/private-link
FAQ
Hub-spoke ou Virtual WAN ?
Hub-spoke pour 1-3 régions et < 10 spokes. Virtual WAN pour multi-région globale ou 10+ branches — c'est l'orchestration managée du même pattern.
Azure Firewall Standard ou Premium ?
Standard pour 95 % des cas. Premium ajoute TLS inspection et IDPS — justifié pour banques avec PCI-DSS strict. Coût Premium ~2000 USD/mois vs 900 Standard.
Mots-clés secondaires : hub spoke azure, vnet peering transit, azure firewall standard, private endpoint dns zone, application gateway waf v2, azure bastion, expressroute vs vpn