DEV Community: Atul Vishwakarma

Stop Hardcoding AWS Credentials: How to Manage Secrets Securely

Atul Vishwakarma — Fri, 10 Jul 2026 02:30:00 +0000

It is a cloud engineer's worst nightmare.

You finish a long coding session, type git push origin main, and go to sleep. You wake up the next morning to hundreds of automated emails from AWS and a billing dashboard showing a $5,000 charge.

What happened? You accidentally pushed your AWS Access Key and Secret Key to a public GitHub repository. Within seconds, automated bots scraped your keys and spun up dozens of expensive EC2 instances across the globe to mine cryptocurrency.

Today, we are going to make sure this never happens to you. Here is how to stop hardcoding your AWS credentials and manage your secrets securely.

The Bad Way: Hardcoding in Your App

When you are just learning how to use the AWS SDK (like boto3 for Python or the AWS SDK for Node.js), it is incredibly tempting to just paste your keys directly into your code so it works:

// ❌ NEVER DO THIS!
const AWS = require('aws-sdk');

const s3 = new AWS.S3({
    accessKeyId: "AKIAIOSFODNN7EXAMPLE",
    secretAccessKey: "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
});

If this code gets pushed to GitHub, your AWS account is completely compromised. We need to separate our code from our configuration.

The Good Way (Local Development): AWS CLI Profiles

Instead of putting credentials in your code, you should store them securely on your local machine using the AWS Command Line Interface (CLI).

If you have the AWS CLI installed, open your terminal and run:

aws configure

It will prompt you to enter your Access Key, Secret Key, default region (e.g., us-east-1), and output format.

Once you do this, AWS creates a hidden file on your machine. If you are developing on a Linux system (like Fedora) or macOS, this file lives at ~/.aws/credentials. On Windows, it is at C:\Users\YOUR_USERNAME\.aws\credentials.

Now, when you run your code, the AWS SDK will automatically look for this hidden file and use the credentials inside it. Your code becomes completely clean:

// ✅ THE SAFE WAY
const AWS = require('aws-sdk');

// The SDK automatically pulls from your ~/.aws/credentials file!
const s3 = new AWS.S3();

The Good Way (Pipelines & CI/CD): Environment Variables

If you are running your code inside a Docker container or a GitHub Actions pipeline, you can't manually run aws configure. Instead, you use Environment Variables.

AWS SDKs are programmed to automatically look for these specific variables:

AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY
AWS_DEFAULT_REGION

If you are working locally with a .env file, it should look like this:

AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
AWS_DEFAULT_REGION=us-east-1

Crucial Step: You must add .env to your .gitignore file. If you track your .env file in Git, you are right back to the nightmare scenario we talked about at the beginning!

The Ultimate Fix (Production): AWS Secrets Manager

The methods above are perfect for personal projects, local development, and simple CI/CD pipelines.

However, when you are dealing with production microservices at scale, managing dozens of .env files becomes a massive security liability. In a true production environment, the best practice is to migrate credential management to AWS Secrets Manager.

By using Secrets Manager, you eliminate hardcoded secrets entirely, automate key rotation, and establish SOC2-aligned auditability so you know exactly which microservice accessed which secret and when.

The Takeaway

Security in the cloud isn't just an afterthought; it is step zero. By utilizing aws configure locally and environment variables in your pipelines, you can push your code to GitHub with complete peace of mind.

(If you are using these secured credentials to write infrastructure code, be sure to bookmark my Ultimate Terraform Cheatsheet to speed up your workflow!)

If this security tip helped you out today, you can ☕ buy me a coffee here to support my work!

Infrastructure as Code 101: Provisioning an AWS EC2 Instance with Terraform

Atul Vishwakarma — Thu, 02 Jul 2026 12:30:00 +0000

If you are currently managing your AWS infrastructure by logging into the console, clicking through menus, checking boxes, and hitting "Create," you are practicing what DevOps engineers jokingly call "ClickOps."

While clicking around is fine for learning, it is a nightmare for production. Manual clicks are impossible to track, prone to human error, and incredibly slow to replicate. If your server goes down, you have to remember exactly which boxes you checked six months ago to rebuild it.

The solution is Infrastructure as Code (IaC).

