Load balancer types comparison in GCP - Commands & Configuration

Introduction

When you have many users trying to access your app, you need a way to share the work across several servers. Load balancers help by spreading the traffic so no single server gets overwhelmed. Google Cloud offers different types of load balancers for different needs.

When you want to share user requests across multiple servers to keep your app fast and reliable.

When you need to balance traffic for a website that uses HTTP or HTTPS protocols.

When you want to distribute traffic inside your private network without exposing it to the internet.

When you want to balance traffic for TCP or UDP applications like games or chat servers.

When you want to route traffic based on the location of your users to reduce delay.

Commands

This command lists all forwarding rules, which show active load balancers and their types in your Google Cloud project.

Terminal

gcloud compute forwarding-rules list

Expected Output

NAME                 REGION       IP_ADDRESS      IP_PROTOCOL  TARGET

example-http-lb       us-central1  34.68.123.45   TCP          target-http-proxy-1

This command lists backend services that are used by load balancers to send traffic to groups of servers.

Terminal

gcloud compute backend-services list

Expected Output

NAME                 PROTOCOL  BACKENDS

example-backend       HTTP      instance-group-1

This command shows how HTTP(S) load balancers route traffic based on URL paths or hostnames.

Terminal

gcloud compute url-maps describe example-url-map

Expected Output

defaultService: https://www.googleapis.com/compute/v1/projects/my-project/global/backendServices/example-backend

hostRules:

- hosts:

  - '*'

  pathMatcher: path-matcher-1

This command lists target pools used by network load balancers to distribute traffic to instances.

Terminal

gcloud compute target-pools list

Expected Output

NAME                 REGION       INSTANCES

example-target-pool   us-central1  instance-1,instance-2

Key Concept

If you remember nothing else, remember: different load balancers in Google Cloud serve different traffic types and use cases like HTTP(S), TCP/UDP, or internal-only traffic.

Common Mistakes

Trying to use an HTTP(S) load balancer for TCP traffic.

HTTP(S) load balancers only handle web traffic and won't work for raw TCP or UDP connections.

Use a TCP/UDP network load balancer for non-web traffic.

Not checking the forwarding rules to see which load balancers are active.

Without checking forwarding rules, you might not know which load balancer is handling your traffic.

Always list forwarding rules to verify load balancer setup.

Summary

Use 'gcloud compute forwarding-rules list' to see active load balancers and their types.

Use 'gcloud compute backend-services list' to check backend groups serving traffic.

Use 'gcloud compute url-maps describe' to understand HTTP(S) routing rules.

Use 'gcloud compute target-pools list' to see instance groups behind network load balancers.

Practice

1. Which GCP load balancer type is best suited for distributing HTTP and HTTPS traffic globally with SSL termination?

easy

A. TCP Proxy Load Balancer

B. Internal Load Balancer

C. Network Load Balancer

D. HTTP(S) Load Balancer

Solution

1. Step 1: Understand the traffic type

   HTTP and HTTPS traffic require Layer 7 (application layer) handling with SSL termination.

2. Step 2: Match load balancer capabilities

   HTTP(S) Load Balancer supports global distribution and SSL termination for web traffic.

3. Final Answer:

   HTTP(S) Load Balancer -> Option D

4. Quick Check:

   HTTP/HTTPS + SSL termination = HTTP(S) Load Balancer [OK]

Hint: Web traffic with SSL? Pick HTTP(S) Load Balancer [OK]

Common Mistakes:

• Confusing TCP Proxy with HTTP(S) for web traffic
• Choosing Network Load Balancer for HTTPS termination
• Using Internal Load Balancer for global traffic

2. Which GCP load balancer type uses a regional forwarding rule and supports TCP and UDP traffic without SSL termination?

easy

A. HTTP(S) Load Balancer

B. Network Load Balancer

C. TCP Proxy Load Balancer

D. Internal Load Balancer

Solution

1. Step 1: Identify the traffic and forwarding rule type

   TCP and UDP traffic with regional forwarding rules indicates a Layer 4 load balancer.

2. Step 2: Match with GCP load balancer types

   Network Load Balancer supports TCP/UDP traffic regionally without SSL termination.

