VPC GCP : subnets, firewall, Cloud NAT, peering — tutoriel ACE 2026

Bâtir un VPC Google Cloud propre — custom-mode, subnets régionaux, firewall stateful, Cloud NAT et VPC peering — pour passer le domaine 2 de l’examen ACE et architecturer correctement vos premières applications cloud. Tutoriel pas-à-pas du cluster Associate Cloud Engineer.

📍 Article principal du cluster : Devenir Google Cloud Associate Cloud Engineer (ACE) — Guide complet 2026
Cet article fait partie du cluster « GCP ACE ». Pour la vue d’ensemble, lire d’abord le pilier.

Introduction

Le réseau virtuel — Virtual Private Cloud — est la fondation invisible sur laquelle reposent toutes les ressources Compute Engine, GKE, Cloud SQL et plus. Mal le concevoir, c’est se condamner à des migrations douloureuses six mois plus tard quand l’application explose en production. Mal en comprendre les règles, c’est perdre dix points faciles à l’examen ACE. Ce tutoriel construit un VPC Google Cloud de zéro, en mode custom comme le recommandent les bonnes pratiques officielles, et explore les pièges classiques par rapport à AWS — où les subnets sont zonaux et les règles firewall fonctionnent différemment. Tous les paramètres cités sont validés sur la doc officielle Google Cloud à fin avril 2026.

Prérequis

• Compte Google Cloud Free Trial actif (cf. Créer un compte GCP gratuit 300 USD sans risque de facturation).
• Projet GCP avec compte de facturation lié (ex : lab-ace-2026).
• Cloud Shell ou gcloud CLI installé localement.
• Compréhension basique du modèle TCP/IP (CIDR, RFC 1918, NAT). Si vous préparez aussi le CCNA, ce tutoriel sera plus rapide à digérer.
• Niveau attendu : intermédiaire en réseau, débutant en GCP.
• Temps estimé : 90 minutes pour suivre toutes les étapes avec lab.

Étape 1 — Comprendre la spécificité VPC GCP

Avant de créer quoi que ce soit, fixez les trois différences fondamentales entre VPC GCP et VPC AWS — qui sont régulièrement testées à l’examen et déstabilisent les candidats venant d’AWS. Première différence : sur GCP, un VPC est global par défaut. Un seul VPC peut couvrir Paris, Belgique, Johannesburg et São Paulo. Sur AWS, un VPC est régional, et il faut du peering ou Transit Gateway pour relier deux régions. Cette globalité GCP simplifie énormément les architectures multi-région.

Deuxième différence : les subnets GCP sont régionaux, pas zonaux comme sur AWS. Un subnet en europe-west9 (Paris) couvre les trois zones europe-west9-a, europe-west9-b, europe-west9-c. Vous n’avez pas besoin de créer trois subnets pour avoir une haute disponibilité multi-zone — un seul suffit. Troisième différence : les règles firewall sont attachées au VPC, pas aux subnets ni aux instances directement. Le filtrage par instance se fait via des tags ou des service accounts, mécanisme à connaître précisément pour l’examen.

Étape 2 — Créer un VPC custom-mode

Le mode auto crée automatiquement un subnet dans chaque région avec des plages préfabriquées issues du bloc 10.128.0.0/9. Pratique pour démarrer mais déconseillé en production : vous perdez le contrôle sur le plan d’adressage. Le mode custom crée un VPC vide ; vous y ajoutez les subnets que vous voulez, avec les CIDR que vous choisissez. C’est le mode recommandé par la documentation officielle pour tout usage sérieux.

# Creer le VPC custom-mode (aucun subnet auto)
gcloud compute networks create vpc-lab \
  --subnet-mode=custom \
  --bgp-routing-mode=regional \
  --mtu=1460 \
  --project=lab-ace-2026

# Verifier
gcloud compute networks describe vpc-lab --project=lab-ace-2026

Le réseau est créé sans aucun subnet. Le paramètre --bgp-routing-mode=regional limite la propagation des routes Cloud Router à la région du Cloud Router ; global propage à toutes les régions du VPC. Pour un lab simple, regional suffit. Le MTU 1460 est la valeur standard ; si vous travaillez avec des charges qui exigent des jumbo frames, GCP supporte aussi 8896 mais c’est rarement utile pour l’ACE.

Étape 3 — Créer des subnets régionaux

