Google Cloud Load Balancing Types

Internal HTTP(S) Load Balancing

• is a proxy-based, regional Layer 7 load balancer that enables running and scaling services behind an internal IP address.
• distributes HTTP and HTTPS traffic to backends hosted on Compute Engine and GKE
• is accessible only in the chosen region of the Virtual Private Cloud (VPC) network on an internal IP address.
• enables rich traffic control capabilities based on HTTP(S) parameters.
• is a managed service based on the open source Envoy proxy.
• needs one proxy-only subnet in each region of a VPC network where internal HTTP(S) load balancers is used. All the internal HTTP(S) load balancers in a region and VPC network share the same proxy-only subnet because all internal HTTP(S) load balancers in the region and VPC network share a pool of Envoy proxies.
• supports path based routing
• preserves the Host header of the original client request and also appends two IP addresses (Client and LB )to the X-Forwarded-For header
• supports a regional backend service, which distributes requests to healthy backends (either instance groups containing Compute Engine VMs or NEGs containing GKE containers).
• supports a regional health check that periodically monitors the readiness of the backends. This reduces the risk that requests might be sent to backends that can’t service the request.
• if a backend becomes unhealthy, traffic is automatically redirected to healthy backends within the same region.
• has native support for the WebSocket protocol when using HTTP or HTTPS as the protocol to the backend
• accepts only TLS 1.0, 1.1, 1.2, and 1.3 when terminating client SSL requests.
• isn’t compatible with the following features:
  • Cloud CDN
  • Google Cloud Armor
  • Cloud Storage buckets
  • Google-managed SSL certificates
  • SSL policies

External HTTP(S) Load Balancing

• is a global, proxy-based Layer 7 load balancer that enables running and scaling the services worldwide behind a single external IP address.
• distributes HTTP and HTTPS traffic to backends hosted on Compute Engine and GKE
• is implemented on Google Front Ends (GFEs). GFEs are distributed globally and operate together using Google’s global network and control plane.
  • In the Premium Tier, GFEs offer global load balancing
  • With Standard Tier, the load balancing is handled regionally.
• provides cross-regional or location-based load balancing, directing traffic to the closest healthy backend that has the capacity and terminating HTTP(S) traffic as close as possible to your users.
• supports content-based load balancing using URL maps to select a backend service based on the requested host name, request path, or both.
• supports 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
• preserves the Host header of the original client request and also appends two IP addresses (Client and LB )to the X-Forwarded-For header
• supports Cloud Load Balancing Autoscaler, which allows users to perform autoscaling on the instance groups in a backend service.
• supports connection draining on backend services to ensure minimal interruption to the users when an instance that is serving traffic is terminated, removed manually, or removed by an autoscaler.
• supports Session affinity as a best-effort attempt to send requests from a particular client to the same backend for as long as the backend is healthy and has the capacity, according to the configured balancing mode. It offers three types of session affinity:
  • NONE. Session affinity is not set for the load balancer.
  • Client IP affinity sends requests from the same client IP address to the same backend.
  • Generated cookie affinity sets a client cookie when the first request is made, and then sends requests with that cookie to the same backend.
• if a backend becomes unhealthy, traffic is automatically redirected to healthy backends within the same region.
• has native support for the WebSocket protocol when using HTTP or HTTPS as the protocol to the backend
• accepts only TLS 1.0, 1.1, 1.2, and 1.3 when terminating client SSL requests.
• does not support client certificate-based authentication, also known as mutual TLS authentication.

Internal TCP/UDP Load Balancing

• is a managed, internal, pass-through, regional Layer 4 load balancer that enables running and scaling services behind an internal IP address.
• distributes traffic among VM instances in the same region in a VPC network by using an internal IP address.
• provides a high-performance, pass-through Layer 4 load balancer for TCP or UDP traffic.
• routes original connections directly from clients to the healthy backends, without any interruption.
• Responses from the healthy backend VMs go directly to the clients, not back through the load balancer. TCP responses use direct server return.
• does not terminate SSL traffic and SSL traffic can be terminated by the backends instead of by the load balancer
• Unlike proxy load balancer, it doesn’t terminate connections from clients and then opens new connections to backends.
• provides access through VPC Network Peering, Cloud VPN or Cloud Interconnect
• supports Session affinity as a best-effort attempt for TCP traffic to send requests from a particular client to the same backend for as long as the backend is healthy and has the capacity, according to the configured balancing mode. It offers three types of session affinity:
  • None : default setting, effectively same as Client IP, protocol, and port.
  • Client IP : Directs a particular client’s requests to the same backend VM based on a hash created from the client’s IP address and the destination IP address.
  • Client IP and protocol : Directs a particular client’s requests to the same backend VM based on a hash created from three pieces of information: the client’s IP address, the destination IP address, and the load balancer’s protocol (TCP or UDP).
  • Client IP, protocol, and port : Directs a particular client’s requests to the same backend VM based on a hash created from these five pieces of information:
    • Source IP address of the client sending the request
    • Source port of the client sending the request
    • Destination IP address
    • Destination port
    • Protocol (TCP or UDP)
• UDP protocol doesn’t support sessions, session affinity doesn’t affect UDP traffic.
• supports health check that periodically monitors the readiness of the backends. If a backend becomes unhealthy, traffic is automatically redirected to healthy backends within the same region.
• supports HTTP(S), HTTP2, TCP, and SSL as health check protocols; the protocol of the health check does not have to match the protocol of the load balancer:
• does not offer a health check that uses the UDP protocol, but can be done using TCP-based health checks
• does not support Network endpoint groups (NEGs) as backends
• support some backends to be configured as failover backends. These backends are only used when the number of healthy VMs in the primary backend instance groups has fallen below a configurable threshold.

