Pourquoi le hub-and-spoke Azure reste le modèle “par défaut” en entreprise
Le hub-and-spoke Azure n’est pas “juste” un schéma de VNet. C’est un modèle d’exploitation : centraliser les services partagés (sécurité, connectivité, DNS, inspection) dans un hub, et isoler les charges de travail (applications, environnements, BU) dans des spokes.
L’objectif : réduire la complexité, mieux contrôler les flux, et rendre la gouvernance plus prévisible (et auditable).
Mais en pratique, la plupart des incidents viennent de détails : un DNS mal pensé, une route UDR qui casse un flux, un NSG trop permissif “temporaire”, ou une inspection Firewall qui n’a jamais été alignée avec les besoins applicatifs.
La checklist “réseau” avant même de dessiner le diagramme
Avant de créer des VNets, clarifiez ces points :
- Segmentation : quels spokes (prod/non-prod, par application, par BU) ?
- Connectivité : Internet sortant direct, via Firewall, via NVA, via proxy ?
- On-prem : VPN, ExpressRoute, les deux, et quel modèle de bascule ?
- DNS : résolution interne, zones privées, split-horizon, intégration AD DS ?
- Inspection : quels flux doivent être inspectés (north-south, east-west) ?
- Privé vs public : Private Endpoint généralisé ou au cas par cas ?
- Observabilité : logs réseau, flow logs, alerting, standardisation des diagnostics.
Si ces décisions ne sont pas prises, le hub-and-spoke Azure devient un “spaghetti” proprement câblé… mais impossible à opérer.
Checklist de conception : peering, routage, et transit
1. Peering VNet : simple… jusqu’au transit
Le peering est rapide à mettre en place, mais il faut décider explicitement :
- Allow forwarded traffic (si vous avez Firewall/NVA)
- Use remote gateways / Allow gateway transit (si le hub porte la passerelle)
- Topologie : hub unique, hubs régionaux, ou hub global + hubs locaux
Point clé : le peering n’est pas transitif. Vous devez concevoir le transit via hub (et le routage associé), sinon les spokes ne “se voient” pas comme prévu.
2. Routage : UDR, BGP, et “qui décide du chemin”
Le routage est souvent la source #1 de surprises.
- UDR (User Defined Routes) : utile pour forcer le passage par Firewall/NVA
- BGP : utile avec ExpressRoute/VPN, mais peut introduire des routes inattendues
- Priorité : une UDR peut surcharger des routes système, et casser un flux “qui marchait hier”
Checklist routage :
- Définir les préfixes on-prem, spokes, services partagés
- Documenter les tables de routage par subnet (pas seulement par VNet)
- Valider le chemin de sortie Internet (SNAT, inspection, exceptions)
- Tester les flux critiques : DNS, AD, update, accès PaaS, API externes
Checklist sécurité : NSG, Azure Firewall, et micro-segmentation réaliste
NSG : le minimum vital (mais pas suffisant)
Les NSG sont parfaits pour une segmentation “L3/L4” proche des workloads.
- Standardiser des patterns (spoke-app, spoke-data, management)
- Éviter les règles “Any/Any” même temporaires
- Utiliser des Application Security Groups (ASG) pour réduire la dette de règles
Azure Firewall : l’endroit où tout finit par arriver
Si vous centralisez l’inspection, vous devez traiter Azure Firewall comme un produit d’exploitation :
- Policy-as-code (ou au minimum : versioning + change management)
- Règles réseau vs application (FQDN) : clarifier l’intention
- DNAT : documenter les entrées (et les justifier)
- Logs : activer et exploiter (pas juste “collecter”)
Piège classique : on active le Firewall, puis on découvre que les flux PaaS (Storage, Key Vault, ACR) nécessitent une stratégie claire (Private Endpoint, service endpoints, ou exceptions contrôlées).
DNS & Private Endpoints : là où les architectures se gagnent (ou se perdent)
Le DNS est souvent sous-estimé, surtout quand on généralise les Private Endpoints.
Checklist DNS :
- Choisir le modèle : Azure DNS Private Resolver, serveurs DNS dans le hub, AD DS, ou hybride
- Créer les Private DNS Zones nécessaires (par service)
- Lier les zones aux VNets (hub + spokes concernés)
- Gérer le split-horizon (même nom, résolution différente interne/externe)
- Tester la résolution depuis chaque spoke (pas seulement depuis le hub)
Si vous faites des Private Endpoints sans DNS cohérent, vous aurez des symptômes “bizarres” : timeouts intermittents, accès qui marche depuis un spoke mais pas un autre, ou des applications qui retombent sur des endpoints publics.
Observabilité : ce que vous devez activer dès le jour 1
- NSG Flow Logs (et une stratégie de rétention exploitable)
- Azure Firewall logs (Application + Network + Threat Intel si utilisé)
- Connection Monitor pour les flux critiques
- Diagnostic settings standardisés (policy)
- Un tableau de bord minimal : top denies, top flows, top destinations, anomalies
Sans observabilité, vous “débuggez” au hasard. Avec, vous réduisez le MTTR et vous sécurisez les changements.
Le test final : 10 validations avant de dire “c’est prêt”
- Résolution DNS interne OK (hub + chaque spoke)
- Accès PaaS prévu (public/privé) validé
- Sortie Internet conforme (SNAT, inspection, exceptions)
- Flux on-prem ↔ spokes validés (VPN/ER)
- Flux spoke ↔ spoke (si autorisé) validés via hub
- NSG : pas de règles “ouvertes” non justifiées
- Firewall : règles minimales, logs activés, politique documentée
- Monitoring : flow logs + alerting de base en place
- Documentation : diagramme + routage + DNS + responsabilités
- Runbook incident : “où regarder en premier” (DNS, routes, NSG, Firewall)
Se former : AZ-700 (et renforcer avec AZ-104)
Si vous concevez, sécurisez ou dépannez des réseaux Azure, la formation certifiante Azure Network Engineer Associate (AZ-700) est un excellent cadre pour structurer vos compétences : connectivité, sécurité, DNS, hybridation, et troubleshooting.
Si vous souhaitez solidifier l’administration Azure au sens large (identité, compute, stockage, gouvernance), la formation Azure Administrator AZ-104 complète très bien le parcours.
FAQ
Le hub-and-spoke Azure est-il “obligatoire” en entreprise ?
Non, mais c’est souvent le modèle le plus gouvernable à l’échelle dès que vous devez standardiser connectivité, inspection, DNS et segmentation sur plusieurs environnements/équipes.
Quelle est l’erreur #1 dans un design hub-and-spoke ?
Ne pas décider (et tester) le modèle DNS + Private Endpoints dès le départ : zones privées, liens VNet (hub + spokes), résolution hybride, split-horizon.
Le peering VNet rend-il les spokes transitifs via le hub ?
Non. Le peering n’est pas transitif. Le transit spoke↔spoke “via hub” doit être conçu explicitement (routage/UDR + sécurité + inspection éventuelle).
Forced tunneling ou split tunneling : lequel choisir ?
Forced tunneling = contrôle/inspection centralisés mais complexité (UDR, SNAT, dépendances SaaS).
Split tunneling = plus simple, mais moins de contrôle central. Choisissez selon vos exigences d’inspection et de conformité.
Pourquoi “ça marche parfois” mais l’application time-out ?
Souvent à cause d’un routage asymétrique (aller via Firewall/NVA, retour différent) ou d’un DNS incohérent entre spokes. C’est la source classique des pannes “intermittentes”.
NSG vs Azure Firewall : est-ce que les NSG suffisent ?
Souvent à cause d’un routage asymétrique (aller via Firewall/NVA, retour différent) ou d’un DNS incohérent entre spokes. C’est la source classique des pannes “intermittentes”.
