Load Balancers Across AWS, Azure, and GCP. A Practitioner's Guide

Every hyperscaler sells you a load balancer. None of them sell you the same thing twice. Strip away the marketing names and you’ll find five recurring architectural patterns — but how each cloud implements, tiers, and prices them diverges enough to trip up even experienced architects moving between platforms.

This post breaks down the landscape in three passes: a high-level map of the categories, a deep dive into each cloud’s specific implementation, and a use-case reference you can pull from when designing.

Part 1: The High-Level Map

Regardless of vendor, load balancing on the public clouds falls into five functional categories:

The big philosophical fork is global-by-default vs. regional-by-default. GCP’s load balancers are global-first — a single anycast IP can front backends in multiple regions natively. AWS and Azure are regional-first, requiring you to bolt on a separate global layer (Global Accelerator, Front Door) to get the same effect.

The second fork is appliance insertion maturity. AWS (Gateway Load Balancer) and Azure (Gateway Load Balancer) both have a purpose-built, GENEVE-encapsulated primitive for transparently steering traffic through firewall/IDS fleets. GCP doesn’t — the closest pattern uses Private Service Connect, which is architecturally different and less standardized.

With the map in place, here’s how each cloud actually implements it.

Part 2: Deep Dive by Cloud

AWS — Elastic Load Balancing (ELB)

AWS’s ELB portfolio is the flattest of the three: four load balancer types, no internal tiering within each, consumption-based pricing built on capacity units (LCU for ALB, NLCU for NLB, GLCU for GWLB).

Application Load Balancer (ALB) — Layer 7. Terminates HTTP/HTTPS/WebSocket/gRPC, inspects the request, and routes based on path, host, header, method, or query string. Targets can be EC2 instances, IP addresses, Lambda functions, or containers via ECS/EKS. This is AWS’s default recommendation for anything web-facing — if you’re unsure which to pick, start here.

Network Load Balancer (NLB) — Layer 4. Operates on flow-hash routing, delivers single-digit millisecond latency, and scales to millions of connections per second. It allocates a static IP per Availability Zone (a common reason teams reach for it over ALB when downstream firewall allowlisting needs a fixed address) and preserves the original client source IP by default. NLB is also the load balancer of choice for PrivateLink-fronted services.

Gateway Load Balancer (GWLB) — Layer 3. Functionally distinct from the other two — it doesn’t serve application traffic at all. GWLB transparently steers traffic through a fleet of third-party virtual appliances (firewalls, IDS/IPS, DPI) using GENEVE encapsulation over port 6081. Traffic reaches it via Gateway Load Balancer Endpoints (a VPC Endpoint/PrivateLink variant), and it’s the only ELB type that interacts directly with route tables, since it operates as a network-layer next-hop rather than a traditional listener-based proxy.

Classic Load Balancer (CLB) — Legacy. No WAF integration, no WebSocket/HTTP2 support, basic round-robin or least-outstanding-requests routing. AWS’s own documentation steers customers toward ALB/NLB for any new design; CLB shows up almost exclusively in environments lifted-and-shifted from on-prem without re-architecture.

AWS Global Accelerator — worth a mention even though it’s not strictly part of ELB. It provides static anycast IPs at AWS’s edge and routes traffic into NLB, ALB, EC2, or Elastic IP backends. Notably, it accelerates any TCP/UDP application, not just HTTP — a genuine differentiator versus Azure and GCP’s more HTTP-centric global tiers.

Azure — Load Balancing & Content Delivery

Azure has the most tiered, and most recently re-tiered, lineup of the three. Two retirements matter if you’re advising customers right now:

• Basic Load Balancer was retired September 30, 2025. Anyone still running it needs to upgrade to Standard.
• Application Gateway v1 (Standard and WAF) was retired April 28, 2026. Migration to v2 (Standard_v2/WAF_v2) is now mandatory for new and existing deployments.

Azure Load Balancer (Standard SKU) — Layer 4. TCP/UDP load balancing with zone redundancy, configurable outbound rules, and HTTPS health probes. This is now the only supported SKU for general-purpose L4 balancing following Basic’s retirement.

Azure Gateway Load Balancer — Layer 3, GENEVE-encapsulated. A close architectural port of AWS’s GWLB: it chains to a Standard Load Balancer’s frontend IP configuration and uses Private Link on the consumer side. Same use case — transparent NVA insertion for firewalls and inspection appliances — released after AWS’s version and following a near-identical mechanics model.

Application Gateway (Standard_v2 / WAF_v2) — Layer 7. HTTP(S)-aware, terminates client connections and proxies separately to the backend, enabling SSL offload, header rewriting, and (on WAF_v2) OWASP-based web application firewall inspection. It’s regional and requires its own dedicated subnet, separate from backend targets. The v2 generation added autoscaling, which v1 lacked — a major reason behind the v1 retirement.

Azure Front Door (Standard / Premium) — Layer 7, global anycast. Combines CDN-style edge caching with global HTTP(S) load balancing and built-in WAF. Premium adds Private Link origin support, managed rule sets, and bot protection. Front Door and Application Gateway cause more customer confusion than any other pairing in Azure’s portfolio — Front Door is edge/global, App Gateway is regional/VNet-injected, and teams frequently reach for App Gateway when they actually need Front Door for global high availability.

Traffic Manager — DNS-level routing, not a data-plane proxy at all. It resolves DNS based on performance, priority, or geography rather than terminating and forwarding traffic. Worth distinguishing clearly from Front Door, since both get pitched as “the global option.”

GCP — Cloud Load Balancing