Today, we are diving into Terraform, the industry standard for IaC. I am going to show you how to stop clicking and start coding by provisioning a basic Linux AWS EC2 instance using just a few lines of code.

What is Terraform?

Created by HashiCorp, Terraform is a tool that allows you to define both cloud and on-premise resources in human-readable configuration files. It uses a declarative language called HCL (HashiCorp Configuration Language).

"Declarative" means you just tell Terraform what you want (e.g., "I want one t2.micro EC2 instance"), and Terraform figures out how to communicate with AWS APIs to make it happen.

Prerequisites

Before we write our code, you need three things:

An AWS Account (the Free Tier is perfect).
The AWS CLI installed and configured on your machine with your IAM credentials (so Terraform has permission to talk to your account).
Terraform installed on your local machine.

Step 1: Define the Provider

Terraform can manage infrastructure on AWS, Azure, Google Cloud, and even GitHub! To tell Terraform we want to talk specifically to AWS, we need to configure a "Provider."

Create a new folder on your computer, open it in your terminal, and create a file called main.tf.

Add this code:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

# Configure the AWS Provider
provider "aws" {
  region = "us-east-1" # Change this to your preferred region
}

Step 2: Write the EC2 Resource Block

Now, we tell Terraform exactly what resource we want to build. Below your provider block in main.tf, add the following code:

resource "aws_instance" "my_first_server" {
  ami           = "ami-0c7217cdde317cfec" # Ubuntu 22.04 LTS in us-east-1
  instance_type = "t2.micro"

  tags = {
    Name = "AtulCodes-Terraform-Server"
  }
}

Breaking down the code:

resource: Tells Terraform we are creating a new piece of infrastructure.
"aws_instance": The specific type of resource (an EC2 instance).
"my_first_server": This is just a local name we use to reference this server within our Terraform code. AWS never sees this name.
ami: The Amazon Machine Image ID. Note: AMIs are region-specific! The one above is for Ubuntu in us-east-1. If you are in ap-south-1 (Mumbai), you will need to grab a different AMI ID from the AWS console.
instance_type: We are using t2.micro because it qualifies for the AWS Free Tier.
tags: This is how we actually name the server inside the AWS Console.

Step 3: The Core Terraform Workflow

Terraform relies on three magical commands to get your infrastructure into the cloud: init, plan, and apply.

1. Initialize the Directory

Open your terminal in your project folder and run:

terraform init

This command looks at your main.tf file, sees you want to use AWS, and downloads the necessary AWS plugins in the background.

2. Plan the Deployment

Next, we want to see what Terraform is going to do before it actually does it.

terraform plan

You will get a large output showing exactly what resources will be created. Look for the green + signs. At the bottom, it should say: Plan: 1 to add, 0 to change, 0 to destroy.

3. Apply the Code

If the plan looks good, it is time to deploy!

terraform apply

Terraform will show you the plan one more time and ask you to type yes to confirm. Type yes and hit enter. Within a few seconds, Terraform will communicate with AWS and spin up your server!

Step 4: Verify in the AWS Console

Don't just take my word for it. Log into your AWS Management Console, navigate to the EC2 Dashboard, and click on Instances.

You will see a brand-new server named AtulCodes-Terraform-Server sitting right there, in a "Running" state. You provisioned that without clicking a single button in the UI!

Step 5: Destroy the Evidence (Crucial!)

One of the best features of IaC is how easy it is to clean up. If you leave this server running, AWS might eventually charge you for it.

To tear down everything we just built, run:

terraform destroy

Type yes when prompted. Terraform will gracefully delete the EC2 instance it created.

The Takeaway

You have officially taken your first step into Infrastructure as Code. By writing your infrastructure as code, you can version control it in Git, review it in Pull Requests, and ensure your staging environments are exact replicas of your production environments.

Next week, I am dropping my Ultimate Terraform Cheatsheet! It will cover all the essential commands, state management, and variable syntax you need for your daily DevOps workflows. Make sure you hit the subscribe button so you don't miss it.

If this tutorial helped you deploy your first Terraform resource, you can ☕ buy me a coffee here to support my work!

TIL: How to Fix the "Port Already in Use" Error in Docker

Atul Vishwakarma — Tue, 30 Jun 2026 03:30:00 +0000

