Load Balancing & Managed Instance Groups

GCP Fundamentals

Chapter 8 · Load Balancing & Managed Instance Groups

AWS Fundamentals Chapter 8 covered ELB's own ALB/NLB split and Auto Scaling Groups. Azure Fundamentals Chapter 8 went further with a genuinely more specialized four-way load-balancing split, plus the honest warning that "a scale set alone can't protect you against data center failures." GCP's own load-balancing story picks up directly from Chapter 5's own real finding that a VPC network is global — because on GCP, the load balancer itself inherits that same global-by-default character.

Cloud Load Balancing: Global by Default

A Real, Distinctive Architecture

A GCP global load balancer presents a single anycast IP address as the frontend for backend instances in regions around the world — one IP, genuinely spanning multiple regions at once, with automatic cross-region failover built in. This is delivered through Google's own real edge network, Google Front Ends, present in over 80 distinct locations worldwide, and built on real internal Google infrastructure (Maglev, Andromeda, Envoy proxies) rather than instance-based load balancer software.

This is a genuinely different starting point from both siblings. AWS's ALB/NLB are inherently regional constructs — genuine global routing needs a separate service layered on top (Route 53 or CloudFront). Azure's own Load Balancer and Application Gateway are similarly regional, with Front Door as the separate global layer. On GCP, a global external load balancer is already multi-region, with no separate global-routing service required to get there.

Layer 4 vs. Layer 7, and Global vs. Regional

GCP splits load balancers along the same real Layer 4 / Layer 7 line as its siblings — Network Load Balancers (Layer 4, routing on TCP/UDP/other transport-layer data) and Application Load Balancers (Layer 7, routing on HTTP headers and URI paths) — then further splits each by scope: global external, regional external, or classic, with internal variants for private-only traffic.

Type	Layer	Real scope options
Application Load Balancer	7 (HTTP-aware)	Global external, regional external, classic, internal (regional/cross-region)
Network Load Balancer	4 (TCP/UDP)	Proxy (global/regional/classic/internal) or passthrough (global/regional/internal)

Managed Instance Groups (MIGs)

A Managed Instance Group keeps a fleet of identical VMs — built from one shared instance template — running as a single manageable entity, with automatic recreation of failed instances, integration with load balancers, and automated rolling updates.

Zonal MIG — every instance lives in one real zone, supporting up to 1,000 VMs.
Regional MIG — instances spread automatically across multiple zones in one region, supporting up to 2,000 VMs, giving real protection against a single zone's own failure.

The Same Warning Azure's Own Scale Sets Carry

A zonal MIG, by itself, gives no protection at all against a zone going down — every instance in it lives in that one zone. This is the exact same real gap Azure Fundamentals Chapter 8 already flagged for a Virtual Machine Scale Set on its own: high availability against a genuine zone/data-center failure has to be a deliberate choice (a regional MIG here), not an assumption that comes free with autoscaling.

Real Autoscaling Signal Types

CPU utilization — scale based on average CPU across the group.
Load balancing capacity — scale directly on the backend service's own real traffic load.
Cloud Monitoring metrics — scale on any custom metric.
Schedule-based — scale on a predetermined timetable.
Queue-based (zonal MIGs only) — scale based on a workload queue, e.g. Pub/Sub backlog.

Two Real, Distinct Health-Check Mechanisms

GCP names this distinction explicitly, where it's often left implicit elsewhere: a real load-balancing health check exists to redirect traffic away from an instance that's failing, while a real, separate autohealing health check exists to proactively recreate that instance entirely. Same underlying idea as AWS's and Azure's own health-check-driven instance replacement, but GCP names and configures the two purposes as two distinct checks rather than one shared mechanism.

Hands-On Exercises

Exercise 1

A team wants one single IP address to front backend instances deployed across three different GCP regions, with automatic failover between regions if one goes down. Explain, in your own words, whether GCP's global load balancer can do this natively, and how that compares to what AWS's ALB alone would need.

📄 View solution

Exercise 2

A team deploys a zonal Managed Instance Group and assumes it is already protected against a single zone going down, since it autoscales and autoheals. Explain, in your own words, why this assumption is wrong, and what real change would fix it.

📄 View solution

Exercise 3

An instance in a Managed Instance Group is briefly slow to respond to the load balancer's own health check, but its own application-level autohealing check still passes. Explain, in your own words, what real, different action GCP takes as a result of each of these two checks.

📄 View solution

Chapter 8 Quick Reference

Real, major finding: GCP's global load balancer is one anycast IP spanning multiple regions at once, natively — no separate global-routing layer needed, unlike AWS (Route 53/CloudFront) or Azure (Front Door)
Layer 4 (Network LB) vs. Layer 7 (Application LB), each further split by global/regional/classic scope
Zonal MIG (single zone, up to 1,000 VMs) vs. Regional MIG (multi-zone, up to 2,000 VMs, real zone-failure protection)
A zonal MIG alone offers no zone-failure protection — the same real gap Azure's own scale sets carry without explicit multi-zone configuration
Two distinct, explicitly named health checks: load-balancing (redirects traffic) and autohealing (recreates the instance)