6.3 Cloud Load Balancing, Cloud CDN & Cloud DNS

Cloud Load Balancing, Cloud CDN & Cloud DNS

Architectural Paradigm: Traditional cloud architectures rely on DNS round-robin or regional load balancers that introduce high latency and complex cross-region failover scripts. Google Cloud fundamentally reimagines traffic management through Global Anycast IP routing and software-defined traffic proxies (Envoy and Maglev). A single Anycast IP address serves millions of users worldwide, terminating connections at edge Points of Presence (PoPs) within milliseconds of the end user.

---

Cloud Load Balancing Taxonomy & Classification

Google Cloud Load Balancing is a fully distributed, software-defined managed service. It is not an appliance or virtual machine cluster that can bottleneck under traffic spikes; it scales instantaneously from zero to millions of requests per second.

+-----------------------------------------------------------------------------------------+
|                         GOOGLE CLOUD LOAD BALANCER TAXONOMY                             |
+-----------------------------------------------------------------------------------------+
|                                 APPLICATION (LAYER 7)                                   |
|   - Global External Application Load Balancer (Envoy Proxy, HTTP/HTTPS, HTTP/2, HTTP/3) |
|   - Regional External Application Load Balancer (Envoy Proxy, Regional Data Locality)   |
|   - Internal Application Load Balancer (Regional / Cross-Region Private Envoy Proxy)    |
+-----------------------------------------------------------------------------------------+
|                                   NETWORK (LAYER 4)                                     |
|   - External Proxy Network Load Balancer (Global/Regional TCP/SSL Proxy, SSL Offload)   |
|   - Internal Proxy Network Load Balancer (Regional Envoy TCP Proxy)                     |
|   - External Passthrough Network Load Balancer (Regional Maglev Passthrough, Direct DSR)|
|   - Internal Passthrough Network Load Balancer (Regional Andromeda Passthrough SDN)     |
+-----------------------------------------------------------------------------------------+

Comprehensive Load Balancer Comparison Matrix

---

Global Anycast IP Architecture

When a client connects to a Global External Application Load Balancer or External Proxy Network Load Balancer, the connection behaves fundamentally differently from traditional DNS-based multi-region load balancing.

+-----------------------------------------------------------------------------------------+
|                            GLOBAL ANYCAST ROUTING MECHANICS                             |
|                                                                                         |
|   User in Tokyo (Client)                 User in Frankfurt (Client)                     |
|        |                                              |                                 |
|        v (Sub-5ms to Edge)                           v (Sub-5ms to Edge)                |
|   [ Google Edge PoP: Tokyo ]                     [ Google Edge PoP: Frankfurt ]         |
|   * Anycast IP: 34.120.50.1                      * Anycast IP: 34.120.50.1              |
|   * TCP / TLS Handshake Terminates               * TCP / TLS Handshake Terminates       |
|   * HTTP/3 & BBR Congestion Control              * HTTP/3 & BBR Congestion Control      |
|        |                                              |                                 |
|        +---------------------+  Google Private Backbone  +------------------------------+
|                              |  (Long-Lived TCP Pools)  |                              |
|                              v                          v                              |
|                  [ Backend: us-central1 ]    [ Backend: europe-west3 ]                  |
+-----------------------------------------------------------------------------------------+

Core Benefits of Google Anycast Routing

1. Edge TLS Termination: The client establishes the TCP 3-way handshake and TLS cryptographic negotiation with the nearest Google Edge Point of Presence (PoP), often less than 10 milliseconds away.
2. Backbone Acceleration: Traffic between the Google Edge PoP and backend instances flows over Google's private global fiber network using pre-warmed, persistent TCP connection pools and BBR congestion control, bypassing public internet packet loss and congestion.
3. Instant Cross-Region Failover: If backend instances in europe-west3 become unhealthy or reach capacity limits, the global load balancer instantly routes incoming requests to the nearest healthy region (e.g., us-central1) without waiting for DNS TTL caches to expire.

---

Network Endpoint Groups (NEGs) & Backend Architecture

Modern cloud-native architectures require load balancers to route traffic to abstractions beyond traditional Compute Engine virtual machine instance groups. Network Endpoint Groups (NEGs) decouple the load balancer from raw VM instances.