We have all been there. You just built a fresh Docker image, you confidently type your docker run command into the terminal, and BAM. You are hit with a massive wall of red text that looks something like this:

Error starting userland proxy: listen tcp4 0.0.0.0:3000: bind: address already in use.

This error (often referred to as EADDRINUSE) simply means that something else on your computer is already using the port you are trying to assign to your Docker container.

Today I Learned (TIL) the fastest way to find that rogue process and terminate it so you can get back to coding. Here is the two-step fix for Mac and Linux users.

Step 1: Find the Rogue Process

To find out exactly which application is hoarding your port, we will use the lsof (List Open Files) command.

Open your terminal and type this command, replacing 3000 with whatever port is giving you trouble:

lsof -i :3000

This will return a list of processes using that port. Look under the PID (Process ID) column. You need that number.

Step 2: Kill the Process

Now that we have the Process ID, we can force it to shut down using the kill command. Pass the -9 flag to ensure it terminates immediately, followed by the PID you found in Step 1:

kill -9 14235

That’s it! Your port is now free. You can run your docker run -p 3000:3000 my-app command again, and it will spin up perfectly.

Bonus: What if it's a "Ghost" Docker Container?

Sometimes, the port is being blocked because you started a Docker container earlier, forgot about it, and left it running in the background.

If lsof doesn't solve your problem, quickly check your active Docker containers:

docker ps

Find the container using your port, grab its Container ID, and stop it gracefully:

docker stop <CONTAINER_ID>

📚 Catch up on this Docker Series:

Part 1: How to Dockerize a Node.js App in 5 Easy Steps
Part 2: Automate Your Docker Builds with GitHub Actions

If this quick tip saved you some debugging time today, you can ☕ buy me a coffee here to support my work!

TerraGuard AI: Adding an AI Brain to Terraform Drift Detection — Design Decisions, Trade-offs, and Lessons Learned

Atul Vishwakarma — Mon, 29 Jun 2026 05:30:00 +0000

Repo: https://github.com/vatul16/TerraGuard-AI — full source, Terraform infra, drift detection engine, and CI/CD workflows.

When I finished TerraTier, the 3-tier AWS architecture project I wrote about last time, I wanted to build something that pushed in a different direction. TerraTier was about the infrastructure layer — networking, security boundaries, secrets management. This project is about the operational layer: what happens after the infrastructure is running, when someone inevitably makes a change outside of Terraform.

The result is TerraGuard AI — an event-driven drift detection system that catches manual AWS console changes, classifies their risk using an LLM, and routes context-rich alerts intelligently instead of just firing a generic notification every time a description field changes. A Node.js API on ECS Fargate, a PostgreSQL database on RDS, and an ALB are the infrastructure being monitored. GitHub Actions, Python, and Groq's API for Llama 3.3 are how the detection and analysis work.

This article is about the decisions behind why it works the way it does, and what I'd change.

The problem with standard drift detection

The textbook implementation of Terraform drift detection is: run terraform plan -detailed-exitcode on a cron job, check the exit code, send an alert if it's non-zero. This works, and it takes maybe 30 lines of shell script to implement. The problem isn't the detection — it's what happens to the humans on the other end of the alert.

In any environment where more than one person touches the AWS console, drift is nearly constant. Someone tags a security group directly in the console, or updates a description, or changes a retention period on a log group that wasn't in Terraform yet. Each of these fires the exact same alert as "port 22 opened to 0.0.0.0/0 on a production security group." After the third or fourth time the on-call engineer wakes up to an alert and finds a tag change, they start doing what humans do with noisy signals: they ignore them.

Alert fatigue is a well-documented problem in SRE literature, but most drift detection tooling solves it by giving you more configuration options — exception lists, ignore patterns, threshold tuning. That's fighting symptoms. The actual cause is that the alerting system has no concept of severity. It knows something changed; it doesn't know what that means.

The insight that shaped this project is that detection and classification are two separate problems, and they need different tools. Terraform is genuinely excellent at detection — it has the full resource schema, it talks directly to the AWS APIs, and its plan output is deterministic and reliable. It has no idea what a change means from a security or business perspective. That's a reasoning problem, and it's exactly what language models are good at.

So TerraGuard AI uses Terraform to detect drift, and an LLM to classify it. The two tools do the parts they're each actually suited for.

