"We'll deploy during the maintenance window" is an admission that your deployment process can't guarantee availability. Blue-green deployment eliminates that admission entirely — you run two complete, identical production environments and shift traffic between them, so a release never requires taking anything offline.
Here's how we implement blue-green deployments on AWS in a way that actually holds up under real traffic and real failure scenarios.
The Core Concept
You maintain two identical environments — call them Blue (currently live) and Green (idle or being updated). When you deploy a new version, it goes to the idle environment first. Once validated, traffic shifts from the live environment to the newly-updated one. The previously-live environment becomes idle, ready to receive the next deployment or serve as an instant rollback target.
The critical property this provides: rollback isn't a redeploy of an older version — it's simply shifting traffic back to the environment that was already running the previous version and never stopped.
Implementation on AWS: The Building Blocks
Application Load Balancer with weighted target groups. ALB supports weighted routing across multiple target groups, letting you shift traffic gradually (10%, 50%, 100%) rather than an instant full cutover, which reduces blast radius if something's wrong.
Route 53 weighted routing as an alternative or complement to ALB-level weighting, useful when you need to shift traffic across entirely separate infrastructure stacks (different VPCs, different regions) rather than just target groups within the same load balancer.
ECS/EKS native blue-green support. AWS CodeDeploy has native blue-green deployment support for ECS services, automating much of the target group swap and health check validation that you'd otherwise build manually. For EKS, tools like Argo Rollouts or Flagger provide similar capability at the Kubernetes layer.
Database considerations are the hard part. Blue-green works cleanly for stateless application tiers, but your database is typically shared between both environments — this means your deployments must maintain backward-compatible schema changes (expand-contract migrations) so both the old and new application versions can operate against the same schema during the transition window.
The Deployment Sequence
- Deploy the new version to the idle environment while the live environment continues serving 100% of traffic.
- Run automated smoke tests and health checks against the idle environment before it receives any real traffic.
- Shift a small percentage of traffic (often called a canary phase within the blue-green process) and monitor error rates, latency, and business metrics closely.
- Gradually increase traffic to the new environment if metrics remain healthy, or immediately roll back to 0% if any anomaly appears.
- Complete the cutover to 100% traffic on the new environment.
- Keep the old environment running for a defined bake period (typically 30-60 minutes minimum, sometimes longer) before decommissioning or repurposing it — this is your instant rollback window.
Common Failure Modes and How to Avoid Them
Database migrations that break the old version. If your new schema change removes a column the old application version still reads, you've broken your rollback safety net the moment you deploy. Always use expand-contract: add new columns/fields in one deployment, migrate usage in a following deployment, and only remove the old field in a third deployment once nothing depends on it.
Session state tied to a specific environment. If user sessions are stored in-memory on specific instances rather than in a shared, environment-agnostic store (Redis, DynamoDB), users can experience unexpected session loss mid-cutover. Externalize session state before implementing blue-green deployment.
Background jobs and scheduled tasks running in both environments simultaneously. If both Blue and Green have active cron jobs or queue consumers during the transition window, you risk duplicate processing. Design for idempotency in any job that could theoretically run from either environment during a transition.
Monitoring blind spots during the shift. If your monitoring dashboards aggregate metrics across both environments without environment-level breakdown, you can miss a problem specific to the new environment until it's already affecting most of your traffic. Tag and separate metrics by environment during every deployment.
When Blue-Green Isn't the Right Fit
Very large stateful systems where running two full production-scale environments simultaneously is cost-prohibitive may be better served by canary deployments with feature flags instead — a different pattern that changes behavior gradually within a single environment rather than maintaining two complete infrastructure stacks. Blue-green shines most for stateless services and applications where the cost of running duplicate infrastructure temporarily is justified by the deployment risk it eliminates.
Rutagon designs and implements zero-downtime deployment pipelines on AWS for teams that can't afford maintenance windows. Contact us to discuss a blue-green deployment architecture for your infrastructure.
Frequently Asked Questions
How much does it cost to run blue-green deployments on AWS?
You're effectively running double infrastructure during the deployment and bake period, which adds cost proportional to your environment size and how long you keep the old environment warm. Many teams offset this by scaling down the idle environment between deployments rather than keeping both at full production capacity continuously.
Can blue-green deployments work with a shared database?
Yes, but it requires careful schema migration strategy (expand-contract pattern) so both the old and new application versions remain compatible with the same database schema during the transition window. This is the most common technical challenge in blue-green implementations.
What's the difference between blue-green deployment and canary deployment?
Blue-green maintains two complete separate environments and shifts traffic between them, with the old environment serving as an instant rollback target. Canary deployment typically shifts traffic gradually within a single environment or cluster, often using feature flags rather than a full duplicate infrastructure stack.
How long should I keep the old environment running after a blue-green cutover?
A minimum bake period of 30-60 minutes is common, though some teams keep the old environment available for several hours or even a full day for higher-risk releases, since it serves as your instant rollback path if a problem surfaces after full cutover.
Does AWS have built-in tools for blue-green deployment?
Yes. AWS CodeDeploy has native blue-green support for ECS services, and Application Load Balancer's weighted target groups support gradual traffic shifting. For EKS, third-party tools like Argo Rollouts or Flagger provide similar capability at the Kubernetes layer.