Draining and Redirecting Traffic in Google Cloud

Automated drainage in deployment pipelines is the practice of making traffic shifts a programmed pipeline stage instead of a manual cutover. The pipeline controls Cloud Load Balancing (opens in a new tab) configuration, including URL maps and backend services, so each release or incident response moves traffic from old backends to new backends in small, verifiable steps. Health checks, weight-based splitting, and overload protections provide the signals and guardrails that let the pipeline advance, pause, or roll back without dropping user sessions.

1.1Health Checks and Autohealing as Automated Drainage Signals

Health checks and autohealing are the automated signals that remove unresponsive backends from the serving pool. A Compute Engine virtual machine (VM) can remain in the RUNNING state while its application software has crashed, so autoscaling alone cannot guarantee responsiveness. The health check probes each backend independently, and traffic flows from the load balancer only to backends that respond successfully while traffic stops flowing to backends that fail probes. When backends are Managed Instance Groups (MIGs), autohealing adds a second flow where the MIG depends on its health check to identify unavailable VMs, deletes those VMs, and creates replacement VMs so future pipeline stages have healthy targets.

1.2Weight-Based Splitting for Canary Releases and Rollback

Weight-based traffic splitting is the pipeline mechanism for canary releases, A/B testing, and service migration on Application Load Balancers. The pipeline defines percentage-based splits across multiple backend services, so a new version receives only a small share of live requests while the previous version continues serving the majority. Because the split is controlled by configuration, the pipeline can advance the percentages automatically after validation or reverse them instantly for rollback. A typical automated canary preserves order and validation gates:

1. Deploy new backend service: The pipeline brings up the new version alongside the previous version without sending it user traffic yet.
2. Split live traffic: Traffic flows from the load balancer to both backend services, for example 95% to the previous version and 5% to the new version.
3. Validate and expand: Only after health checks stay passing and canary analysis succeeds, the pipeline gradually shifts weights toward the new version.
4. Complete or roll back: The pipeline completes drainage when 100% of traffic reaches the new version, or reverses the weights back to the previous version when validation fails.

1.3Steering, Actions, and Policies for Targeted Redirection

Traffic steering, actions, and policies are the three Application Load Balancer capabilities for draining specific subsets of traffic. Traffic steering routes requests based on HTTP(S) parameters such as host, path, and headers, so requests carrying user-agent:Mobile flow to mobile-designated instances while other requests flow to default instances. Traffic actions perform request-based and response-based operations such as redirects and header transformations, while traffic policies fine-tune load-balancing behavior such as advanced algorithms and request mirroring to a recording service. The pipeline implements all three capabilities through the same control plane where configuration flows from pipeline automation to URL maps and then to backend services, which in turn select the backends.

Regional internal Application Load Balancers use regional URL maps and backend services, while cross-region internal Application Load Balancers must use the global URL map and global backend service APIs.

1.4Overload Protection During Automated Traffic Shifts

Overload protection is the set of guardrails that keeps remaining backends available while drainage shifts load. Graceful degradation keeps the system available with reduced performance or accuracy under high load, then resumes full functionality when load returns to a manageable level. Google Search illustrates the pattern by prioritizing results from higher-ranked pages during overload and recomputing fuller results after load decreases. Pipeline orchestration combines peer protections so a traffic shift does not cause cascading failures:

• Independent throttling: Each replica throttles incoming requests on its own, with Apigee policy rules controlling API request rates during high-traffic periods.
• Early frontend drops: The frontend layer drops excess requests before they reach backend components, which produces errors for some users but avoids global failure.
• Partial-error handling: Applications handle partial errors and retries seamlessly so as much traffic as possible is still served.
• Overload testing and spike monitoring: Regular overload simulation validates throttle and drop behavior, while analytics detect traffic surges before they escalate.

Project-level quotas limit the number of API requests a Google Cloud service can receive, which protects against distributed denial-of-service (DDoS) attacks and runaway billing. For globally served applications, Network Service Tiers Premium Tier carries traffic from the internet entry point of presence (PoP) closest to the sender across the Google network to the appropriate backend.

