Blue-Green Deployments with EC2 and ALB

Deploy two app versions and switch traffic instantly with zero downtime.

Introduction

30 Second Summary

Every time your favourite app rolls out a new feature without a single second of downtime, there is a deployment strategy working behind the scenes. One of the most reliable patterns used in production is called blue-green deployment.

In this project, you will build a complete blue-green deployment environment on AWS using EC2 Auto Scaling Groups and an Application Load Balancer. You will deploy two versions of an application, perform a zero-downtime traffic switch, and validate an instant rollback.

What You'll Build

A production-ready blue-green deployment infrastructure where two Auto Scaling Groups serve different application versions behind a single ALB, and you switch traffic instantly by modifying the listener's default action.

By the end of this project, you'll have:

A working blue-green infrastructure with two Auto Scaling Groups and separate Target Groups behind a single Application Load Balancer.
A zero-downtime traffic switch performed by modifying the ALB listener default action to forward traffic from the blue environment to the green environment.
A validated instant rollback proving you can revert to the previous application version in seconds.
Secret Mission: Implement weighted target group routing for gradual canary-style traffic shifting.

Are there any prerequisites?

You need an AWS account with console access. This project uses the AWS Management Console for all steps. No CLI tools or local installations are required.

Set Up Networking and Security

Before you can deploy any application versions, you need the networking backbone that routes traffic to your instances.

In this step, you will create the security group, target groups, and Application Load Balancer that form the foundation of your blue-green deployment infrastructure.

In this step, get ready to:

Create a security group that allows HTTP traffic on port 80.
Create two target groups (blue and green) for your Auto Scaling Groups to register with.
Create an Application Load Balancer with an HTTP listener that forwards traffic to the blue target group.

Create the security group

A security group acts as a virtual firewall that controls which traffic can reach your resources. You need one that allows inbound HTTP traffic so the ALB and EC2 instances can serve web pages.

In the AWS Management Console, use the search bar at the top to search for EC2 and select it.
In the left navigation pane, under Network & Security, choose Security Groups.
Click Create security group.
For Security group name, enter bg-deploy-sg.
For Description, enter Security group for blue-green deployment ALB and instances.
For VPC, keep your default VPC selected.
Under Inbound rules, click Add rule.
For Type, select HTTP.
For Source, select Anywhere-IPv4 (this sets it to 0.0.0.0/0).
Leave the Outbound rules section unchanged. The default rule allows all outbound traffic.
Click Create security group.

What is a security group?

A security group is a set of firewall rules that controls inbound and outbound traffic for AWS resources. Security groups are stateful, meaning if you allow inbound traffic on a port, the response traffic is automatically allowed out.

By allowing HTTP on port 80 from 0.0.0.0/0, you are permitting anyone on the internet to reach your web pages through the load balancer.

You should see a green success banner confirming bg-deploy-sg was created.

Don't see the security group?

Make sure you are in the same AWS Region throughout this project. The security group only appears in the Region where you created it.

help me find my security group in the EC2 console

Create the target groups

A target group tells the load balancer where to send incoming requests. You need two target groups: one for the blue environment and one for the green environment.

Why create target groups before the ALB?

When you create the ALB, you need to specify a target group as the default action for its listener. The target group must already exist before the ALB can reference it.

In the left navigation pane, under Load Balancing, choose Target Groups.
Click Create target group.
For Choose a target type, select Instances.
For Target group name, enter bg-deploy-blue-tg.
For Protocol, keep HTTP. For Port, keep 80.
For VPC, select your default VPC.
Under Health checks, keep the default health check path of /.
Click Next.
On the Register targets page, do not select any instances. You will register targets later through Auto Scaling Groups.
Click Create target group.

Now repeat the process for the green target group.

Click Create target group again.
For Choose a target type, select Instances.
For Target group name, enter bg-deploy-green-tg.
For Protocol, keep HTTP. For Port, keep 80.
For VPC, select your default VPC.
Under Health checks, keep the default health check path of /.
Click Next.
Skip registering targets and click Create target group.

You should now see both bg-deploy-blue-tg and bg-deploy-green-tg listed in the Target Groups console.

Only see one target group?

