Professional Cloud DevOps Engineer
GCP load balancers provide powerful features to control how traffic moves through your infrastructure. Traffic steering lets you route requests based on HTTP parameters like headers, host, and path. Weight-based traffic splitting allows you to gradually shift a percentage of traffic between different backend services—for example, sending 95% of traffic to the current version and 5% to a new version, then increasing the percentage as you validate the new deployment works correctly. These traffic policies fine-tune load balancing behavior and help you make controlled changes without disrupting users.
To redirect traffic, you configure URL maps and backend services with routing rules. Host rules determine which backend handles requests based on the domain, while path matchers route based on URL paths. You can also use URL redirects to forward users from HTTP to HTTPS or from old URLs to new ones. For more complex needs, header-based routing directs specific users—such as mobile app users—to different backend services based on their request headers.
GCP supports multiple failover strategies depending on your load balancer type. Active-passive failover automatically shifts traffic to a backup regional load balancer when the primary fails, using health checks to detect problems and Cloud DNS routing policies to manage the transition. Multi-region deployments with global load balancers route traffic to the closest healthy backend, so users experience minimal disruption even during regional outages. Health checks continuously monitor backends and remove unhealthy ones from the rotation.
Monitoring during traffic shifts is critical to ensure the transition succeeds. Track metrics such as latency, error rates, and successful request percentages across both the original and new backend services. GCP monitoring tools let you set up alerts that notify you if error rates spike or performance degrades during a traffic shift, enabling quick intervention if problems occur.
Always use health checks to ensure only healthy backends receive traffic. Implement gradual traffic shifts rather than making sudden changes, and test failover configurations regularly. Design for graceful degradation by implementing throttling, dropping excess requests early at the frontend layer, and building applications to handle partial errors and retries seamlessly.
Automated traffic redirection integrates directly into continuous delivery workflows to minimize user impact during deployments and incident responses. In GCP, this uses Application Load Balancers with URL maps and backend services to handle routing programmatically. This makes traffic draining a hands-free step in your deployment pipeline rather than a manual operation.
Two primary mechanisms manage user traffic during updates: traffic steering and weight-based traffic splitting. Traffic steering routes requests based on HTTP parameters like headers, while traffic splitting divides traffic by percentages among different backends. These support gradual rollouts (shifting small percentages to a new canary), A/B testing (directing specific user agents to specialized versions), and safe rollbacks (redirecting users immediately if errors are detected).
Systems must handle graceful degradation during traffic draining or infrastructure transitions to prevent complete outages. Graceful degradation means the system continues functioning with temporarily reduced performance under high loads or changes. Engineers achieve this by implementing throttling, dropping excess requests early at the frontend, and configuring automated health checks within managed instance groups. If a backend replica fails during traffic redirection, the load balancer automatically stops routing requests to it.
Organizations automate traffic adjustments using Infrastructure as Code (IaC) tools like Terraform. These automated workflows coordinate with canary analysis and rollback procedures to dynamically adjust URL map configurations. If anomalies are detected during a deployment, the pipeline triggers an automated rollback to restore the previous stable state. This programmatic control improves recovery times and protects the user experience during changes.
Traffic drainage gracefully removes backend instances from service during deployments, maintenance, or incident response while minimizing user impact by ensuring in-flight requests complete successfully before termination. In GCP, this is managed through connection draining settings on load balancers, which control how existing TCP connections are handled when a backend is taken out of rotation.
A key decision is whether to enable or disable connection draining during failover events. Disabling draining terminates connections quickly, often with a TCP reset packet. This works well for planned activities like patching backend VMs, where you want all connections to move swiftly to healthy backups. It is also essential for scenarios requiring data consistency, where only a single backend VM should be active at any time to prevent conflicts. Enabling draining allows a configurable timeout for existing connections to finish, which is preferable for minimizing errors during unplanned failovers.
The process is governed by a failover policy defined on a backend service. This policy includes a failover ratio that determines the minimum number of healthy primary instances required to avoid a failover—for example, with four primary VMs and a ratio of 0.5, at least two must be healthy. The policy also controls connection draining on failover and whether to drop traffic if all backends become unhealthy. Configuring this policy involves setting appropriate drain timeouts and monitoring connection termination to validate that drainage occurs as intended without dropping user requests.
To validate and ensure high availability, drainage strategies must be tested within broader architectural patterns. This includes configuring cross-region load balancing with health checks and DNS-based failover policies. GCP offers service load balancing policies that fine-tune algorithms like waterfall-by-region or spray-to-region and enable auto-capacity draining, which automatically drains traffic from backend groups with a high percentage of unhealthy endpoints. This further protects users from degraded performance during partial outages.
Prepare and test your skills
Prepare and test your skills
Enabling connection draining allows a configurable timeout for existing TCP connections to finish before a backend is taken out of rotation, which is preferable for minimizing errors during unplanned failovers. Disabling draining terminates connections quickly, often with a TCP reset packet, and works well for planned activities like patching backend VMs where you want all connections to move swiftly to healthy backups.
Use traffic steering to route requests based on HTTP parameters like headers, host, and path, which is ideal for directing specific users, such as mobile app users, to different backend services. Use weight-based traffic splitting to gradually shift a percentage of traffic between different backend services, supporting gradual rollouts like sending 95% of traffic to the current version and 5% to a new version.
An active-passive failover automatically shifts traffic to a backup regional load balancer when the primary fails, using health checks to detect problems and Cloud DNS routing policies to manage the transition. Health checks continuously monitor backends and remove unhealthy ones from the rotation, ensuring only healthy backends receive traffic.
Set the balancing mode on the canary backend service to RATE with a max rate of zero, which automatically triggers a gentle 70% cross-zone traffic drain to the baseline backend.
Configure CLIENT_IP session affinity on both backend services to maintain sticky routing; session affinity takes precedence over URL map weighted traffic splitting rules to prevent canary users from hopping backends.
Create separate global forwarding rules for each backend service and balance traffic between them using multiple anycast IP addresses on the same URL map.
Configure weighted traffic splitting in the URL map across the two backend services; weighted traffic splitting takes precedence over session affinity, and health check failures automatically redirect traffic to healthy backends.
Your team is preparing to execute a canary deployment for a high-traffic e-commerce microservice exposed via a Global External Application Load Balancer. You need to design a controlled traffic shift that gradually redirects incoming HTTP(S) requests from the baseline backend service to a newly deployed canary backend service while preserving high availability and predictable failover.
Which configuration and runtime behavior correctly describes how the Global External Application Load Balancer executes this traffic redirection?
StudyCerts
StudyCerts