Connection draining is the pattern for gracefully removing a backend from serving traffic so in-flight requests complete before shutdown. When an instance is removed from an instance group or an endpoint is removed from a zonal network endpoint group (zonal NEG), the backend service (opens in a new tab) stops sending new connections to that removed backend while existing connections are allowed time to finish. This behavior applies to Google Cloud load balancers and Cloud Service Mesh and is controlled by a connection draining timeout of 0 to 3600 seconds.

2.1Graceful Removal and Protection of In-Flight Requests

Graceful removal is the separation of new traffic from existing traffic at the moment a backend is marked for removal. The load balancer sends no new connections or requests to the removed virtual machine (VM) or endpoint, while packets and requests that belong to already-established flows continue to reach that same backend for the configured timeout. If no timeout is set, or the timeout is set to zero (0), Google Cloud ends existing connections on the removed instance or endpoint as quickly as possible. Validating drainage therefore means confirming that new flows arrive only on remaining backends while old flows on the draining backend decline to zero before the VM is deleted.

2.2Drainage Behavior Across Load Balancer Types

Drainage behavior across load balancer types depends on whether the load balancer proxies the connection or only routes packets. During the timeout all three types withhold new connections from the draining backend, but what happens after the timeout reflects how each design terminates connections.

A passthrough Network Load Balancer by itself cannot send RST or FIN packets to close a connection. After its connection tracking entry is removed, the newly selected backend has no record of the old TCP connection, so closure depends on that backend sending an RST and the client reconnecting through normal backend selection.

2.3Drain Timeout Configuration and Conflict Resolution

Drain timeout configuration is set on the backend service that references the instance group or zonal NEG. In the console, the timeout is set under backend configuration in Advanced configurations in the Connection draining timeout field, where 0 disables draining. With Google Cloud CLI (gcloud), the timeout is set with the --connection-draining-timeout flag on a new or existing backend service, for example on a global backend service with gcloud compute backend-services update BACKEND_SERVICE --global --connection-draining-timeout=CONNECTION_TIMEOUT_SECS. When the same instance group or zonal NEG is a backend for multiple backend services, the largest timeout value becomes the effective timeout. If the backend is a managed instance group (MIG), operations that delete the instance are delayed by at least that effective timeout, so the timeout must be long enough for the longest expected request plus connection close time.

2.4Validation of Completed Drainage

Validation of completed drainage confirms that the draining backend receives no new work and that its existing work finishes cleanly. Health checking supports this by helping ensure that traffic is not routed to unhealthy or unavailable resources, and backend health can be checked during removal to confirm that remaining backends stay healthy while the removed backend stops receiving new flows. Operators should monitor open connections and request counts on the draining VM or endpoint until existing requests complete and connection termination is observed, and only then allow the managed instance group deletion or endpoint removal to proceed. Connection pooling can break this validation because a previously established pooled connection can still carry new requests to a draining VM, and those requests may succeed at first and then fail when the VM is deleted.

Traffic redirection and failover in Google Cloud is the controlled shifting of user traffic between backend services, regions, or deployments to preserve availability. Global external Application Load Balancer (opens in a new tab) resources distribute traffic across regions in normal operation, regional external Application Load Balancer resources provide isolated backup targets, and Cloud DNS routing policies automate the switch between them. Health checks, URL maps, backend services, and Premium Tier routing work together so only responsive backends receive traffic while performance and error signals are observed.

3.1URL Maps and Backend Services as Traffic Control Plane

URL maps and backend services form the traffic control plane for Application Load Balancers by separating where traffic should go from how backends share that traffic. A request follows a two-phase flow where the load balancer first selects a backend service or backend bucket based on rules in the URL map, then the selected backend service selects a specific backend instance based on its locality policy, hashing, and outlier detection. Regional internal, cross-region internal, and global external Application Load Balancers support the same three categories of advanced behavior:

• Traffic steering: Intelligently route traffic based on HTTP(S) parameters such as host, path, headers, and other request parameters.
• Traffic actions: Perform request-based and response-based actions such as redirects and header transformations.
• Traffic policies: Fine-tune load-balancing behavior such as advanced load-balancing algorithms.

URL map routing modes are mutually exclusive within one URL map. A simple host and path rule first evaluates host rules against the request host, then evaluates the associated path matcher on a longest-path-matches-first basis. An advanced host, path, and route rule instead evaluates route rules in priority order, which enables precise percentage splits and header matches.

3.2Gradual Deployment Shifts with Splitting and Steering

