Skip to main content
In this lesson we explore blue‑green deployments for multi‑service applications: what they are, how they work on AWS, practical patterns, benefits, and common pitfalls to avoid. At a high level, blue‑green deployment means you keep two parallel environments:
  • Blue — the current live (production) version.
  • Green — the new version staged for release.
You build the green environment, run smoke tests and health checks, then shift production traffic from blue to green. The main advantages are zero downtime, fast rollback capability, and improved testability because environments are provisioned immutably.
A presentation slide about Blue/Green deployments showing a diagram of a "Blue Environment" with two availability zones (AZ1, AZ2) labeled as the current live version. To the right are two key benefits listed: "Zero Downtime" and "Instant Rollback."
Why teams choose blue‑green:
  • Removes configuration drift by provisioning immutable environments.
  • Enables full testing against a production‑like environment before routing live traffic.
  • Simplifies rollback: if green has issues, route traffic back to blue instantly.
A presentation slide titled "Blue/Green Deployments – Key Benefits" showing a diagram of a Blue Environment with application instances in two availability zones (AZ1 and AZ2). To the right are two benefit panels labeled "No Configuration Drift" and "Consistency Across Services" with icons.
Traffic shifting patterns Traffic can be shifted in multiple ways. DNS weighted routing (for example, with Amazon Route 53) allows gradual rollouts — 0%, 10%, 20% … up to 100% — giving you controlled exposure and an easy rollback by adjusting weights.
A diagram titled "Update DNS Routing With Amazon Route 53" showing users hitting Route 53, which routes traffic to blue and green environments. Each environment contains load-balanced instances spread across two availability zones (AZ1 and AZ2).
Route 53 weighted routing supports many target types — single IP/A records, instance targets or record sets, Auto Scaling groups, load balancers (ELB/ALB/NLB), and Elastic Beanstalk environments. For containerized services (Amazon ECS), Route 53 typically weights traffic to the load balancer fronting the service.
A slide titled "Update DNS Routing With Amazon Route 53" listing routing targets — Single instances, Group of instances, Instances in an Auto Scaling Group, ECS services, and Elastic Beanstalk web tiers — each with an icon. A cloud icon on the left connects to a rounded box containing the list.
DNS caveats and immediate cutovers DNS caching and TTLs can delay an effective cutover. For faster switchover, swap targets at the load balancer level: have the green Auto Scaling group (ASG) register with an ELB/ALB/NLB, verify health, then deregister blue instances.
When using DNS‑based cutovers, set low TTLs and plan for caching delays. For near‑instant switches, update target registration at the load balancer (ELB/ALB/NLB) to avoid DNS propagation issues.
A diagram titled "Swapping Auto Scaling Group Behind Elastic Load Balancer" showing users routed via Route 53 to an ELB inside the AWS cloud. The ELB forwards traffic to two Auto Scaling Groups, one containing EC2 instances and the other empty (standby).
ELB + ASG swap pattern This pattern supports an in‑place traffic shift: register green instances with the load balancer, confirm healthy status, then deregister or remove blue instances. Keep the blue environment as a rollback target or tear it down after successful verification. AWS provides managed tooling for blue‑green as well. AWS CodeDeploy supports blue‑green deployment strategies across EC2/On‑Prem, Auto Scaling groups, and Amazon ECS, and can automate traffic cutovers (automated or manual).
A diagram titled "Blue/Green Deployments Using CodeDeploy" showing an AWS CodeDeploy icon on the left connected to two deployment groups—Blue (Deployment Group A) and Green (Deployment Group B)—each containing three instance icons. A green bar labeled "Automated/Manual cutover" on the right indicates switching between the environments.
Typical CI/CD workflow A common automated workflow:
  1. Developers commit code.
  2. AWS CodeBuild produces artifacts.
  3. AWS CodeDeploy deploys artifacts to the target (EC2/ASG/ECS).
  4. Traffic is shifted from blue to green using automated routing or load‑balancer/Route 53 adjustments.
