Blue-Green Deployments Using Weighted Load Balancers

Blue-green deployments eliminate downtime and reduce release risk by running two identical production environments, where one serves live traffic while the other hosts the new release. By introducing weighted load balancer rules into this strategy, development teams can gradually shift user traffic from the active "blue" environment to the updated "green" environment rather than executing an abrupt, all-at-once cutover. This approach provides an automated safety net, allowing teams to monitor performance metrics, catch regressions under partial load, and execute instant rollbacks if issues arise.

1. Provisioning Dual Production Environments

Teams maintain two structurally identical production environments:

  • Blue (Active): Currently handles 100% of user traffic and runs the stable version of the application.
  • Green (Idle/Staging): Runs the newly deployed application version, provisioned via Infrastructure as Code (IaC) tools such as Terraform, AWS CloudFormation, or Kubernetes manifests.

Both environments connect to the same persistent data stores or use synchronized, backward-compatible database schemas to ensure data integrity during parallel execution.

2. Registering Distinct Target Groups

Modern application load balancers (such as AWS ALB, GCP Cloud Load Balancing, NGINX, or HAProxy) organize compute instances or containers into target groups.

The web development team registers:

  • Target Group Blue containing instances running version n.
  • Target Group Green containing instances running version n+1.

Both target groups reside behind a single load balancer endpoint configured with listener rules capable of weight-based distribution.

3. Pre-Shift Validation

Before routing public traffic to the green target group:

  1. Internal synthetic testing and automated end-to-end smoke tests run against the green environment via internal-only host headers or direct IP routing.
  2. Health check endpoints on the green instances must return continuous 200 OK responses to ensure the application layer is fully primed and dependencies are reachable.

4. Incremental Traffic Shifting via Weights

Once validated, the team initiates traffic migration by modifying the load balancer listener rules. Weights are assigned to each target group, representing the percentage of total requests each environment will receive.

A typical phased shift progresses as follows:

  • Initial State: Blue: 100% | Green: 0%
  • Canary Phase: Blue: 95% | Green: 5% (Monitors baseline performance under real-world conditions)
  • Intermediate Phase: Blue: 50% | Green: 50% (Validates capacity, connection pools, and database load)
  • Final Cutover: Blue: 0% | Green: 100% (The green environment now serves all incoming traffic)

These adjustments can be executed manually through a dashboard or automated using continuous delivery pipelines (such as GitHub Actions, GitLab CI, or Argo Rollouts).

5. Monitoring and Automated Rollback

During each weighting phase, monitoring platforms observe key health indicators:

  • HTTP 5xx error rates
  • Request latency (p95 and p99 percentiles)
  • CPU and memory saturation on green instances

If any metric breaches predefined service-level thresholds, the deployment pipeline immediately intervenes by reverting the load balancer weight to Blue: 100% / Green: 0%. Because the blue environment remained warm throughout the rollout, traffic shifts back instantly with zero downtime.

6. Post-Deployment Decommissioning

After the green environment runs at 100% weight for a designated bake period without incident, the deployment concludes:

  1. Active sessions on the blue environment are allowed to drain gracefully.
  2. The blue environment is either stopped to save infrastructure costs or designated as the standby target group for the next deployment cycle.