Les subnets sont là où les VMs reçoivent leurs IP privées. Pour cet exercice, créons deux subnets dans europe-west9 (Paris) et un subnet en europe-west1 (Belgique), pour simuler une architecture multi-région.

# Subnet web public en europe-west9 (Paris)
gcloud compute networks subnets create subnet-web-eu9 \
  --network=vpc-lab \
  --region=europe-west9 \
  --range=10.10.0.0/24 \
  --project=lab-ace-2026

# Subnet app prive en europe-west9 (Paris)
gcloud compute networks subnets create subnet-app-eu9 \
  --network=vpc-lab \
  --region=europe-west9 \
  --range=10.20.0.0/24 \
  --project=lab-ace-2026

# Subnet web en europe-west1 (Belgique) pour simuler multi-region
gcloud compute networks subnets create subnet-web-eu1 \
  --network=vpc-lab \
  --region=europe-west1 \
  --range=10.11.0.0/24 \
  --project=lab-ace-2026

# Lister tous les subnets du VPC
gcloud compute networks subnets list --filter="network:vpc-lab"

Les ranges 10.10.0.0/24, 10.20.0.0/24 et 10.11.0.0/24 ne se chevauchent pas — c’est obligatoire pour pouvoir router entre eux. Le 10.20.0.0/24 sera notre subnet « privé » sans IP externe, qui aura besoin de Cloud NAT pour sortir vers Internet (étape 6). Notez qu’aucune zone n’est mentionnée : un subnet GCP couvre automatiquement toutes les zones de sa région.

Étape 4 — Comprendre les règles firewall par défaut

Sur le VPC default que Google crée automatiquement à l’ouverture du compte, quatre règles firewall préexistent et sont fréquemment testées à l’examen. Sur notre vpc-lab custom, aucune règle n’existe par défaut : c’est implied deny ingress total et implied allow egress total. Tout trafic entrant est bloqué tant qu’on ne crée pas de règle explicite ; tout trafic sortant est autorisé sauf si on l’interdit explicitement.

Plusieurs points piégeux à mémoriser. Premièrement, ces règles n’existent que sur le VPC default — c’est pourquoi exposer SSH ou RDP à 0.0.0.0/0 sans réflexion est une mauvaise idée par défaut sur GCP. Deuxièmement, la priorité 65534 est presque la plus basse possible (max 65535) : n’importe quelle règle plus spécifique avec une priorité plus basse (numériquement) écrasera ces autorisations. Troisièmement, les règles GCP sont stateful — le trafic retour d’une connexion autorisée passe automatiquement, pas besoin de règle inverse.

Étape 5 — Créer une règle firewall ciblée

Cas concret : vous voulez autoriser HTTP (port 80) et HTTPS (port 443) uniquement sur les VMs taguées web-server, depuis n’importe quelle IP Internet. Le tagging est la mécanique GCP standard pour cibler des instances précises sans devoir énumérer leurs IPs.

# Autoriser HTTP/HTTPS sur les VMs taguees "web-server"
gcloud compute firewall-rules create fw-allow-web \
  --network=vpc-lab \
  --direction=INGRESS \
  --priority=1000 \
  --action=ALLOW \
  --rules=tcp:80,tcp:443 \
  --source-ranges=0.0.0.0/0 \
  --target-tags=web-server \
  --project=lab-ace-2026

# Autoriser SSH uniquement depuis votre IP de bureau
MY_IP="$(curl -s ifconfig.me)/32"
gcloud compute firewall-rules create fw-allow-ssh-bureau \
  --network=vpc-lab \
  --direction=INGRESS \
  --priority=1000 \
  --action=ALLOW \
  --rules=tcp:22 \
  --source-ranges=$MY_IP \
  --target-tags=ssh-allowed

La règle fw-allow-web ne s’applique qu’aux VMs qui portent le tag réseau web-server. Le tag s’attache à la VM lors de sa création avec --tags=web-server. La règle SSH restreint à votre seule IP — bonne pratique fondamentale qui évite les milliers de scans bruteforce SSH sur le port 22 ouvert globalement. Attention : ifconfig.me peut être bloqué dans certains réseaux ; un fallback est curl ifconfig.co ou simplement consulter votre IP publique sur whatismyip.com.

Étape 6 — Cloud NAT pour la sortie privée vers Internet

Une VM dans subnet-app-eu9 sans IP externe ne peut pas joindre Internet par défaut. C’est exactement ce qu’on veut pour la sécurité — pas de surface d’attaque entrante — mais on a quand même besoin de sortir pour apt-get update, télécharger des images Docker depuis Docker Hub, etc. Cloud NAT est la solution managée Google Cloud qui permet exactement cela : sortie Internet sans exposition entrante.

# 1. Creer un Cloud Router en europe-west9
gcloud compute routers create router-eu9 \
  --network=vpc-lab \
  --region=europe-west9 \
  --project=lab-ace-2026

# 2. Creer la configuration NAT sur ce router
gcloud compute routers nats create nat-eu9 \
  --router=router-eu9 \
  --region=europe-west9 \
  --auto-allocate-nat-external-ips \
  --nat-all-subnet-ip-ranges \
  --project=lab-ace-2026

Cloud NAT est un service régional. Le Cloud Router est un prérequis : il sert de point de configuration du NAT mais ne route pas le trafic NAT lui-même (qui est géré par l’infrastructure Google sans VM intermédiaire). L’option –auto-allocate-nat-external-ips laisse Google gérer les IPs externes utilisées pour le NAT ; en production avec besoin d’IPs fixes pour des allowlist côté tiers, vous réserveriez des IPs statiques avec --nat-external-ip-pool.

Côté tarification, Cloud NAT facture deux choses : un coût horaire par VM utilisant le NAT et un coût par GB de données traitées. Les chiffres exacts varient selon les régions et évoluent ; consultez la page officielle de tarification Cloud NAT avant tout déploiement réel. Pour un lab d’apprentissage avec quelques VMs et peu de trafic, le coût mensuel reste de l’ordre de quelques dollars.

Étape 7 — VPC Peering entre projets

Le VPC peering permet à deux VPCs (du même projet, de projets différents, voire d’organisations différentes) de communiquer en utilisant des IPs privées, sans transiter par Internet. C’est la mécanique standard pour relier l’environnement de dev à celui de production, ou pour exposer un VPC partagé à plusieurs équipes.

# Pre-requis : avoir un deuxieme projet avec un VPC vpc-prod
PROJECT_DEV="lab-ace-2026"
PROJECT_PROD="prod-ace-2026"

# Creer le peering cote dev vers prod
gcloud compute networks peerings create peer-dev-to-prod \
  --network=vpc-lab \
  --peer-project=$PROJECT_PROD \
  --peer-network=vpc-prod \
  --auto-create-routes \
  --project=$PROJECT_DEV

# Creer le peering cote prod vers dev (les deux cotes sont obligatoires)
gcloud compute networks peerings create peer-prod-to-dev \
  --network=vpc-prod \
  --peer-project=$PROJECT_DEV \
  --peer-network=vpc-lab \
  --auto-create-routes \
  --project=$PROJECT_PROD

Trois règles à mémoriser pour l’examen. Les deux côtés du peering doivent être créés explicitement — un seul ne suffit pas. Les CIDR des deux VPCs ne doivent pas se chevaucher, sinon le peering échoue. Le peering n’est pas transitif : si A peere avec B et B peere avec C, A et C ne se voient pas. Pour des architectures complexes hub-and-spoke, regardez Network Connectivity Center ou un VPN/Interconnect.

Étape 8 — Cleanup

# Supprimer le NAT et le router
gcloud compute routers nats delete nat-eu9 --router=router-eu9 --region=europe-west9 --quiet
gcloud compute routers delete router-eu9 --region=europe-west9 --quiet

# Supprimer les peerings
gcloud compute networks peerings delete peer-dev-to-prod --network=vpc-lab --quiet

# Supprimer les regles firewall
gcloud compute firewall-rules delete fw-allow-web fw-allow-ssh-bureau --quiet

# Supprimer les subnets
gcloud compute networks subnets delete subnet-web-eu9 --region=europe-west9 --quiet
gcloud compute networks subnets delete subnet-app-eu9 --region=europe-west9 --quiet
gcloud compute networks subnets delete subnet-web-eu1 --region=europe-west1 --quiet

# Supprimer le VPC
gcloud compute networks delete vpc-lab --quiet

Ordre du cleanup : ressources internes au VPC (NAT, peerings, firewall, subnets) avant le VPC lui-même. Un VPC ne peut pas être supprimé tant qu’il contient des subnets ou des règles firewall, et un subnet ne peut pas être supprimé tant qu’une VM ou une load balancer y vit. La commande échoue alors avec une erreur explicite pointant la dépendance à libérer en premier.

