abla.adem

Recent Notes

Réseau GCP

8 min read

🌐 La Bible du Réseau GCP : Du VPC Global au Load Balancing Anycast

Ce guide détaille comment les données circulent, sont protégées, routées et accélérées sur GCP — en insistant sur les différences structurelles avec AWS, plus qu’avec le monde on-premise (déjà couvert côté AWS).

1. Fondations : un VPC global, pas régional

La différence la plus importante avec AWS.

  • Sur AWS : un VPC est confiné à une région. Pour couvrir plusieurs régions, il faut du VPC Peering ou un Transit Gateway inter-régions.
  • Sur GCP : un VPC est une ressource globale. Ses subnets, eux, sont régionaux — un seul VPC peut donc avoir des subnets à Paris, Francfort et Tokyo, tous capables de se parler nativement sans peering ni passerelle.

Pas d’Internet Gateway explicite

  • Sur AWS : il faut créer et attacher un objet Internet Gateway (IGW) au VPC.
  • Sur GCP : chaque VPC dispose implicitement d’une route par défaut (0.0.0.0/0) vers une passerelle Internet gérée par Google. Aucune ressource à créer ni attacher — il suffit qu’une instance ait une IP externe (ou passe par Cloud NAT) pour sortir.

Les Routes (globales, pas par subnet)

  • Sur AWS : une table de routage est associée à un ou plusieurs subnets.
  • Sur GCP : les routes sont définies au niveau du VPC entier (portée globale), et peuvent être restreintes à des instances via des tags réseau ou des comptes de service. Le “scoping” se fait par tag, pas par association à un subnet.

vNIC et IP alias

Chaque instance a une interface réseau virtuelle (vNIC) avec une IP primaire, et peut recevoir des IP alias ranges — un mécanisme central pour les clusters GKE en mode VPC-native (voir Node pools et autoscaling), où chaque pod reçoit une IP routable directement depuis une alias range du subnet.

2. Le NAT : Cloud NAT, sans ressource dédiée

Le principe du PAT (Port Address Translation, “plusieurs pour un”) est identique à AWS, mais l’implémentation diffère :

  • Cloud NAT : ce n’est pas une “gateway” avec sa propre IP comme le NAT Gateway AWS — c’est une configuration attachée à un Cloud Router. Entièrement managé, il alloue et gère automatiquement les ports NAT (pas de limite fixe de connexions à surveiller comme sur AWS NAT Gateway).
  • NAT par instance (legacy) : équivalent de la NAT Instance AWS — une VM avec IP forwarding activé et une route statique pointant vers elle. Déconseillé : limité par le CPU/RAM de la VM, aucune haute disponibilité native.

3. Sécurité : un seul niveau — les Firewall Rules

Différence structurelle majeure avec AWS. Là où AWS empile deux couches (Security Group au niveau instance + NACL au niveau subnet), GCP n’a qu’un seul système : les VPC Firewall Rules.

CaractéristiqueSecurity Group + NACL (AWS)Firewall Rules (GCP)
NiveauInstance (SG, stateful) + Subnet (NACL, stateless) — deux couchesLe VPC entier, ciblé par tags réseau ou comptes de service — une seule couche
ÉtatSG stateful / NACL statelessToujours stateful
Type de règleSG : Allow uniquement / NACL : Allow et DenyAllow et Deny (comme la NACL), mais stateful (comme le SG)
ApplicationSG attaché à l’ENI / NACL attaché au subnetRègle globale au VPC, filtrée par target tags ou service account, avec une priorité numérique (0 = plus prioritaire)

Il n’y a donc pas de double filtrage à raisonner (contrairement à SG + NACL) : une seule liste de règles ordonnées par priorité décide de tout le trafic, ingress et egress.

4. Architectures Multi-VPC : Peering vs Shared VPC vs Hub & Spoke

VPC Network Peering (le maillage)

  • Connexion directe 1-à-1, pas de transitivité (identique à AWS).
  • Chaque VPC garde sa propre route par défaut vers Internet.

Shared VPC (le modèle natif GCP)

  • Un Host Project possède le VPC, des Service Projects y déploient leurs ressources sans jamais peering — voir Architecture réseau multi-projets pour le détail.
  • Sans équivalent direct côté AWS (le VPC Sharing via RAM existe mais reste une option parmi d’autres, pas le modèle par défaut).

Network Connectivity Center (le hub-and-spoke)

  • Équivalent du Transit Gateway : hub central pour VPC, VPN et Interconnect, routage transitif complet.

5. Connectivité Hybride & Privée

Cloud VPN (HA VPN)

  • Tunnel IPSec chiffré via Internet. Contrairement au VPN Site-to-Site AWS (une seule passerelle par défaut), HA VPN garantit 99.99% de SLA en établissant automatiquement deux tunnels sur deux IP externes distinctes.
  • Nécessite un Cloud Router (BGP) pour l’échange dynamique de routes — pas de routage statique recommandé en production.