Double-check you clicked Create target group (not just Next) on the Register targets page for the first target group. If the first one is missing, create it again using the steps above.

help me find my missing target group

Create the Application Load Balancer

The ALB is the single entry point for all user traffic. Its listener will forward requests to whichever target group you point it at, which is how you perform the traffic switch later.

In the left navigation pane, under Load Balancing, choose Load Balancers.
Click Create load balancer.
Under Application Load Balancer, click Create.
For Load balancer name, enter bg-deploy-alb.
For Scheme, select Internet-facing.
For Load balancer IP address type, keep IPv4.
Under Network mapping, for VPC, select your default VPC.
For Availability Zones and subnets, select subnets from at least 2 different Availability Zones.
Under Security groups, remove the default security group and select bg-deploy-sg (the one you just created).
Under Listeners and routing, keep the default protocol as HTTP and port 80.
For Default action, select bg-deploy-blue-tg from the target group dropdown.
Scroll down and click Create load balancer.

Why point the listener at the blue target group?

The ALB listener always needs a default action. By pointing it at the blue target group first, all traffic will initially go to your blue (v1) environment.

Later, when you want to switch to the green (v2) environment, you will simply change this default action to point at bg-deploy-green-tg instead.

The ALB will take a minute or two to provision. Wait until its State changes from Provisioning to Active.

Once active, select bg-deploy-alb from the list.
Copy the DNS name shown in the load balancer details. You will use this to access your application in later steps.

Why does the ALB need at least 2 Availability Zones?

AWS requires Application Load Balancers to span at least two Availability Zones for high availability. If one zone goes down, the ALB can still route traffic to healthy targets in the other zone.

ALB stuck in Provisioning state?

This is normal. It can take 2-3 minutes for the ALB to become active. Click the refresh icon on the Load Balancers page to check the latest status.

If it stays in Provisioning for more than 5 minutes, verify that your default VPC has an internet gateway attached.

help me troubleshoot my ALB that is stuck provisioning

Your networking foundation is in place. Next up, you will create the Launch Template versions that define what your blue and green instances actually run.

Create Launch Template Versions

Your networking layer is ready. The ALB, target groups, and security group are all in place, waiting for EC2 instances to serve traffic to.

Now you need to define what those EC2 instances actually look like. A Launch Template is a blueprint that tells AWS which AMI to use, what instance type to launch, and what startup script to run. By creating two versions of the same template, you can deploy different application versions without rebuilding your infrastructure from scratch.

In this step, get ready to:

Create a Launch Template with a user data script that deploys a blue v1 web page.
Create Version 2 of the template with user data that deploys a green v2 web page.
Verify both versions exist in the EC2 console.

Create the launch template with blue v1 user data

The launch template defines the instance configuration that your Auto Scaling Groups will use to spin up EC2 instances. Version 1 will serve the blue environment.

