Google Cloud Load Balancing Cheat Sheet

Last updated on March 17, 2026

Google Cloud Load Balancing Cheat Sheet

Google Cloud Load Balancing allows you to put your resources behind a single IP address.

Features

Can be set to be available externally or internally with your Virtual Private Network (VPC).
HTTP(S) load balancing can balance HTTP and HTTPS traffic across multiple backend instances, across multiple regions.
Enable Cloud CDN for HTTP(S) load balancing to optimize application delivery for your users with a single checkbox.
You can define the autoscaling policy and the autoscaler performs automatic scaling based on the measured load. No pre-warming required — go from zero to full throttle in seconds.
Manage SSL certificates and decryption.
Single anycast IP address: One IP serves as frontend for backend instances across all regions worldwide. Provides cross-region load balancing and automatic multi-region failover.
Software-defined load balancing: Fully distributed, managed service. Not instance-based or device-based, avoiding physical infrastructure lock-in.
Layer 4 and Layer 7 load balancing: Direct traffic based on network/transport protocols (TCP, UDP, ESP, GRE, ICMP) or application layer attributes (HTTP headers, URIs).
Global and regional deployment: Global load balancers support backends in multiple regions; regional support backends in a single region.
Premium and Standard Network Tiers: Premium Tier uses Google’s global backbone; Standard Tier uses public internet. Choose based on cost vs performance priorities.

Advanced feature support: IPv6 load balancing, source IP-based traffic steering, weighted load balancing, WebSockets, user-defined request headers, protocol forwarding for private VIPs.
Integrations:
- Cloud CDN: Supported with global external Application Load Balancer and classic Application Load Balancer.
- Cloud Armor: DDoS protection for global external Application Load Balancer, classic Application Load Balancer, external proxy Network Load Balancer, and external passthrough Network Load Balancer. Advanced network DDoS protection available for external passthrough Network Load Balancers.

Types of Google Cloud Load Balancers

External Load Balancer
- External HTTP(s)
  - Supports HTTP/HTTP(s) traffic
  - Distributes traffic for the following backend types:
    - Instance groups
    - Zonal network endpoint groups (NEGs)
    - Serverless NEGs: One or more App Engine, Cloud Run, or Cloud Functions services
    - Internet NEGs, for endpoints that are outside of Google Cloud (also known as custom origins)
    - Buckets in Cloud Storage
  - Scope is global
  - Destination ports
    - HTTP on 80 or 8080
    - HTTPS on 443
  - On each backend service, you can optionally enable Cloud CDN and Google Cloud Armor.
  - Global external: HTTP/HTTPS, backends in multiple regions. Built on Envoy-based Google Front End (GFE).
  - Regional external: HTTP/HTTPS, backends in single region. Built on Envoy.
  - Classic: HTTP/HTTPS. Global in Premium Tier, regional in Standard Tier. Built on GFE.
- External Network TCP/UDP
  - A network load balancer that distributes TCP or UDP traffic among virtual machines in the same region.
  - Regional in scope
  - Can receive traffic from:
    - Any client on the Internet
    - Google Cloud VMs with external IP
    - Google Cloud VMs that have Internet access through Cloud NAT or instance-based NAT
  - Network load balancers are not proxies.
    - Load-balanced packets are received by backend VMs with their source IP unchanged.
    - Load-balanced connections are terminated by the backend VMs.
    - Responses from the backend VMs go directly to the clients, not back through the load balancer. The industry term for this is direct server return.
  - Passthrough Network Load Balancer preserves client source IP and uses direct server return (DSR). Built on Maglev.
  - Supports additional protocols: ESP, GRE, ICMP, ICMPv6.
- SSL Proxy Load Balancer
  - Supports TCP with SSL offload traffic.
  - It is intended for non-HTTP(S) traffic.
  - Scope is global.
  - By using SSL Proxy Load Balancing, SSL connections are terminated at the load balancing layer, and then proxied to the closest available backend.
  - Destination ports
    - 5, 43, 110, 143, 195, 443, 465, 587, 700, 993, 995, 1883, 3389, 5222, 5432, 5671, 5672, 5900, 5901, 6379, 8085, 8099, 9092, 9200, and 9300
- TCP Proxy
  - Traffic coming over a TCP connection is terminated at the load balancing layer, and then proxied to the closest available backend.
  - Destination Ports
    - 25, 43, 110, 143, 195, 443, 465, 587, 700, 993, 995, 1883, 3389, 5222, 5432, 5671, 5672, 5900, 5901, 6379, 8085, 8099, 9092, 9200, and 9300.
  - Can be configured as a global service where you can deploy your backends in multiple regions and it automatically directs traffic to the region closest to the user.
Internal Load Balancer
- Internal HTTP(s)
  - A proxy-based, regional Layer 7 load balancer that enables you to run and scale your services behind an internal IP address.
  - Supports HTTP/HTTP(s) traffic.
  - Distributes traffic to backends hosted on Google Compute Engine (GCE) and Google Kubernetes Engine (GKE).
  - Scope is regional.
  - Load Balancer destination ports
    - HTTP on 80 or 8080
    - HTTPS on 443
  - Cross-region internal: HTTP/HTTPS, backends in multiple regions, globally accessible. Built on Envoy.