Erreurs fréquentes

Adaptation au contexte ouest-africain

Latence Dakar → europe-west9. Les workloads avec interface web doivent réfléchir à la latence vers Paris (90-130 ms depuis Dakar, 120-160 ms depuis Abidjan, 50-90 ms depuis Casablanca). Pour des SPA modernes c’est acceptable ; pour de la voix temps réel c’est limite. Le choix d’europe-west9 reste néanmoins le meilleur compromis qualité/coût pour la plupart des PME UEMOA.

Conformité données et VPC. Si votre client impose la non-sortie d’UE, configurez le BGP routing en regional et n’établissez aucun peering vers des VPCs hors UE. C’est la barrière technique simple à documenter pour un audit ARTCI ou CDP.

Cloud NAT vs proxy mutualisé. Pour une PME ivoirienne avec quelques VMs derrière NAT, le coût Cloud NAT reste modeste. Mais si votre architecture dépasse la cinquantaine de VMs faisant beaucoup de trafic sortant, comparer avec un proxy auto-hébergé sur une VM avec IP publique peut être intéressant — au prix d’une responsabilité supplémentaire (mises à jour, scaling).

VPN site-to-site vers le SI sur site. Si vous gardez une partie de l’infra dans un data center local à Dakar (Tigo, Sonatel) ou à Abidjan, GCP Cloud VPN se configure avec un Cloud Router côté GCP et un firewall compatible IPsec côté on-prem. Comptez un débit théorique maximal de 3 Gbps par tunnel, suffisant pour la plupart des connexions WAN africaines.

Tutoriels frères

• Compute Engine : déployer une VM Linux et Windows — la suite logique : poser les premières VMs dans vos subnets.
• IAM GCP : utilisateurs, rôles, service accounts, MFA — la sécurité d’identité, complément naturel de la sécurité réseau.

Pour aller plus loin

• 🔝 Retour au pilier : Devenir Google Cloud Associate Cloud Engineer (ACE) — Guide complet 2026
• Doc officielle VPC : cloud.google.com/vpc/docs/vpc
• Doc Firewall Rules : cloud.google.com/vpc/docs/firewalls
• Doc Cloud NAT : cloud.google.com/nat/docs/overview
• Suggestion suivante : Compute Engine — déployer une VM Linux et Windows

FAQ

Auto-mode ou custom-mode pour un projet pro ?
Custom-mode systématiquement. Auto-mode est pratique pour démarrer mais inflexible : vous ne pouvez pas changer les CIDR, et le mode auto écrase les bonnes pratiques de moindre exposition réseau.

Faut-il créer un VPC par environnement (dev/staging/prod) ?
Idéalement oui, ou au minimum un projet par environnement avec leur VPC respectif. Cela rend le blast radius d’une erreur dev incapable de toucher la prod. Le peering ou le Shared VPC permet de partager certaines briques (DNS privé, Cloud DNS).

Quelle est la différence entre route et firewall rule ?
Une route définit où le paquet doit aller (next hop). Une règle firewall définit si le paquet est autorisé à partir/arriver. Les deux doivent autoriser le trafic pour qu’il passe.

Quelle est la différence entre Cloud NAT et un load balancer ?
Cloud NAT permet la sortie Internet à des VMs sans IP publique. Un load balancer expose un service à Internet. Les deux n’ont rien à voir. Cloud NAT est sortant ; load balancer est entrant.

Le VPC peering peut-il franchir des organisations ?
Oui. Le peering fonctionne entre VPCs de projets différents, organisations différentes, voire entre clients différents. La seule contrainte technique reste l’absence de chevauchement CIDR.

Comment déboguer un trafic qui ne passe pas ?
VPC Flow Logs (à activer subnet par subnet) et Connectivity Tests (outil dédié dans la console Network Intelligence Center). Connectivity Tests simule un paquet entre deux IPs et indique exactement où il est bloqué : route manquante, firewall, etc. C’est l’outil de référence pour les questions « pourquoi ma VM ne joint pas X ? ».

Mots-clés : VPC GCP, custom-mode, subnet régional, firewall stateful, Cloud NAT, VPC peering, Cloud Router, ACE certification réseau, Cloud VPN Afrique