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.

Practice

1. What is the main goal of a zero-downtime deployment in Terraform?

easy

A. Manually switch traffic after deployment

B. Update applications without stopping them or causing downtime

C. Deploy new versions only during off-hours

D. Stop all running tasks before updating

Solution

1. Step 1: Understand zero-downtime deployment purpose

   Zero-downtime deployment means updating apps without stopping them or causing service interruptions.

2. Step 2: Compare options with this goal

   Only Update applications without stopping them or causing downtime describes updating without stopping or downtime, matching the goal.

3. Final Answer:

   Update applications without stopping them or causing downtime -> Option B

4. Quick Check:

   Zero-downtime = no stopping, no downtime [OK]

Hint: Zero downtime means no stopping or service interruption [OK]

Common Mistakes:

• Thinking deployment must stop all tasks
• Assuming manual traffic switch is required
• Believing updates only happen off-hours

2. Which Terraform setting helps control how many tasks run during an update for zero-downtime?

easy

A. min_healthy_percent

B. max_percent

C. desired_count

D. task_definition

Solution

1. Step 1: Identify settings related to task counts during update

   Terraform uses settings like max_percent and min_healthy_percent to control task numbers during deployment.

2. Step 2: Understand min_healthy_percent role

   min_healthy_percent ensures a minimum percentage of tasks stay healthy and running during updates, preventing downtime.

3. Final Answer:

   min_healthy_percent -> Option A

4. Quick Check:

   min_healthy_percent controls running tasks during update [OK]

Hint: min_healthy_percent keeps tasks running during updates [OK]

Common Mistakes:

• Confusing max_percent with min_healthy_percent
• Using desired_count which sets total tasks, not update behavior
• Selecting task_definition which defines task specs

3. Given this Terraform snippet for ECS service update:

deployment_minimum_healthy_percent = 75
deployment_maximum_percent = 200

What does this configuration ensure during deployment?

medium

A. Exactly 75 tasks run; maximum 200 tasks allowed

B. No new tasks start until all old tasks stop

C. Deployment stops 25% of tasks before starting new ones

D. At least 75% of tasks stay running; up to 200% tasks can run temporarily

Solution

1. Step 1: Interpret deployment_minimum_healthy_percent

   This means at least 75% of current tasks must stay healthy and running during deployment.

2. Step 2: Interpret deployment_maximum_percent

   This allows up to 200% of the desired tasks to run temporarily, enabling new tasks to start before old ones stop.

3. Final Answer:

   At least 75% of tasks stay running; up to 200% tasks can run temporarily -> Option D

4. Quick Check:

   Min healthy 75%, max 200% = safe rolling update [OK]

Hint: Min healthy % keeps tasks running; max % allows extra tasks [OK]

Common Mistakes:

• Thinking percentages mean exact task counts
• Assuming deployment stops tasks before starting new ones
• Confusing min and max percentages

4. You set deployment_minimum_healthy_percent = 100 and deployment_maximum_percent = 100 in Terraform for ECS service. What issue will this cause?

medium

A. Deployment will run twice the desired tasks temporarily

B. Deployment will succeed with zero downtime

C. Deployment will fail because no new tasks can start before old ones stop

D. Deployment will ignore these settings and use defaults

Solution

1. Step 1: Analyze min and max percent both at 100%

   Min healthy 100% means all old tasks must stay running; max 100% means no extra tasks can start.

2. Step 2: Understand deployment impact

   New tasks cannot start until old ones stop, but old ones cannot stop because min healthy is 100%, causing deployment to fail.

3. Final Answer:

   Deployment will fail because no new tasks can start before old ones stop -> Option C

4. Quick Check:

   Min 100% + Max 100% blocks rolling update [OK]

Hint: Min 100% and Max 100% blocks task replacement [OK]

Common Mistakes:

• Assuming deployment will succeed without downtime
• Thinking max 100% allows extra tasks
• Ignoring min healthy effect on stopping old tasks

5. You want to deploy a new version of your app with zero downtime using Terraform ECS service. Your desired task count is 4. Which configuration best supports zero-downtime deployment?

hard

A. deployment_minimum_healthy_percent = 75deployment_maximum_percent = 125

B. deployment_minimum_healthy_percent = 100deployment_maximum_percent = 100

C. deployment_minimum_healthy_percent = 50deployment_maximum_percent = 150

D. deployment_minimum_healthy_percent = 0deployment_maximum_percent = 200

Solution

1. Step 1: Evaluate each option for zero-downtime support

   deployment_minimum_healthy_percent = 50
deployment_maximum_percent = 150 allows only 50% healthy tasks, risking downtime. deployment_minimum_healthy_percent = 100
deployment_maximum_percent = 100 blocks new tasks starting before old stop. deployment_minimum_healthy_percent = 0
deployment_maximum_percent = 200 allows zero healthy tasks, risking downtime. deployment_minimum_healthy_percent = 75
deployment_maximum_percent = 125 keeps 75% healthy and allows 125% max tasks, enabling smooth rolling update.

2. Step 2: Choose best balance for zero-downtime

   deployment_minimum_healthy_percent = 75
deployment_maximum_percent = 125 ensures enough healthy tasks remain while allowing new tasks to start before old stop, supporting zero downtime.

3. Final Answer:

   deployment_minimum_healthy_percent = 75 and deployment_maximum_percent = 125 -> Option A

4. Quick Check:

   Min healthy 75% + max 125% = safe rolling update [OK]

Hint: Min healthy ~75% and max ~125% enable zero downtime [OK]

Common Mistakes:

• Choosing min healthy too low risking downtime
• Choosing min and max both 100% blocking updates
• Allowing zero healthy tasks during deployment