AWS with Terraform (Day 17)

Blue-Green Deployment on AWS Elastic Beanstalk Using Terraform

Seamless Releases. Zero Downtime. Maximum Confidence.

Today’s focus was on one of the most essential real-world DevOps deployment strategies: Blue-Green Deployment using AWS Elastic Beanstalk + Terraform. I cloned the repository, applied file permissions, packaged application versions, deployed both blue & green environments, and even executed the final DNS swap. Everything worked smoothly end-to-end.

This blog captures the full journey.

What is Blue-Green Deployment?

Blue-Green deployment maintains two identical environments:

  • Blue → Active production environment

  • Green → Staging/testing environment

You deploy updates to Green, validate everything, then swap traffic to Green using DNS/CNAME.
Rollback? One click. Swap back.

No downtime, no user impact, no surprises.

Why Elastic Beanstalk + Terraform?

Combining Elastic Beanstalk with Terraform provides:

Automation

Infrastructure is codified — no manual point-and-click deployments.

Safe Deployment Flow

Changes land on the staging environment first.

Instant Rollbacks

Traffic swap back is immediate.

Environment Isolation

Each environment stays identical, making the swap predictable.

Architecture Summary

  1. Package app versions (v1 & v2) → store in private S3 bucket.

  2. Create two Beanstalk environments (blue and green).

  3. Deploy v1 to blue (live) and v2 to green (staging).

  4. Test the green environment thoroughly.

  5. Swap environment CNAMEs → green becomes live.

  6. Rollback by swapping again if required.

Repo Structure I Worked With Today (Day-17)

├── app_versions/
│   ├── v1/
│   └── v2/
├── scripts/
│   ├── package_apps.sh
│   └── package_apps.ps1
├── main.tf
├── blue_environment.tf
├── green_environment.tf
├── providers.tf
├── outputs.tf
└── variables.tf

I granted permissions to the scripts, zipped the app versions, and applied the Terraform config with:

terraform init
terraform plan
terraform apply

Both environments were created successfully, and the CNAME swap executed perfectly.

Key Terraform Components

S3 (Private)

Stores application .zip files.

Elastic Beanstalk Application

Holds metadata and version info.

Blue & Green Environments

Each includes:

  • Solution stack

  • Instance profile & IAM

  • Autoscaling config

  • Load balancer health checks

  • Deployment policies

Outputs

  • Environment names

  • URLs (CNAMEs)

  • Instructions for swapping URLs

DNS Swap & Verification

Once the green environment was validated:

  • Swapped CNAME in Elastic Beanstalk console

  • Traffic instantly moved to the green environment

  • No downtime

  • Smooth transition

Rollback was tested as well — working perfectly.

Best Practices I Followed Today

✔ Keep S3 buckets private
✔ Match blue/green environment configurations
✔ Use correct health check paths (/ on port 80)
✔ Plan DNS propagation
✔ Tag every resource
✔ Test rollback before declaring success
✔ Avoid long-lived idle environments unless required

Key Learnings from Day-17

  • Blue-Green deployment drastically reduces release risk.

  • Terraform makes environment provisioning predictable and repeatable.

  • Elastic Beanstalk handles a lot of complexity behind the scenes.

  • DNS swapping is one of the safest changes when implemented correctly.

  • Always validate the green environment thoroughly before swap.

  • Rollback strategy should be tested—not assumed.

Diagram




Final Thought

“Deploy to a staging copy, validate thoroughly, and swap when ready — minimal downtime, maximum confidence.”

This strategy is battle-tested and one of the cleanest ways to release updates in production without impacting users.

Day 17 complete. On to the next challenge. 

Here is the repo link: https://github.com/Mo-Adnan-Mo-Ayyub/Aws-with-Terraform

Here is the session link: 



Comments

Post a Comment

Popular posts from this blog

AWS with Terraform (Day 01)

Image
  Terraform Fundamentals – Day 01 (My Learning Notes as a DevOps Engineer) Today I wrapped up Day-01 of my Terraform with AWS series, and even with my DevOps background, this session helped me tighten my fundamentals and rethink how I approach cloud provisioning. Terraform is something I’ve used before, but today was more about understanding why IaC matters at scale and why Terraform continues to dominate in real-world DevOps ecosystems. Understanding Infrastructure as Code (IaC) As a DevOps engineer, IaC is not new to me. But today’s session broke it down in a way that clarified its real value. IaC = Infrastructure represented as code. Instead of building resources manually through AWS/Azure/GCP consoles, we define everything in .tf files. This ensures our setup is predictable, repeatable, and version-controlled. What I liked most is how clearly the contrast was shown: Cloud-Agnostic Tools (Terraform / Pulumi) Work across AWS, Azure, GCP, Kubernetes, GitHub, etc. ...
Read more

AWS with Terraform (Day 02)

Image
  AWS with Terraform – Day 02 Deep Dive into Providers, Versioning & the Real “Bridge” Between Code and Cloud Today’s session took me from simply writing Terraform code to actually understanding the engine behind it — the Provider layer . And honestly, once this clicks, Terraform stops feeling like just a tool and starts feeling like a real engineering system. Here’s what I learned and how I’ve started applying it. Providers: The Plugin That Makes Terraform Real The simplest way I now understand it: Terraform writes the story. Providers translate it into cloud actions. Before today, I treated the provider block as just two lines of mandatory code. Now I see it as the translator that turns HCL into actual AWS API calls . Example: I write: resource "aws_s3_bucket" "demo" { bucket = "my-app-demo" } The AWS provider turns that into the exact S3 API request. This layer saves us from manually hitting APIs, building payloads, or juggling ...
Read more

AWS with Terraform (Day 06)

Image
Mastering Terraform File Structure: Best Practices for Scalable AWS Infrastructure as Code You've built your first AWS resources with Terraform in one big main.tf file. It works fine at first. But as your project grows, that single file turns into a mess. Resources pile up. Variables hide in plain sight. Debugging takes forever. Good news. You can fix this now. Split your Terraform files the right way. Follow HashiCorp's tips for a clean setup. This boosts readability. It helps teams work together. Plus, it scales for big AWS setups like VPCs, EC2s, and S3 buckets. Stick with me. You'll see hands-on steps to organize your root module today. The Anatomy of a Well-Organized Terraform Root Module The root directory acts as your Terraform project's heart. It's the root module. Here, you keep all key files. No strict rules exist for names. But smart choices make life easier. Start simple. Break one fat main.tf into focused files. This stops resource clutter. You n...
Read more