GCP - Load Balancing

Google Cloud offers various load balancing options, each designed for specific use cases. The Global External Network Load Balancer and the Global External Application Load Balancer are two distinct types, primarily differing in the OSI model layer at which they operate and the features they provide.

Global External Network Load Balancer

The Global External Network Load Balancer operates at Layer 4 (L4) of the OSI model, primarily dealing with TCP and UDP traffic. It's a pass-through load balancer, meaning it forwards incoming client requests directly to healthy backend instances without proxying or terminating the connection.

Key Characteristics:

OSI Layer: Layer 4 (Transport Layer).
Protocols: Primarily TCP and UDP. It can also handle SSL/TLS traffic in passthrough mode (where the SSL termination happens on the backend instance, not the load balancer).
Traffic Distribution: Distributes traffic based on source IP, destination IP, port, and protocol.
Client IP Preservation: The original client IP address is preserved and visible to the backend instances.
Backends: Supports instance groups (managed and unmanaged) and private IP addresses as backends.
Global Reach: Provides a single global IP address (Anycast IP) that can route traffic to the closest healthy backend in a regional or global setup.
Health Checks: Uses TCP, SSL, HTTP, HTTPS, or UDP health checks to determine backend instance health.
Use Cases: High-performance services requiring direct client IP access, gaming servers, custom protocols, non-HTTP(S) applications, and applications where SSL termination is best handled by the backend itself.

Global External Application Load Balancer

The Global External Application Load Balancer operates at Layer 7 (L7) of the OSI model, specifically designed for HTTP(S) traffic. It acts as a proxy, terminating client connections at the load balancer and establishing new connections to the backend. This allows for advanced traffic management features.

Key Characteristics:

OSI Layer: Layer 7 (Application Layer).
Protocols: HTTP, HTTPS, HTTP/2, QUIC.
Traffic Distribution: Distributes traffic based on URL path, host header, cookie information, and other HTTP attributes.
Client IP Preservation: Does not directly preserve the original client IP; it adds the client IP to the X-Forwarded-For header. The load balancer's IP is seen by the backend.
SSL/TLS Termination: Can perform SSL/TLS termination at the load balancer level, offloading the encryption/decryption burden from backend instances.
Backends: Supports instance groups (managed and unmanaged), serverless (Cloud Run, App Engine, Cloud Functions), external backends (Internet NEG), and GKE Ingress.
Global Reach: Provides a single global IP address (Anycast IP) for low-latency access from anywhere in the world, routing users to the closest healthy backends.
Advanced Features:
- URL Maps: Content-based routing (e.g., example.com/videos goes to one backend, example.com/images goes to another).
- Host-based routing: api.example.com goes to one backend, www.example.com to another.
- Cloud Armor Integration: Provides Web Application Firewall (WAF) capabilities and DDoS protection.
- Identity-Aware Proxy (IAP) Integration: Secures access to web applications.
- Session Affinity (Sticky Sessions): Routes subsequent requests from the same client to the same backend instance.
- Traffic Management: Weighted traffic splitting, header-based routing, request/response rewriting.
Health Checks: Uses HTTP, HTTPS, or HTTP/2 health checks.
Use Cases: Web applications, APIs, microservices architectures, content delivery networks (CDNs), services requiring SSL termination at the edge, and services needing advanced routing or security features (WAF).

Side-by-Side Comparison

Feature	Global External Network Load Balancer	Global External Application Load Balancer
OSI Layer	Layer 4 (Transport)	Layer 7 (Application)
Protocols Supported	TCP, UDP, SSL (passthrough)	HTTP, HTTPS, HTTP/2, QUIC
Client IP Address	Preserved (visible to backends)	Added to `X-Forwarded-For` header (Load Balancer's IP seen)
SSL/TLS Handling	Passthrough (backends handle SSL termination)	Termination (Load Balancer handles SSL termination)
Traffic Steering	Based on IP address, port, protocol (simple distribution)	Based on URL path, host, headers, cookies (advanced routing)
Backend Types	Instance groups (managed/unmanaged), private IP addresses	Instance groups, serverless, external backends, GKE Ingress
Advanced Features	Minimal, focused on L4 traffic	URL mapping, host routing, Cloud Armor, IAP, session affinity, traffic management
Complexity	Simpler to configure and manage	More complex configuration due to rich feature set
Primary Use Cases	Gaming, VoIP, custom protocols, high-performance TCP/UDP	Web apps, APIs, microservices, CDN, WAF protection

When to Use Which:

Choose Global External Network Load Balancer when:

Your application uses non-HTTP(S) protocols (e.g., custom TCP/UDP, gaming servers).
You need to preserve the original client IP address directly on the backend instance.
You prefer to handle SSL/TLS termination on your backend instances rather than at the load balancer.
You require maximum performance and minimal latency for L4 traffic.
Your routing needs are simple and based purely on network-layer information.

Choose Global External Application Load Balancer when:

Your application uses HTTP(S) protocols (web applications, REST APIs, microservices).
You need advanced content-based routing (e.g., routing based on URL path or hostname).
You want to offload SSL/TLS termination from your backend instances to the load balancer.
You require WAF capabilities and DDoS protection (via Cloud Armor integration).
You need session affinity (sticky sessions) for stateful applications.
You are integrating with serverless backends (Cloud Run, App Engine, Cloud Functions) or GKE Ingress.
You need to control traffic management (e.g., weighted traffic splitting for A/B testing or canary deployments).

In essence, the Network Load Balancer is a lean, high-performance L4 workhorse for raw TCP/UDP traffic, while the Application Load Balancer is a feature-rich L7 proxy specifically designed for the complexities of modern web applications and APIs.

SWP and Proxy-only subnet

SWP and other load balancers are based on Envoy: NLB and SWP are running as Envoy jobs, each task is for one tenant.
proxy-only subnet: A proxy-only subnet provides a pool of IP addresses that are reserved exclusively for Envoy proxies used by Google Cloud load balancers. It cannot be used for any other purposes.
The SWP instance resides within a dedicated VPC, A Private Service Connect (PSC) service attachment is deployed in the centralized proxy VPC, allowing users to connect to SWP via PSC