🌐 Architecture Réseau GCP Multi-Projets : Connectivité et Partage
1. Le Réseau Multi-Projets : Connecter (ou partager) les VPC
GCP propose trois modèles, à ne pas confondre.
VPC Network Peering (la connexion point à point)
- Le principe : Connexion directe 1-à-1 entre deux VPC (même organisation ou non), le trafic passe par le réseau privé de Google.
- La limite majeure (pas de transitivité) : identique à AWS — si VPC A ↔ VPC B et VPC B ↔ VPC C, alors A ne peut pas parler à C. Il faut peering directement A ↔ C.
- À l’échelle : même explosion combinatoire qu’avec le VPC Peering AWS.
Shared VPC (le modèle natif et recommandé sur GCP)
C’est la différence structurelle majeure avec AWS : là où AWS partage des subnets via RAM (mécanisme optionnel parmi d’autres), GCP construit son modèle multi-projets autour du Shared VPC.
- Le principe : un Host Project possède le VPC et ses subnets. Des Service Projects y sont rattachés (“attached”) et peuvent y déployer des ressources (VM, GKE, Cloud SQL) — sans jamais posséder le réseau eux-mêmes.
- Pas de peering nécessaire : les Service Projects sont dans le même VPC que le Host Project, donc aucune connexion à établir — la communication est native.
- Séparation des responsabilités :
- Équipe Réseau (Host Project) : gère le VPC, les plages IP, les routes, les Cloud NAT, les Firewall Rules globales.
- Équipes Applicatives (Service Projects) : déploient leurs ressources sur les subnets qu’on leur a attribués, gèrent uniquement leur IAM et leurs ressources applicatives.
Network Connectivity Center (le hub centralisé)
Équivalent du Transit Gateway AWS — un hub qui connecte VPC, VPN et Interconnect entre eux avec routage transitif complet (hub-and-spoke), utile quand le Shared VPC seul ne suffit pas (multi-organisation, hybrid cloud complexe, interconnexion de VPC déjà existants et non fusionnables en Shared VPC).
2. Comparatif des trois modèles
| VPC Peering | Shared VPC | Network Connectivity Center | |
|---|---|---|---|
| Transitivité | Non | N/A (un seul VPC) | Oui |
| Cas d’usage | 2-3 VPC isolés, cross-org | Multi-équipes dans une même org, standard GCP | Hybrid cloud, beaucoup de spokes (VPC + VPN + Interconnect) |
| Gestion IP | Chaque VPC garde son CIDR | Un seul plan d’adressage, pas de chevauchement possible par design | Chaque spoke garde son CIDR, doit éviter le chevauchement |
| Complexité | Faible | Faible à modérée (setup initial) | Élevée |
3. L’Overlapping IP : le même ennemi que sur AWS
Le problème est identique : deux réseaux avec le même bloc CIDR (ex. 10.0.0.0/16) ne peuvent pas être routés l’un vers l’autre sans ambiguïté.
- VPC Peering : GCP bloque la création du peering si les CIDR se chevauchent, comme AWS.
- Shared VPC : l’overlapping est impossible par design — un seul VPC, un seul plan d’adressage, GCP empêche de créer deux subnets se chevauchant.
- Network Connectivity Center : comme le Transit Gateway AWS, il laisse attacher des spokes avec des IP en conflit, mais le routage entre eux devient impossible ou asymétrique.
Pas d’équivalent direct à AWS IPAM
GCP n’a pas de service de gouvernance IP dédié aussi complet qu’AWS VPC IPAM. Les approches disponibles :
- Internal Range API : permet de réserver et d’allouer automatiquement des blocs CIDR non chevauchants entre projets (le plus proche d’un “pool IPAM”), mais moins mature/outillé que le produit AWS.
- Planification manuelle + Terraform : dans la pratique, la plupart des organisations GCP planifient leur adressage à l’avance (documenté, versionné en Terraform) plutôt que de déléguer à un service d’allocation dynamique.
💡 Aide-mémoire Obsidian
- Par défaut sur GCP : penser Shared VPC avant Peering. C’est le pattern natif et recommandé par Google pour le multi-équipes ; le Peering reste pour des cas ponctuels ou du cross-organisation.
- Un VPC GCP est global, pas régional — un Shared VPC peut donc contenir des subnets dans toutes les régions, contrairement à un VPC AWS confiné à une région.
- Network Connectivity Center inter-région : pas besoin de “peering de hub” comme avec deux Transit Gateway AWS — un seul NCC couvre déjà toutes les régions.
- Règle de base IP : comme sur AWS, toujours planifier l’adressage avant de créer les projets et VPC — encore plus vrai ici vu l’absence d’un IPAM aussi complet.
- Sous-réseaux : privilégier des subnets dimensionnés au besoin réel (
/24,/20) plutôt que de sur-allouer, même si l’espace CIDR global du VPC est en théorie très large.
En relation avec
- Gouvernance — Vue d’ensemble — hub gouvernance GCP
- Réseau et VPC — Vue d’ensemble — hub réseau, Shared VPC en pratique
- Réseau GCP — fondamentaux réseau GCP (firewall, routes, NAT)
- Shared VPC / Network Connectivity Center — fiches détaillées des deux mécanismes
- Architecture réseau multi-comptes — équivalent conceptuel côté AWS