+-----------------------------------------------------------------------------------------+
|                         NETWORK ENDPOINT GROUP (NEG) SPECTRUM                           |
+-----------------------------------------------------------------------------------------+
|  1. ZONAL NEGs           |  Direct IP:Port endpoints (e.g., GKE Pod IPs).               |
|                          |  Enables Container-Native Load Balancing (No kube-proxy NAT) |
+--------------------------+--------------------------------------------------------------+
|  2. SERVERLESS NEGs      |  Points directly to Cloud Run, App Engine, or Cloud Functions|
|                          |  Enables custom domains, Cloud Armor WAF, and Cloud CDN.     |
+--------------------------+--------------------------------------------------------------+
|  3. HYBRID NEGs          |  Points to on-premises IP:Port endpoints via VPN/Interconnect|
|                          |  Enables seamless hybrid traffic migration and routing.      |
+--------------------------+--------------------------------------------------------------+
|  4. INTERNET NEGs        |  Points to external public endpoints outside Google Cloud.   |
|                          |  Enables Cloud CDN caching and Cloud Armor for external apps.|
+-----------------------------------------------------------------------------------------+

Container-Native Load Balancing via Zonal NEGs

In standard GKE clusters using Instance Groups, the load balancer sends traffic to the VM node's NodePort. The node's internal kube-proxy iptables rules then execute a second network hop (DNAT) to route the packet to the actual Pod running on a different node.

With Container-Native Load Balancing (Zonal NEGs):

• The Google Cloud Load Balancer routes traffic directly to the Pod's primary IP address.
• Eliminates double-hopping, reducing p99 latency by up to 40%.
• Preserves accurate client source IP addresses without complex externalTrafficPolicy: Local workarounds.
• Health checks evaluate individual container health endpoints directly rather than entire VM nodes.

---

URL Maps, Path Routing & Canary Traffic Splitting

The URL Map is the core Layer 7 traffic routing engine for Application Load Balancers. It inspects incoming HTTP/S request headers, hostnames, paths, and query parameters to determine routing behavior.