3. Final Answer:

   Network Load Balancer -> Option B

4. Quick Check:

   TCP/UDP + regional + no SSL = Network Load Balancer [OK]

Hint: TCP/UDP regional traffic? Use Network Load Balancer [OK]

Common Mistakes:

• Choosing HTTP(S) Load Balancer for UDP traffic
• Confusing TCP Proxy with Network Load Balancer
• Selecting Internal Load Balancer for external traffic

3. Given this scenario: You want to load balance TCP traffic globally with SSL offloading. Which GCP load balancer type will you use?

client -> GCP LB -> backend instances (TCP with SSL offloading)

medium

A. TCP Proxy Load Balancer

B. Internal Load Balancer

C. Network Load Balancer

D. HTTP(S) Load Balancer

Solution

1. Step 1: Analyze traffic and SSL offloading need

   TCP traffic with SSL offloading requires Layer 4 proxy with SSL termination.

2. Step 2: Match with GCP load balancer types

   TCP Proxy Load Balancer supports global TCP traffic with SSL offloading.

3. Final Answer:

   TCP Proxy Load Balancer -> Option A

4. Quick Check:

   Global TCP + SSL offloading = TCP Proxy Load Balancer [OK]

Hint: Global TCP + SSL offload? Use TCP Proxy Load Balancer [OK]

Common Mistakes:

• Choosing Network Load Balancer which lacks SSL offloading
• Selecting HTTP(S) Load Balancer for TCP traffic
• Using Internal Load Balancer for external traffic

4. You configured an Internal Load Balancer but your clients outside the VPC cannot access the service. What is the most likely cause?

medium

A. Internal Load Balancer only supports traffic inside the VPC

B. You forgot to enable global forwarding rules

C. Internal Load Balancer does not support TCP traffic

D. You need to use HTTP(S) Load Balancer for internal traffic

Solution

1. Step 1: Understand Internal Load Balancer scope

   Internal Load Balancer is designed for traffic inside a VPC or connected networks only.

2. Step 2: Identify access limitation

   Clients outside the VPC cannot reach Internal Load Balancer because it does not expose external IPs.

3. Final Answer:

   Internal Load Balancer only supports traffic inside the VPC -> Option A

4. Quick Check:

   Internal LB = VPC-only traffic [OK]

Hint: Internal LB is VPC-only; external clients can't connect [OK]

Common Mistakes:

• Assuming Internal LB supports global forwarding
• Thinking Internal LB supports external TCP traffic
• Confusing Internal LB with HTTP(S) Load Balancer

5. You have a multi-region web app serving HTTP and HTTPS traffic with backend services in multiple zones. You want to minimize latency and provide automatic failover. Which GCP load balancer type should you choose and why?

hard

A. Network Load Balancer because it supports UDP and TCP globally

B. Internal Load Balancer because it routes traffic inside the VPC

C. HTTP(S) Load Balancer because it offers global load balancing with SSL termination and health checks

D. TCP Proxy Load Balancer because it handles TCP traffic with SSL offloading

Solution

1. Step 1: Analyze requirements for multi-region HTTP/HTTPS app

   Needs global load balancing, SSL termination, low latency, and failover.

2. Step 2: Match load balancer features

   HTTP(S) Load Balancer supports global distribution, SSL termination, health checks, and automatic failover.

3. Step 3: Exclude other options

   Network Load Balancer is regional and lacks SSL termination; Internal Load Balancer is internal-only; TCP Proxy is for TCP, not HTTP/HTTPS.

4. Final Answer:

   HTTP(S) Load Balancer because it offers global load balancing with SSL termination and health checks -> Option C

5. Quick Check:

   Multi-region HTTP/HTTPS + failover = HTTP(S) Load Balancer [OK]

Hint: Global web app? Pick HTTP(S) Load Balancer for SSL and failover [OK]

Common Mistakes:

• Choosing Network Load Balancer for HTTP/HTTPS global traffic
• Using Internal Load Balancer for external multi-region access
• Selecting TCP Proxy Load Balancer for HTTP traffic