DEV Community: Atul Vishwakarma

Building a Production-Grade 3-Tier AWS Architecture with Terraform: Design Decisions, Trade-offs, and Lessons Learned

Atul Vishwakarma — Fri, 19 Jun 2026 02:30:00 +0000

Repo: https://github.com/vatul16/terratier — full Terraform source, module docs, and architecture diagram.

When I set out to build this project, I didn't want another "deploy a VM and call it infrastructure" tutorial repo. I wanted something that would force me to think through the same questions a platform team actually argues about: how many subnet tiers do you really need, where do secrets live, how do you let engineers SSH in without handing out keys forever, and what's the cheapest way to stay highly available without going broke on NAT Gateway bills.

The result is TerraTier — a small Go/Node.js goal-tracking app, deployed across a fully isolated, auto-scaling, four-tier network on AWS, provisioned entirely through modular Terraform. The app itself is deliberately boring (it's a CRUD list of goals). The infrastructure underneath it is the actual point of the project, and this article walks through why it looks the way it does.

The problem with most "3-tier Terraform" examples

Search for AWS 3-tier Terraform examples and you'll find a lot of repositories that split a VPC into public, private, and database subnets, drop a web server in private, and call it done. That's a reasonable starting point, but it collapses two very different concerns into one "private" tier: the stateless web/API layer that talks to the internet (indirectly, via a load balancer) and the application layer that's allowed to talk to the database. If your web tier gets compromised, in that model, it's sitting in the same subnet — and often the same security group — as anything that can reach your data.

I wanted the network topology itself to enforce a stricter rule: nothing can reach the database except the backend tier, and nothing can reach the backend tier except the frontend tier and the internal load balancer. So the VPC here has four subnet tiers instead of three, each duplicated across two Availability Zones:

Public — Internet Gateway route, NAT Gateways, the public-facing ALB, and the bastion host.
Frontend private — the Node.js Express tier, reachable only from the public ALB.
Backend private — the Go API tier, reachable only from an internal ALB that the frontend talks to.
Database isolated — RDS PostgreSQL, with no route to the internet at all, reachable only from the backend's security group.

That extra split is a small addition in Terraform — one more aws_subnet resource block, one more security group, one more ALB — but it changes the blast radius of a compromised frontend instance from "can reach the database" to "can reach exactly one internal load balancer on one port."

Two ALBs instead of one

This is probably the single decision in the repo that most resembles a real production pattern rather than a tutorial shortcut. The public ALB load-balances browser traffic across the frontend Auto Scaling Group on port 3000. The frontend, in turn, doesn't call backend instances directly — it calls a second, internal-only ALB, which load-balances across the backend Auto Scaling Group on port 8080.

The alternative — having the frontend call backend instances directly via private IPs, or through a Cloud Map service registry — would save the cost of a second ALB (roughly $16–20/month plus LCU charges). I chose the internal ALB anyway, for a few reasons that matter more once you have more than one backend instance: it gives the backend tier the same health-checked, load-balanced semantics as the frontend tier; it means backend instances can scale, fail, and get replaced without the frontend needing to know anything about individual instance IPs; and it gives me a single, consistent mental model — "every tier that has more than one instance sits behind an ALB" — instead of two different patterns for two tiers that conceptually do the same kind of horizontal scaling.

Secrets Manager, not environment variables baked into an AMI

The RDS master password is generated once, at apply time, with Terraform's random_password resource — 16 characters, with a curated set of special characters that won't break a Postgres connection string. It's written to a single Secrets Manager secret ({environment}-{project}-db-credentials) as a JSON blob containing the username, password, host, port, and database name together, so the backend only ever needs one secret ARN, not five separate values to wire through.

At boot, the backend's user-data script calls aws secretsmanager get-secret-value, parses the result with jq, and passes the individual fields into the Docker container as environment variables. The instance's IAM role grants exactly one Secrets Manager permission — GetSecretValue and DescribeSecret, scoped to that one secret's ARN, nothing else. No password ever gets written to a Dockerfile, a Docker image layer, or a .env file checked into git.

I'll be upfront about the limitation here, because it's the kind of thing an interviewer will probe and you should be ready to discuss it honestly: the password still flows through a Terraform variable (var.db_password), which means it exists in plan output and state, even though the variable itself is marked sensitive = true. The cleaner pattern is to have RDS generate and manage its own master password natively (manage_master_user_password = true, an RDS feature that creates and rotates the secret for you, with Terraform never touching the plaintext at all). I built it the way I did first because I wanted to understand the full credential lifecycle by hand before reaching for the feature that hides it.

Bastion host and SSM, deliberately redundant

Every EC2 instance in this stack — bastion, frontend, backend — gets the same IAM instance profile, which includes the AmazonSSMManagedInstanceCore managed policy. That alone is enough to aws ssm start-session --target <instance-id> into any instance with no SSH key, no open port 22 from the internet, and a full audit trail in CloudTrail of who connected and when.

So why keep the bastion at all? Two reasons. First, pragmatically: SSM Session Manager occasionally has friction in CI environments, narrow corporate proxy setups, or when you specifically need to forward a local port (aws ssm start-session ... --document-name AWS-StartPortForwardingSession) and just want a plain ssh -L tunnel instead of remembering the SSM syntax. Second, for this project specifically: a bastion host is the pattern most reviewers and interviewers will recognize immediately, and I wanted the repo to demonstrate both the "traditional" approach and the modern, keyless approach side by side, with the security trade-offs of each visible in the Terraform itself (the bastion's security group only allows SSH from var.allowed_ssh_cidrs, which defaults to "change this" rather than 0.0.0.0/0).

Picking the cheaper failure mode: single NAT Gateway

NAT Gateways are billed per-hour and per-GB processed, and they're one of the easiest places for a demo environment's AWS bill to quietly balloon. The VPC module supports both single_nat_gateway = true (one NAT Gateway, shared by both AZs' private subnets) and false (one NAT Gateway per AZ, fully redundant). The dev environment defaults to true.

That default is an explicit cost/availability trade-off, not an oversight: if the AZ hosting the single NAT Gateway has an outage, outbound internet access from the other AZ's private subnets breaks too — even though those subnets' EC2 instances are otherwise healthy. For a portfolio project that's torn down between demos, that's an acceptable risk for roughly half the NAT cost. For an actual production workload, flipping the flag to false is a one-line terraform.tfvars change, because the module was written to support both from day one rather than hardcoding the cheap option.

What happens when an instance boots

The launch templates for both ASGs run a user-data script that does the same rough sequence of things, and getting this script right was where I spent most of my actual debugging time on this project:

Install Docker and the AWS CLI v2.
(Backend only) Pull database credentials from Secrets Manager, with retry logic — because the very first time an ASG instance boots, RDS and the backend's DNS record might genuinely not be resolvable yet, and a script that fails fast on a transient DNS hiccup will throw the instance into a boot-loop of CrashLoopBackOff-style ASG churn.
(Frontend only) Poll the internal ALB's hostname and port with nc -z in a retry loop before starting the frontend container, so the frontend doesn't come up, fail its first few requests to a backend that isn't ready yet, and confuse anyone watching the ALB's health checks.
Pull the application's Docker image and run it with docker run --restart unless-stopped.
Install and configure the CloudWatch Agent to ship the user-data log and basic CPU/memory metrics.
Drop a cron entry that independently re-checks the container's health every 5 minutes and restarts Docker/the container if it's unhealthy — a cheap, ASG-independent self-healing layer on top of the ALB's own health checks.

The retry loops in steps 2 and 3 are the unglamorous but important part. The first version of this script didn't have them, and the very first terraform apply after a from-scratch deploy failed about a third of the time, simply because RDS or the internal ALB's DNS hadn't fully propagated by the time the EC2 instances finished booting — a classic race condition in any "spin up dependent infrastructure simultaneously" deployment. Adding bounded retry loops (with logging at every attempt, so you can actually see what happened in CloudWatch Logs afterward) turned that into a non-issue.

Observability: metrics, logs, and three layers of health checking

The Go backend exposes Prometheus-format metrics at /metrics — request counters labeled by path, and dedicated counters for goal-add and goal-remove operations — using the official prometheus/client_golang library. That's not wired up to a Prometheus server in this repo (there's no managed Prometheus or Grafana here yet), but the endpoint exists and is ready to be scraped, which matters more than it sounds: instrumenting an application for metrics is a decision you make in the application's code, and it's far easier to do it from the start than to retrofit it later.

Health checking happens at three independent layers, deliberately overlapping rather than relying on a single mechanism: the ALB target group's own health check (GET /health, every 30 seconds, 2 successes to mark healthy / 3 failures to mark unhealthy); a cron-based self-check on each instance every 5 minutes that restarts the container if it's failing locally; and CloudWatch Alarms watching aggregate CPU utilization and unhealthy target counts, wired to an alarm_actions list that's empty by default but ready to point at an SNS topic.

What I'd build next

A few things didn't make it into v1, on purpose — I'd rather ship something complete at a smaller scope than something half-finished at a larger one. In rough priority order:

A CI/CD pipeline is the most obvious gap. Right now, deploying a new image means running build_and_push.sh and then manually triggering (or waiting for) an ASG instance refresh. A GitHub Actions workflow that runs terraform plan on every pull request, builds and pushes images on merge, and triggers a rolling instance refresh would turn this from "infrastructure I deploy by hand" into "infrastructure that deploys itself," which is really the whole point of the discipline.

Moving from Docker Hub to Amazon ECR removes both the anonymous-pull rate limiting that public Docker Hub images are subject to and the need to pass Docker Hub credentials into instance user-data at all — ECR authentication can ride entirely on the existing IAM instance profile.

And finally, remote state. The S3 backend block is already scaffolded and commented out in provider.tf, because local state is fine for solo development but becomes a real liability the moment more than one person — or one CI pipeline plus one person — needs to run terraform apply against the same environment.

Closing thoughts

None of the individual pieces here are exotic — VPCs, ALBs, ASGs, RDS, Secrets Manager, and IAM are about as standard an AWS toolkit as exists. What I think is actually worth showing in an interview isn't any single resource block; it's the reasoning behind where the boundaries are drawn — which tier can talk to which, where a secret lives versus where it's read, what happens in the 90 seconds between "instance is running" and "instance is actually ready to serve traffic" — and being able to articulate the trade-off in each decision rather than just the decision itself.

The full code is on GitHub at https://github.com/vatul16/terratier, along with a deeper architectural breakdown in ARCHITECTURE.md and auto-generated input/output documentation for every Terraform module. I'm currently looking for Cloud/DevOps Engineer roles — feel free to reach out on LinkedIn if you'd like to talk through any part of this in more depth.

Stop Deploying Manually: How to Build Your First CI/CD Pipeline with GitHub Actions

Atul Vishwakarma — Mon, 15 Jun 2026 09:00:00 +0000

If you are still manually running tests and deploying your code from your local terminal, you are wasting valuable time.

When I first started diving into DevOps and Cloud engineering, the concept of CI/CD (Continuous Integration / Continuous Deployment) felt incredibly intimidating. I thought I needed a complex Jenkins server or a massive AWS architecture just to automate my workflows.

It turns out, if your code is already on GitHub, you can build your first automated pipeline in under 10 minutes using GitHub Actions.

Today, I’ll show you exactly how to set up a basic workflow that automatically tests your code every time you push to your repository.

Prerequisites:

A GitHub account
A basic understanding of Git (git add, git commit, git push)
A sample project (we will use a simple Node.js project for this example, but the concepts apply to any language).

Step 1: Create Your Workflow File

GitHub Actions looks for a very specific folder structure in your repository to know what to run.

In the root directory of your project, create a new folder called .github, and inside that, create a folder called workflows. Finally, create a YAML file inside it. You can name it whatever you want, but ci.yml is standard.

Your path should look like this: .github/workflows/ci.yml

Step 2: Write the YAML Configuration

YAML is the language of DevOps. It relies heavily on indentation, so make sure your spacing is exact!

Open your ci.yml file and paste the following code:

name: Node.js CI Pipeline

# 1. When should this workflow run?
on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

# 2. What jobs should it execute?
jobs:
  build-and-test:
    # We need a virtual machine to run our code
    runs-on: ubuntu-latest

    # 3. What are the exact steps?
    steps:
    # Step A: Check out the code from our repository
    - name: Checkout code
      uses: actions/checkout@v3

    # Step B: Set up the Node.js environment
    - name: Setup Node.js
      uses: actions/setup-node@v3
      with:
        node-version: '18.x'

    # Step C: Install dependencies
    - name: Install Dependencies
      run: npm ci

    # Step D: Run our tests
    - name: Run Tests
      run: npm test

Breaking Down the Code:

on: This tells GitHub exactly when to trigger the pipeline. In our case, it runs every time someone pushes code or opens a pull request to the main branch.
runs-on: GitHub provisions a fresh, temporary Ubuntu server (a runner) specifically to execute your commands.
steps: This is the chronological list of commands. We check out the code, install Node.js, install our npm packages, and finally, run the tests.

Step 3: Push and Watch the Magic

Save your file, commit it, and push it to GitHub:

git add .github/workflows/ci.yml
git commit -m "chore: add github actions CI pipeline"
git push origin main

Now, navigate to your repository on GitHub and click the "Actions" tab at the top.

You will see your workflow running in real-time! If your tests pass, you will get a satisfying green checkmark ✅. If they fail, you will get a red X and a log detailing exactly what broke, preventing bad code from making it to production.

The Takeaway

Congratulations! You just implemented Continuous Integration.

This is the foundational building block of modern DevOps. From here, you can expand this exact same file to automatically push Docker images to AWS, trigger serverless deployments, or send a Slack message when a build fails.

Automation is about letting the machines do the repetitive work so you can focus on building cool things.

I'll be sharing more DevOps and Cloud tutorials here as I build and learn. If this tutorial saved you some time, you can ☕ buy me a coffee here to support my work!

From Zero to Infrastructure-as-Code Hero: My 30-Day Terraform Journey

Atul Vishwakarma — Wed, 29 Apr 2026 07:18:55 +0000

After 30 days of consistent learning, building, breaking, and debugging… I’ve officially completed the 30 Days of AWS Terraform Challenge.

What started as a curiosity about Infrastructure as Code (IaC) has evolved into a deep, hands-on understanding of how modern cloud systems are designed, automated, and maintained.

This isn’t just a completion post—it’s a reflection on what it really takes to go from beginner to confident practitioner in Terraform and DevOps.

🌍 Why Terraform?

In today’s cloud-first world, managing infrastructure manually is:

❌ Error-prone
❌ Hard to scale
❌ Nearly impossible to audit

Terraform changes that by enabling:

✅ Declarative infrastructure
✅ Version-controlled environments
✅ Repeatable deployments

But more importantly, it introduces a mindset shift:

Treat infrastructure like application code.

📈 The Journey: From Basics to Production-Grade Systems

🔹 Phase 1: Foundations (Days 1–10)

I started with:

Providers & resources
State files
Basic AWS services (EC2, S3, IAM)

💡 Key realization:
Terraform isn’t just about creating resources—it’s about managing their lifecycle.

🔹 Phase 2: Scaling & Logic (Days 11–20)

This is where things got interesting:

Expressions & Functions → dynamic configurations
Meta-arguments (count, for_each) → scalable infrastructure
Modules → reusable and clean architecture
Provisioners → bootstrapping resources

💡 Key realization:
Clean, modular code is the difference between a demo and production-ready infrastructure.

🔹 Phase 3: Real-World Architectures (Days 21–28)

Here’s where theory met reality:

🏗️ 2-tier & 3-tier architectures
🌐 VPC design with public/private subnets
⚖️ Load Balancers + Auto Scaling
🔐 IAM policies & governance
📊 Observability with CloudWatch

💡 Key realization:
Infrastructure is not about individual services—it’s about how they work together.

🔹 Phase 4: DevOps Maturity (Days 29–30)

The final stretch focused on automation and reliability:

🔁 GitOps with ArgoCD

Self-healing Kubernetes deployments
Git as single source of truth

🔍 Drift Detection (Final Milestone)

Using:

terraform plan -detailed-exitcode

I built a pipeline that:

Detects infrastructure drift
Automatically remediates it
Notifies the team

💡 This was the biggest “aha” moment:

Infrastructure that fixes itself is the end goal.

🧠 Key Skills I Gained

✅ Infrastructure Design

High availability architectures
Secure networking (NAT, private subnets)
Scalable systems (ASG + ALB)

✅ Terraform Mastery

Modules & reusability
Remote state management (S3 + DynamoDB)
Data sources & dynamic blocks

✅ DevOps Automation

CI/CD with GitHub Actions
GitOps workflows
Drift detection pipelines

✅ Security & Governance

IAM best practices
Policy enforcement
Secrets management awareness

⚠️ Challenges Along the Way

This journey wasn’t smooth—and that’s the point.

Some real struggles:

Debugging Terraform state issues
Handling provider deprecations
Fixing networking misconfigurations
Understanding IAM policy conflicts

💡 Lesson learned:

Debugging is where real learning happens.

🔄 What Changed for Me

Before this challenge:

I knew how to create resources

Now:

I understand how to design systems

Before:

I deployed manually

Now:

I automate everything

Before:

I fixed issues manually

Now:

I build systems that prevent them

🚀 What’s Next?

This is just the beginning.

Next steps:

🔹 Advanced Kubernetes (EKS deep dive)
🔹 Multi-cloud Terraform deployments
🔹 Policy-as-Code (OPA, Sentinel)
🔹 Production-grade CI/CD pipelines

💭 Final Thoughts

This challenge taught me something beyond Terraform:

Consistency beats intensity.

Showing up every day—even when debugging for hours—made all the difference.

If you’re starting your DevOps journey:
👉 Don’t just watch tutorials
👉 Build projects
👉 Break things
👉 Fix them with code

That’s how you grow.

Mastering GitOps: Bridging Infrastructure and Application Delivery with Terraform & ArgoCD

Atul Vishwakarma — Tue, 28 Apr 2026 06:07:55 +0000

After an intense journey through the #30DaysOfAWSTerraform challenge, Day 29 stands out as one of the most transformative milestones so far.

This wasn’t just about provisioning infrastructure anymore—it was about building a self-healing, automated, and production-grade GitOps workflow.

If Infrastructure as Code (IaC) is the foundation, GitOps is the operating system that keeps everything running smoothly.

🔄 From IaC to GitOps: What Changed?

Until now, Terraform allowed me to:

Define infrastructure declaratively
Provision resources consistently
Avoid manual “ClickOps”

But GitOps takes it a step further:

Git becomes the single source of truth
Systems automatically reconcile drift
Deployments become continuous and auditable

👉 In short:
IaC provisions infrastructure. GitOps keeps it correct.

🏗️ Architecture Overview

This project bridges infrastructure provisioning and application deployment into one cohesive system.

1. Infrastructure Repository (Terraform)

Responsible for:

Provisioning an Amazon EKS cluster
Setting up networking (VPC, subnets)
Installing ArgoCD via Helm
Configuring storage (EBS CSI driver)

2. Application Repository (Kubernetes Manifests)

Contains:

Frontend (UI layer)
Backend (API layer)
PostgreSQL database

⚙️ How the Workflow Operates

Terraform provisions the infrastructure (EKS + ArgoCD)
ArgoCD connects to the application Git repository
Kubernetes manifests define the desired application state
ArgoCD continuously monitors and syncs changes

💡 The Magic:

If anything changes outside Git (manual kubectl edits, scaling, etc.),
ArgoCD automatically reverts it back to the desired state.

🔍 Key Concepts I Mastered

🔹 1. Terraform Helm Provider

Instead of manually installing ArgoCD:

resource "helm_release" "argocd" {
  name       = "argocd"
  repository = "https://argoproj.github.io/argo-helm"
  chart      = "argo-cd"
}

👉 This ensures ArgoCD itself is version-controlled and reproducible.

🔹 2. The “App of Apps” Pattern

Rather than deploying each service manually:

A parent ArgoCD application manages multiple child apps
Each microservice is defined independently

✅ Result:

Scalable architecture
Clean separation of concerns
Easier multi-service management

🔹 3. Drift Detection & Self-Healing

This was the biggest “aha!” moment.

I tested:

Manually modifying a deployment
Changing image versions outside Git

📌 Result:
ArgoCD instantly detected the drift and reconciled it automatically.

👉 No manual rollback. No panic fixes. Just automation.

🧠 What This Means in Real-World DevOps

This project reflects how modern teams operate:

Traditional Approach	GitOps Approach
Manual deployments	Automated sync
Human error risk	Self-healing systems
Drift goes unnoticed	Drift auto-corrected
Config scattered	Git as single truth

🔐 Challenges & Lessons Learned

⚠️ Secrets Management

Kubernetes secrets are base64 encoded—not secure enough
Next step: integrate AWS Secrets Manager

⚠️ State Management

Local Terraform state is risky
Plan: move to:
- S3 backend
- DynamoDB locking

⚠️ Complexity Growth

GitOps introduces more moving parts
But the trade-off is worth it for automation + reliability

🚀 What’s Next? (Final Stretch)

Before wrapping up the challenge, I plan to:

✅ Implement remote state management
✅ Secure secrets with AWS Secrets Manager
✅ Enhance CI/CD integration
✅ Explore advanced GitOps patterns

💭 Final Thoughts

Day 29 changed how I think about infrastructure.

This isn’t just about provisioning resources anymore—it’s about:

Building autonomous systems
Reducing human intervention
Creating resilient platforms

👉 The goal is no longer just “infrastructure that works”
👉 It’s “infrastructure that fixes itself.”

Scaling Cloud Proficiency: Building a Production-Ready 3-Tier Architecture with Terraform

Atul Vishwakarma — Mon, 27 Apr 2026 07:19:35 +0000

As part of my 30 Days of AWS Terraform Challenge, Day 28 marked a significant milestone in my cloud engineering journey—designing and deploying a fully automated, production-grade 3-tier architecture on AWS using Terraform.

This project wasn’t just about provisioning resources. It was about thinking like a systems designer—balancing scalability, security, and reliability.

🌍 Why 3-Tier Architecture Matters

The 3-tier architecture is a foundational pattern in modern cloud systems because it separates concerns into:

Presentation Layer (Web Tier) → Handles user requests
Application Layer (App Tier) → Processes business logic
Data Layer (DB Tier) → Stores and manages data

✅ Benefits:

Improved security through isolation
Better scalability per tier
Increased fault tolerance
Easier maintenance & updates

🏗️ Architecture Overview

Here’s how I implemented the architecture on AWS:

🔹 1. Custom VPC & Networking

I created a custom Virtual Private Cloud (VPC) with:

Public subnets → For Load Balancer
Private subnets → For App + DB tiers
Internet Gateway → Public access
NAT Gateway → Secure outbound access

👉 This ensures:
✔ Public entry is controlled
✔ Backend remains private

🔹 2. High Availability Across AZs

To eliminate single points of failure:

Deployed resources across 2 Availability Zones
Distributed compute and networking components

👉 Result:
✔ Application remains available even during AZ failures

🔹 3. Web Tier (Presentation Layer)

Application Load Balancer (ALB)
Handles incoming traffic
Routes requests to application servers

👉 Acts as the only public entry point

🔹 4. Application Tier (Logic Layer)

EC2 instances inside private subnets
Managed using Auto Scaling Groups (ASG)

Features:

Horizontal scaling based on demand
High availability
Fault tolerance

🔹 5. Database Tier (Data Layer)

Amazon RDS (MySQL/PostgreSQL)
Placed in private subnet group
Accessible only from application tier

👉 Ensures:
✔ No public exposure
✔ Strong data security

⚙️ Terraform Implementation

Everything was provisioned using Terraform, following a modular approach.

📦 Modules Created:

VPC Module
Security Groups Module
Compute (EC2 + ASG) Module
RDS Module
Load Balancer Module

💡 Why Modular Terraform?

✔ Reusable across environments
✔ Cleaner codebase
✔ Easier debugging
✔ Faster deployments

👉 Write once → reuse everywhere

🔐 Security Best Practices Implemented

Private subnets for app & DB
Security group restrictions (least privilege)
No direct DB exposure
NAT for controlled outbound traffic
Secrets managed via AWS Secrets Manager

🚧 Challenges & Troubleshooting

This project wasn’t without hurdles:

RDS parameter group configuration issues
Terraform provider inconsistencies
Networking misconfigurations
Security group debugging

👉 These challenges were the real learning moments.

💡 Key Learnings

🔹 1. Design > Deployment

Provisioning is easy. Designing a resilient system is the real skill.

🔹 2. Security by Default 🔐

Never expose databases publicly
Always isolate layers

🔹 3. Modularity is Power

Terraform modules turn complex systems into manageable components.

🔹 4. Hands-On > Theory

Breaking things and fixing them teaches more than tutorials ever can.

🎯 Final Thoughts

Day 28 felt like a turning point in my journey.

I moved from:
➡️ Writing Terraform code
➡️ To designing real-world cloud architectures

This project reflects how modern systems are built:
✔ Scalable
✔ Secure
✔ Fault-tolerant
✔ Automated

🔮 What’s Next?

Only 2 days left in this challenge! Up next:

Final optimizations
Advanced patterns
Wrapping up the journey

Building a Highly Available Web Architecture with Terraform

Atul Vishwakarma — Mon, 20 Apr 2026 09:01:59 +0000

As part of my 30 Days of AWS Terraform Challenge, Day 24 marked a major milestone in my journey—from provisioning basic infrastructure to designing a highly available, fault-tolerant, and scalable web architecture using Terraform.

This project pushed me to think like a Cloud Engineer, not just a Terraform user.

🌍 Why High Availability Matters

In real-world production systems, downtime is not an option.

A resilient architecture must:

Handle failures gracefully
Scale automatically with demand
Maintain security best practices
Ensure consistent performance

This project brought all of these principles together.

🏗️ Architecture Overview

The infrastructure I built follows a multi-tier, production-grade design on AWS:

🔹 1. Application Load Balancer (ALB)

The ALB acts as the entry point for all incoming traffic.

Distributes traffic across multiple EC2 instances
Spans multiple Availability Zones
Ensures fault tolerance if one AZ fails

👉 Result: Improved uptime and reliability

🔹 2. Auto Scaling Group (ASG)

To make the system elastic, I configured an Auto Scaling Group:

Defined min, max, and desired capacity
Integrated CloudWatch metrics (CPU utilization)
Automatically:
- Scales out during high traffic
- Scales in during low usage

👉 Result: Performance + cost optimization

🔹 3. Private Subnet Architecture 🔐

Instead of exposing servers directly to the internet:

EC2 instances are deployed in private subnets
Only the ALB resides in public subnets

👉 Result: Strong security posture (Zero direct public access)

🔹 4. NAT Gateway for Outbound Access

Since private instances need internet access:

NAT Gateways were deployed in each AZ
Enables:
- OS updates
- Pulling Docker images
- External API calls

👉 Result: Secure outbound connectivity without compromising isolation

⚙️ Terraform Implementation

The entire infrastructure was built using Infrastructure as Code (IaC) with Terraform.

📦 Key Components:

🔸 Launch Templates

Defined EC2 configuration
Automated:
- Docker installation
- Application deployment (Django app)

🔸 Auto Scaling Policies

Connected with CloudWatch alarms
Triggered scaling actions automatically

🔸 Modular Design

Separated:
- Networking
- Compute
- Security
Improved readability and reusability

👉 Result: Clean, scalable, production-ready codebase

📊 Key Learnings

💡 1. Fault Tolerance is Essential

Deploying across multiple Availability Zones ensures:

No single point of failure
Continuous availability

💡 2. Automation Eliminates Drift

Manually building this setup would:

Be error-prone
Lead to inconsistencies

With Terraform:

terraform apply
terraform destroy

Everything becomes:
✔ Repeatable
✔ Version-controlled
✔ Reliable

💡 3. Security First Mindset 🔐

Private subnets for compute
ALB as the only public entry
NAT for controlled outbound access

👉 This is how real-world systems are designed

💡 4. Scalability is a Design Principle

Instead of guessing capacity:

Let metrics drive scaling decisions
Build systems that adapt automatically

🚧 Challenges Faced

Understanding ASG + ALB integration
Debugging health checks
Configuring correct security group rules
Ensuring proper routing between subnets

👉 Each issue improved my troubleshooting skills significantly

🎯 Final Thoughts

This project was a turning point in my Terraform journey.

I moved from:
➡️ Creating resources
➡️ To designing resilient cloud systems

This is what real DevOps engineering looks like.

🔮 What’s Next?

As I approach the final stretch of this challenge, I’m excited to explore:

Advanced deployment strategies
CI/CD integrations
Multi-account architectures

Building Production-Grade Observability with Terraform

Atul Vishwakarma — Mon, 20 Apr 2026 06:23:24 +0000

From Deployment to Visibility: Observability in Action 🚀

As part of my 30 Days of AWS Terraform challenge, Day 23 marked a crucial milestone — shifting focus from simply deploying infrastructure to monitoring, analyzing, and ensuring its reliability.

Today’s project was all about End-to-End Observability, a critical pillar of any production-grade system.

Because in real-world systems, success is not just about launching applications — it’s about understanding:

How they behave 📊
When they fail ⚠️
Why they fail 🔍

🔎 Why Observability Matters

In modern cloud environments:

❌ Failures are inevitable
❌ Traffic patterns are unpredictable
❌ Systems are distributed

Without observability, debugging becomes guesswork.

👉 Observability enables teams to detect, diagnose, and resolve issues proactively.

By using Terraform, we can:

✔️ Automate monitoring setup
✔️ Ensure consistency across environments
✔️ Treat observability as code

🏗️ Project Architecture Overview

For this project, I built an observability layer around a serverless image-processing pipeline.

Core Architecture:

Amazon S3 → Image upload trigger
AWS Lambda → Image processing function
CloudWatch → Logs, metrics, dashboards, alarms
SNS → Alert notifications

This architecture demonstrates a real-world event-driven system.

📊 Deep Dive into Observability Components

1. CloudWatch Log Groups 🪵

Every Lambda execution generates logs.

I provisioned log groups using Terraform to:

Centralize logs
Retain execution history
Enable debugging

2. Metric Filters 📈

Logs alone aren’t enough — we need structured metrics.

Using CloudWatch Metric Filters, I extracted:

Processing success rates
Error counts
Latency metrics (P99)
Image size distributions

Why This Matters:

✔️ Converts raw logs into actionable insights
✔️ Enables performance tracking
✔️ Supports alerting systems

3. Custom Dashboards 📊

I created a CloudWatch Dashboard using Terraform to visualize system health.

Included Widgets:

Request count
Error rates
Latency trends
Throughput metrics

Benefit:

👉 Real-time visibility into application performance

4. Automated Alerts with SNS 🚨

Monitoring without alerting is incomplete.

I configured 12 CloudWatch alarms to detect anomalies such as:

High error rates
Increased latency
High concurrency spikes

Alert Workflow:

CloudWatch Alarm → SNS Topic → Email Notification

Result:

✔️ Proactive incident response
✔️ Reduced downtime
✔️ Faster debugging

⚙️ Terraform Implementation Highlights

Using Terraform, I automated:

Log group creation
Metric filters
Dashboard definitions
Alarm configurations
SNS topic setup

Why This is Powerful:

👉 Observability is deployed alongside infrastructure — not as an afterthought.

🧪 Testing & Troubleshooting

One of the most valuable parts of this project was testing the system.

Scenarios I Simulated:

Uploading invalid files → Trigger errors
Increasing load → Test concurrency alarms
Delayed processing → Validate latency thresholds

Key Learnings:

Metric filters must match log patterns precisely
Alarm thresholds require fine-tuning
Evaluation periods impact alert accuracy

This hands-on debugging made the learning much more practical.

💡 Key Takeaways from Day 23

✔️ Observability is essential for production systems
✔️ Terraform can fully automate monitoring stacks
✔️ Metrics + logs = complete visibility
✔️ Alerts enable proactive operations
✔️ Testing monitoring systems is as important as building them

🧠 Why This Matters in Real-World DevOps

In production environments:

You won’t always see failures immediately
Users will experience issues before you do (if no monitoring exists)

Observability ensures:

✔️ Faster incident detection
✔️ Better system reliability
✔️ Improved user experience

🚀 What’s Next?

With just a few days left in this challenge, I’m excited to explore:

Advanced monitoring tools
Distributed tracing
CI/CD observability integration

🎯 Final Thoughts

Day 23 was a turning point in my Terraform journey.

It reinforced that:

👉 Deploying infrastructure is only half the job — monitoring it is the other half.

If you're learning DevOps or Terraform, don’t skip observability — it’s what makes systems truly production-ready.

Building a Production-Ready 2-Tier Architecture on AWS with Terraform

Atul Vishwakarma — Fri, 17 Apr 2026 09:16:42 +0000

From Theory to Real-World Infrastructure 🚀

As part of my 30 Days of AWS Terraform challenge, Day 22 was a major milestone where I moved beyond individual resources and built a production-style 2-tier architecture using Terraform.

This project was all about combining networking, security, compute, and database layers into a cohesive and secure system — just like real-world applications.

🏗️ The Goal: Build a Secure 2-Tier Architecture

The objective of this project was to design and deploy:

Web Tier (Public Layer) → EC2 instances running a Flask application
Database Tier (Private Layer) → MySQL RDS instance

These two layers communicate securely while maintaining strict isolation from public access.

🔐 Architecture Overview

Web Tier (Public Subnet)

EC2 instance running Flask app
Accessible via Internet Gateway
Uses User Data for automated setup

Database Tier (Private Subnet)

Amazon RDS (MySQL)
No public access
Only accessible from Web Tier via Security Groups

⚙️ Core Infrastructure Components

To support this architecture, I provisioned:

🌐 Networking

Custom VPC
Public & Private subnets
Internet Gateway (for web tier)
NAT Gateway (for private subnet outbound access)

🔒 Security

Security Groups with strict rules
Principle of Least Privilege enforced

🔑 Secrets Management

AWS Secrets Manager for DB credentials
No hardcoded sensitive data

🖥️ Compute

EC2 instance with Flask app
Automated setup via User Data

🗄️ Database

RDS MySQL instance in private subnet

🧩 Modular Terraform Architecture

One of the biggest highlights of Day 22 was applying Terraform Modules in a real project.

Instead of one large configuration file, I structured my code into reusable modules:

Module Structure:

VPC Module → Networking setup
Security Group Module → Access control
RDS Module → Database provisioning
Secrets Module → Credential management
EC2 Module → Web server deployment

🔄 Data Flow Between Modules

Terraform modules don’t communicate directly — so I used:

outputs.tf → to expose values
variables.tf → to pass inputs

Example:

VPC module outputs subnet IDs
Root module passes them to EC2 & RDS modules
Secrets module outputs credentials used by EC2

This pattern ensures:

✔️ Loose coupling
✔️ High reusability
✔️ Clean architecture

🧪 Testing the Application

After deployment, I validated the setup by hitting:

/health → Application health check
/db/info → Database connectivity

Seeing the Flask app successfully connect to the RDS instance was a huge win! 🎉

🔐 Security Best Practices Implemented

This project reinforced critical security principles:

✔️ Private Database

RDS placed in private subnet
No direct internet exposure

✔️ Controlled Access

Only EC2 security group can access DB

✔️ Secrets Management

Credentials stored in AWS Secrets Manager

✔️ Least Privilege

Minimal permissions across components

💡 Key Learnings from Day 22

Modules are essential for scalable Terraform projects
Networking design is critical for security
Secrets should never be hardcoded
Private subnets protect sensitive resources
Testing validates real-world readiness

🧠 Why This Project Matters

This was not just another Terraform lab — it was a real-world architecture simulation.

It taught me how to:

Design secure systems
Structure modular IaC
Connect application & database layers
Apply DevOps best practices

This is the kind of project that bridges the gap between learning and real engineering.

🚀 What’s Next?

With only 8 days remaining, I’m excited to explore:

CI/CD integration
Advanced security practices
Multi-environment deployments

🎯 Final Thoughts

Day 22 was one of the most practical and rewarding days of this challenge.

It reinforced that:

👉 Good infrastructure is not just functional — it’s secure, modular, and scalable.

If you're learning Terraform, I highly recommend building projects like this to truly understand how cloud systems work.

Mastering Cloud Policy & Governance with Terraform

Atul Vishwakarma — Fri, 17 Apr 2026 05:56:46 +0000

Building Secure & Compliant Cloud Infrastructure with IaC 🚀

As part of my 30 Days of AWS Terraform challenge, Day 21 marked a major shift in perspective — from simply provisioning infrastructure to governing and securing it at scale.

Today’s focus was on AWS Policy and Governance using Terraform, and it was one of the most practical and impactful lessons so far.

Because in real-world cloud environments, success isn’t just about deploying resources — it’s about ensuring they are:

Secure 🔐
Compliant 📋
Auditable 🔍
Consistent ⚙️

Why Policy & Governance Matter

When infrastructure grows across teams, regions, and environments, manual management becomes:

❌ Error-prone
❌ Inconsistent
❌ Difficult to audit
❌ A major security risk

This is where Infrastructure as Code (IaC) combined with governance tools becomes critical.

👉 Terraform allows us to codify guardrails, ensuring that every deployment automatically follows best practices.

Core Concepts I Explored

Today’s lab focused on three essential pillars of cloud governance:

1. Preventive Controls with IAM Policies 🔐

IAM acts as the first line of defense.

Instead of reacting to issues, we can prevent them entirely by defining strict policies.

What I Implemented:

Denied S3 bucket deletion without MFA
Enforced encrypted uploads (HTTPS only)
Restricted unsafe operations based on conditions

Why It Matters:

✔️ Stops misconfigurations before they happen
✔️ Enforces least privilege
✔️ Protects critical infrastructure

2. Continuous Monitoring with AWS Config 📊

IAM prevents bad actions — but what about changes over time?

That’s where AWS Config comes in.

What I Built:

Enabled AWS Config recorder
Configured managed rules
Monitored compliance continuously

Example Checks:

Unencrypted EBS volumes
Missing resource tags
Non-compliant S3 buckets

Why It Matters:

✔️ Detects drift in infrastructure
✔️ Ensures continuous compliance
✔️ Provides audit visibility

3. Secure Logging & Audit Trails 🪵

Governance is incomplete without proper logging.

What I Implemented:

Centralized S3 bucket for logs
Enabled versioning
Enforced encryption
Restricted public access

Why It Matters:

✔️ Enables audits & investigations
✔️ Preserves historical data
✔️ Strengthens security posture

Hands-On Implementation Highlights ⚙️

Today’s project involved building governance controls using Terraform:

✔️ AWS Config Setup

Config recorder automation
Managed rule definitions

✔️ Tagging Enforcement

Standardized tags across all resources
Improved cost tracking & ownership

✔️ IAM Guardrails

Attached policies to roles
Controlled access behavior

This made the entire infrastructure:

👉 Self-governing
👉 Consistent
👉 Production-ready

The Real Challenge: IAM Policy Evaluation 🧠

One of the most valuable learnings today was understanding how IAM policies are evaluated.

It’s not just about writing policies — it’s about understanding:

Explicit Deny vs Allow
Policy precedence
Conditional logic behavior

Key Insight:

👉 An explicit deny always overrides an allow.

This concept is critical when designing secure systems.

Why This Matters in Real Organizations 🏢

In enterprise environments, governance ensures:

✔️ Compliance with regulations
✔️ Security at scale
✔️ Standardized deployments
✔️ Reduced human error

Without governance, cloud infrastructure quickly becomes chaotic.

With Terraform + AWS Config + IAM → you get automated compliance.

Key Takeaways from Day 21 💡

Terraform can enforce governance, not just provisioning
IAM policies act as preventive controls
AWS Config enables continuous monitoring
Logging is critical for auditing
Understanding policy evaluation is essential

What’s Next? 🔥

As I move forward in this journey, I’m excited to explore:

Policy as Code (OPA, Sentinel)
Advanced compliance automation
Security frameworks integration

Final Thoughts

Day 21 was a turning point.

It changed my mindset from:

➡️ “How do I deploy infrastructure?”
➡️ To “How do I secure and govern infrastructure at scale?”

That’s the real difference between writing Terraform and engineering cloud systems.

If you’re learning Terraform, don’t skip governance — it’s what makes your infrastructure production-ready.

Mastering Custom Terraform Modules for Scalable AWS Infrastructure

Atul Vishwakarma — Thu, 16 Apr 2026 10:48:58 +0000

Building Production-Ready Infrastructure with Reusable Terraform Modules 🚀

As part of my 30 Days of AWS Terraform challenge, Day 20 was a major milestone in my Infrastructure as Code journey.

Today’s focus was on one of the most important Terraform concepts for real-world DevOps: Custom Terraform Modules.

Until now, most of my learning revolved around creating and managing AWS resources directly. But Day 20 introduced the concept that truly separates beginner Terraform projects from production-grade cloud systems:

👉 Modularity and reusability.

This project gave me hands-on experience building an Amazon EKS cluster using a modular Terraform architecture — and it completely changed how I think about writing infrastructure code.

Why Terraform Modules Matter

When starting with Terraform, it’s common to place everything in a single main.tf file:

VPC
Subnets
Security groups
IAM roles
EKS cluster

This works for simple labs.

But in real-world environments, this quickly becomes:

❌ Hard to manage
❌ Difficult to debug
❌ Impossible to scale
❌ Error-prone for teams

Terraform modules solve this problem.

Benefits of Modules:

✅ Code reusability
✅ Better readability
✅ Easier collaboration
✅ Standardized deployments
✅ Simplified maintenance

Modules help transform Terraform from a scripting tool into a proper infrastructure framework.

Types of Terraform Modules I Explored

Today, I explored the three main types of modules:

1. Public Modules

Modules published in the Terraform Registry by providers like HashiCorp.

Example:

AWS VPC module

2. Partner Modules

Modules maintained jointly by HashiCorp and cloud vendors / partners.

Useful for:

Enterprise integrations
Verified architectures

3. Custom Modules (Main Focus Today)

Custom modules are built by your own team to:

Match internal standards
Enforce security controls
Improve reusability

This was the core focus of Day 20.

Project Goal: Build an EKS Cluster with Custom Modules 🎯

For today’s hands-on project, I built an Amazon EKS (Elastic Kubernetes Service) cluster using modular Terraform code.

Instead of writing one large configuration file, I split the infrastructure into reusable child modules:

Module Breakdown:

VPC Module → Networking, subnets, routing
IAM Module → Roles, policies, permissions
EKS Module → Cluster and worker node setup

This approach felt much closer to how real production systems are designed.

Understanding Root Module vs Child Modules 🧠

One of the biggest learnings today was understanding how Terraform structures module relationships.

Root Module

The root module acts as the main entry point.

Responsibilities:

Calling child modules
Passing variables
Managing overall orchestration

Child Modules

Child modules are reusable building blocks.

Each child module:

Handles one responsibility
Has its own variables
Exposes outputs

Why This Matters

This separation improves:

Team ownership
Maintainability
Debugging

This was a huge mindset shift for me.

Passing Data Between Modules 🔄

Today’s most important concept was learning how to pass information between modules.

Key Challenge:

Terraform child modules cannot directly communicate with each other.

So if:

VPC module creates subnets
IAM module creates roles

The EKS module still needs:

Subnet IDs
IAM Role ARN

Solution:

Using:

variables.tf
outputs.tf

Example Flow:

VPC module outputs subnet IDs
Root module receives outputs
Root passes them into EKS module

Why This Matters

This teaches clean architecture principles:

👉 Modules should stay independent, but data should flow intentionally.

This was the biggest technical takeaway from Day 20.

Encapsulation = Cleaner Infrastructure 🧩

Another major lesson was the power of encapsulation.

Instead of exposing all resource complexity in the root module:

I wrapped:

IAM roles
Node groups
Networking logic

Inside modules.

Result:

My root configuration became:

✔️ Cleaner
✔️ Easier to understand
✔️ Faster to extend

This makes future projects much easier to maintain.

Why This Matters in Real Organizations 🏢

Custom modules are essential for enterprise DevOps because they help enforce standards.

Examples:

Secure default VPC rules
Required resource tags
Approved IAM policies
Logging standards

Benefits for Teams:

✔️ Consistency across environments
✔️ Better compliance
✔️ Faster deployments
✔️ Reduced human error

Today made me realize that writing reusable Terraform is as important as writing correct Terraform.

Key Learnings from Day 20 💡

Today’s biggest takeaways:

✔️ Terraform modules improve scalability
✔️ Root / child architecture is powerful
✔️ Variables & outputs are the backbone of modularity
✔️ Encapsulation makes code production-ready
✔️ Reusability saves time and reduces errors

This felt like a major step toward thinking like a professional cloud engineer.

Advice for Beginners

If you’re learning Terraform:

Start small.

Try creating modules for:

VPC
EC2 instance
Security groups

Before moving to advanced services like EKS.

The sooner you understand modules, the easier Terraform becomes.

What’s Next? 🔥

Looking ahead, I’m excited to explore:

Module versioning
Remote module sources
CI/CD integration
Multi-environment deployments

Still 10 days to go — excited to keep building.

Final Thoughts

Day 20 was one of the most impactful milestones in this Terraform challenge.

It taught me that great Infrastructure as Code is not just about provisioning resources — it’s about building systems that are:

Reusable
Scalable
Maintainable

Custom Terraform modules are a game-changer for anyone serious about cloud engineering.

If you’re on your own Terraform journey, I highly recommend spending time mastering modules — they unlock the real power of IaC.

How are you using Terraform modules in your projects? I’d love to hear your best practices.

Building a Serverless Image Processing Pipeline with Terraform

Atul Vishwakarma — Wed, 15 Apr 2026 10:02:43 +0000

Automating Image Workflows with AWS Lambda, S3, and Terraform 🚀

As part of my 30 Days of AWS Terraform challenge, Day 18 was one of the most exciting and practical projects so far.

Today, I moved beyond basic infrastructure provisioning and built a fully automated serverless image processing pipeline using:

AWS S3
AWS Lambda
IAM Roles & Policies
Terraform

This project was a major step toward understanding how real-world event-driven cloud systems are designed and automated.

The Project Goal 🎯

The goal was simple but powerful:

👉 Whenever an image is uploaded to a source S3 bucket, AWS should automatically process it and store multiple optimized versions in a destination bucket.

Output Variants Included:

Compressed versions
Different file formats
Thumbnail image

This type of architecture is highly relevant for:

Media platforms
E-commerce websites
User profile image optimization
Content delivery systems

Why Serverless Architecture Matters

Traditional image processing systems often require:

Dedicated servers
Manual scaling
Ongoing maintenance

That creates:

Higher cost
Operational complexity
Slower deployments

Serverless changes everything.

Benefits of Serverless:

✅ Event-driven execution
✅ No server management
✅ Auto scaling
✅ Pay only for usage
✅ Faster deployment cycles

This project showed me exactly why serverless is such a powerful cloud pattern.

Architecture Overview 🏗️

The architecture for today’s project looked like this:

Step-by-Step Flow:

User uploads image to Source S3 bucket
S3 event notification triggers Lambda
Lambda processes image using Pillow library
Lambda generates multiple variants
Processed images are uploaded to Destination bucket

This entire workflow runs automatically without any manual intervention.

Terraform Resources Used ⚙️

This project was a great demonstration of how Terraform can automate complex serverless stacks.

Key Resources Provisioned:

1. S3 Buckets 📦

Terraform created:

Source bucket (incoming uploads)
Destination bucket (processed images)

Bucket setup included:

Event notification configuration
Permissions for Lambda access

2. AWS Lambda Function 🧠

The core logic was implemented inside a Lambda function.

Responsibilities:

Read uploaded image
Process and compress variants
Generate thumbnail
Upload outputs

Why Lambda?

Lambda is ideal because:

No server maintenance
Automatic scaling
Fast event response

3. IAM Roles & Least Privilege Security 🔐

A key learning today was implementing secure IAM access.

Terraform provisioned:

Lambda execution role
Scoped IAM policies

Permissions included:

s3:GetObject from source bucket
s3:PutObject to destination bucket
CloudWatch logs access

Why This Matters

Security in automation is critical.

This reinforced:

👉 Always grant only the permissions required.

4. CloudWatch Logging 📊

Terraform also provisioned:

Log groups
Monitoring support

This helped with:

Debugging failures
Monitoring execution
Troubleshooting events

CloudWatch visibility was extremely useful during testing.

Biggest Challenge: Dependency Management 🐳

One of the most valuable lessons today came from troubleshooting Python dependencies.

The Problem:

Libraries like:

Pillow

Often fail when packaged locally because:

Local machine OS differs from AWS Lambda runtime
Binary dependencies break

The Solution:

I used Docker to build Lambda Layers.

Why Docker Helped:

Matched AWS Linux environment
Prevented runtime compatibility issues
Ensured consistent builds

Key Lesson:

👉 “It works on my machine” is not enough in cloud engineering.

Environment consistency matters.

This was one of the most important practical takeaways so far.

Key Learnings from Day 18 💡

Today’s project taught me:

✔️ How event-driven serverless systems work
✔️ How S3 triggers Lambda in real workflows
✔️ Why least privilege IAM matters
✔️ How Terraform simplifies complex deployments
✔️ Why dependency packaging is critical

This was one of the clearest examples yet of Terraform enabling repeatable, scalable cloud systems.

Why Terraform Made This Easier

Without Terraform, setting this up manually would involve:

Creating buckets
Uploading Lambda code
Configuring IAM roles
Setting triggers
Setting logs

This would be:

❌ Time-consuming
❌ Error-prone
❌ Hard to reproduce

Terraform made the entire setup:

✅ Repeatable
✅ Version-controlled
✅ Easy to destroy / recreate

This is exactly why IaC is such a game changer.

What’s Next? 🔥

Future improvements I’d like to explore:

Adding image watermarking
Using Step Functions for complex workflows
Integrating API Gateway for direct uploads
Setting lifecycle rules on processed images
Adding alerts for failed Lambda runs

Excited to keep building.

Final Thoughts

Day 18 was one of the most practical and rewarding milestones in this challenge so far.

This project showed me how Terraform can be used not just to provision resources, but to automate intelligent business workflows.

Serverless architectures are efficient, scalable, and increasingly relevant in modern cloud systems — and building one from scratch was a huge confidence boost.

If you’re learning Terraform, I highly recommend exploring serverless projects like this. They teach infrastructure, automation, debugging, and cloud design all at once.

Have you built event-driven serverless workflows with Terraform? I’d love to hear your experiences.

Mastering Blue-Green Deployments with Terraform & AWS Elastic Beanstalk

Atul Vishwakarma — Tue, 14 Apr 2026 10:33:51 +0000

Achieving Zero-Downtime Deployments with Infrastructure as Code 🚀

As part of my 30 Days of AWS Terraform challenge, Day 17 was one of the most exciting milestones so far: implementing a Blue-Green Deployment strategy using Terraform and AWS Elastic Beanstalk.

This project took my Terraform journey beyond provisioning infrastructure into the world of release engineering, deployment safety, and production reliability.

Until now, I had focused on building resources and automating cloud workflows. But today’s challenge taught me something even more valuable:

👉 How to deploy application updates without downtime and with instant rollback capability.

Why Blue-Green Deployment Matters

In production systems, every deployment introduces risk.

Common challenges with traditional deployments:

Temporary downtime during updates
Risk of failed releases affecting users
Difficult rollbacks
Limited testing in production-like conditions

This is where Blue-Green Deployment becomes a game-changer.

What is Blue-Green Deployment?

Blue-Green is a deployment strategy where you maintain two identical production environments:

🔵 Blue Environment

Current live production version
Serving real users

🟢 Green Environment

New version deployment
Used for testing and validation

Once Green is validated:

👉 Traffic is switched from Blue to Green instantly.

If something breaks:

👉 Rollback is as simple as switching traffic back.

Project Goal 🎯

The goal for today’s project was to:

Deploy two versions of an application (v1 and v2)
Host them in separate Elastic Beanstalk environments
Manage infrastructure using Terraform
Perform a zero-downtime DNS cutover

This project was a perfect mix of:

Terraform provisioning
AWS application hosting
Deployment strategy
Risk mitigation

Architecture Overview 🏗️

Key AWS Components Used

1. Amazon S3 for Application Packaging 📦

I first packaged:

Application version v1.0
Application version v2.0

As ZIP archives.

These were uploaded to an S3 bucket, which served as the source for Elastic Beanstalk deployments.

Why This Matters

S3 acts as:

Central artifact storage
Version-controlled release source
Secure deployment package repository

2. AWS Elastic Beanstalk Environments 🌱

Terraform was used to provision:

Elastic Beanstalk Application
Blue environment (live)
Green environment (candidate release)

Elastic Beanstalk simplified:

EC2 provisioning
Load balancing
Auto scaling
Health monitoring

This allowed me to focus more on deployment logic than server management.

3. IAM Roles & Instance Profiles 🔐

To make the environments work securely, Terraform also provisioned:

EC2 IAM roles
Instance profiles
Required permissions

This ensured:

S3 access for artifacts
Elastic Beanstalk environment operations

A good reminder that security is always part of automation.

Terraform in Action ⚙️

This project helped me apply Terraform in a real deployment workflow.

Key Terraform Concepts Used:

✔️ Resource provisioning for Elastic Beanstalk
✔️ S3 object uploads for artifacts
✔️ IAM role automation
✔️ Environment lifecycle management
✔️ Infrastructure consistency between Blue & Green

Biggest Benefit

Because both environments were managed as code:

Configuration stayed consistent
Drift was minimized
Deployment became repeatable

This is exactly why IaC matters.

The Best Part: Zero-Downtime DNS Swap 🔄

The highlight of today’s project was performing the actual traffic cutover.

Once Green was deployed and tested:

I validated the new version
Confirmed health checks
Swapped the CNAME / DNS routing

Result:

✅ Users experienced zero downtime
✅ Traffic shifted instantly
✅ No service interruption

This was one of the most satisfying hands-on moments in this challenge so far.

Key Learnings from Day 17 💡

1. Downtime Can Be Avoided

Production deployments don’t have to impact users.

Blue-Green strategies provide:

Safer releases
Better customer experience
Lower operational risk

2. Rollbacks Should Be Simple

One of the strongest lessons:

👉 Good systems are not just deployable — they are recoverable.

If Green fails:

Switch traffic back to Blue
Restore production quickly

This kind of safety net is essential in real systems.

3. Testing Matters

Green environments allow:

Smoke tests
Health checks
Validation before release

This reduces bad deployments significantly.

Real-World Extensions 🔥

To make this production-grade, future improvements could include:

Route 53 weighted routing
Automated DNS cutover via Terraform / CLI
CI/CD integration with GitHub Actions / Jenkins
Canary deployments
Monitoring with CloudWatch

These are areas I’m excited to explore next.

Final Thoughts

Day 17 was a major mindset shift.

This project showed me that DevOps is not just about creating infrastructure — it’s about designing systems that are:

Reliable
Recoverable
Safe to change

Blue-Green deployment is one of the clearest examples of how cloud engineering directly improves user experience.

If you’re learning Terraform or AWS, I highly recommend trying a project like this. It teaches both technical depth and deployment discipline.