Cloud Load Balancing Study Notes
Cloud Load Balancing distributes traffic across backend instances, containers, or network endpoint groups while presenting a single entry point to clients. Google Cloud offers a family of global and regional, external and internal load balancers, and the ACE exam tests whether you can pick the correct type from protocol, scope, and client location clues.
Key facts
- Application Load Balancers operate at Layer 7 for HTTP and HTTPS traffic and support host and path-based routing, header-based decisions, and integration with Cloud CDN and Cloud Armor.
- The global external Application Load Balancer uses a single anycast IP address worldwide and routes users to the nearest healthy backend, simplifying DNS and improving latency.
- Network Load Balancers operate at Layer 4 for TCP and UDP traffic, preserving client IP information in many configurations and handling protocols that are not HTTP-based.
- Internal load balancers expose a private RFC 1918 IP address inside a VPC, distributing traffic between tiers such as web front ends and application servers without internet exposure.
- All load balancer types rely on health checks; only backends passing their configured HTTP, HTTPS, TCP, or SSL health check receive new traffic from the forwarding rule.
- Backend services define capacity, balancing mode such as utilisation or rate, session affinity, timeouts, and the instance groups or network endpoint groups that receive traffic.
- Managed instance groups pair naturally with load balancers because autoscaling and autohealing keep the backend pool sized and healthy without manual instance replacement.
- SSL policies control the minimum TLS version and cipher profile for HTTPS load balancers, and Google-managed certificates remove the need to manually renew public certificates.
- At the time of writing, some load balancer variants are global and others regional by default, so you must check scope carefully rather than assuming every Google load balancer is global.
What the exam expects you to know
- Match protocol to layer: HTTP or HTTPS and content-based routing means Layer 7 Application Load Balancer; raw TCP or UDP means Network Load Balancer.
- Match audience to exposure: internet clients need an external load balancer, while tier-to-tier traffic inside a VPC needs an internal load balancer.
- Choose global load balancing when users are worldwide and a single IP address is desired; choose regional when backends and clients are confined to one region.
- Recognise health check misconfiguration as the common cause of 502 errors or backends receiving no traffic despite instances running normally.
- Know that Cloud Armor and Cloud CDN attach to the Application Load Balancer backend service, not directly to individual VM instances.
- Identify URL maps as the Application Load Balancer component that implements host and path rules sending different URLs to different backend services.
Cloud Load Balancing vs DNS Round Robin: when to use which
Use Cloud Load Balancing instead of DNS round robin whenever you need health-aware routing, instant removal of failed backends, session control, or a single stable IP address. DNS round robin distributes names but clients cache records, failed backends keep receiving attempts until TTLs expire, and there is no protocol-aware routing. A global Application Load Balancer solves all of those problems with anycast routing and continuous health checks. For the exam, any mention of unhealthy instances still receiving traffic, global users, or HTTPS termination points firmly to a managed load balancer, not DNS tricks. See also the DNS Round Robin notes.
Useful gcloud commands
gcloud compute health-checks create http my-health-check --port=80
gcloud compute backend-services create my-backend --protocol=HTTP --health-checks=my-health-check --global
gcloud compute url-maps create my-url-map --default-service=my-backend
gcloud compute forwarding-rules listCommon exam traps
- Trap: Selecting a Network Load Balancer for path-based routing. Layer 4 balancers do not inspect HTTP paths or headers; only Application Load Balancers make content-based decisions.
- Trap: Forgetting health checks need an allow firewall rule. If the health check probe ranges are blocked, healthy VMs are marked unhealthy and the balancer returns errors.
- Trap: Assuming an internal load balancer can serve internet clients. Internal balancers have only private addresses and are reachable from within the VPC or connected networks.
- Trap: Confusing forwarding rule, target proxy, URL map, and backend service roles on the Application Load Balancer; each component has a distinct job in the traffic path.
Frequently asked questions
When should I choose an Application Load Balancer over a Network Load Balancer?
Choose an Application Load Balancer when traffic is HTTP or HTTPS and you need features such as host and path-based routing, SSL termination, Cloud CDN, or Cloud Armor integration. Choose a Network Load Balancer for non-HTTP TCP or UDP protocols, for preserving client behaviour at Layer 4, or when the application protocol is not understood by a Layer 7 proxy.
Why does my load balancer return 502 errors when VMs are running?
The most common cause is failing health checks. If the health check protocol, port, or path does not match what the application actually serves, or a firewall rule blocks Google's health check probe ranges, backends are marked unhealthy and the load balancer has nowhere healthy to send traffic. Verify the health check configuration and firewall rules before suspecting the instances.
What is an internal load balancer used for?
An internal load balancer distributes traffic over a private IP address inside your VPC, typically between application tiers that should never be exposed to the internet. For example, web servers can call a pool of application servers through one stable internal address with health checking and failover, gaining load balancing benefits while keeping the backend tier completely private.
Study aid disclaimer: Cloud Cert Notes is an independent educational study aid. It is not affiliated with, endorsed by, or sponsored by Google, Microsoft, Amazon, Oracle, or Alibaba. Google Cloud, Associate Cloud Engineer, and Cloud Digital Leader are trademarks of Google LLC; all other certification names and product names are trademarks of their respective owners. Always confirm service details against the official provider documentation before sitting an exam.