+-----------------------------------------------------------------------------------------+
|                                 URL MAP ROUTING ENGINE                                  |
|                                                                                         |
|   Incoming Request: https://api.example.com/v2/checkout                                 |
|                                                                                         |
|   1. Host Rule Match:        api.example.com                                            |
|   2. Path Matcher:           /v2/*                                                      |
|   3. Traffic Split Policy:   90% -> Backend Service Production (v2.0)                   |
|                              10% -> Backend Service Canary (v2.1)                       |
|   4. Header Transformation:  Inject 'X-Client-Region: US'                              |
|   5. Security Policy:        Cloud Armor 'block-sql-injection-policy'                   |
+-----------------------------------------------------------------------------------------+

Key URL Map Capabilities

• Host-Based Routing: Routes example.com to web frontends and api.example.com to microservice API clusters.
• Path-Based Routing: Routes /static/* to a Cloud Storage Backend Bucket, /video/* to video streaming clusters, and /api/* to GKE services.
• Canary Deployments & Weighted Traffic Splitting: Directs a precise percentage of live user traffic (e.g., 5%) to a canary backend service running a new software version while sending 95% to the stable production backend service.
• URL Redirects & Rewrites: Automatically enforces HTTP-to-HTTPS redirects at the load balancer edge with zero compute overhead.

---

Cloud CDN Architecture & Edge Caching

Cloud CDN (Content Delivery Network) integrates natively with the Global External Application Load Balancer. Enabling Cloud CDN requires merely checking a box on the backend service or backend bucket.

+-----------------------------------------------------------------------------------------+
|                             CLOUD CDN CACHING WORKFLOW                                  |
|                                                                                         |
|  Client Request ===> [ Edge PoP Cache Hit (95%) ] ===(Instant 2ms Response)===> Client  |
|                             |                                                           |
|                      Cache Miss (5%)                                                    |
|                             v                                                           |
|                [ Backend Service / GCS Bucket ]                                         |
+-----------------------------------------------------------------------------------------+

Cloud CDN Configuration Levers

1. Cache Modes:
   • CACHE_ALL_STATIC: Automatically caches static web assets (images, CSS, JS, PDFs) based on file extensions, honoring origin Cache-Control headers.
   • USE_ORIGIN_HEADERS: Caches strictly according to Cache-Control, Expires, and Pragma headers generated by the origin backend service.
   • FORCE_CACHE_ALL: Unconditionally caches all responses, overriding origin headers.
2. Custom Cache Keys: By default, the cache key includes the full URI (protocol, host, path, and all query parameters). Architects can optimize cache hit ratios by stripping non-essential query parameters (e.g., utm_source, session_id) or including specific HTTP request headers.
3. Negative Caching: Instructs Cloud CDN to cache HTTP error responses (e.g., 404 Not Found, 502 Bad Gateway) for short durations (e.g., 30 seconds), preventing malicious query flooding from overwhelming backend databases.
4. Cache Invalidation: Supports instant global cache purging by exact URL, directory prefix, or wildcard path (/images/*).

---

Cloud DNS: Public, Private, Hybrid & Advanced Routing

Cloud DNS is a high-performance, resilient global DNS service that guarantees 100% availability SLA by utilizing Anycast name servers distributed across all Google Edge locations worldwide.

+-----------------------------------------------------------------------------------------+
|                        HYBRID SPLIT-HORIZON & FORWARDING DNS                            |
|                                                                                         |
|  +-----------------------------------+        +--------------------------------------+  |
|  | GOOGLE CLOUD VPC                  |        | ON-PREMISES ENTERPRISE NETWORK       |  |
|  |                                   |        |                                      |  |
|  | Private Zone: corp.internal       |        | Active Directory DNS: onprem.corp    |  |
|  | (Resolves 10.10.x.x RFC 1918)     |        | (Resolves 192.168.x.x)               |  |
|  |                                   |        |                                      |  |
|  | Outbound Forwarding Zone:         | =====> | On-Prem DNS Forwarder IP             |  |
|  | *.onprem.corp -> 192.168.1.10     |        | (Resolves onprem.corp queries)       |  |
|  |                                   |        |                                      |  |
|  | Inbound Server Policy:            | <===== | On-Prem DNS Conditional Forwarder    |  |
|  | Inbound Forwarder IP: 10.10.0.254 |        | *.gcp.corp -> 10.10.0.254            |  |
|  +-----------------------------------+        +--------------------------------------+  |
+-----------------------------------------------------------------------------------------+

Enterprise Cloud DNS Zone Types & Policies

1. Public DNS Zones: Internet-facing authoritative zones serving DNS records to the global internet.
2. Private DNS Zones: Authoritative zones accessible only within authorized Google Cloud VPC networks.
3. Split-Horizon DNS: Hosting both a public zone and a private zone for the same domain name (e.g., app.example.com). Public internet users resolve to the external Anycast Load Balancer IP, while internal VPC instances resolve to the internal RFC 1918 private IP.
4. DNS Forwarding Zones & Inbound Server Policies:
   • Outbound DNS Forwarding: Allows VPC instances to resolve on-premises DNS domains (e.g., corp.local) by forwarding queries to on-premises DNS servers over Cloud VPN or Interconnect.
   • Inbound DNS Forwarding Policy: Allocates a dedicated internal IP address (e.g., 10.10.0.254) inside the VPC that on-premises DNS servers can target with conditional forwarding rules to resolve private GCP DNS records.
5. DNS Peering: Shares a private DNS zone from one VPC to another VPC without establishing full network peering or routing connectivity.
6. Advanced DNS Routing Policies:
   • Geolocation Routing: Resolves DNS queries to the IP address of the nearest regional deployment based on the client's geographic origin.
   • Weighted Round-Robin (WRR): Splits DNS resolution across multiple backend endpoints according to assigned percentage weights (useful for blue/green migrations across multi-cloud environments).

---

Concrete Architectural Scenario: Global E-Commerce Architecture

Scenario Profile

• Platform: Global digital retail platform with millions of concurrent shoppers in North America, Europe, and Asia.
• Architecture Blueprint:
  1. Frontend Entrypoint: Global External Application Load Balancer configured with a single Anycast IP and Google-managed SSL certificates.
  2. Static Media & Product Images: URL map routes /images/* and /catalog/static/* to a Cloud Storage Backend Bucket with Cloud CDN enabled (CACHE_ALL_STATIC mode with custom cache key stripping analytics parameters).
  3. Checkout & Transaction Microservices: URL map routes /api/checkout to a VPC-native GKE cluster using Zonal NEGs for container-native routing with zero kube-proxy hop latency.
  4. Canary Release Strategy: URL map applies a 90/10 weighted traffic split on /api/payment between payments-service-prod and payments-service-v2-canary.
  5. Hybrid Inventory Lookup: URL map routes /inventory/legacy/* to an internal on-premises mainframe using a Hybrid NEG connected over Cloud Dedicated Interconnect.

---

[!IMPORTANT] Exam Watch: Health check probes originate from Google internal IP ranges 35.191.0.0/16 and 130.211.0.0/22 (or 209.85.152.0/22 / 209.85.204.0/22 for regional LBs). You must configure ingress firewall rules permitting traffic from these exact IP CIDRs to backend instance ports, or the load balancer will mark all backend instances unhealthy and drop connections. For hybrid DNS resolution, on-premises DNS servers cannot query Cloud DNS directly without an Inbound Server Policy provisioned in the VPC.