Day 17 - AWS Elastic Beanstalk Blue Green Deployment with Terraform

Today I worked on Blue Green Deployment using AWS Elastic Beanstalk and Terraform.

The main goal was to understand how to release a new version of an application without taking production down. In Azure App Service, this is commonly done using deployment slots. In AWS Elastic Beanstalk, the same idea can be implemented by running two separate environments and swapping their environment URLs.

What I Built

In this project, I created two Elastic Beanstalk environments.

The Blue environment represents production and runs application version 1.0.

The Green environment represents staging and runs application version 2.0.

Both environments are created using Terraform. Each environment has its own Elastic Beanstalk setup with load balancing, auto scaling, health checks, and application version deployment.

Architecture


Why Blue Green Deployment Matters

In a normal deployment, we update the existing application in place. If something goes wrong during the deployment, users may see downtime or errors.

Blue Green Deployment avoids this by keeping the current version running while the new version is deployed separately.

This is similar to database failover thinking. You do not modify the active system blindly. You prepare another environment, validate it, and only then move traffic.

Terraform Flow

First, I packaged both versions of the application.


Then I initialized Terraform.

terraform init

After that, I validated and reviewed the plan.

terraform fmt
terraform validate
terraform plan



Then I deployed the infrastructure.

terraform apply

Once the deployment completed, Terraform displayed the URLs for both environments.

Testing Blue and Green

I opened the Blue environment URL first. This showed application version 1.0, which represented the current production version.


Then I opened the Green environment URL. This showed application version 2.0, which represented the new release.


At this stage, both versions were running independently.

Performing the Swap

After validating the Green environment, I performed the CNAME swap.

This can be done from the AWS Console or using the AWS CLI.

aws elasticbeanstalk swap-environment-cnames \
  --source-environment-name my-app-bluegreen-blue \
  --destination-environment-name my-app-bluegreen-green \
  --region us-east-1


After the swap, the production URL started serving version 2.0.



The old version was still available in the other environment, which means rollback is simple. If version 2.0 has an issue, I can swap again and move traffic back to version 1.0.

Key Learnings

Blue Green Deployment helps reduce deployment risk.

Elastic Beanstalk provides a managed way to run application environments without manually building every EC2, load balancer, and auto scaling component.

Terraform makes the infrastructure repeatable.

CNAME swap is the key step that moves traffic from one environment to another.

The main tradeoff is cost because two environments run at the same time.

Cleanup

Since this demo creates Elastic Beanstalk environments, EC2 instances, load balancers, and other resources, cleanup is important.

terraform destroy

Final Thoughts

This was a good practical lesson in production safe deployments. The important idea is not just deploying code, but deploying it in a way that gives us validation, rollback, and less risk.

Video Reference



Jay

Comments

Post a Comment

Popular posts from this blog

ASM Integrity check failed with PRCT-1225 and PRCT-1011 errors while creating database using DBCA on Exadata 3 node RAC

Image
  Error: The error message PRCT-1225: failed to verify Oracle Automatic Storage Management (Oracle ASM) user credentials using the command 'asmcmd credverify' indicates that the asmcmd credverify command failed to verify the Oracle ASM user credentials. This can happen for a number of reasons, including: The user credentials are incorrect. The user credentials file is corrupted. The user does not have the necessary permissions to run the asmcmd credverify command. There is a problem with the Oracle ASM instance. To troubleshoot this error, you can try the following: Make sure that the user credentials are correct. You can do this by trying to log in to the Oracle ASM instance using the same credentials. Check the user credentials file for errors. You can do this by using a text editor to open the file and inspect the contents. Make sure that the user has the necessary permissions to run the asmcmd credverify command. You can do this by checking the user's permissi...
Read more

Life is beautiful

Image
Life brings unexpected tragedies that are beyond our control. It's heartbreaking to witness people facing circumstances they never chose. We react with tears and inevitably wonder, "What if that happens to me?" As humans, we naturally focus on the positive and avoid dwelling on such thoughts—and that's healthy. But this perspective has shaped how I approach life: Am I prepared for these scenarios? Are my loved ones protected if something goes wrong? If I were to die, I couldn't be there to tell them to stay strong—they'd have to face that grief alone. But I can give them financial security through proper planning, wills, and trusts. These are tangible ways to care for them even when I'm gone. Beyond that, what else can I control? I don't waste energy worrying about an uncertain past or future. Instead, I choose to spread peace, truly listen to others, and share genuine smiles. I embrace the principle of living fully while letting others do the same. ...
Read more

Lock Tables in MariaDB

Whether or not you need to lock tables while backing up MariaDB depends on a few factors, including the type of backup you are performing and the tools you are using. If you are performing a full backup , you should lock the tables to ensure that the backup is consistent. This is because a full backup copies all of the data in the database, including any data that is currently being modified by transactions. If you do not lock the tables, it is possible that the backup could contain inconsistent data. If you are performing a differential backup or an incremental backup , you may not need to lock the tables. Differential and incremental backups only copy the data that has changed since the previous backup. This means that the data is already consistent, so there is no need to lock the tables. However, some backup tools may require you to lock the tables, even if you are performing a differential or incremental backup. This is because these tools may need to modify the database in some ...
Read more