Decision 1: AI for classification, not detection

This distinction is worth dwelling on, because it's easy to imagine AI being used to find drift — some vector-similarity approach comparing current state to desired state, or something. That would be using AI to badly replicate something Terraform already does perfectly.

The LLM layer in this project only ever sees the parsed output of terraform plan. Drift is already confirmed by the time the AI gets involved. What the AI does is answer a different set of questions: Is this change a security risk or a configuration nuance? Should it be reverted or adopted into the Terraform codebase? What is the exact command someone should run to remediate it, right now, without having to look anything up?

The prompt asks Groq's Llama 3.3 to act as a Senior Cloud Security Engineer and return a structured JSON response with a risk level (CRITICAL / HIGH / MEDIUM / LOW / INFO), a score out of 10, an impact summary, a recommended action (REVERT / ADOPT / INVESTIGATE / MONITOR), and a concrete remediation command. The temperature is set to 0.1 — not 0, because zero-temperature responses can be oddly mechanical, but close enough to zero that the analysis is consistent and factual rather than creative.

{
  "risk_level": "CRITICAL",
  "risk_score": 9,
  "category": "Security",
  "summary": "Security group ingress rule added exposing SSH port 22 to all internet traffic.",
  "impact": "Any host on the internet can attempt SSH brute-force or exploitation against ECS tasks.",
  "action": "REVERT",
  "remediation": "terraform apply -target=aws_security_group.ecs_tasks",
  "reasoning": "Opening port 22 to 0.0.0.0/0 is a critical security misconfiguration..."
}

Based on that response, the routing is simple: CRITICAL or HIGH goes to Slack immediately, plus a GitHub Issue for the audit trail. MEDIUM, LOW, or INFO creates a GitHub Issue that goes into the backlog — no Slack notification, no on-call page.

The practical effect is that the Slack channel only gets messages that actually need a human to look at something now. The rest creates a self-organizing backlog of minor drift that can be handled during normal working hours. That's not a feature — it's the entire point.

Decision 2: Groq over AWS Bedrock

The obvious choice for an AWS-native project would be Amazon Bedrock. The LLM call would live inside the VPC, authentication would use the same IAM role the rest of the infrastructure uses, and there would be no external API dependency.

I chose Groq instead, for two reasons that turned out to matter more than I expected.

The first is speed. Groq's custom LPU hardware runs Llama 3.3 70B at a genuinely unusual pace — we're talking single-digit seconds for a complete risk analysis. Bedrock inference at a comparable model size is slower, and when drift detection runs in a GitHub Actions workflow with a 6-hour cron cadence, latency matters less than it would in a real-time system. But for local development and testing, where you're running the detector manually and waiting for output, the speed difference makes iteration significantly less frustrating.

The second reason is cost. Groq's free tier is 14,400 requests per day, which is more than enough for a drift detection workflow that runs every 6 hours and only calls the API when drift is actually found. Bedrock charges per-token with no free tier. For a personal portfolio project that also needs to pay for ECS, RDS, NAT Gateway, and an ALB, not paying for inference is a meaningful constraint.

The trade-off is the external dependency. The drift detector now requires an outbound HTTPS connection from the GitHub Actions runner to api.groq.com, and if Groq is down or rate-limiting, the analysis step fails. I handled this with a fallback in the Python script: if the Groq call fails or returns unparseable JSON, the detector falls back to a MEDIUM risk assessment with a manual review recommendation rather than crashing entirely. The drift is still logged and acted on; it just lacks the AI analysis.

Decision 3: GitHub Actions over Lambda

The architecturally "purer" approach to scheduled drift detection is a Lambda function triggered by EventBridge on a cron schedule, with an additional EventBridge rule listening to CloudTrail events for real-time detection when a console change happens. That's closer to the enterprise architecture in the project's original design.

I built it on GitHub Actions instead, and I think that was the right call for this stage.

The practical argument: GitHub Actions is free, already configured for the project, and doesn't require provisioning, IAM-scoping, or maintaining a separate compute resource. A Lambda function adds at least three more Terraform resources to manage, an ECR image or deployment package to maintain, and CloudWatch Logs to check when something goes wrong — all of which is real work that doesn't directly demonstrate anything new. The drift detection workflow in GitHub Actions does the same job with less infrastructure surface area and a simpler debugging story (Actions tab in GitHub, logs right there).

