3.2 Geography, Network Tiers, and Load Balancers

2.1 Geographic Distribution & Cloud Load Balancing

Designing resilient, highly responsive cloud-native applications on Google Cloud requires understanding how client requests traverse global network infrastructure. As a developer, selecting the correct load balancing architecture, network service tier, and backend abstraction determines whether your services survive regional outages, satisfy latency service level objectives (SLOs), and adhere to international data sovereignty mandates.

---

Geographic Resilience: Zonal, Regional, and Multi-Region Architectures

Google Cloud partitions its physical infrastructure into regions (independent geographic areas) and zones (isolated failure domains within a region interconnected with low-latency, high-bandwidth networking).

+--------------------------------------------------------------------------+
| Google Cloud Physical Infrastructure Topology                           |
+--------------------------------------------------------------------------+
| Multi-Region (Global Anycast Routing, Active-Active Cross-Continent)     |
|                                                                          |
|  +---------------------------+       +---------------------------+       |
|  | Region: us-central1       |       | Region: europe-west1      |       |
|  | (Service-specific availability)    |       | (Service-specific availability)    |       |
|  |  +------+ +------+ +------+ |     |  +------+ +------+ +------+ |     |
|  |  |Zone A| |Zone B| |Zone C| |     |  |Zone B| |Zone C| |Zone D| |     |
|  |  +------+ +------+ +------+ |     |  +------+ +------+ +------+ |     |
|  +---------------------------+       +---------------------------+       |
+--------------------------------------------------------------------------+

Zonal Deployments

• Topology: Resources (such as standalone Compute Engine VMs, zonal persistent disks, or single-zone GKE node pools) reside entirely within a single zone (e.g., us-central1-a).
• Availability: Single point of failure. A localized data center power disruption, physical hardware fault, or maintenance event will cause downtime.
• Use Cases: Batch compute tasks with checkpointing, non-production test environments, or temporary processing instances where cost minimization overrides availability.

Regional Deployments

• Topology: Resources use a service-specific multi-zone design within one region (e.g., regional Managed Instance Groups [MIGs] or regional GKE clusters operating in us-central1).
• Availability: Availability SLAs depend on the product, edition, and deployment configuration. If an entire zone fails, the regional control plane and healthy instances in surviving zones continue serving traffic without operational disruption.
• Compliance & Latency: Regional placement can help meet residency requirements. Assess the specific service, replication, backups, logs, support access, and contract; a regional deployment does not itself establish regulatory compliance.

Multi-Region Deployments

• Topology: Services run active-active across multiple geographically separated regions (e.g., us-central1, europe-west1, and asia-east1).
• Availability: Shields the system against catastrophic civil infrastructure failures, submarine cable cuts, or total regional cloud outages.
• Routing Mechanics: Client traffic is directed to the geographically closest healthy region via Anycast BGP routing, minimizing Round-Trip Time (RTT).

---

Network Service Tiers: Premium Tier vs. Standard Tier

Google Cloud provides two distinct network tiers for external public ingress and egress. The network tier directly dictates how packets traverse the public internet versus Google's internal private fiber network.

Exam Trap: Global External Application Load Balancers cannot be deployed using Standard Tier. If a question describes deploying a global HTTP/S load balancer with a single Anycast IP to route between North America and Europe, Premium Tier is mandatory.

---

Cloud Load Balancing Topology

Google Cloud Load Balancing is a software-defined, distributed proxy service implemented across Google's global Andromeda virtualization and Envoy proxy fleet. It is not an appliance; there is no physical bottleneck or pre-warming requirement.

+--------------------------------------------------------------------------+
| Google Cloud Load Balancing Architectural Topology                       |
+--------------------------------------------------------------------------+
|                                                                          |
| [ External Traffic ]                                                     |
|         |                                                                |
|         v                                                                |
|  +--------------------------------------------------------------------+  |
|  | Global External Application Load Balancer (Google Front Ends)    |  |
|  | - Single Global Anycast VIP (IPv4/IPv6)                             |  |
|  | - Edge SSL/TLS Termination & HTTP/2 / HTTP/3 (QUIC) Support        |  |
|  | - Edge Cloud Armor WAF & DDoS Inspection                           |  |
|  | - Cloud CDN Edge Cache Offload                                     |  |
|  +--------------------------------------------------------------------+  |
|         |                                                                |
|         | URL Map Routing (Host Rules, Path Matchers, Header Matchers)   |
|         v                                                                |
|  +----------------------------------+---------------------------------+  |
|  |                                  |                                 |  |
|  v                                  v                                 v  |
| [ Backend Service: US ]            [ Backend Service: EU ]         [ GCS Bucket ]
|  - Serverless NEG: no balancing-mode capacity settings    - Serverless NEG: no balancing-mode capacity settings  (Static Assets)
|  - Cloud Run affinity configured on the service                                 |
|  +-------------------+              +-------------------+             |
|  | Serverless NEG    |              | Serverless NEG    |             |
|  | (Cloud Run: US)   |              | (Cloud Run: EU)   |             |
|  +-------------------+              +-------------------+             |
+--------------------------------------------------------------------------+

Global External Application Load Balancer

• OSI Layer: Layer 7 (HTTP, HTTPS, HTTP/2, HTTP/3 with QUIC).
• Architecture: Distributed Google Front Ends (GFEs) terminate client sessions. Regional external Application Load Balancers use regional Envoy proxies. Backends can be located across multiple regions.
• Key Features: Cross-region automatic failover, single global Anycast IP, URL maps for path-based (/api/v1/* vs /static/*) and header-based routing, traffic splitting (canary releases), and seamless integration with Cloud Armor and Cloud CDN.

Regional External Application Load Balancer

• OSI Layer: Layer 7 (HTTP/S).
• Architecture: Regional Envoy proxy terminating traffic inside a specific Google Cloud region.
• Use Case: Systems bound by data sovereignty laws requiring that TLS termination, payload inspection, and routing logic occur strictly within the borders of a specific region (e.g., Frankfurt europe-west3). Supports both Standard and Premium Tiers.

Internal Application Load Balancers (Regional & Cross-Region)

• OSI Layer: Layer 7.
• Architecture: Private RFC 1918 load balancer deployed inside a Virtual Private Cloud (VPC). Proxies traffic between internal microservices with TLS inspection, URL maps, and zero-trust service perimeters.

Official references checked October 18, 2026: Google Cloud 1.