Cloud Interconnect (la fibre dédiée)

  • Dedicated Interconnect : connexion physique directe dans un point de présence Google (10 ou 100 Gbps), équivalent de Direct Connect.
  • Partner Interconnect : via un partenaire réseau, pour les débits plus faibles ou les sites sans accès à un point de présence Google.
  • VLAN Attachments : équivalent des Virtual Interfaces (VIF) AWS — les “tuyaux” logiques créés dans la connexion physique.

Private Service Connect (l’accès privé aux services)

  • Pour parler aux APIs Google ou à des services tiers/internes sans passer par Internet ni payer de Cloud NAT.
  • Private Google Access : gratuit, simple option activée sur un subnet, équivalent du Gateway Endpoint AWS (S3, DynamoDB) — juste une route, pas de ressource facturée.
  • Private Service Connect (endpoints) : payant, dépose une IP interne dans ton subnet pointant vers un service producteur (comme une Interface Endpoint / PrivateLink AWS).

6. Diffusion Globale et Répartition de Charge

Cloud CDN : le cache mondial

  • Fonctionne en s’adossant à un Cloud Load Balancer — pas de ressource “CDN” indépendante comme CloudFront. Cache aux edge PoPs de Google si le contenu est un hit, sinon va chercher à l’origine (Cloud Storage, Compute Engine, backend GKE).

Cloud Load Balancing : global et anycast, par défaut

  • Différence majeure avec AWS : il n’existe pas de produit séparé équivalent à Global Accelerator. Le Load Balancer HTTP(S) externe de GCP est nativement global : une seule IP anycast, le trafic entre sur le réseau privé de Google (Premium Tier) au point de présence le plus proche de l’utilisateur, puis voyage sur le backbone Google jusqu’au backend — exactement ce que fait Global Accelerator sur AWS, mais intégré par défaut.
  • Standard Tier : option moins chère, le trafic reste sur l’Internet public plus longtemps avant d’entrer sur le réseau Google — plus proche d’un ELB “régional” classique.
  • Types : Global external Application Load Balancer (L7, HTTP(S)), Global external proxy Network Load Balancer (L4, TCP/SSL), Regional/Internal Load Balancers pour le trafic interne au VPC.
  • Network Endpoint Groups (NEG) : routage direct vers des pods GKE plutôt que vers des nœuds entiers.

7. L’Intelligence du Routage : Cloud DNS vs Load Balancer

Même distinction qu’AWS entre le DNS (macro, avant la connexion) et le Load Balancer (micro, après la connexion) :

  • Cloud DNS (le GPS global) : résout un nom vers une IP, “stateless” — ne voit ni le CPU ni la RAM des serveurs, décide via des règles déclaratives.
  • Load Balancer (le vigile local) : reçoit la connexion sur l’IP donnée par Cloud DNS (ou directement, puisque le LB a déjà une IP anycast fixe) et distribue les paquets aux backends.

Routing policies Cloud DNS (mêmes concepts que Route 53) :

  1. Simple : un nom → une IP fixe.
  2. Weighted Round Robin : répartition pondérée façon “dé virtuel”, comme le Weighted Routing de Route 53.
  3. Geolocation : route selon la localisation géographique déduite de l’IP du client.
  4. Failover / Health Checks : bascule vers une IP de secours si les sondes échouent.

⚠️ Même piège qu’avec Route 53 : Cloud DNS ne connaît jamais la charge réelle du serveur. C’est le rôle du Load Balancer (avec ses propres health checks applicatifs) de vérifier la charge et de retirer un backend saturé de la rotation.

💡 L’Aide-mémoire Ultime de l’Architecte GCP

  • Le VPC est global — penser plan d’adressage à l’échelle mondiale dès le départ, pas région par région.
  • Un seul système de firewall (Firewall Rules) remplace le duo SG + NACL — une seule liste de priorités à auditer.
  • Shared VPC avant Peering pour le multi-équipes — c’est le pattern par défaut sur GCP, contrairement à AWS.
  • Cloud NAT n’a pas d’IP propre à retenir : c’est une config sur un Cloud Router, pas une ressource “boîte noire”.
  • Cloud Load Balancing = ELB + Global Accelerator réunis par défaut en Premium Tier — pas besoin d’un second produit pour l’anycast global.
  • Cloud Interconnect pour une fibre privée dédiée ; Cloud VPN (HA) pour un tunnel chiffré rapide à monter via Internet.
  • Private Service Connect / Private Google Access pour rester 100% privé vers les APIs Google, sans NAT.

En relation avec

Graph View

Backlinks