A URL map is a Google Cloud configuration resource that decides where to send incoming HTTP(S) requests. It acts as the routing brain for an Application Load Balancer, examining each request's hostname and URL path to direct it to the correct backend service or storage bucket.
A URL map is built from three key parts that work together. Host rules match the domain name in the request, like api.example.com. If a host rule matches, the load balancer uses its associated path matcher. Inside a path matcher, path rules (or advanced route rules) examine the URL path, with more specific paths taking priority. If no rule matches, the request is sent to the default service as a fallback.
URL maps operate in one of two exclusive modes. Simple host and path rules use basic path matching, ideal for straightforward routing like sending /api traffic to one backend and /web traffic to another. Advanced host, path, and route rules offer more power, allowing matching based on HTTP headers and query parameters, and enabling traffic actions like URL rewrites directly within the rule.
Beyond host and path, URL maps can steer traffic using other parts of an HTTP request. Header-based routing can send mobile user traffic to a different backend than desktop traffic. Query parameter-based routing can direct users for A/B testing, like sending requests with ?version=beta to a canary backend. This allows for complex routing logic without needing extra proxy software.
Traffic actions modify requests as they pass through the load balancer. URL rewrites change the request's host or path before it reaches the backend, useful for creating clean public URLs that map to internal structures. URL redirects immediately send the client's browser to a new URL, commonly used to force HTTPS connections or handle moved content.
Traffic policies provide fine-grained control over load balancing behavior. Request mirroring sends a copy of each request to a secondary backend for testing or debugging without affecting the user's experience. Weighted traffic splitting directs a specific percentage of traffic (like 5%) to a new backend version for a canary deployment, allowing you to gradually increase traffic as confidence grows. Note that session affinity should not be used with weighted traffic splitting.
URL maps are configured using YAML files imported with the gcloud command-line tool. The YAML defines the host rules, path matchers, and default service. You can include configuration tests within the YAML file to verify routing logic. It is critical to validate the URL map with gcloud compute url-maps validate before deploying it to production to catch routing errors.
Configuring load balancers involves setting up health checks to monitor backend health and, for internal load balancers, enabling global access so clients from any region can reach regionally hosted services.
A Google Cloud health check is a resource that defines how Google's infrastructure probes and tests your backend endpoints, like VMs. The health check's settings—including protocol, port, check interval, and success thresholds—determine if a backend is marked healthy or unhealthy. For these probes to reach your backends, you must create a VPC firewall rule that allows traffic from Google's health check probe IP ranges (such as 35.191.0.0/16). Without this rule, probes are blocked and all backends will be considered unhealthy.
When creating a health check, you select a protocol (HTTP, HTTPS, TCP, etc.) that should match your backend service. You define the port, either as a fixed number or to use the instance's serving port. Key timing parameters are the check interval (time between probes, default 5 seconds) and the timeout (probe wait time, which must be less than or equal to the check interval). For a probe to succeed, it must meet protocol-specific criteria, such as receiving an HTTP 200 OK response before the timeout.
Global access is a feature for internal Application and TCP proxy load balancers. Normally, a client must be in the same region as the internal load balancer. When global access is enabled on the load balancer's forwarding rule, clients from any region within the same VPC (or a peered VPC) can connect. This allows a service deployed in a single region to be accessed by users or applications across multiple regions, simplifying architecture while keeping traffic private.
Backend services in Google Cloud Load Balancing use balancing modes, capacity scalers, and session affinity to intelligently distribute client traffic and manage backend workload.
A balancing mode defines how the load balancer measures the workload capacity of a backend group, like an instance group. The Rate (RATE) mode uses requests per second (RPS) and is recommended for Application Load Balancers to prevent uneven distribution. The Utilization (UTILIZATION) mode balances based on average backend VM CPU usage. The Connection (CONNECTION) mode, used by Proxy Network Load Balancers, measures capacity by concurrent open connections. Custom Metrics (CUSTOM_METRICS) mode allows using user-defined metrics for traffic distribution.
A capacity scaler is a multiplier (from 0.1 to 1.0) that adjusts a backend's effective serving capacity without changing its underlying configuration. Setting it to 0 drains the backend to 0% capacity, immediately stopping new traffic from being sent there and allowing for graceful maintenance or migrations. This is more controlled than failing health checks.
Traffic distribution happens in layers. After a region is selected, a load balancing locality policy determines how traffic is spread within that zone. The default ROUND_ROBIN distributes requests evenly. LEAST_REQUEST sends traffic to the backend with the fewest active requests. RING_HASH uses consistent hashing to minimize disruption when backends are added or removed. RANDOM picks a backend randomly, and WEIGHTED_ROUND_ROBIN uses custom metric weights.
Session affinity ensures a client's requests go to the same backend for the duration of a session. Client IP Affinity hashes the client's IP address. Generated Cookie Affinity issues a load-balancer cookie (GCILB) to track the session. HTTP Cookie Affinity uses an application-defined cookie, and Header Field Affinity uses a custom HTTP header value.
Connection draining gracefully removes a backend from service. When triggered, the backend stops accepting new connections but allows existing ones to complete up to a configurable timeout, after which any remaining connections are closed.
StudyCerts
StudyCerts35.191.0.0/16); otherwise, all backends will be marked unhealthy.0 immediately drains a backend to 0% capacity, excluding it from receiving new traffic without failing health checks.Simple mode uses basic path rules for routing based on hostname and URL path prefix. Advanced mode uses route rules, which add the ability to match on HTTP headers and query parameters, and include traffic actions like rewrites and redirects directly within the rule itself.
Use a capacity scaler when you need to gracefully and precisely reduce traffic to a backend for maintenance, canary testing, or migration. Setting the scaler to 0 provides immediate, controlled drainage. Modifying health checks is a blunter instrument that simulates a failure, which may not allow for a smooth transition of existing connections.
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.
Client IP affinity is simple but can be ineffective if many users share an IP (like behind a corporate NAT). Generated cookie affinity is more reliable for web traffic but requires cookie support. Header field affinity offers flexibility but relies on your application setting a specific header. The choice depends on your application's architecture and client characteristics.
Professional Cloud Network Engineer
Prepare and test your skills
Prepare and test your skills