Professional Cloud Network Engineer
Choosing the right load balancer in Google Cloud starts with understanding your traffic type and architectural needs. Application Load Balancers handle HTTP(S) traffic at Layer 7, offering content-aware routing. Network Load Balancers handle TCP, UDP, and other IP protocols at Layer 4, and come in proxy and passthrough subtypes. You must then decide between external load balancers for internet traffic and internal load balancers for traffic within your Virtual Private Cloud (VPC) or connected private networks. The scope is another key choice: global load balancers distribute traffic across multiple regions using a single anycast IP, while regional load balancers operate within a single region. Finally, proxy load balancers terminate client connections and open new ones to backends, while passthrough load balancers forward packets unchanged, preserving the original client source IP.
External load balancers distribute traffic that originates from the internet into your Google Cloud VPC. They use external IP addresses reachable from anywhere and form the public entry point for user-facing applications.
Internal load balancers distribute traffic exclusively from clients already inside your VPC or from networks connected via VPC Network Peering, Cloud VPN, or Cloud Interconnect. They use internal IP addresses and are essential for keeping intermediate application tiers and databases isolated from the public internet, such as in a three-tier web architecture.
Global load balancers deploy frontend infrastructure across Google's worldwide points of presence. Client traffic enters Google's network at the nearest edge, which terminates Transport Layer Security (TLS) close to the user for low latency. They can automatically route requests to the closest healthy backend and fail over to another region if needed. Global external Application Load Balancers and proxy Network Load Balancers require the Premium Tier of Network Service Tiers.
Regional load balancers operate within a single Google Cloud region. All traffic and TLS connections terminate strictly inside that region. Choose a regional load balancer when compliance mandates traffic stay within a geographic area, when you need only IPv4 termination, or when you require precise control over where TLS termination occurs.
Proxy load balancers, including all Application Load Balancers and proxy Network Load Balancers, terminate the client connection at the load balancer and establish a new connection to the backend. This changes the source IP address seen by the backend but enables features like SSL offloading and advanced traffic management.
Passthrough load balancers do not terminate connections. They forward packets directly to backend VMs with the original source and destination IPs, ports, and protocols unchanged, a method known as direct server return (DSR). Responses go directly back to the client. Choose passthrough when you must preserve the client source IP or need to load balance protocols like UDP, ESP, or ICMP.
Traffic steering directs traffic based on HTTP parameters like request headers or query parameters, for example, routing mobile user traffic to a specific backend. Traffic splitting distributes a percentage of traffic across multiple backend services for gradual canary deployments. Request mirroring copies incoming traffic to a secondary backend for testing or logging without affecting the client's response.
A backend service defines how traffic is distributed to backends like Managed Instance Groups (MIGs) or Network Endpoint Groups (NEGs). It includes settings for health checks, which verify backend readiness, and session affinity, which attempts to send a client's requests to the same backend. Failover configuration designates backup backends to use when primary backends become unhealthy.
Google Cloud offers Premium Tier and Standard Tier network service tiers. Premium Tier routes traffic through Google's global backbone for high performance and is required for global external Application Load Balancers. Standard Tier offloads traffic to the public internet closer to the destination region, which is less expensive but may have higher latency.
Cloud CDN integrates with global external Application Load Balancers to cache content at Google's edge locations. Google Cloud Armor provides DDoS protection and web application firewall capabilities for load balancers. Service Extensions allow you to insert custom logic into the load balancing data path for supported Application Load Balancers.
Backend services use Managed Instance Groups (MIGs) and Network Endpoint Groups (NEGs) to distribute traffic. A MIG is a group of identical Virtual Machine instances managed by Google Cloud. A NEG is a more flexible logical grouping of IP:port endpoints, which can represent individual containers in Google Kubernetes Engine (GKE), serverless functions, or external systems.
A backend service attaches MIGs or NEGs and defines the balancing mode for traffic distribution. Modes include rate (requests per second), utilization (backend CPU usage), and connection (concurrent connections). Health checks continuously probe backends, and the load balancer only sends traffic to healthy endpoints.
Autoscaling policies for MIGs determine when to add or remove instances based on demand. Triggers can be based on CPU utilization, load balancing serving capacity, or custom metrics from Cloud Monitoring. Scaling is fine-tuned with cool-down periods to prevent rapid flapping and scale-in controls to manage how aggressively capacity is reduced.
Hybrid connectivity NEGs (type NON_GCP_PRIVATE_IP_PORT) allow load balancers to direct traffic to endpoints outside Google Cloud, such as on-premises data centers, reachable via Cloud VPN or Cloud Interconnect. This requires configuring firewall rules to allow health check probes from Google's IP ranges.
Zonal NEGs group endpoints within a single zone. The GCE_VM_IP_PORT type is used for container-native load balancing in GKE, sending traffic directly to Pod IPs. The GCE_VM_IP type is used exclusively with internal and external passthrough Network Load Balancers, supporting load balancing to non-primary network interfaces.
Connection draining prevents dropped sessions during updates or autoscaling. When a backend instance is being terminated, the load balancer places it in a draining state, allowing in-flight requests to complete while immediately stopping new traffic from being sent to it.
A URL map is the routing configuration for an Application Load Balancer. It uses host rules to match domain names and path matchers to examine URL paths, directing requests to the appropriate backend service. URL maps support advanced routing based on HTTP headers and query parameters, traffic splitting for canary deployments, and traffic actions like URL rewrites and redirects.
Health checks probe backends to determine their operational state. For probes to succeed, you must create a VPC firewall rule allowing ingress from Google's health check IP ranges (e.g., 35.191.0.0/16). Global access is a feature for internal load balancers. When enabled on a forwarding rule, clients from any region within the same VPC can connect to a regionally hosted service, simplifying multi-region access.
The balancing mode (RATE, UTILIZATION, CONNECTION) defines how the load balancer measures a backend's capacity. A capacity scaler is a multiplier that can be set to 0 to immediately drain a backend for maintenance. Session affinity (Client IP, Generated Cookie, HTTP Cookie) attempts to send a client's requests to the same backend. Connection draining gracefully removes a backend from service by allowing existing connections to complete.
In Google Kubernetes Engine (GKE), load balancing integrates closely with containerized workloads. The GKE Ingress controller automates the creation of a Google Cloud Application Load Balancer to expose HTTP(S) services. For more advanced and standardized API gateway features, the GKE Gateway controller implements the Kubernetes Gateway API. Both controllers often use zonal NEGs (type GCE_VM_IP_PORT) to enable container-native load balancing, where traffic is sent directly to individual Pod IP addresses rather than routing through node-level proxies, reducing latency and providing Pod-level metrics.
Application Load Balancers provide powerful traffic management features configured primarily through URL maps. Traffic splitting directs a configured percentage of traffic (e.g., 5%) to a different backend service, enabling safe canary deployments. Traffic mirroring sends a copy of each request to a separate backend for analysis without impacting the live response. URL rewrites modify the hostname or path of a request before it reaches the backend, allowing you to present clean public URLs that map to internal application structures.
Proxy load balancers terminate the client connection at the load balancer and create a new connection to the backend, changing the source IP address seen by the backend. Passthrough load balancers forward packets unchanged to backends, preserving the original client source IP, and responses go directly back to the client without passing through the load balancer.
Choose a regional load balancer when compliance requirements mandate that all traffic remain within a specific geographic region, when you only need IPv4 termination, or when you require precise control over where TLS termination occurs. Also use a regional load balancer if your backends exist in only one region.
A hybrid connectivity NEG allows a Google Cloud load balancer to distribute traffic to backend endpoints located outside of Google Cloud, such as in an on-premises data center or another public cloud. This requires connectivity via Cloud VPN or Cloud Interconnect and specific firewall configuration for health checks.
Without global access, clients must be in the same region as the internal load balancer's forwarding rule. With global access enabled, clients can connect from any region within the same VPC network or a peered VPC, enabling a single regional service to be accessed from across a multi-region deployment.
Prepare and test your skills
Prepare and test your skills
StudyCerts
StudyCerts