In the EC2 console left navigation pane, scroll down to the Instances section and click Launch Templates.
Click Create launch template.
Enter bg-deploy-template in the Launch template name field.
Under Application and OS Images (Amazon Machine Image), select Amazon Linux 2023 AMI (it should be listed under Quick Start with the Free tier eligible label).
Under Instance type, select t3.micro.
Skip the Key pair section (you won't need SSH access for this project).
Under Network settings, click Select existing security group and choose bg-deploy-sg.
Expand the Advanced details section at the bottom of the page.
Scroll down to the User data field and paste the following script:

#!/bin/bash
yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd
echo "<html><body style='background-color: #2196F3; color: white; text-align: center; padding: 50px; font-family: Arial;'><h1>Blue Environment - Version 1</h1><p>Instance ID: $(curl -s http://169.254.169.254/latest/meta-data/instance-id)</p><p>Availability Zone: $(curl -s http://169.254.169.254/latest/meta-data/placement/availability-zone)</p></body></html>" > /var/www/html/index.html

What does this script do?

yum update -y updates all system packages on the Amazon Linux instance.
yum install -y httpd installs the Apache web server.
systemctl start httpd and systemctl enable httpd start the web server immediately and ensure it starts automatically on reboot.
The echo command writes an HTML page with a blue background to the default web root. It also pulls the instance ID and Availability Zone from the EC2 metadata service so you can see which instance served each request.

This script runs once when the instance first boots. Every instance launched from this template version will serve the exact same blue page.

Click Create launch template.
You should see a success banner confirming the template was created.

Seeing a validation error?

Make sure the template name bg-deploy-template has no spaces or special characters.
If the security group bg-deploy-sg doesn't appear in the dropdown, confirm it was created in the same region you're currently working in.
Check that you selected an AMI and instance type before scrolling to Advanced details.

Stuck on something else? Help me troubleshoot my launch template creation error.

Create Version 2 with green user data

Now you'll create a second version of the same template. The only difference is the user data script, which deploys a green v2 page instead of blue v1.

In the Launch Templates list, select bg-deploy-template.
Click Actions, then select Modify template (Create new version).
Under Source template version, select 1 so all settings carry over from Version 1.
Scroll down to Advanced details and expand it.
Find the User data field. Clear the existing script and replace it with this:

#!/bin/bash
yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd
echo "<html><body style='background-color: #4CAF50; color: white; text-align: center; padding: 50px; font-family: Arial;'><h1>Green Environment - Version 2</h1><p>Instance ID: $(curl -s http://169.254.169.254/latest/meta-data/instance-id)</p><p>Availability Zone: $(curl -s http://169.254.169.254/latest/meta-data/placement/availability-zone)</p></body></html>" > /var/www/html/index.html

What changed between Version 1 and Version 2?

Only two things changed in the HTML: the background color switched from #2196F3 (blue) to #4CAF50 (green), and the heading text changed from "Blue Environment - Version 1" to "Green Environment - Version 2".

Everything else is identical. The AMI, instance type, security group, and Apache install steps are all inherited from Version 1. This is the power of Launch Template versioning: you only change what's different.

Click Create template version.
You should see a success message confirming Version 2 was created.

Don't see the Create template version button?

Make sure you used Actions > Modify template (Create new version) instead of creating a brand new template. The button label changes depending on which flow you're in.
If your User data field is empty, check that you selected Version 1 as the source template version at the top of the form.

Need more help? Help me create a new version of my launch template.

Verify both template versions exist

In the left navigation pane, click Launch Templates to return to the templates list.
Click on bg-deploy-template to open it.
Select the Versions tab.
Confirm you see two versions listed: Version 1 and Version 2.

You can click on each version number and scroll to the User data section under Advanced details to confirm that Version 1 shows the blue script and Version 2 shows the green script.

✔️ Awesome, I've got everything!

Great. Both versions of your launch template are ready for the Auto Scaling Groups to use.

ⓧ I'd like to double check the user data scripts

Here are both user data scripts for comparison.

Version 1 (Blue):

#!/bin/bash
yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd
echo "<html><body style='background-color: #2196F3; color: white; text-align: center; padding: 50px; font-family: Arial;'><h1>Blue Environment - Version 1</h1><p>Instance ID: $(curl -s http://169.254.169.254/latest/meta-data/instance-id)</p><p>Availability Zone: $(curl -s http://169.254.169.254/latest/meta-data/placement/availability-zone)</p></body></html>" > /var/www/html/index.html

Version 2 (Green):

#!/bin/bash
yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd
echo "<html><body style='background-color: #4CAF50; color: white; text-align: center; padding: 50px; font-family: Arial;'><h1>Green Environment - Version 2</h1><p>Instance ID: $(curl -s http://169.254.169.254/latest/meta-data/instance-id)</p><p>Availability Zone: $(curl -s http://169.254.169.254/latest/meta-data/placement/availability-zone)</p></body></html>" > /var/www/html/index.html

Why use Launch Template versions instead of two separate templates?

Versions keep your blue and green configurations linked under a single template name. When you create an Auto Scaling Group, you point it at a specific version number. This makes it clear that both environments share the same base infrastructure and only differ in the application code they deploy.

It also simplifies rollback. If Version 2 has a bug, you just point back to Version 1 instead of hunting for a separate template by name.

Your launch template is ready with two versions. Next up, you'll use Version 1 to deploy the blue environment and see your v1 page served through the ALB.

Deploy the Blue Environment

Your launch template has two versions ready to go. Now it is time to bring the blue environment to life by creating an Auto Scaling Group that launches EC2 instances using Version 1.

The Auto Scaling Group automatically registers its instances with the blue Target Group. Since the ALB listener already forwards traffic to that target group, the moment instances become healthy, your blue application is live.

In this step, get ready to:

Create an Auto Scaling Group that launches blue v1 instances.
Verify instances pass health checks and register with the target group.
Access the ALB DNS name and confirm the blue page is live.

Create the blue Auto Scaling Group

An Auto Scaling Group (ASG) manages a fleet of EC2 instances based on rules you define. You will create one that launches exactly 2 instances using the blue v1 launch template version, then wires them into the blue target group so the ALB can route traffic to them.

In the EC2 console navigation pane, scroll down and select Auto Scaling Groups.
Click Create Auto Scaling group.
For Auto Scaling group name, enter bg-deploy-blue-asg.
For Launch template, select bg-deploy-template.
For Launch template version, choose a specific version and select 1 (this is the blue version).
Click Next.
Under Network, for VPC, select your default VPC.
For Availability Zones and subnets, select the same subnets you used for the ALB (at least 2 Availability Zones).
Click Next to proceed to the integrations page.
Under Load balancing, choose Attach to an existing load balancer.
Select Choose from your load balancer target groups.
In the Existing load balancer target groups dropdown, select bg-deploy-blue-tg.
Under Health checks, for Additional health check types, select Turn on Elastic Load Balancing health checks.
Click Next to proceed to the group size page.
Under Group size, set Desired capacity to 2.
Set Min desired capacity to 1.
Set Max desired capacity to 3.
Click Skip to review.
Review your settings and click Create Auto Scaling group.

What does this configuration do?

The ASG uses Version 1 of your launch template to launch 2 instances. Each instance runs the User Data script that installs Apache and deploys the blue v1 HTML page.

By attaching the ASG to bg-deploy-blue-tg, instances are automatically registered as targets. The ALB can then distribute incoming HTTP traffic across them.

Enabling ELB health checks means the ASG will replace any instance that the load balancer reports as unhealthy. This keeps your blue environment self-healing.

Why enable ELB health checks?

By default, the ASG only checks whether the EC2 instance itself is running. Turning on ELB health checks adds a layer that verifies the instance is actually responding to HTTP requests on port 80.

If an instance is running but its web server has crashed, the ASG will detect it through the load balancer and automatically launch a replacement.

Verify instances are healthy in the target group

After creating the ASG, EC2 Auto Scaling launches 2 instances. Each instance needs time to boot, run the User Data script, and pass multiple health checks before it is marked healthy.

In the EC2 console navigation pane, under Load Balancing, select Target Groups.
Click on bg-deploy-blue-tg to open it.
Select the Targets tab.

You should see 2 registered targets. Their status will initially show as initial while health checks are in progress.

Wait 2-3 minutes for both targets to transition to healthy status.
Click the refresh icon periodically to check their progress.

Why does it take a few minutes?

Each instance must boot up, install Apache via the User Data script, and then pass 5 consecutive health checks (one every 30 seconds). That adds up to about 2.5 minutes of health checking alone, plus boot time.

Targets stuck in unhealthy status?

Make sure your security group bg-deploy-sg allows inbound HTTP traffic on port 80 from 0.0.0.0/0. The ALB needs this to reach your instances.

Verify the health check path for bg-deploy-blue-tg is set to /. A wrong path causes all checks to fail.

Check that the subnets you selected for the ASG match the subnets used by the ALB. Mismatched subnets prevent routing.

Help me troubleshoot unhealthy targets in my blue target group.

Access the ALB and confirm the blue page is live

With healthy targets registered, the ALB is now routing traffic to your blue instances. Time to see it in action.

In the EC2 console navigation pane, under Load Balancing, select Load Balancers.
Select bg-deploy-alb from the list.
In the Description tab, find the DNS name field and copy the full DNS name.
Open a new browser tab and paste the DNS name into the address bar.
Press Enter.

You should see a blue page with the heading "Blue Environment - Version 1" along with the Instance ID and Availability Zone of the instance that served the request.

Refresh the page several times.
Notice the Instance ID changes between refreshes. This confirms the ALB is distributing traffic across both instances.

What is load balancing doing here?

The Application Load Balancer uses a round-robin algorithm by default. Each time you refresh, it routes your request to a different healthy target in the blue target group. The changing Instance ID proves both instances are serving traffic.

Seeing a 503 error?

A 503 error means the ALB has no healthy targets to route to. Return to Target Groups and confirm both targets in bg-deploy-blue-tg show healthy status.

If they still show initial, wait another minute and try again. The User Data script takes time to install Apache and write the HTML file.

Help me fix the 503 error when accessing my ALB.

Your blue environment is live and load balancing across two instances. Next up, you will deploy the green environment and perform the zero-downtime traffic switch.

Deploy the Green Environment and Switch Traffic

Your blue environment is live and serving traffic. Now it is time to deploy the updated v2 application alongside it and perform the zero-downtime cutover.

In a blue-green deployment, both versions run simultaneously before you flip traffic. The switch happens at the Application Load Balancer listener level, which means users experience no interruption. If anything goes wrong, you can switch back just as quickly.

In this step, get ready to:

Create the green Auto Scaling Group attached to the green target group.
Verify both environments are running simultaneously with healthy targets.
Perform the zero-downtime traffic switch by modifying the ALB listener.

Create the green Auto Scaling Group

The green environment uses Version 2 of the same launch template. It deploys identical infrastructure but runs the updated v2 application code.

In the EC2 console navigation pane, choose Auto Scaling Groups.
Click Create Auto Scaling group.
For Auto Scaling group name, enter bg-deploy-green-asg.
For Launch template, select bg-deploy-template.
For Launch template version, choose version 2 (your green version).
Click Next.
Under Network, for VPC, keep the default VPC selected.
For Availability Zones and subnets, select the same subnets you used for bg-deploy-blue-asg and the ALB.
Click Next to continue to the Configure advanced options page.
Under Load balancing, choose Attach to an existing load balancer.
Select Choose from your load balancer target groups.
In the Existing load balancer target groups dropdown, select bg-deploy-green-tg.
Under Health checks, Additional health check types, select Turn on Elastic Load Balancing health checks.
Click Next to go to the Configure group size and scaling policies page.
Under Group size, set Desired capacity to 2.
Set Min desired capacity to 1.
Set Max desired capacity to 3.
Click Skip to review.
Review the configuration, then click Create Auto Scaling group.

Why a separate ASG for the green environment?

Each Auto Scaling Group automatically registers its instances with the attached Target Group. By having bg-deploy-green-asg attached to bg-deploy-green-tg, you can switch traffic at the listener level without touching any instances directly.

Both environments stay fully independent. This isolation is what makes rollback instant.

Wait for green instances to become healthy

The new instances need time to launch, install httpd, and pass the ALB health checks.

In the EC2 console navigation pane, under Load Balancing, choose Target Groups.
Select bg-deploy-green-tg.
Choose the Targets tab.
Wait until both registered targets show a status of healthy. This typically takes 1-2 minutes.

What should I see?

You should see 2 targets in bg-deploy-green-tg with the status healthy. If targets show initial, they are still registering or undergoing health checks. Wait and refresh.

At this point, both environments are running simultaneously. The blue ASG serves production traffic while the green ASG sits ready behind its own target group.

Targets stuck in unhealthy or unused state?

Make sure bg-deploy-sg allows inbound HTTP on port 80. The health check path is / and the instances need to respond with a 200 status code.

Also confirm you selected the same subnets as the ALB. The ASG must be in the same VPC and Availability Zones for health checks to reach the instances.

Why are my green targets not becoming healthy?

Perform the blue-green traffic switch

This is the moment of truth. You will change the ALB listener's default action so it forwards traffic to the green target group instead of blue. This is a zero-downtime switch.

In the EC2 console navigation pane, under Load Balancing, choose Load Balancers.
Select bg-deploy-alb.
Choose the Listeners and rules tab.
Click the text in the Protocol:Port column for the HTTP:80 listener.
On the Rules tab, select the default rule.
Click Actions, then Edit rule.
Under Default action, change the forward target from bg-deploy-blue-tg to bg-deploy-green-tg.
Click Save changes.

What just happened?

The ALB listener's default action determines where all incoming traffic goes. By changing it to forward to bg-deploy-green-tg, every new request is now routed to the green instances running v2.

The blue instances continue running but no longer receive traffic. This separation is what makes rollback possible. You simply change the listener back.

Open a new browser tab and paste the ALB DNS name (the same URL you used earlier to see the blue page).
Refresh the page several times to confirm load balancing across both green instances.

You should see the green v2 page with a green background, the heading "Green Environment - Version 2", and alternating instance IDs on refresh.

Still seeing the blue page?

Clear your browser cache or open an incognito window. Some browsers cache the previous response for a short time.

Verify the listener change was saved. Return to Load Balancers and check that the HTTP:80 listener's default action now shows bg-deploy-green-tg.

Why is my ALB still serving the blue page after I changed the listener?

You have just performed a zero-downtime blue-green deployment. In the next step, you will validate that rollback is just as fast by switching the listener back to blue.

Validate Rollback

You just proved the blue-green switch works. Traffic is flowing to the green v2 environment with zero downtime.

Now for the real test of a blue-green deployment pattern: can you roll back instantly if something goes wrong? In this step, you will switch traffic back to blue and then decommission the green environment to complete the lifecycle.

In this step, get ready to:

Roll back to the blue environment by switching the ALB listener.
Decommission the green environment by scaling its ASG to zero.

Perform the rollback

Imagine you deployed v2 and users started reporting issues. In a blue-green setup, the fix is a single listener change that takes effect in seconds.

Navigate to EC2 in the AWS console.
In the left navigation pane, under Load Balancing, select Load Balancers.
Select bg-deploy-alb.
Click the Listeners and rules tab.
Click the text in the Protocol:Port column (HTTP:80).
In the Listener rules section, select the default rule.
Click Actions, then Edit rule.
Under Default action, change the forward target group from bg-deploy-green-tg to bg-deploy-blue-tg.
Click Save changes.

Why is this considered instant rollback?

The blue instances never stopped running. They have been sitting idle in bg-deploy-blue-asg the entire time, still registered as healthy targets in bg-deploy-blue-tg.

When you switch the listener, the ALB immediately starts routing new connections to the blue targets. There is no deployment, no provisioning, and no DNS propagation delay.

Open a new browser tab and paste the ALB DNS name (the same URL you used earlier).
Confirm you see the blue v1 page with the heading Blue Environment - Version 1 and a blue background.
Refresh a few times to verify all responses come from the blue environment.

Still seeing the green page?

Double check that you saved the listener rule change. Return to the Listeners and rules tab and verify the default action shows bg-deploy-blue-tg.

If using a cached browser, try a hard refresh or open an incognito window.

Help me troubleshoot why my ALB is still serving the green page after I changed the listener rule.

Decommission the green environment

Once you are confident the rollback is stable, there is no reason to keep the green instances running and incurring cost. Scaling the green ASG to zero terminates its instances while preserving the group configuration for future deployments.

In the EC2 console left navigation pane, under Auto Scaling, select Auto Scaling Groups.
Select the checkbox next to bg-deploy-green-asg. A split pane opens at the bottom of the page.
On the Details tab, choose Group details, then click Edit.
Set Desired capacity to 0.
Set Min desired capacity to 0 (desired capacity cannot be lower than the minimum).
Click Update.

What happens when desired capacity reaches zero?

The Auto Scaling Group terminates all running instances to match the new desired count of zero. The ASG itself, its launch template association, and its target group attachment remain intact.

This means you can scale back up later by simply editing the desired capacity again. The group will launch fresh instances using the same launch template version.

Wait 1-2 minutes for the instances to terminate.
In the left navigation pane under Load Balancing, select Target Groups.
Select bg-deploy-green-tg and click the Targets tab.
Confirm that no targets are registered. The list should be empty.

Targets still showing in the green target group?

Instances take a minute or two to fully terminate after the desired capacity change. Refresh the target group page after waiting.

If targets still appear after several minutes, return to Auto Scaling Groups and verify that bg-deploy-green-asg shows 0 in the Desired column. Also check the Activity tab for any error messages.

Help me figure out why my green ASG instances are not terminating after I set desired capacity to 0.

You have now completed the full blue-green deployment lifecycle: deploy, switch, and roll back. Your infrastructure is ready for the Secret Mission, where you will implement gradual traffic shifting instead of an all-or-nothing switch.

Secret mission

Implement Weighted Traffic Shifting

Instead of an instant all-or-nothing switch, configure the ALB listener to use weighted target group routing and gradually shift traffic from blue to green. This is the canary-style deployment pattern used by teams who want to catch issues before they affect all users.

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project uses paid AWS resources (an ALB and EC2 instances) that incur ongoing hourly charges while running.

Cost warning

The ALB costs approximately $0.0225/hour and each EC2 t3.micro instance costs approximately $0.0104/hour. With all resources running (1 ALB + up to 4 instances), you spend roughly $0.06-0.07 per hour.

Leaving everything running overnight (12 hours) would cost approximately $1.50. Delete or pause your resources when you are done to avoid unexpected charges.

Resources you used:

1 Application Load Balancer (bg-deploy-alb).
2 Target Groups (bg-deploy-blue-tg and bg-deploy-green-tg).
2 Auto Scaling Groups (bg-deploy-blue-asg and bg-deploy-green-asg) managing up to 4 EC2 instances total.
1 Launch Template (bg-deploy-template) with 2 versions.
1 Security Group (bg-deploy-sg).

Keep everything running

No action needed. Choose this if you are still actively experimenting with blue-green deployments or plan to continue with a related project.

To reduce costs while keeping your infrastructure configuration intact, set both ASG desired capacities to 0. This terminates all EC2 instances but preserves the ASGs, target groups, ALB, and launch template.
The ALB will still incur a small hourly charge (~$0.0225/hour) even with no instances behind it.

Pause - I'll come back to this later

Shut down your EC2 instances to stop compute charges while preserving all configuration. You can scale back up later without recreating anything.

In the EC2 console, select Auto Scaling Groups in the left navigation pane.
Select bg-deploy-blue-asg, click Edit, and set Desired capacity, Minimum capacity, and Maximum capacity all to 0. Click Update.
Repeat for bg-deploy-green-asg.
Wait for both ASGs to show 0 instances. The ALB and target groups remain configured but the ALB will still incur a small hourly charge.

Delete - I don't want to use this again

Remove all project resources completely. Follow this order to avoid dependency errors.

Step 1: Delete both Auto Scaling Groups.

In the EC2 console, select Auto Scaling Groups in the left navigation pane.
Select bg-deploy-blue-asg, click Delete, type delete to confirm, and click Delete.
Repeat for bg-deploy-green-asg. This terminates all EC2 instances managed by these groups.

Step 2: Delete the Application Load Balancer.

In the left navigation pane, select Load Balancers under Load Balancing.
Select bg-deploy-alb, click Actions, then Delete load balancer. Type confirm and click Delete.

Step 3: Delete both Target Groups.

In the left navigation pane, select Target Groups under Load Balancing.
Select bg-deploy-blue-tg, click Actions, then Delete. Confirm the deletion.
Repeat for bg-deploy-green-tg.

Step 4: Delete the Launch Template.

In the left navigation pane, select Launch Templates under Instances.
Select bg-deploy-template, click Actions, then Delete template. Type Delete to confirm and click Delete. This removes both versions.

Step 5: Delete the Security Group.

In the left navigation pane, select Security Groups under Network & Security.
Select bg-deploy-sg, click Actions, then Delete security groups. Confirm the deletion.
If you see a dependency error, wait a few minutes for the ALB deletion to fully complete, then try again.

Nice Work!

You just built a production-ready blue-green deployment environment on AWS. You can now release new application versions with zero downtime and roll back instantly if something goes wrong.

You learned how to:

Build a complete blue-green deployment infrastructure with two Auto Scaling Groups and separate target groups behind a single Application Load Balancer.
Perform a zero-downtime traffic switch by modifying the ALB listener default action to forward traffic between target groups.
Validate an instant rollback by switching the listener back to the original target group, proving the blue environment stays ready as a safety net.
Secret Mission: Implement weighted target group routing for gradual canary-style traffic shifting across multiple weight configurations.

Ready to quiz yourself?