- Internal TCP or UDP
  - A regional load balancer that allows you to run and scale your services behind an internal load balancing IP address that is accessible only to your internal virtual machine instances.
  - Distributes traffic among virtual machine instances in the same region in a Virtual Private cloud network by using an internal IP address.
  - Does not support:
    - Backend virtual machines in multiple regions
    - Balancing traffic that originates from the Internet
  - Internal passthrough: TCP, UDP, ICMP, ICMPv6, SCTP, ESP, AH, GRE. Built on Andromeda. Preserves client source IP.

Underlying Technologies

Google Front Ends (GFEs): Software-defined, distributed systems located in Google points of presence (PoPs). Perform global load balancing.
Andromeda: Google Cloud’s software-defined network virtualization stack.
Maglev: Distributed system for network load balancing.
Envoy: Open source edge and service proxy for cloud-native applications.

Network Service Tiers

Premium Tier: Uses Google’s high-quality global backbone. Higher performance, higher cost.
Standard Tier: Uses public internet. Lower cost, reliable connectivity.
Some load balancers available only in Premium Tier.

Validate Your Knowledge

Question 1

You deploy a web application running on a Cloud Engine instance in the asia-northeast1-a zone. You want to eliminate the risk of possible downtime due to the failure of a single Compute Engine zone while minimizing costs.

What should you do?

Deploy another instance in asia-northeast1-b. Balance the load in asia-northeast1-a, and asia-northeast1-b using an Internal Load Balancer (ILB).
Deploy multiple instances on asia-northeast1-a, asia-northeast1-b, and asia-northeast1-c. Balance the load across all zones using an Internal Load Balancer (ILB).
Create an instance template and deploy a managed instance group in a single zone. Configure a health check to monitor the instances.
Create a snapshot schedule for your instance. Set up a Cloud Monitoring Alert to monitor the instance. Restore the instance using the snapshot when the instance goes down.

Show me the answer!

Correct Answer: 1

You can host your Compute Engine resources in different geographical locations called regions. A region is composed of three or more zones. Zones are isolated locations within a region. Compute resources like VMs and persistent disks are hosted on these regions.

Google recommends deploying applications in multiple regions and zones to protect them from unforeseen component failures or even sudden zonal and regional outages. This makes your application fault-tolerant and highly available.

Hence, the correct answer is: Deploy another instance in asia-northeast1-b. Balance the load in asia-northeast1-a and asia-northeast1-b using an Internal Load Balancer (ILB).

The option that says: Create an instance template and deploy a managed instance group in a single zone. Configure a health check to monitor the instances is incorrect because this doesn’t make the application withstand a zonal outage. When the single zone is selected as the location of the managed instance group, it only spawns instances on a single zone.

The option that says: Deploy multiple instances on asia-northeast1-a, asia-northeast1-b and asia-northeast1-c. Balance the load across all zones using an Internal Load Balancer (ILB) is incorrect because having the application deployed on all zones (asia-northeast1-a, asia-northeast1-b, and asia-northeast1-c) will incur more cost. Deploying the application on two zones is more cost-effective and will already satisfy the given requirements.

The option that says: Create a snapshot schedule for your instance. Set up a Cloud Monitoring Alert to monitor the instance. Restore the instance using the snapshot when the instance goes down is incorrect because this solution can’t protect the application from zonal failure. This only gives you an application backup that requires a lot of time to restore.

Reference:
https://cloud.google.com/compute/docs/load-balancing-and-autoscaling
https://cloud.google.com/compute/docs/regions-zones

Note: This question was extracted from our Google Certified Associate Cloud Engineer Practice Exams.

Question 2

Your team maintains an application that receives SSL/TLS-encrypted traffic on port 443. Your customers from various parts of the globe report latency issues when accessing your application.

What should you do?

Use an External HTTP(S) Load Balancer in front of your application.

Use an SSL Proxy Load Balancer in front of your application.
Use a TCP Proxy in front of your application.
Use an Internal HTTP(S) Load Balancer in front of your application.

Show me the answer!

Correct Answer: 2

A load balancer distributes user traffic across multiple instances of your applications. By spreading the load, load balancing reduces the risk that your applications experience performance issues.

The external HTTP(S) load balancer and SSL proxy load balancer terminate Transport Layer Security (TLS) in locations that are distributed globally, so as to minimize latency between clients and the load balancer. If you require geographic control over where TLS is terminated, you should use Network Load Balancing instead, and terminate TLS on backends that are located in regions appropriate to your needs.

It is stated in the scenario that your application must handle SSL/TLS-encrypted traffic on port 443 from your global customers.

Hence, the correct answer is: Use an SSL Proxy Load Balancer in front of your application.

The option that says: Use an External HTTP(S) Load Balancer in front of your application is incorrect because this type of load balancer only handles HTTP and HTTPS traffic. It is not capable of offloading SSL/TLS-encrypted traffic.

The option that says: Use a TCP Proxy in front of your application is incorrect. Although it handles TCP traffic, it is not designed to offload SSL connections.

The option that says: Use an Internal HTTP(S) Load Balancer in front of your application is incorrect because an internal load balancer doesn’t expose your application on the public Internet. In addition, Internal HTTP(S) Load Balancers only handles HTTP and HTTPS traffic.

References:
https://cloud.google.com/load-balancing/docs/choosing-load-balancer
https://cloud.google.com/load-balancing

Note: This question was extracted from our Google Certified Associate Cloud Engineer Practice Exams.

For more Google Cloud practice exam questions with detailed explanations, check out the Tutorials Dojo Portal: