Shared VPC est le modèle natif de GCP pour le réseau multi-projets : un Host Project possède le VPC, des Service Projects y déploient leurs ressources sans jamais créer de peering — la communication est native puisqu’ils sont dans le même réseau.
Rôles
| Rôle | Responsabilités |
|---|---|
| Host Project | Possède le VPC : subnets, routes, Cloud NAT, Firewall Rules — géré par l’équipe Réseau |
| Service Projects | Rattachés (“attached”) au Host Project, déploient des ressources (VM, GKE, Cloud SQL) sur les subnets qui leur sont assignés, gèrent uniquement leur IAM et leurs ressources applicatives |
Pourquoi c’est différent d’AWS
Sur AWS, le VPC Sharing (via AWS RAM) est une option parmi d’autres (à côté du VPC Peering et de la Transit Gateway) pour le multi-comptes. Sur GCP, Shared VPC est LE pattern par défaut recommandé pour le multi-équipes — le VPC Network Peering reste réservé aux cas ponctuels ou cross-organisation.
Avantage clé : pas d’overlapping IP possible
Puisque tout se passe dans un seul VPC, GCP empêche par construction de créer deux subnets avec des plages qui se chevauchent — le problème d’overlapping CIDR qui complique le VPC Peering et le Transit Gateway sur AWS ne se pose pas.
En relation avec
- Architecture réseau multi-projets — Shared VPC en détail, comparé au Peering et au Network Connectivity Center
- Réseau GCP — vue d’ensemble réseau
- AWS RAM (Resource Access Manager) — équivalent conceptuel AWS (option, pas défaut)