Zero-downtime deployment pattern in Terraform - Step-by-Step Execution

Process Flow - Zero-downtime deployment pattern

Start with current version live

↓

Deploy new version alongside

↓

Run health checks on new version

↓

Switch traffic

↓

Old version off

↓

End

Deploy new version alongside old, test it, then switch traffic if healthy, ensuring no downtime.

Execution Sample

Terraform

resource "aws_lb_target_group" "blue" {}
resource "aws_lb_target_group" "green" {}
resource "aws_lb_listener_rule" "switch" {}

# Deploy green, test, then switch listener to green

Terraform code to create blue and green target groups and switch traffic for zero downtime.

Process Table

Step	Action	Resource State	Traffic Routing	Result
1	Deploy blue target group	Blue TG created	Traffic to Blue	Blue version live
2	Deploy green target group	Green TG created	Traffic still to Blue	Green version ready but idle
3	Run health check on green	Green TG healthy	Traffic still to Blue	Green version healthy
4	Switch listener to green	Listener updated	Traffic to Green	Users served by green version
5	Deregister blue target group	Blue TG deregistered	Traffic to Green	Old version off
6	Cleanup blue resources	Blue TG deleted	Traffic to Green	Deployment complete
7	If green health check fails	Green TG unhealthy	Traffic remains to Blue	Rollback green, keep blue live

💡 Deployment ends when traffic fully switches to healthy green version and blue is removed.

Status Tracker

Variable	Start	After Step 2	After Step 4	After Step 6
blue_target_group	not created	created	active	deleted
green_target_group	not created	created	active	active
traffic_target	blue	blue	green	green

Key Moments - 3 Insights

Why do we deploy the green version before switching traffic?

Deploying green first ensures it is ready and healthy before users start using it, as shown in step 3 of execution_table.

What happens if the green version fails health checks?

Traffic stays on blue version and green is rolled back, preventing downtime, as shown in step 7.

Why do we deregister and delete the blue target group after switching?

To free resources and avoid serving old version, ensuring only the new version handles traffic, as in steps 5 and 6.

Visual Quiz - 3 Questions

Look at the execution_table, at which step does traffic switch from blue to green?

A Step 2

B Step 4

C Step 5

D Step 7

💡 Hint

Check the 'Traffic Routing' column in execution_table rows.

According to variable_tracker, what is the state of blue_target_group after step 6?

A deleted

B active

C created

D deregistered

💡 Hint

Look at the last column for blue_target_group in variable_tracker.

If green target group fails health check, what happens to traffic routing?

A Traffic switches to green anyway

B Traffic is split evenly

C Traffic remains on blue

D Traffic stops completely

💡 Hint

Refer to step 7 in execution_table for traffic routing on failure.

Concept Snapshot

Zero-downtime deployment:
- Deploy new version alongside old
- Run health checks on new
- Switch traffic only if healthy
- Deregister old version after switch
- Rollback if new fails health checks
Ensures users never see downtime during updates.

Full Transcript

Zero-downtime deployment means updating your service without stopping it for users. First, you deploy the new version alongside the current one. Then you check if the new version is healthy. If it is, you switch user traffic to it. After switching, you remove the old version. If the new version is not healthy, you keep using the old one. This way, users always have a working service without interruption.