External TCP/UDP Network Load Balancing

• is a managed, external, pass-through, regional Layer 4 load balancer that distributes TCP or UDP traffic originating from the internet to among virtual machine (VM) instances in the same region
• are not proxies, but pass-through
  • 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.
  • TCP responses use direct server return.
• scope of a network load balancer is regional, not global. A network load balancer cannot span multiple regions. Within a single region, the load balancer services all zones.
• distributes connections among backend VMs contained within managed or unmanaged instance groups.
• supports regional health check that periodically monitors the readiness of the backends. If a backend becomes unhealthy, traffic is automatically redirected to healthy backends within the same region.
• supports HTTP(S), HTTP2, TCP, and SSL as health check protocols; the protocol of the health check does not have to match the protocol of the load balancer:
• does not offer a health check that uses the UDP protocol, but can be done using TCP-based health checks
• supports connection tracking table and a configurable consistent hashing algorithm to determine how traffic is distributed to backend VMs.
• supports Session affinity as a best-effort attempt for TCP traffic to send requests from a particular client to the same backend for as long as the backend is healthy and has the capacity, according to the configured balancing mode. It offers three types of session affinity:
  • None : default setting, effectively same as Client IP, protocol, and port.
  • Client IP : Directs a particular client’s requests to the same backend VM based on a hash created from the client’s IP address and the destination IP address.
  • Client IP and protocol : Directs a particular client’s requests to the same backend VM based on a hash created from three pieces of information: the client’s IP address, the destination IP address, and the load balancer’s protocol (TCP or UDP).
  • Client IP, protocol, and port : Directs a particular client’s requests to the same backend VM based on a hash created from these five pieces of information:
    • Source IP address of the client sending the request
    • Source port of the client sending the request
    • Destination IP address
    • Destination port
    • Protocol (TCP or UDP)
• UDP protocol doesn’t support sessions, session affinity doesn’t affect UDP traffic.
• supports connection draining which allows established TCP connections to persist until the VM no longer exists. If connection draining is disabled, established TCP connections are terminated as quickly as possible.
• supports only self-managed SSL certificates
• does not support Network endpoint groups (NEGs) as backends

External SSL Proxy Load Balancing

• is a reverse proxy, layer 4, an external load balancer that distributes SSL traffic coming from the internet to VM instances in the VPC network.
• with SSL traffic, supports SSL offload where user SSL (TLS) connections are terminated at the load balancing layer, and then proxied to the closest available backend instances by using either SSL (recommended) or TCP.
• supports global load balancing service with the Premium Tier
• supports regional load balancing service with the Standard Tier
• is intended for non-HTTP(S) traffic. For HTTP(S) traffic, GCP recommends using HTTP(S) Load Balancing.
• supports proxy protocol header to preserve the original source IP addresses of incoming connections to the load balancer
• performs traffic distribution based on the balancing mode and the hashing method selected to choose a backend (session affinity).
• supports two types of balancing mode :
  • CONNECTION : the load is spread based on how many concurrent connections the backend can handle.
  • UTILIZATION: the load is spread based on the utilization of instances in an instance group.
• supports Session Affinity and offers client IP affinity, which forwards all requests from the same client IP address to the same backend.
• supports a single backend service resource. Changes to the backend service are not instantaneous and would take several minutes for changes to propagate to Google Front Ends (GFEs).
• do not support client certificate-based authentication, also known as mutual TLS authentication.

External TCP Proxy Load Balancing

• is a reverse proxy, external, layer 4 load balancer that distributes TCP traffic coming from the internet to VM instances in the VPC network
• terminates traffic coming over a TCP connection at the load balancing layer, and then forwards to the closest available backend using TCP or SSL
• use a single IP address for all users worldwide and automatically routes traffic to the backends that are closest to the user
• supports global load balancing service with the Premium Tier
• supports regional load balancing service with the Standard Tier
• performs traffic distribution based on the balancing mode and the hashing method selected to choose a backend (session affinity).
• supports proxy protocol header to preserve the original source IP addresses of incoming connections to the load balancer
• supports two types of balancing mode
  • CONNECTION : the load is spread based on how many concurrent connections the backend can handle.
  • UTILIZATION: the load is spread based on the utilization of instances in an instance group.
• supports Session Affinity and offers client IP affinity, which forwards all requests from the same client IP address to the same backend.

GCP Cloud Load Balancing Decision Tree

GCP Certification Exam Practice Questions

• Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
• GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
• GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
• Open to further feedback, discussion and correction.

1. Your development team has asked you to set up an external TCP load balancer with SSL offload. Which load balancer should you use?
   1. SSL proxy
   2. HTTP load balancer
   3. TCP proxy
   4. HTTPS load balancer
2. You have an instance group that you want to load balance. You want the load balancer to terminate the client SSL session. The instance group is used to serve a public web application over HTTPS. You want to follow Google-recommended practices. What should you do?
   1. Configure a HTTP(S) load balancer.
   2. Configure an internal TCP load balancer.
   3. Configure an external SSL proxy load balancer.
   4. Configure an external TCP proxy load balancer.
3. Your development team has asked you to set up load balancer with SSL termination. The website would be using HTTPS protocol. Which load balancer should you use?
   1. SSL proxy
   2. HTTP load balancer
   3. TCP proxy
   4. HTTPS load balancer
4. You have an application that receives SSL-encrypted TCP traffic on port 443. Clients for this application are located all over the world. You want to minimize latency for the clients. Which load balancing option should you use?
   1. HTTPS Load Balancer
   2. Network Load Balancer
   3. SSL Proxy Load Balancer
   4. Internal TCP/UDP Load Balancer. Add a firewall rule allowing ingress traffic from 0.0.0.0/0 on the target instances.