The conceptual argument: the drift detector is not a latency-sensitive workload. A 6-hour detection window is fine for a portfolio project, and even for many real production environments, catching a security group change within 6 hours is a meaningful improvement over catching it when someone manually reviews the AWS console. Real-time detection via CloudTrail + EventBridge is in the project roadmap, but it's a layer added on top of a working baseline, not a prerequisite.

Where this decision has a genuine cost: the GitHub Actions runner needs AWS credentials. That means AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY as repository secrets — long-lived credentials stored in GitHub, which is a less secure pattern than OIDC role assumption. The Terraform IAM code in the project already scaffolds the OIDC setup (aws_iam_openid_connect_provider, aws_iam_role with a GitHub OIDC trust policy), and migrating to keyless authentication is the highest-priority item on the roadmap. I built with access keys first to get the workflow working without debugging OIDC trust policies at the same time, which is a trade-off I'd make again in the same situation.

Decision 4: Minimal infrastructure being monitored

A reasonable design question for a drift detector is: what infrastructure should it monitor? You could make the case that the more complex the infrastructure, the more impressive the demo — VPCs with 20 resources, multiple environments, Auto Scaling Groups, the works.

I went the opposite direction. The monitored infrastructure is as simple as it can be while still being realistic: one ECS Fargate service, one RDS PostgreSQL database, one ALB. That's a pattern that appears in real production environments constantly — it's the architecture for a backend API behind a load balancer with persistent storage. Nothing exotic.

The reason for keeping it simple is that the interesting thing in this project is the drift detection and classification layer, not the infrastructure. A 40-resource VPC with multiple tiers and Auto Scaling Groups would take most of the explanation budget to describe, and would make the CI/CD and drift detection workflows harder to follow for someone reading the code. By keeping the infrastructure simple and well-understood, someone reading the repository can quickly get past "what does this infrastructure do" and get to "how does the drift detection actually work" — which is the part worth explaining.

Decision 5: Separating infrastructure and application deployment

The most practically important single line in the entire ecs.tf file is this:

lifecycle {
  ignore_changes = [task_definition]
}

