Après avoir détaillé le fonctionnement des Load Balancers sur Azure, penchons-nous sur l’approche radicalement différente de Google Cloud Platform (GCP).

Là où la plupart des fournisseurs cloud historiques instancient des paires de machines virtuelles dédiées dans votre VPC lors de la création d’un répartiteur de charge, GCP s’appuie sur son infrastructure logicielle mondiale (Maglev et les Google Front Ends : GFE) directement en bordure de son réseau fibre optique.

1. Load Balancer de Niveau 4 (Couche Transport OSI) sur GCP

En couche 4 (TCP, UDP, ESP, ICMP), GCP utilise son répartiteur distribué Maglev :

• Pass-through Network Load Balancer : les paquets ne sont pas terminés par un proxy intermédiaire ; ils sont routés directement vers la VM ou le nœud GKE cible qui porte l’adresse IP VIP en Direct Server Return (DSR). La latence ajoutée est quasi nulle et l’adresse IP source du client est nativement préservée.
• Proxy Network Load Balancer (TCP/SSL Proxy) : termine la connexion TCP à l’Edge Google le plus proche de l’utilisateur avant d’ouvrir une connexion optimisée sur le backbone privé de Google jusqu’à la région cible.

2. Load Balancer de Niveau 7 (Couche Application OSI) sur GCP

L’équivalent d’Azure Application Gateway sur GCP est le Global External HTTP(S) Load Balancer :

• Une seule IP Anycast mondiale : vos utilisateurs à Paris, Tokyo ou Montréal interrogent la même adresse IPv4/IPv6. Ils entrent sur le réseau privé de Google dès la première milliseconde (PoP local) ;
• Routage intelligent L7 (URL Maps) : aiguillage par nom d’hôte, préfixe d’URL (/api/* vers GKE, /static/* vers un bucket Cloud Storage avec Cloud CDN activé) ;
• Couplage natif avec Cloud Armor : protection DDoS et pare-feu applicatif (WAF) évalués à la périphérie avant même que le trafic n’atteigne votre VPC.

3. Supervision avec Cloud Monitoring & Cloud Logging (MQL)

Contrairement aux Load Balancers L4 pass-through dont la télémétrie se lit au niveau du flux réseau, le Load Balancer L7 génère un journal structuré pour chaque requête HTTP. Voici comment isoler les latences back-end et les erreurs 5xx dans Logs Explorer :

resource.type="http_load_balancer"
httpRequest.status >= 500

Et via Monitoring Query Language (MQL) pour tracer le 99e centile de latence totale (total_latencies) vers Grafana :

fetch https_lb_rule
| metric 'loadbalancing.googleapis.com/https/total_latencies'
| group_by 1m, [value_total_latencies_percentile: percentile(value.total_latencies, 99)]
| every 1m

MàJ 2026 Bascule sur Envoy, HTTP/3 et Kubernetes Gateway API

Cinq ans plus tard, l’architecture d’équilibrage de charge GCP a franchi un cap majeur :

Les 3 nouveautés incontournables en 2026

1. Architecture unifiée autour d’Envoy : les nouveaux Application Load Balancers (globaux, régionaux et internes) reposent sur une pile Envoy managée qui offre des capacités avancées de gestion de trafic (injection de fautes, circuit breaking, outlier detection automatique des pods défaillants).
2. Cloud Service Mesh & Gateway API : sur GKE, l’ancien objet Ingress laisse place à l’API déclarative Kubernetes Gateway, permettant de partager un même Load Balancer L7 entre plusieurs namespaces d’équipes en toute sécurité.
3. Cross-Cloud Network : les Application Load Balancers GCP peuvent désormais cibler des back-ends hybrides ou multi-cloud via des Network Endpoint Groups (Hybrid Connectivity NEGs).

Partager cette note :

LinkedIn Post X Telegram E-mail Copier le lien

Hardening Maximal en Production (CLI gcloud & Terraform)

Pour sécuriser un Google Cloud External Application Load Balancer (GFE L7) au niveau CIS Benchmark Level 2, trois verrous sont indispensables [1] :

1. Politique TLS 1.3 stricte (MODERN / RESTRICTED avec TLS 1.2 minimum ou TLS 1.3 exclusivement) [2].
2. Google Cloud Armor WAF attaché au BackendService avec règles préconfigurées OWASP Top 10 (sqli-v33-stable, xss-v33-stable) et Adaptive Protection L7 [3].
3. Journalisation d’audit et en-têtes de sécurité HSTS forcés sur le proxy HTTPS cible.

1. Commandes CLI (gcloud) : Hardening Complet

# 1. Créer une politique SSL/TLS stricte (TLS 1.2+ profil RESTRICTED)
gcloud compute ssl-policies create prod-ssl-policy-strict \
  --profile=RESTRICTED \
  --min-tls-version=1.2

# 2. Créer une politique Cloud Armor WAF (Protection DDoS L7 + OWASP SQLi/XSS + Rate Limit)
gcloud compute security-policies create prod-cloud-armor-waf \
  --description="Hardening maximal WAF L7 + Adaptive Protection"

gcloud compute security-policies update prod-cloud-armor-waf \
  --enable-layer7-ddos-defense \
  --layer7-ddos-defense-rule-visibility=STANDARD

gcloud compute security-policies rules create 1000 \
  --security-policy=prod-cloud-armor-waf \
  --expression="evaluatePreconfiguredWaf('sqli-v33-stable') || evaluatePreconfiguredWaf('xss-v33-stable')" \
  --action=deny-403 \
  --description="Block OWASP SQLi and XSS"

# 3. Attacher Cloud Armor et la politique TLS au Load Balancer
gcloud compute backend-services update prod-backend-svc \
  --global \
  --security-policy=prod-cloud-armor-waf \
  --enable-logging \
  --logging-sample-rate=1.0

gcloud compute target-https-proxies update prod-https-proxy \
  --ssl-policy=prod-ssl-policy-strict

2. Terraform HCL : Load Balancer GCP Hardened (TLS + Cloud Armor WAF)

resource "google_compute_ssl_policy" "strict_tls" {
  name            = "prod-ssl-policy-strict"
  profile         = "RESTRICTED"
  min_tls_version = "TLS_1_2"
}

resource "google_compute_security_policy" "waf_hardened" {
  name        = "prod-cloud-armor-waf"
  description = "WAF L7 OWASP + Adaptive Protection DDoS"

  adaptive_protection_config {
    layer_7_ddos_defense_config {
      enable          = true
      rule_visibility = "STANDARD"
    }
  }

  rule {
    action   = "throttle"
    priority = 900
    match {
      versioned_expr = "SRC_IPS_V1"
      config { src_ip_ranges = ["*"] }
    }
    rate_limit_options {
      conform_action = "allow"
      exceed_action  = "deny(429)"
      enforce_on_key = "IP"
      rate_limit_threshold {
        count        = 300
        interval_sec = 60
      }
    }
    description = "Rate limiting anti-burst par IP"
  }

  rule {
    action   = "deny(403)"
    priority = 1000
    match {
      expr {
        expression = "evaluatePreconfiguredWaf('sqli-v33-stable') || evaluatePreconfiguredWaf('xss-v33-stable')"
      }
    }
    description = "Blocage OWASP SQLi & XSS"
  }

  rule {
    action   = "allow"
    priority = 2147483647
    match {
      versioned_expr = "SRC_IPS_V1"
      config { src_ip_ranges = ["*"] }
    }
    description = "Default allow after WAF inspection"
  }
}

resource "google_compute_backend_service" "hardened_backend" {
  name                  = "prod-backend-svc"
  protocol              = "HTTPS"
  load_balancing_scheme = "EXTERNAL_MANAGED"
  security_policy       = google_compute_security_policy.waf_hardened.id
  enable_cdn            = false

  log_config {
    enable      = true
    sample_rate = 1.0
  }

  custom_response_headers = [
    "Strict-Transport-Security: max-age=63072000; includeSubDomains; preload",
    "X-Content-Type-Options: nosniff",
    "X-Frame-Options: DENY"
  ]
}

Sources

• [1] Google Cloud Official Documentation : Cloud Load Balancing Overview & Architecture
• [2] Google Cloud Official Documentation : SSL Policies for HTTPS Load Balancers
• [3] Google Cloud Official Documentation : Google Cloud Armor Security Policies & Adaptive Protection