Automation ensures repeatability and reduces manual errors.
A diagram titled "Blue/Green Deployments Using CodeDeploy." It shows a CI/CD flow from a developer to CodeCommit → CodeBuild → CodeDeploy → ECS, then branching into Blue and Green environments.
Best practices
  • Automate pipelines end‑to‑end so deployments are repeatable and auditable.
  • Prefer a load balancer (ELB/ALB/NLB) for immediate cutovers; use Amazon Route 53 when you need global DNS control or weighted rollouts.
  • Use one primary health‑check mechanism (load balancer or Route 53 health checks) to gate cutovers.
  • Choose a rollout strategy: all‑at‑once, canary (small percentage increments), or linear (fixed increments over time).
  • Make rollback trivial: retain the previous environment, or be ready to revert weights/listeners quickly.
  • Monitor application metrics, logs, and business KPIs throughout the shift.
Table — Quick reference: rollout strategies
A presentation slide titled "Blue/Green Deployments on AWS – Best Practices" with a left-hand list of recommendations (e.g., Leverage ELB, Use Route 53, Implement Health Checks). On the right is a diagram of an Elastic Load Balancer directing traffic between two environments labeled E1 and E2.
Canary example (concept)
  • Start at 10% traffic to green.
  • Monitor errors, latency, resource usage, and business KPIs for a fixed window.
  • If stable, increase to 20%, and repeat until 100%.
  • If issues appear, revert back to blue by resetting weights or swapping targets.
A presentation slide titled "Blue/Green Deployments on AWS – Best Practices" showing a left-hand list of recommendations (e.g., automate pipelines, use ELB/Route 53, health checks, canary rollouts) with "Enable Rollback Mechanisms" highlighted. The right side has an illustration of a document with an exclamation icon and a gear.
Common failures and what to watch for
Slide diagram titled "Blue/Green Deployments – Common Failures" showing an AWS CloudFormation box connected by arrows to a Blue Environment and a Green Environment (each with three compute icons). The arrows are labeled "Infrastructure Provisioning Issues" and "Lack of IAM permission" and a red warning triangle is shown.
Application startup failures A common scenario: the green environment deploys but apps fail to start due to misconfigured environment variables, missing secrets, or unavailable dependencies. Add readiness and liveness checks so the load balancer only routes traffic to healthy instances.
A presentation slide titled "Blue/Green Deployments – Common Failures." It shows a green environment diagram with icons for a compute instance, application code (browser), and an error triangle, labeled "Application Startup Failures."
Routing and caching pitfalls DNS or load balancer misconfiguration can route traffic incorrectly. Client‑side caching and DNS TTLs may cause some users to continue hitting blue after cutover. Always verify routing with health checks and synthetic transactions.
A diagram titled "Blue/Green Deployments – Common Failures" showing users, an Amazon Route 53 icon, and traffic being routed to blue and green environments across AZ1 and AZ2. It highlights DNS or load balancer misrouting as a common failure with an error symbol.
Incomplete duplication and stateful components Incomplete duplication of infra (networking, security groups, IAM roles, ALB target groups, autoscaling policies) leads to subtle bugs. Stateful services (sessions, caches, queues, databases) require careful planning — use backward‑compatible schemas, rolling migrations, or explicit migration steps.
Be careful with database migrations and other stateful changes. Blue‑green cutovers work best when the new version is backward‑compatible with the existing data model, or when migrations are performed in a safe, coordinated manner.
A slide titled "Blue/Green Deployments – Common Failures" showing two side-by-side boxes labeled Blue Environment and Green Environment. Each contains two availability zones (AZ1, AZ2) with compute instances, and a "not equal" symbol indicating incomplete infrastructure duplication between them.
Where blue‑green is commonly applied (Links to AWS docs and service pages are embedded earlier for deeper reading.) Plan summary
  • Choose the right traffic shift strategy (all‑at‑once, canary, linear) based on risk.
  • Automate provisioning, builds, and deployments.
  • Use health checks and monitoring as the single source of truth for cutover decisions.
  • Ensure rollback procedures are simple and tested.
  • Treat stateful systems and DB migrations with extra caution.
With these patterns and safeguards in place, blue‑green deployments are a safe, repeatable way to release multi‑service applications with minimal downtime and fast recovery options. All right — see you in the next lesson.

Watch Video