Kubernetes · EKS
Blue/green deployments on EKS: a practical guide
A plain Kubernetes rolling update is not a blue/green deployment, even though teams call it that. Rolling updates replace pods one at a time inside the same Service; there is no second full environment standing by, and rollback means rolling replicas back one by one while bad code may already be serving real traffic. True blue/green means two complete, independent environments at full capacity, one flip of a switch to move all traffic, and the same flip in reverse to roll back.
TL;DR
- Blue/green means both environments are fully up and healthy before any real user sees the new version. Cutover and rollback are both a single, instant flip.
- EKS does not give you this for free. You build the traffic switch yourself, at the load balancer, the deployment controller, or the cluster level.
- Three real approaches: two target groups behind one ALB (simplest), Argo Rollouts with the AWS Load Balancer Controller (automated, analysis-gated), or a second full cluster (heaviest, safest for major changes).
- Pick based on how much automatic rollback and metric analysis you actually need, not just team size.
Rolling update, canary, and blue/green are not the same thing
A rolling update mutates the existing Deployment pod by pod. There is no second environment, and there is no atomic rollback, you are always mid-transition to something. A canary sends a small percentage of traffic to the new version first and ramps up gradually, watching metrics as it goes; it overlaps with blue/green in tooling but the intent is gradual exposure, not an instant switch. Blue/green is the strict version: both environments run at full scale, the new one is validated before it sees a single real user, and the cutover is one change, not a gradual ramp.
Approach 1: two target groups behind one ALB
The simplest real implementation. Deploy Blue and Green as separate Kubernetes Services, each bound to its own Target Group via the AWS Load Balancer Controller. Both stay live behind the same Application Load Balancer. Cutover is a listener rule weight change, 100/0 to 0/100, applied through Terraform or a GitOps pipeline so the flip is reviewed and auditable, not a manual console click. Rollback is the same change in reverse. This needs no extra controller, but the cutover and any rollback decision are driven by a human or a script you write yourself.
Approach 2: Argo Rollouts
Argo Rollouts replaces the standard Deployment with a Rollout custom resource and understands blue/green and canary natively. Paired with the AWS Load Balancer Controller, it manages the target group weights for you and can gate promotion on real metric analysis, error rate and latency from Prometheus or Datadog, rolling back automatically if the new version fails its own health checks under real traffic. If the team already runs ArgoCD (see our ArgoCD vs Flux comparison), Argo Rollouts is from the same project family and slots into an existing GitOps pipeline rather than adding a separate tool to learn.
Approach 3: cluster-level blue/green
For changes riskier than an application deploy, a Kubernetes minor version upgrade, a node OS change, a major EKS platform change, stand up a second full EKS cluster and cut external traffic over with Route53 weighted records or an external load balancer pointed at whichever cluster's ingress is live. This is the most expensive option, effectively double infrastructure cost during the cutover window, but it isolates risk at the control-plane and node level, not just the application level, which the first two approaches cannot do.
| Approach | Setup effort | Rollback speed | Automated analysis | Best for |
|---|---|---|---|---|
| Two target groups, one ALB | Low | Fast (manual trigger) | No | Small teams, infrequent releases |
| Argo Rollouts | Medium | Fast, automatic | Yes, metric-gated | Teams already on ArgoCD, frequent releases |
| Second full cluster | High | Slower (DNS-dependent) | No, by default | Major version or node-level changes |
What actually goes wrong
- DNS-based cutovers with high TTLs. If the switch relies on Route53 record changes, a stale TTL means some users stay on the old environment far longer than the dashboard suggests. Target-group weight flips at the ALB are effectively instant because they are not DNS-cached; DNS-based cluster-level cutovers need a short TTL set well before the change.
- No smoke test against Green before the flip. Hit the Green target group directly by IP or host header and confirm it is healthy under synthetic load before it ever gets real traffic.
- Shared database, incompatible schema. If Blue and Green share a database, every schema migration during the overlap window has to be backward compatible with both versions running at once.
- No automatic rollback trigger. Relying on someone watching a dashboard after cutover is how bad deploys stay live for twenty extra minutes. Argo Rollouts' analysis step exists specifically to remove that human reaction-time gap.
What to do next
Blue/green on EKS is not hard to describe, it is easy to get subtly wrong: a cutover that looks instant but is not, a rollback that is slower than the incident that triggered it, a schema change that only one side can read. If you are setting this up for the first time or want a second look at what you already run, this is exactly the kind of platform work we do.