Cloud networking : principes et composants
Dans le cloud, le réseau devient une ressource logicielle créée par API. Réseaux virtuels, sous-réseaux, routage, filtrage, répartiteurs et connectivité : les concepts communs à AWS, Azure et Google Cloud.
Dans un centre de données traditionnel, créer un réseau implique d'acheter, d'installer et de câbler des équipements. Dans le cloud public, un réseau complet — sous-réseaux, routage, pare-feu, répartiteurs de charge — se crée en quelques minutes par une console ou une API. Les concepts restent ceux du réseau classique, mais leur mise en œuvre, leurs limites et leurs pièges sont différents.
Objectif : comprendre les composants réseau communs aux grands fournisseurs de cloud et les principes de conception qui s'appliquent. Les particularités d'AWS et d'Azure sont détaillées dans des articles dédiés.
Le modèle de responsabilité partagée
Le fournisseur de cloud est responsable de la sécurité du cloud : centres de données, matériel, réseau physique, couche de virtualisation. Le client est responsable de la sécurité dans le cloud : configuration de ses réseaux virtuels, règles de filtrage, identités, données, systèmes d'exploitation de ses machines virtuelles.
Conséquence : une base de données exposée sur Internet par une règle trop permissive est une erreur du client, pas du fournisseur. Les erreurs de configuration sont l'une des principales causes d'incidents dans le cloud.
Les composants communs
| Concept | AWS | Azure | Google Cloud |
|---|---|---|---|
| Réseau virtuel isolé | VPC | Virtual Network (VNet) | VPC |
| Sous-réseau | Subnet (lié à une zone de disponibilité) | Subnet (régional) | Subnet (régional) |
| Table de routage | Route table | Route table (UDR) | Routes |
| Filtrage au niveau des instances | Security group (avec état) | Network Security Group (avec état) | Règles de pare-feu VPC |
| Filtrage au niveau du sous-réseau | Network ACL (sans état) | NSG associé au sous-réseau | — |
| Accès Internet | Internet Gateway | Accès sortant via passerelle NAT, IP publique ou répartiteur | Passerelle Internet par défaut |
| NAT sortant | NAT Gateway | NAT Gateway | Cloud NAT |
| Interconnexion de réseaux virtuels | VPC Peering, Transit Gateway | VNet Peering, Virtual WAN | VPC Network Peering |
| VPN site à site | Site-to-Site VPN | VPN Gateway | Cloud VPN |
| Liaison dédiée | Direct Connect | ExpressRoute | Cloud Interconnect |
Le réseau virtuel
Un réseau virtuel est un espace d'adressage privé isolé, défini par un ou plusieurs blocs CIDR (par exemple 10.20.0.0/16). Il est découpé en sous-réseaux.
Choisir l'adressage avec soin dès le départ :
- utilisez des plages RFC 1918 qui ne chevauchent ni vos réseaux sur site, ni les autres réseaux virtuels avec lesquels vous devrez communiquer. Deux réseaux qui se chevauchent ne peuvent pas être interconnectés simplement ;
- prévoyez de la marge : agrandir un réseau virtuel ou un sous-réseau est possible chez certains fournisseurs, avec des contraintes ;
- tenez compte des adresses réservées par le fournisseur dans chaque sous-réseau (cinq adresses chez AWS et Azure, par exemple).
Voir Calcul de sous-réseaux IPv4.
Sous-réseaux publics et privés
La distinction ne tient pas à l'adressage (tous les sous-réseaux utilisent des adresses privées) mais au routage :
- un sous-réseau public a une route vers Internet par une passerelle Internet : les ressources dotées d'une adresse publique y sont joignables (si le filtrage l'autorise) ;
- un sous-réseau privé n'a pas de route directe entrante depuis Internet ; ses ressources peuvent sortir via une passerelle NAT.
Bonne pratique : seuls les composants qui doivent être exposés (répartiteurs de charge, bastions éventuels) sont dans des sous-réseaux publics ; les serveurs applicatifs et bases de données restent dans des sous-réseaux privés.
Le filtrage
Deux niveaux existent généralement :
- groupes de sécurité (security groups, NSG) : pare-feu avec état appliqué aux interfaces des ressources. Une réponse à une connexion autorisée est automatiquement acceptée ;
- listes de contrôle au niveau du sous-réseau (Network ACL chez AWS) : sans état, évaluées par ordre de numéro ; il faut autoriser explicitement les flux de retour (ports éphémères).
Principes :
- refuser par défaut, autoriser précisément (source, port, protocole) ;
- référencer des groupes plutôt que des adresses (« le groupe des serveurs web peut joindre le groupe des bases de données sur le port 5432 ») : les règles suivent les ressources même lorsque leurs adresses changent ;
- ne jamais ouvrir l'administration (SSH, RDP) à 0.0.0.0/0 : utilisez un bastion géré, un accès par session du fournisseur ou un VPN.
Les répartiteurs de charge
Les fournisseurs proposent des répartiteurs gérés :
- niveau 4 (TCP/UDP) : haute performance, sans inspection applicative ;
- niveau 7 (HTTP/HTTPS) : routage selon le chemin ou le nom d'hôte, terminaison TLS, intégration à un pare-feu applicatif (WAF).
Ils effectuent des contrôles de santé et ne dirigent le trafic que vers les instances saines, réparties sur plusieurs zones de disponibilité pour la résilience.
Le DNS
Chaque fournisseur offre un DNS public (gestion de vos zones) et un DNS privé pour résoudre les noms internes du réseau virtuel. Dans un environnement hybride, il faut organiser la résolution dans les deux sens : les serveurs sur site doivent résoudre les noms privés du cloud, et inversement, au moyen de redirecteurs conditionnels et de résolveurs dédiés.
L'accès privé aux services gérés
Les services gérés (stockage objet, bases de données, files de messages) sont souvent accessibles par des points de terminaison publics. Pour que le trafic reste sur le réseau privé, les fournisseurs proposent des points de terminaison privés (PrivateLink, Private Endpoint, Private Service Connect) qui exposent le service avec une adresse privée dans votre réseau virtuel.
La connectivité hybride
Relier le cloud au réseau de l'entreprise se fait par :
- VPN IPsec sur Internet : rapide à mettre en place, débit et latence dépendants d'Internet ;
- liaison dédiée : connexion privée via un opérateur ou un point d'échange, plus prévisible et souvent plus performante.
BGP est couramment utilisé pour échanger dynamiquement les routes. Voir VPN cloud et connectivité hybride.
Les architectures en étoile
Lorsque les réseaux virtuels se multiplient (par environnement, par application, par équipe), on adopte une architecture en étoile (hub and spoke) : un réseau central (hub) héberge les services partagés (connectivité vers le site, pare-feu, DNS), et les réseaux applicatifs (spokes) s'y raccordent. Les services de transit managés (Transit Gateway, Virtual WAN) simplifient ce modèle.
Observer et contrôler les coûts
- Journaux de flux (VPC Flow Logs, NSG/VNet flow logs) : enregistrement des flux acceptés et refusés, indispensable au diagnostic et à la sécurité.
- Coûts réseau : les transferts sortants vers Internet, entre régions et parfois entre zones de disponibilité sont facturés. Les passerelles NAT et les liaisons ont aussi un coût horaire. Intégrez ces éléments dès la conception.
Erreurs courantes
- Adressage qui chevauche le réseau de l'entreprise ou d'autres réseaux virtuels.
- Règles ouvertes à 0.0.0.0/0 pour l'administration ou les bases de données.
- Tout placer dans des sous-réseaux publics.
- Ignorer les coûts de transfert de données.
- Configurer manuellement dans la console sans infrastructure en tant que code, rendant les environnements irreproductibles.
Conclusion
Le réseau cloud reprend les concepts classiques — adressage, routage, filtrage, répartition — sous une forme logicielle et pilotable par API. Un adressage planifié, des sous-réseaux privés par défaut, un filtrage par groupes et une connectivité hybride maîtrisée constituent la base de toute architecture. Poursuivez avec Réseaux AWS : VPC, sous-réseaux et routage et Réseaux Azure : VNets, NSG et connectivité.