GCP organizes its portfolio around three primitives — Application Load Balancer (L7), proxy Network Load Balancer (L4, connection-terminating), and passthrough Network Load Balancer (L4, Direct Server Return) — each available in global, regional, cross-region, or internal variants depending on need. This is architecturally the most unified model: one mental framework, multiple deployment scopes, rather than entirely separate products.

Application Load Balancer — Layer 7, built on Envoy (regional/cross-region) or Google Front Ends (global/classic). The global external Application Load Balancer uses a single anycast IP and can direct traffic to backends across multiple regions natively — this is the clearest expression of GCP’s global-by-default philosophy. The classic Application Load Balancer is the legacy global HTTP(S) LB, global in Premium Tier but regional-only in Standard Tier. Regional external and internal (regional or cross-region) variants exist for single-region or VPC-internal use.

Proxy Network Load Balancer — Layer 4, connection-terminating. Used for TCP/SSL traffic that isn’t HTTP(S) but still benefits from proxy-based termination. Available in global, regional, and internal-regional modes.

Passthrough Network Load Balancer — Layer 4, true pass-through using Direct Server Return — the load balancer doesn’t terminate the connection; backend VMs respond directly to clients, preserving source IP without proxy overhead. Built on Maglev (external) or Andromeda (internal). The internal variant supports the broadest protocol range of any GCP load balancer: TCP, UDP, ICMP, ICMPv6, SCTP, ESP, AH, and GRE.

Network Service Tiers (Premium vs. Standard) — a cross-cutting dimension unique to GCP. Premium Tier routes traffic over Google’s private global backbone; Standard Tier routes over the public internet at lower cost but with fewer global capabilities. Not every load balancer type supports Standard Tier, so this becomes a real design constraint, not just a cost lever.

No native GWLB equivalent. The closest pattern for transparent appliance insertion uses Private Service Connect producer/consumer architecture, which is fundamentally different from GENEVE-based steering and considerably less standardized — most GCP customers historically hand-rolled this with custom routes and an Internal Load Balancer, similar to how AWS customers worked before GWLB existed. GCP increasingly pushes customers toward managed third-party integrations (e.g., Palo Alto Cloud NGFW for GCP) instead.

Post-quantum note: GCP has begun rolling out post-quantum key exchange on SSL policies, with default-on enablement phased in from October 2026 through October 2027. Worth tracking if PQC readiness is part of your evaluation criteria — the hyperscalers are moving the same direction the rest of the industry is.

Part 3: Use Cases by Category

Layer 4 (NLB / Azure Standard LB / GCP Network LB)

• Ultra-low-latency, high-throughput TCP/UDP — gaming backends, financial trading, IoT telemetry ingestion
• Static IP requirements for downstream firewall allowlisting or partner peering
• Preserving real client source IP for backend-side geo-routing or fraud detection
• Non-HTTP protocols — MQTT, SMTP, database connection pooling
• TLS passthrough for compliance-driven end-to-end encryption
• Absorbing extreme, sudden traffic spikes without L7 processing overhead

Layer 7 (ALB / Application Gateway / GCP Application LB)

• Microservices routing by path or host to different backend pools
• WAF-integrated edge defense against OWASP Top 10 threats
• Blue/green and canary deployments via weighted target groups
• Container-native routing — direct integration with ECS/EKS, AKS (via AGIC), or GKE
• Authentication offload before traffic reaches backends (Cognito/OIDC, Azure AD)
• HTTP-triggered serverless backends (ALB → Lambda is a common pattern)

Global/Anycast (Global Accelerator / Front Door / GCP Global LB)

• Multi-region active-active architectures behind a single IP or hostname
• DDoS resilience absorbed at the provider’s edge rather than your origin
• Disaster recovery with health-check-driven failover (faster than DNS TTL-based failover)
• CDN and load balancing convergence for global, content-heavy applications
• Non-HTTP global acceleration — Global Accelerator’s standout capability versus Front Door and GCP’s more HTTP-centric global tier

Internal/East-West LBs

• Service mesh ingress points fronting microservices entirely within a VPC/VNet
• Multi-tier app architectures — independently scaled web, app, and data tiers
• Compliance-driven network segmentation, keeping traffic off the public internet entirely
• Sitting behind PrivateLink, Private Service Connect, or Private Endpoint as the target

Appliance Insertion (GWLB / Azure Gateway LB)

• Centralized firewall inspection in hub-and-spoke topologies, where all spoke traffic transits a shared inspection VPC/VNet
• Transparent IDS/IPS insertion (Palo Alto, Fortinet, Check Point) without re-architecting routing per network
• Compliance-mandated deep packet inspection for regulated industries
• Multi-tenant MSSP architectures offering security-as-a-service across customer environments

The Bigger Picture

Five categories, three clouds, and roughly a dozen distinct SKUs once you count tiers and modes — and that’s before factoring in retirements like Azure’s Basic LB and Application Gateway v1, both of which disappeared within the past year. The categories are converging conceptually (everyone now has L4, L7, global, internal, and — mostly — appliance-insertion options) even as the underlying implementations and naming remain stubbornly vendor-specific.

The one category without a true equivalent everywhere is appliance insertion. AWS and Azure both built dedicated, GENEVE-based primitives specifically because centralized inline inspection chaining was architecturally painful enough to warrant new infrastructure. GCP’s relative gap here is itself a useful signal: even the hyperscalers are acknowledging that bump-in-the-wire appliance chaining is a tax worth engineering around — which raises the more interesting question of whether transparent insertion is the right long-term answer at all, versus removing the chokepoint from the path entirely.

Written by Paul Carvill

Enterprise → cloud → AI networking. I write the breakdowns I wish I’d had. New field notes roughly twice a month.