Without this, terraform apply and the deploy-app.yml GitHub Actions workflow would fight each other. The deploy workflow updates the ECS task definition to use a new ECR image URI (tagged with the git SHA) every time new code is pushed to app/**. If Terraform's ECS service resource didn't ignore task definition changes, the next terraform apply — triggered by the drift detector or by a manual infra change — would overwrite the CI/CD-deployed image with whatever image URI is in the Terraform variables. Deploying a new version of the app would immediately cause "drift" against the Terraform-managed state.

The ignore_changes lifecycle setting tells Terraform: "I know this attribute might differ from what's in the config, and that's intentional — CI/CD owns it, not you." This is the standard pattern for separating infrastructure management (Terraform's job) from application deployment (CI/CD's job) on ECS, and it's one of those things that sounds obvious in retrospect but takes a debugging session to discover if you haven't seen it before.

The deploy workflow itself follows a pattern worth understanding: it doesn't just push an image and call aws ecs update-service --force-new-deployment. It downloads the current live task definition from AWS, replaces only the container image URI, registers the modified definition as a new revision, and then updates the service to use that revision. The reason for this sequence is that the task definition contains Secrets Manager ARNs, IAM role ARNs, environment variable sets, and health check configuration that are all managed by Terraform. Overwriting the entire task definition from a CI/CD workflow would blow away those fields. Downloading the live definition and patching only the image preserves everything else.

Decision 6: Secrets Manager with ECS secrets references, not environment variables

The Node.js application gets its database connection details through a combination of plain environment variables and a secrets block in the ECS task definition.

Non-sensitive values — DB_HOST, DB_PORT, DB_NAME, DB_USER, NODE_ENV, PORT — are passed as plain environment variables. They're not sensitive: knowing the RDS hostname doesn't help an attacker get into the database.

The password is different. The ECS secrets block references the Secrets Manager secret by ARN, and at container startup, the ECS agent fetches the value, injects it as DB_PASSWORD in the container's environment, and never writes it anywhere that shows up in the task definition JSON, CloudWatch logs, or the AWS console. The only evidence it existed is the ARN reference.

secrets = [
  {
    name      = "DB_PASSWORD"
    valueFrom = aws_secretsmanager_secret.db_password.arn
  }
]

This also required a specific IAM policy attached to the ECS execution role (not the task role — the agent that starts containers, not the container itself):

Action   = ["secretsmanager:GetSecretValue"]
Resource = aws_secretsmanager_secret.db_password.arn

The scoping matters. The policy grants access to exactly one secret ARN, not "Resource": "*". If an attacker found a way to escalate privileges from inside the container to the execution role, they could read one specific secret with a known ARN, not any secret in the account. That's a meaningful reduction in blast radius for a one-line change.

A race condition I hit and what it taught me

When I added the Node.js app port (3000) to the Terraform configuration — replacing the placeholder 80 that was there from the initial setup — running terraform apply produced an error I hadn't seen before:

Error: deleting ELBv2 Target Group: ResourceInUse: Target group is currently in use by a listener or a rule

What happened: changing the port on an ALB target group forces replacement (Terraform creates a new target group, then tries to delete the old one). But the ALB listener still referenced the old target group when Terraform tried to delete it. The listener update and the target group deletion were running in the wrong order — or more precisely, in parallel, and the deletion raced against the listener update and lost.

The fix was simply running terraform apply a second time. The first apply created the new target group and partially updated the listener, but the listener change hadn't completed by the time the old target group deletion ran. The second apply found the listener already pointing to the new target group and successfully deleted the old one.

I mention this because it's the kind of error that's alarming-looking and turns out to be completely benign — and knowing that pattern ("Terraform apply failed with ResourceInUse, run it again") is one of those things that takes a long time to learn from documentation and about five seconds to learn from experience. If you hit it: apply again.

The deeper lesson is about Terraform's dependency graph. Terraform builds an explicit dependency graph from the depends_on and implicit references in your configuration, and parallelizes everything it can within that graph. When you're modifying a resource that has something depending on it and you're replacing the resource rather than updating it in-place, the order of operations for the replacement can be non-obvious. Looking at the terraform plan output more carefully — specifically the -/+ indicators for "destroy and create replacement" — before applying would have flagged this in advance.

What I'd build next

The most significant gap in the current design is real-time detection. Running terraform plan every 6 hours means there's a window of up to 6 hours between a manual console change and the drift detection alert. For most configuration changes that's probably fine. For a security group rule opening port 22 to the internet, it's not.

The architecture for closing that gap exists: an EventBridge rule that listens to CloudTrail events for specific API calls (AuthorizeSecurityGroupIngress, ModifyDBInstance, AttachRolePolicy, and similar high-risk mutations), triggering a Lambda function that runs the plan-and-classify pipeline on demand, within seconds of the change. That's the enterprise-grade pattern that the project's original design was based on, and it's what I'd add in v2.

OIDC authentication for GitHub Actions is the other immediate priority. Storing AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY as repository secrets is functional but carries unnecessary risk — those credentials persist until they're rotated, and rotating them requires remembering they exist. The OIDC setup in iam.tf is already scaffolded; it's a workflow change and a secret deletion away from being the default.

A drift history store is something I've sketched but not built. Right now, every drift detection run is stateless — the result goes to Slack or GitHub Issues, and that's the end of it. If you wanted to answer "how often does our infrastructure drift, in which direction, and is it getting better or worse over time?", there's nowhere to look. A DynamoDB table storing detection results per run, with a simple dashboard, would turn TerraGuard AI from a reactive alerting tool into something with genuine observability over infrastructure compliance trends.

Closing thoughts

The most useful framing I found for this project is that it's not an AI project with some infrastructure bolted on, and it's not an infrastructure project with some Python bolted on. It's an operations automation project that happens to use AI for the part where you'd otherwise need a human to make a judgment call.

That framing matters because it determines what you actually have to understand to build it well. The Groq integration is a dozen lines of Python — the interesting engineering is in understanding when to call it, with what inputs, and what to do with the output, which requires thinking about the infrastructure, the CI/CD pipeline, the IAM model, and the alerting routing as a system. None of those are complicated individually. The interesting work is making them compose.

The full source is at https://github.com/vatul16/terraguard-ai — Terraform, Python detector, GitHub Actions workflows, and the Node.js app. I'm actively looking for Cloud/DevOps Engineer roles as I transition from full-stack development, and I'd genuinely enjoy talking through any part of this with someone who has questions about a specific decision. You can find me on LinkedIn.

Previous project: TerraTier — Production-grade 3-tier AWS architecture with Terraform, Auto Scaling Groups, two ALBs, four subnet tiers, and SSM Session Manager.

Automate Your Docker Builds with GitHub Actions

Atul Vishwakarma — Thu, 25 Jun 2026 12:30:00 +0000

Over the last two weeks, we solved two massive DevOps problems. First, we stopped deploying manually by building a CI/CD pipeline with GitHub Actions. Then, we solved the "it works on my machine" problem by containerizing a Node.js app with Docker.

Today, we are going to combine these two superpowers.

Running docker build manually on your laptop every time you change a line of code is tedious. Instead, we are going to configure GitHub Actions to automatically build your Docker image and push it to Docker Hub the second you push your code to the main branch.

Let's automate it.

Prerequisites

A free Docker Hub account.
A basic Node.js application with a Dockerfile (If you don't have one, follow my 5-step Docker tutorial here).
A GitHub repository with an active Actions workflow (Learn how to set one up in 10 minutes here).

Step 1: Create a Docker Hub Access Token

To let GitHub securely push images to your Docker Hub account, we need to give it a "password" in the form of an Access Token.

Log in to Docker Hub.
Click your profile picture in the top right and select Account Settings.
Click on Personal access tokens then Generate new token.
Name it github-actions-token, give it "Read & Write" permissions, and click Generate.
Copy this token immediately (you won’t be able to see it again).

Step 2: Add Your Secrets to GitHub

Now, we need to hand that token over to GitHub safely. Never hardcode passwords in your code!

Go to your repository on GitHub.
Click the Settings tab at the top.
On the left sidebar, scroll down to Secrets and variables and click Actions.
Click the green New repository secret button.

Create two distinct secrets:

Name: DOCKER_USERNAME | Secret: Your actual Docker Hub username.
Name: DOCKER_PASSWORD | Secret: The Access Token you copied in Step 1.

Step 3: Update Your GitHub Actions Workflow

Open up the .github/workflows/ci.yml file we created a couple of weeks ago. We are going to add a new job to our pipeline.

Replace your existing file contents with this updated YAML code:

name: Node.js CI/CD and Docker Build

on:
  push:
    branches: [ "main" ]

jobs:
  build-and-push-docker-image:
    runs-on: ubuntu-latest

    steps:
    # Step A: Check out the repository code
    - name: Checkout code
      uses: actions/checkout@v3

    # Step B: Log in to Docker Hub using our secure secrets
    - name: Log in to Docker Hub
      uses: docker/login-action@v2
      with:
        username: ${{ secrets.DOCKER_USERNAME }}
        password: ${{ secrets.DOCKER_PASSWORD }}

    # Step C: Build the Docker image and push it to Docker Hub
    - name: Build and push
      uses: docker/build-push-action@v4
      with:
        context: .
        push: true
        # Replace 'yourusername' with your actual Docker Hub username
        tags: yourusername/my-node-app:latest

Make sure to change yourusername on the very last line to your actual Docker Hub username!

Step 4: Push and Watch the Automation

Save your file, commit the changes, and push it up to GitHub.

git add .github/workflows/ci.yml
git commit -m "feat: add docker build and push automation"
git push origin main

Head over to the Actions tab in your GitHub repository. You will see your new workflow spinning up. GitHub is now renting a tiny Ubuntu server, checking out your code, logging into Docker Hub, building your image based on your Dockerfile, and pushing the final product to the cloud.

Once you get the green checkmark, go check your Docker Hub profile. Your brand-new image will be sitting right there, ready to be pulled by any server in the world.

The Takeaway

You have just built a professional-grade continuous delivery pipeline.

From now on, all you have to do is write your code and type git push. The robots handle the rest. This is the exact workflow used by top tech companies, and you just implemented it for free.

Next week, we are going to look at a quick debugging trick: how to fix the dreaded "Port Already in Use" error when working with Docker locally.

If you are enjoying this DevOps series, you can ☕ buy me a coffee here to support my work.

How to Dockerize a Node.js App in 5 Easy Steps

Atul Vishwakarma — Tue, 23 Jun 2026 12:30:00 +0000

"But it works on my machine!" If you are a developer, you have likely said this exact phrase. Your code runs perfectly on your laptop, but the moment you hand it to a coworker or try to deploy it to a production server, it crashes. The Node version is wrong, a dependency is missing, or the environment variables are mismatched.

This is exactly the problem Docker solves.

Docker allows you to package your application and all of its dependencies into a single, standardized unit. Today, I am going to show you how to containerize a simple Node.js application in 5 easy steps so it runs perfectly anywhere, every single time.

Before we write the code, let's clear up the biggest point of confusion for beginners.

The Core Concept: Image vs. Container

People often use these terms interchangeably, but they are completely different things:

The Docker Image: This is the recipe. It is a static, read-only file that contains your source code, libraries, dependencies, and tools. An image does not "run."
The Docker Container: This is the cake. It is the running, active instance of your Docker Image. You can start, stop, and delete a container.

You build an Image once, and you can spin up a hundred Containers from it.

Prerequisites

Docker Desktop installed on your machine.
A basic understanding of the terminal.
Node.js installed locally (just for our initial setup).

Step 1: Create a Simple Node.js App

We need something to containerize. Let's build a dead-simple Express server. Open your terminal, create a new folder, and initialize a project:

mkdir my-docker-app
cd my-docker-app
npm init -y
npm install express

Next, create a file named server.js and paste in this code:

const express = require('express');
const app = express();
const PORT = 3000;

app.get('/', (req, res) => {
  res.send('Hello from inside a Docker Container! 🐳');
});

app.listen(PORT, () => {
  console.log(`Server is running on port ${PORT}`);
});

Finally, open your package.json file and add a start script:

"scripts": {
  "start": "node server.js"
}

Step 2: Write the Dockerfile

The Dockerfile is a text document that contains all the commands needed to assemble your Image. In the root of your project folder, create a new file named exactly Dockerfile (no file extension).

Add the following instructions:

# 1. Specify the base image
FROM node:18-alpine

# 2. Set the working directory inside the container
WORKDIR /usr/src/app

# 3. Copy package.json and package-lock.json first
COPY package*.json ./

# 4. Install dependencies
RUN npm install

# 5. Copy the rest of your application code
COPY . .

# 6. Expose the port your app runs on
EXPOSE 3000

# 7. Define the command to run your app
CMD ["npm", "start"]

Why do we copy the package.json file before the rest of the code? Docker builds images in layers and caches them. If you change a single line in server.js, Docker doesn't need to re-install all your npm packages. It uses the cached layer for the dependencies, making your builds incredibly fast.

Step 3: Add a .dockerignore File

You wouldn't push your node_modules folder to GitHub, and you shouldn't copy it into your Docker image either. Your container should install its own clean dependencies.

Create a file named .dockerignore in your root directory:

node_modules
npm-debug.log
.git

Step 4: Build the Docker Image

Now it is time to bake the recipe. Open your terminal in the root of your project and run this command:

docker build -t my-node-app .

The -t flag "tags" your image with a readable name (my-node-app).
The . at the very end tells Docker to look for the Dockerfile in the current directory. Do not forget the period!

Step 5: Run the Docker Container

Your image is built. Now, let's bring it to life by spinning up a container.

docker run -p 3000:3000 -d my-node-app

The -p 3000:3000 flag maps port 3000 on your physical laptop to port 3000 inside the isolated container.
The -d flag runs the container in "detached" mode so it runs in the background, keeping your terminal usable.

Open your web browser and navigate to http://localhost:3000.

The Takeaway

Congratulations! You just built and ran your first Dockerized application.

Because the environment is bundled directly into the image, you could send this exact my-node-app image to a colleague running Windows, a friend on a Mac, or a Linux server on AWS, and it will run flawlessly. No configuration required.

Next week, we are going to take this a step further and combine it with the CI/CD pipeline we built last time. I will show you how to automatically build this Docker image using GitHub Actions every time you push code.

Make sure to subscribe to the blog so you don't miss it!

If this tutorial helped you finally understand Docker, you can ☕ buy me a coffee here to support my work!

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