Gradual deployment shifts use weight-based splitting and header-based steering to drain traffic from one deployment to another without redeploying code. Traffic splitting defines percentage-based splits across multiple backend services, so an operator can send 95% of traffic to the previous version and 5% to the new version, validate performance and errors, then gradually shift percentages until 100% reaches the new version. This pattern is used for new-version rollouts, A/B testing, and service migration, and the weighted splitting configuration takes precedence if session affinity is also configured. A controlled shift between deployments follows an explicit order:

1. Start with a small canary weight: Route a small percentage to the new backend service while the old backend service carries the majority.
2. Validate key signals: Observe latency, error rate, and backend health on both services before changing weights.
3. Shift weights incrementally: Move traffic in steps toward the new service only after each step remains healthy, then drain the old service to zero.

Header-based steering complements splitting by directing subsets of traffic to designated backends. Traffic steering can send requests with user-agent:Mobile to mobile-optimized instances while sending all other traffic to default instances. Request mirroring copies traffic to an additional service for compliance recording or later replay without affecting the primary response path.

3.3Health-Based Draining and Autohealing for Failover

Health-based draining is the mechanism that removes unresponsive backends from the serving pool during shifts and incidents. Health checks ensure that load balancers route application traffic to only the backends that are responsive, even when infrastructure appears healthy. For example, all Compute Engine virtual machines (VMs) hosting an application might be in the RUNNING state while the application software on some VMs has crashed, and health checks remove those crashed VMs from the serving pool. When backends are managed instance groups (MIGs), autohealing restores capacity because unavailable VMs are proactively deleted and new VMs are created while the load balancer continues to avoid the failed backends. Configure load balancing between application tiers as well as at the edge, such as using an internal Application Load Balancer for reliable communication between the web and application tiers in a three-tier stack, so a failing middle tier is also drained automatically.

3.4Global-to-Regional Failover with Cloud DNS Policies

Global-to-regional failover protects a global external Application Load Balancer with one or more regional external Application Load Balancers and Cloud DNS. The primary load balancer is the global external Application Load Balancer that handles client traffic during normal operations, and each backup load balancer is a regional external Application Load Balancer that receives traffic when the primary fails health checks. Failover occurs when Cloud DNS detects an outage and routes traffic from the primary to the backups, while failback occurs when Cloud DNS reverses routing back to the primary after health checks pass. Regional external Application Load Balancers work best as failover targets because regional load balancers are self-contained within individual regions and isolated from global external Application Load Balancer infrastructure in the same region.

Both load balancer types are based on Envoy proxies and process traffic in similar ways, which reduces behavior differences after failover. Deploy two or more regional external Application Load Balancers in the regions where traffic should fail over, perform capacity planning so surviving regions can absorb the redirected load, and reserve additional proxy-only subnet capacity for standby proxies.

3.5Premium Tier Routing and Observability During Redirection

Premium Tier routing and observability preserve performance and control while redirected traffic shifts regions. Traffic from the internet enters the high-performance Google network at the point of presence (PoP) closest to the sender, is routed within the Google network from the entry PoP to the selected Compute Engine backend, and outbound traffic exits at the PoP closest to the destination. This reduces hops between users and the entry point, which matters when traffic suddenly shifts regions. For multi-region applications serving global users, choose Premium Tier, while for single-region backends that do not need global features, a regional load balancer remains resilient to zone outages. During any shift, protect backends with rate limiting such as API request quotas and project-level resource quotas, throttle overloads independently at replicas with tools like Apigee, drop excess requests at the frontend layer to protect backend components, and monitor traffic spikes with analytics and monitoring tools so surges are detected before they escalate.

Key Facts

• Connection draining timeout on a backend service is configurable from 0 to 3600 seconds, where 0 disables draining and ends existing connections as quickly as possible.
• When one instance group or zonal NEG is shared by multiple backend services, the largest connection draining timeout becomes the effective timeout.
• A Proxy Network Load Balancer closes all existing TCP connections on a draining backend within 10 minutes, the default idle timeout.
• Weight-based traffic splitting across backend services takes precedence over session affinity for canary releases and rollback.
• Global-to-regional failover uses Cloud DNS failover routing policy for active-passive protection and geolocation routing policy for active-active bypass to regional external Application Load Balancers.