DEV Community: Aakash Choudhary

I accidentally deployed into PRODUCTION

Aakash Choudhary — Fri, 10 Apr 2026 04:57:44 +0000

Oops. I pulled a classic "test in production" maneuver... except it wasn’t supposed to be a test.

I’ve been quietly hacking away on a side project. Last week, during a late-night dev session, my tired brain accidentally pushed our raw, internal build straight to the live domain.

Before I could even fix it, a handful of you eagle-eyed folks somehow found it. My tiny setup was definitely not ready for the sudden traffic. If you caught the "accidental launch" and got hit with some spicy downtime or dropped connections—my bad! Honestly, I'm just amazed you spotted it so fast.

So, since the cat is officially out of the bag... what exactly broke my tiny server? 👀

Enter: sketchmyinfra.com

As a DevOps engineer, I hate dragging, dropping, and trying to perfectly align little boxes just to make an architecture diagram.

So, I'm building a lightweight tool that lets DevOps engineers, Cloud Architects, and Developers generate clean, up-to-date architecture diagrams directly from plain text.

Since a few of you already peeked behind the curtain, I decided to stop hiding and just officially open up the Live Demo. 🚀

🛠️ Where things stand right now:

It’s a Work in Progress: It's basically just me hacking this together, so expect a few bugs, rough edges, and missing pieces.
AWS First: Right now, I'm baking in full, integrated support for AWS infrastructure diagrams.
The Roadmap: Scaling the logic to support other cloud environments down the road.

Go ahead and give it a spin: sketchmyinfra.com

(Please try to break it gently this time, the servers are still small!)

I have some massive extensions for this in the works, but right now, your feedback is my fuel. Drop your thoughts, bug reports, or feature requests in the comments! 👇

Your Architecture Diagram Is Lying To You

Aakash Choudhary — Wed, 08 Apr 2026 09:02:33 +0000

The 30-Minute Lie

Last month, I spent 30 minutes in Lucidchart before a design review.

I dragged every box. Connected every arrow. Labeled every subnet, every security group, every load balancer. It looked beautiful.

By the next sprint, half of it was wrong.

A new service had been added. The auth flow had moved to a different VPC. Someone swapped Redis for DynamoDB. Nobody updated the diagram. Why would they? It lived in a tool nobody opened unless there was a meeting.

That diagram — the one I spent 30 minutes on — became a lie.

And here's the thing: this happens in every team I've worked with.

We Solved This Problem Everywhere Else

Think about what DevOps has automated in the last decade:

Infrastructure → Terraform, Pulumi, CloudFormation
Configuration → Ansible, Chef, Puppet
Deployments → ArgoCD, Flux, GitHub Actions
Monitoring → Prometheus rules as code, Grafana dashboards as JSON
Security policies → OPA, Sentinel
Documentation → Markdown in the repo, generated API docs

We version control everything. We code-review everything. We automate everything.

Except the one thing every engineer asks for in their first week:

"Do we have an architecture diagram?"

And the answer is always the same: "There's one in Confluence, but it's probably outdated."

Why Diagrams Resist Automation

I've thought about this a lot. Here's why diagrams have stayed manual while everything else moved to code:

1. The tools are built for designers, not engineers

Lucidchart, Draw.io, Miro — they optimize for visual fidelity and drag-and-drop. None of them treat diagrams as artifacts that should live next to code.

2. PlantUML and Mermaid exist, but they have a learning curve

Yes, you can write diagrams in code today. But the syntax is unfamiliar, the AWS/GCP icon libraries are clunky, and most engineers give up after their first attempt.

3. There's no source of truth

Your Terraform describes what exists. Your diagram describes what someone thought existed three months ago. They drift, and there's no reconciliation.

4. Diagrams die in PR review

You can't review a .png in a pull request. You can't diff two versions of a Lucidchart export. So diagrams stay outside the review process — and outside, they rot.

What Would "Diagrams as Code" Actually Look Like?

If we applied the same principles to diagrams that we apply to infrastructure, here's what changes:

Before	After
Open Lucidchart	Type a description
Drag boxes for 30 minutes	Generate in 5 seconds
Export to PNG	Commit the source to git
Forget to update	Diff in pull requests
One source of truth in someone's head	One source of truth in the repo

The diagram becomes a build artifact, not a manual task.

You describe your system in plain English. A tool turns that description into a clean, accurate diagram. The description lives in your repo. It gets reviewed in PRs. When the system changes, the description changes with it.

The diagram stops being a lie.

What I'm Building

This is the problem I'm trying to solve with SketchMyInfra.

The idea is simple: type what you're building, get an accurate architecture diagram in seconds. No drag-and-drop. No icon libraries to learn. No more 30-minute Lucidchart sessions before design reviews.

I'm building it in public — backend is in progress, frontend waitlist is live. If this resonates with you, I'd love to hear:

Have you experienced the diagram-rot problem? How does your team deal with it today?
What would make a tool like this actually useful to you in your workflow?
What's the worst outdated diagram you've ever inherited? (We've all got one.)

Drop your thoughts in the comments. And if you want to follow along or join the beta when it ships, you can sign up at sketchmyinfra.com.

I'll be writing about the architecture, the AI prompt engineering, and the deployment as I build. Follow along if you're into build-in-public stories.

[Boost]

Aakash Choudhary — Wed, 28 Jan 2026 18:50:22 +0000

GitHub Actions Has a Cleanup Problem — So I Built a Tool

Aakash Choudhary ・ Jan 28

#github #githubactions #cli #python

GitHub Actions Has a Cleanup Problem — So I Built a Tool

Aakash Choudhary — Wed, 28 Jan 2026 18:48:20 +0000

gh-prune 🧹

           __                                                                 
          /  |                                                                
  ______  $$ |____            ______    ______   __    __  _______    ______  
 /      \ $$      \  ______  /      \  /      \ /  |  /  |/       \  /      \ 
/$$$$$$  |$$$$$$$  |/      |/$$$$$$  |/$$$$$$  |$$ |  $$ |$$$$$$$  |/$$$$$$  |
$$ |  $$ |$$ |  $$ |$$$$$$/ $$ |  $$ |$$ |  $$/ $$ |  $$ |$$ |  $$ |$$    $$ |
$$ \__$$ |$$ |  $$ |        $$ |__$$ |$$ |      $$ \__$$ |$$ |  $$ |$$$$$$$$/ 
$$    $$ |$$ |  $$ |        $$    $$/ $$ |      $$    $$/ $$ |  $$ |$$       |
 $$$$$$$ |$$/   $$/         $$$$$$$/  $$/        $$$$$$/  $$/   $$/  $$$$$$$/ 
/  \__$$ |                  $$ |                                              
$$    $$/                   $$ |                                              
 $$$$$$/                    $$/

Keep your GitHub Actions clean. No more ghost workflows.

The Problem

If you use GitHub Actions regularly, you’ve probably noticed something odd:

You delete a workflow file (.github/workflows/old-flow.yml).
But the workflow still appears in the Actions tab.

Then comes the painful part:

Clicking through runs one by one.
Manually deleting history.
Realizing there’s no native bulk cleanup button.

As a DevOps engineer, this felt like unnecessary friction.

gh-prune solves this.

What is gh-prune?

gh-prune is a Python-based CLI tool built on top of the GitHub CLI. It is designed to inspect your repository, identify workflow runs, and help you bulk-delete old or unwanted history to properly clean up the Actions UI.

Key Features

🔍 Inspect GitHub Actions workflows.
📋 List workflow runs clearly.
🗑️ Bulk Delete old or unwanted runs.
✨ Clean the Actions UI of "deleted" workflows that persist in history.

Prerequisites

Because gh-prune leverages the official GitHub CLI for authentication and API interaction, you must have it installed and authenticated.

Install GitHub CLI: Installation Guide
Authenticate:
```
gh auth login
```

Installation

gh-prune is available on PyPI. You can install it via pip:

pip install gh-prune

How I Fixed the “CannotPullContainer” When Running .NET on ECS Fargate (And Made My Docker Image Multi-Platform with Buildx)

Aakash Choudhary — Thu, 07 Aug 2025 08:39:21 +0000

I deployed my .NET app to ECS Fargate, and Docker hit me with a platform error I didn't even know existed."

In this post, I am sharing my personal experience to debug this issue, a deep dive into docker dependency on the OS architectures, on which it's been running on , and a fix that every DevOps engineer should know.

Summary

If you've hit the error:

CannotPullContainerError: pull image manifest has been retried 7 time(s): image manifest. does not container description matching platform 'linux/amd64'

You're likely trying to run a Docker image built for one architecture (say, ARM64) on a platform that only supports another (like AMD64 or Windows). Here's how I ran into this error while deploying a .NET Core app on AWS Fargate, and how I fixed it by building a multi-platform Docker image.

The Night of Murder

I was casually deploying a .NET Core application to my ECS Fargate cluster, sipping coffee… when suddenly "CannotPullContainerError" struck.

"pull image manifest has been retried 7 time(s): image manifest does not contain descriptor matching platform 'linux/amd64'"

My first reaction?
"Well, this night just is going to be long"

Debugging the Beast

The clue was hiding in plain sight: 'linux/amd64' in the error message.

It was yelling at me:

"Hey buddy! I'm trying to run your image, but I can't find the right OS/kernel architecture to match it!"

That's when i focused on architecture point

The Dockerfile I Used

Here's the super basic Dockerfile I used to containerize the app:

FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /builds
COPY . ./
RUN dotnet publish -c Release -o output

FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS runtime
WORKDIR /app
# copy all the build files form the build stage
COPY --from=build /builds/output ./
EXPOSE 8190
ENTRYPOINT ["dotnet", "poc-dockerised-application.dll"]

Looks good, right? But here's where I messed up…

Platform ≠ Platform

The base image mcr.microsoft.com/dotnet/sdk:8.0 is not automatically built for all platforms.

In my case, I was running this on a Windows-based system or trying to deploy on a Fargate host expecting a specific architecture (linux/amd64), while the image may have been for arm64.

How to Check Docker Image Architectures

Use this command to inspect what platforms an image supports:

docker buildx imagetools inspect mcr.microsoft.com/dotnet/sdk:8.0

You'll see output listing supported platforms like:

linux/amd64
linux/arm64
windows/amd64

If your platform isn't listed. Well, tough luck. Docker won't run it.

But What Even Is a Platform in Docker?

A Docker "platform" is basically the combo of:

OS (like Linux or Windows) CPU architecture (like amd64 or arm64)

Think of it as the compatibility handshake between your image and the machine it runs on. If the handshake fails → boom, the error I got.

How to Check Your Own Machine's Architecture

Run:

uname -m

Example outputs:

x86_64 = amd64
aarch64 = arm64

The Fix: Build a Multi-Platform Docker Image

Once I realized the architecture mismatch, I knew I had two options:

Use an image that matches the platform (e.g., linux/amd64)
Or better yet, build a multi-platform image that works everywhere

Here's how I did it with Docker Buildx:

docker buildx build --platform linux/amd64,linux/arm64 -t my-dotnet-app:multi .

Now, your image is a universal soldier now!

Key Takeaways

Docker images are platform-specific unless explicitly built otherwise
ECS Fargate uses linux/amd64 unless you provision ARM-specific infra
Always check what platforms your base image supports
Use docker buildx to build for multiple platforms in one go
Architecture mismatches are sneaky - but easy to fix when you know where to look

Follow for More

If this helped or sparked an idea, drop a comment, or reach out!

Github Repo
My Portfolio
LinkedIn

Architecture of AWS Lambda

Aakash Choudhary — Wed, 16 Jul 2025 10:56:58 +0000

Note: If you’re not a medium member, CLICK H ERE

AWS Lambda = Serverless Functions-as-a-Service (FaaS)

You write the code → Lambda runs it when an event happens → You don’t touch a single server.

It’s called FaaS because you’re essentially running just your function as a service. No need to spin up EC2s or build any Infrastructure( like setting up networking and a new EC2 instance to deploy and run your application). Its like running a simple Python script that just works — zero setup.

You write code → Lambda executes it in response to an event → No need to provision or manage servers.

FaaS because this helps you to run your function as a service. You dont need to setup the infra to run you application( lets take simple python application as example for now).

Feature of Lambda

Trigger-based execution: Events (like S3 upload, API Gateway HTTP call etc.) trigger the function.
Stateless: No persistent local state — use services like S3, DynamoDB, RDS externally.
Auto-scaling: AWS handles concurrency and scaling behind the scenes ( comment for seperate medium article for in-depth analysis of concurrency)
Short-lived tasks: Max 15 mins per invocation.
Cost-efficient: Pay only for execution time and resources used.

Where Does Lambda Actually Run?

Internally, Lambda uses:

Firecracker MicroVMs (AWS-built VMM tech for secure, lightweight VMs) [ please drop in comment if you want a separate article about Firecracker MicroVM’s ]
Think of it as “a mini VM spun up in milliseconds” and isolated securely
It runs in the region where your Lambda is deployed
Backed by physical AWS EC2 infrastructure, but you don’t manage any of that

From Hardware to Lambda

Step 1: Physical Hardware

It all starts with physcial hardware Machine which are present at any data centre. So, AWS has racks of physical servers — metal beasts.

Step 2: Firecracker

Firecracker is AWS’s lightweight hypervisor (open-source, super fast).
It takes that big piece of metal and breaks it into microVMs (micro Virtual Machines), each isolated, secure, and fast-booting.
It’s not a full VM like EC2; it’s tiny, boots in ~125ms or less.

Step 3: Lambda Containers inside MicroVMs

Inside each microVM, your Lambda code runs in a container.
Container doestn’t mean a docker container. Its more like a container runtime environment with minimal OS.

Does Lambda Reuse Containers?

Yes! This might be possible.

AWS uses a concept called “container reuse” or warm containers:

If you invoke a Lambda function and then another invocation comes shortly after…then, AWS may route it to the same container (inside the same microVM)
But remember — it’s possible, not guaranteed. It depends on factors like traffic pattern, memory size, and whether AWS decides to keep that container warm.

The Classic Way to Access EC2 in Private Subnets (That Still Works Today)

Aakash Choudhary — Wed, 16 Jul 2025 10:50:40 +0000

You know that moment when you're trying to SSH into an EC2 in a private subnet, and AWS just silently judges you because... there's no public IP?

So what’s the fix? We sneak in through a side door( by setting up another EC2 instance in a public subnet ). This one does have a public IP, and acts like your inside man.
That’s the Bastion Host, the jump server of your VPC.

But here’s the thing:
Have you ever paused to wonder how this setup actually works? How one EC2 lets you magically hop into another( which even doen’t existed over the internet )?

In this article, I’ll walk you through how Bastion Hosts work, the architecture, the why, and the “ohhh” moment.

Let’s take a quick 3-minute trip into the jumpy world of Bastion Hosts.

What is Bastion Host?

A bastion host, also known as jump server, is like a middleman between you and the private EC2 instance. A bastion host is indirectly a EC2 instance( server ) to which you can SSH , and this jump server is allowed to connect with the EC2 in private subnet.

Summarizing, Bastion host is a server which acts as a link between the EC2 in private subnet and you.

Why do we need Bastion Host?

Lets say, I have an EC2 instance in public subnet. This have a public IP attached to it. To connect with this instance, i can easily SSH into the VM via its public IP. What if this EC2 is in private subnet and it don’t have any public IP associated to it.

At this point, we have two solutions, to proceed with:

Connect to EC2 in private subnet via Bastion Host
Connect to EC2 in private subnet via Session Manager( using VPC endpoint )

Architecture of Bastion host

Lets break down the architecture of Bastion host. A Bastion host generally contains an EC2 instance in public subnet and one EC2 instance in private subnet. The goal is to connect with EC2 instance in private subnet.

We SSH to EC2 in public subnet( via the public IP of the public EC2 instance ). This EC2 instance has allowed outbound to go inside the EC2 instance in private subnet( target instance ).

We can either configure port-forwarding from the public EC2 instance to private EC2 instance, or we can just run the SSH command in public EC2 instance mentioning the SSH command with private IP address of the private EC2 instance.

All the network inside the VPC is communicated between AWS services( like from subnet to NAT Gateway ) using the private IP address attached to the aws resources.

Working model of Bastion host

Lets have a scenario where i have a ec2 deployed in public subnet, and one ec2 in private subnet. I want to connect with EC2 in private subnet but there is no direct way to connect with it.

We will be going through a classic two-tier network architecture in AWS, where the Bastion Host acts as a controlled gateway to access EC2 instances residing in a private subnet.

Below are the components involved in the working of Bastion host:

User (Admin/Developer)

Initiates an SSH connection from a local machine.

Public Subnet

Contains an EC2 instance (the Bastion Host) with a public IP address.
Connected to the Internet Gateway, enabling SSH from the external world.

Private Subnet

Contains an EC2 instance with no public IP, isolated from direct internet access.
Cannot be accessed directly from the internet for security purposes.

Internet Gateway

Attached to the VPC.
Allows the public subnet’s EC2 (Bastion Host) to receive SSH traffic from the internet.

NAT Gateway (Optional)

Present in the public subnet.
Allows outbound internet access for the private EC2 (to download packages, reach external services, etc.)
Route to NAT Gateway from private subnet is only required if outbound internet access is needed.

How It All Connects

The user SSHs into the Bastion Host in the public subnet.
From the Bastion Host, the user SSHs into the private EC2 instance.
The private EC2 instance can remain isolated from the internet unless it needs internet access via the NAT Gateway.

Security Group Rules for public and private EC2

We need to have different configuration for the target server and the bastion host.

Security Group of Bastion Host:

Allows inbound SSH (port 22) only from trusted IPs (your local machine).

Security Group of Private EC2:

Allows inbound SSH only from the Bastion Host’s security group or private IP.
No Public IP for private EC2:
Ensures it cannot be reached directly from the internet.

Follow for More

If this helped or sparked an idea, drop a comment, a clap, or reach out!

How Does Networking Work in AWS?

Aakash Choudhary — Sat, 05 Jul 2025 10:34:33 +0000

There have been times when I tried downloading something inside my EC2 instance and kept hitting a “timeout”. No errors, just silence. I had no idea what was wrong. That’s when I realized, this wasn’t a software bug. It was a networking blind spot. I tried to debug this, and came across that many people stuck in this at some point.

Thats why, i thought to breakdown the architecture behind the networking of AWS in VPC. What are public and private subnet? How can an application in private subnet is able to access the internet! How two different VPC communciate with each other?

Stick with me for 4min to explore about this below.

What is VPC?

A VPC (Virtual Private Cloud) is like your own private club on AWS. You host or deploy your applications here — and the best part? It’s isolated from everyone else’s setup!
Let’s say I’m deploying a Node.js app in my VPC, and you my friend, are doing the same in your VPC. We can both run the same app, but with completely different network configurations, IP ranges, and access rules.

How Do You Connect to Resources in a VPC?

Now wait!! If this is a “private” cloud, then how do we actually access it?

Great question. Like any private club, you need a valid identity to get in. Yes, we need to be validated to access this VPC resources. That’s where IAM (Identity and Access Management) comes in.

Why IAM?

Yes, why does IAM comes into networking part?

Let’s break it down:

I’m on my local laptop, trying to connect to an EC2 instance running in a VPC (say, Vx). AWS exposes public API endpoints for most services, like EC2, RDS, SSM, etc.

When I use the AWS CLI to interact with these services, I send a request to AWS’s public APIs. But AWS won’t just let anyone in.

So, I authenticate using my IAM Access Key and Secret Key.

This verifies:

Who I am
What I can access
Which actions I’m allowed to

Now we know the use of IAM. Its used to validate who can access what, and in what cloud( VPC, and even breaking down to who can perform what operation on what service)

Okay, So We Know VPC and why IAM is used… But

What’s a Subnet?

Now, there may be cases where i have a frontend application on my private cloud, which is static. I want to show it to the world!! right?

What i need to do is to keep this in some place, where its accessible to world. For the world to access it, it need to have some internet connectivity.

Internet Gateway

IGW is a component which is used to connect to internet( consider this as the internet provider for this cloud).

Whoooo!! What if i have a database, and i dont want to expose it to the world?

Yess, great question! So, now, to break this down, we have two types of Subnet.

Public Subnet
Private Subnet

Public Subnet Example

Let’s say I’ve got a frontend app that’s static (like a React site). I want the world to access it.

To do that, I’ll place it in a public subnet, a subnet that’s connected to an Internet Gateway (IGW). Think of IGW as your WiFi provider, giving internet access to your subnet.

If it’s connected to IGW via route tables, then that subnet can send/receive traffic from the internet.

Private Subnet Example

Now, let’s say I have a database. I don’t want people from the outside world to peek into it. So, I put it in a private subnet.

Private subnets have no direct route to an Internet Gateway. So they’re hidden, kind of like the secret basement of your VPC club.

But… sometimes, your DB or EC2 in a private subnet needs to initiate outbound connections (say, to fetch updates or call an API).

So what do they do?

They ask their friendly neighbor (a **_public subnet_**) for help, specifically via a **_NAT Gateway_**.

What is NAT Gateway?

The NAT Gateway lives in a public subnet and helps private subnet resources reach out to the internet, but only outbound.

Think of it like a door that lets you exit, but no one from the internet can enter.

Inbound vs Outbound

Outbound: You can call the internet (like fetching data from an API)
Inbound: The internet can reach you (this is blocked for private subnets unless you do something special)

Breaking Down Subnet Architecture

A VPC is assigned a CIDR block, like 172.31.0.0/16.
This CIDR block defines the total range of IPs you can use in that network
Subnets are chunks of this CIDR block. Like slicing a pizza into small slices so that each friend gets one!
Resources like EC2 instances are deployed into subnets and assigned an IP.

How Does a Subnet Know Where to Send Traffic?

That’s where Route Tables come in.

A Route Table defines rules like:

_Destination_→ 0.0.0.0/0

_Target_ → igw-044a2729e12072922 (this means: “send internet traffic to the Internet Gateway”)

_Destination_ → 172.31.0.0/16

_Target_ → local (this means: “for internal traffic within the VPC”)

Each subnet is associated with a route table. The routes tell the traffic, If you’re going to the internet, take this road/route.

So What Did We Just Cover?

VPC: Your private slice of the AWS cloud
Subnet: Smaller rooms inside your VPC (public or private)
Internet Gateway: The official internet provider for your VPC
NAT Gateway: Middleman that helps private subnets talk to the internet
Route Tables: Route for the traffic

Follow for More

If this helped or sparked an idea, drop a comment, a clap, or reach out!

Github Repo
My Portfolio
LinkedIn

Thank you for being a part of the community

Before you go:

Be sure to clap and follow the writer ️👏️️
Follow us: X | LinkedIn | YouTube | Newsletter | Podcast | Twitch
Start your own free AI-powered blog on Differ 🚀
For more content, visit plainenglish.io + stackademic.com

How to Build a Scalable Multi-Region Terraform Repo with Modules

Aakash Choudhary — Thu, 26 Jun 2025 04:53:43 +0000

Have you ever faced a situation where you needed to deploy identical infrastructure resources across multiple regions in a cloud provider like AWS or Azure?

The best solution to this is multi-region Terraform setups. In this blog, we'll walk through how to structure a Terraform repository to handle resources like S3 buckets, IAM roles, etc., across two or more regions, with reusability, scalability, and simplicity.

What we want?

We'll create a Terraform repository template where:

Infrastructure can be replicated across multiple regions.
The module logic is centralized and reusable.
Region-specific customizations are managed cleanly.

We'll walk through an example of provisioning an S3 bucket in two AWS regions: us-west-1 and us-west-2.

Folder Structure

Here's the directory layout we'll be working with:

├── terraform/
│   ├── backend/
│   │   ├── us-west-1/
│   │   │   └── backend.tfvars
│   │   └── us-west-2/
│   │       └── backend.tfvars
│   ├── modules/
│   │   └── s3/
│   │       ├── main.tf
│   │       ├── variables.tf
│   │       └── output.tf
│   └── regions/
│       ├── us-west-1/
│       │   ├── main.tf
│       │   ├── variables.tf
│       │   ├── provider.tf
│       │   └── output.tf
│       └── us-west-2/
│           ├── main.tf
│           ├── variables.tf
│           ├── provider.tf
│           └── output.tf
├── .gitignore
└── README.md

How to create re-usable terraform repository?

Let’s say we need to create an S3 bucket. Instead of writing this code for each region, we’ll write it once in a reusable module.

So in the modules/s3/variables.tf, the resource looks like this:

resource "aws_s3_bucket" "bucket" {
  bucket        = var.bucket_name
  tags          = var.tags
  force_destroy = true
}

This module expects two input values, so we define them in modules/s3/variables.tf:

variable "bucket_name" {
  type        = string
  description = "Name for the S3 bucket"
}

variable "tags" {
  type        = map(string)
  description = "Tags for the resources to track cost for resources deployed"
}

Conclusion: This module doesn’t contain any hardcoded values, which makes it reusable.

Using the Module per Region

Now, let’s use this module for each region without making changes to the module itself.

In regions/us-west-1/main.tf, we use the module like this:

module "s3" {
  source      = "../../modules/s3"
  bucket_name = var.bucket_name
  tags        = var.tags
}

Where do bucket_name and tags come from?

This module expects two input values, so we define them in modules/s3/variables.tf:

We define them in that region’s variables.tf:

variable "root_var_bucket_name" {
  type        = string
  description = "Name for the S3 bucket"
}

variable "root_var_tags" {
  type        = map(string)
  description = "Tags for the resources to track cost for resources deployed"
}

You can define the actual values in your automation pipeline or in a .tfvars file.

For backend setup, the file backend/us-west-1/backend.tfvars could look like:

bucket         = "my-terraform-state"
key            = "us-west-1/terraform.tfstate"
region         = "us-west-1"
dynamodb_table = "terraform-lock-table"

What to do if i need to make any configuration change, but to any particular region?

Now imagine that you need to change the S3 bucket name — but only for us-west-1.

You don't need to touch the module or duplicate the code. Just go to:

terraform/regions/us-west-1/variables.tf

And update the value for bucket_name. When you run Terraform for that specific region, the module will automatically pick up the new value.

cd terraform/regions/us-west-1
terraform init -backend-config=../../backend/us-west-1/backend.tfvars
terraform plan -var="bucket_name=my-west-bucket" -var="tags={Environment=\"dev\"}"
terraform apply

It doesn’t affect the setup in us-west-2 at all

Best Practices

Avoid hardcoding values inside modules — always pass variables.
Separate state per region to avoid conflicts.
Use identical variable names across regions to standardize configuration.
Centralize shared logic but isolate region-specific values.
Add CI/CD automation for managing multiple environments smoothly.

Summary

This structure makes it easy to:

Replicate infrastructure across regions
Reuse modules without code duplication
Make changes to individual regions independently

The same approach works not only for S3 buckets, but also IAM roles, DynamoDB, VPCs, and even across clouds like Azure or GCP.

Need more examples or want the full working repo on GitHub? Let me know in the comments!

What’s My IP — Build a Serverless API Using Lambda + API Gateway (with Terraform)

Aakash Choudhary — Wed, 25 Jun 2025 10:49:00 +0000

Want to integrate AWS Lambda to an API endpoint? This project will walk you through the exact steps needed to attach Lambda with API Gateway to returning the caller’s public IP using a simple Python Lambda.

What We’ll Build

In this article, we have a lightweight Python function running inside AWS Lambda. The function gets triggered when a user hits an API Gateway (HTTP API) URL. Once called, it grabs the user’s public IP and current timestamp and sends that back in the response.

Example of URL provided by API Gateway:

curl https://<your-api>.execute-api.<region>.amazonaws.com/<stage>/

Output on browser upon hitting URL:

{
  "timestamp": "2025-06-20T17:45:12.841111",
  "ip_address": "103.xx.x.xx"
}

What’s happening behind the scenes ( Overview of request)

As a USER, you will be hitting a URL( that is provided by API Gateway ). Upon hitting the URL, the request will flow from API Gateway to AWS Lambda, which will invoke the python application.

You (the user) hit the URL provided by API Gateway.
API Gateway forwards the request to Lambda.
Lambda runs the Python code and sends back a response with your IP and the current timestamp.

The python application will take “event” metadata from the API Gateway and use that to return the sourceIP. The timestamp is returned using the datetime() function.

Python Application

Here’s the Python function we’re using


import json
import datetime

def lambda_handler(event, context):
    # Fetch the IP from the API Gateway event
    ip_address = event['requestContext']['http']['sourceIp']

    # Get the current timestamp
    timestamp = datetime.datetime.utcnow().isoformat()
    response = {
            'timestamp': timestamp,
            'ip_address': ip_address
        }
        return {
            'statusCode': 200,
            'headers': { 'Content-Type': 'application/json' },
            'body': json.dumps(response)
        }

“event” Metadata from API Gateway

I believe the only component worth exploring here is:

ip_address = event['requestContext']['http']['sourceIp']

“event” is returned by API Gateway and contain some metadata that can be consumed by Lambda. This include the sourceIP field as well, that we will be using to display output on hitting URL.

Metadata in the event context of API Gateway

{
  "requestContext": {
    "accountId": "123456789012",
    "apiId": "a1b2c3d4",
    "http": {
      "method": "GET",
      "path": "/",
      "protocol": "HTTP/1.1",
      "sourceIp": "203.0.113.42",
      "userAgent": "curl/7.64.1"
    },
    "requestId": "abc123",
    "routeKey": "GET /",
    "stage": "$default",
    "time": "20/Jun/2025:10:45:00 +0000",
    "timeEpoch": 1718877900000
  }
}

Why we don’t need any layer for this Python Lambda?

The packages that we are using ( json , datetime ), are part of Python’s standard library, and AWS Lambda already includes the entire standard library for whatever runtime we’re using (like python3.12, python3.11, etc.).

Tech Stack

Python 3.12
AWS Lambda
API Gateway (HTTP API)
Terraform
CloudWatch (for logging/debugging)

Project Structure

.
├── terraform/
│ ├── modules/
│ │ ├── iam/
│ │ │ ├── main.tf
│ │ │ └── outputs.tf
│ │ ├── lambda/
│ │ │ ├── main.tf
│ │ │ ├── variables.tf
│ │ │ └── outputs.tf
│ │ └── apigw/
│ │ ├── main.tf
│ │ ├── variables.tf
│ │ └── outputs.tf
│ ├── main.tf
│ ├── outputs.tf
│ └── provider.tf
├── app.py
├── .gitignore
└── README.md

CODE REPOSITORY ( follow the URL for Github Repository)

Follow the below github repository for the terraform code

https://github.com/ifaakash/whats-my-ip-lambda

Terraform Code Highlight

From terraform POV, we will need to create the components listed below:

`aws_lambda_function` → Lambda function configuration
`aws_apigatewayv2_api` → API for the end user
`aws_lambda_permission` → Ensure API GW have permission to invoke Lambda
`aws_apigatewayv2_integration` → Attach API GW with Lambda function
`aws_api_gatewayv2_route` → Define route for API GW to invoke Lambda
`aws_api_gatewayv2_stage` → Used to handle API GW in multi env( dev, stg, prod )
`aws_iam_role` and policy for Lambda execution

Why create the IAM Role?

Without IAM role, the lambda function will not be able to perform operation like writing logs to cloudwatch, read from S3 bucket etc. So, we need IAM role to allot permission to AWS Lambda.

# IAM Role for AWS Lambda to assume
resource "aws_iam_role" "lambda_exec_role" {
  name = "lambda_exec_role"
  assume_role_policy = jsonencode({
    Version = "2012-10-17",
    Statement = [{
      Action = "sts:AssumeRole",
      Effect = "Allow",
      Principal = {
        Service = "lambda.amazonaws.com"
      }
    }]
  })
}


# Required permission for AWS lambda to perform action on other resources
resource "aws_iam_policy" "permissions" {
  name        = "lambda_permissions"
  description = "Required IAM permission for AWS Lambda Execution"
  policy = jsonencode(
    {
      "Version" : "2012-10-17",
      "Statement" : [
        {
          "Effect" : "Allow",
          "Action" : [
            "logs:CreateLogGroup",
            "logs:CreateLogStream",
            "logs:PutLogEvents"
          ],
          "Resource" : "*"
        }
      ]
    }
  )
}

resource "aws_iam_role_policy_attachment" "lambda_policy_attachment" {
  role       = aws_iam_role.lambda_exec_role.name
  policy_arn = aws_iam_policy.permissions.arn
}

Permission for AWS Lambda

This will allow the API Gateway to invoke the lambda function, when the user hit the API URL.

resource "aws_lambda_permission" "allow_apigw" {
  statement_id  = "AllowAPIGatewayInvoke"
  action        = "lambda:InvokeFunction"
  principal     = "apigateway.amazonaws.com"
  function_name = var.lambda_name
}

Lambda function Configuration

This block defines the python application that need to be used by AWS Lambda and the HASH code for the application to detect changes to the ZIP file.

resource "aws_lambda_function" "lambda" {
  function_name    = var.function_name
  role             = var.lambda_exec_role_arn
  description      = var.description
  filename         = var.filename # <zip_file_name>
  runtime          = var.runtime_env
  package_type     = var.package_type
  handler          = var.handler # <python_file_name.lambda_function_name>
  source_code_hash = filebase64sha256(var.filename)
}

Deploying It

→ Initialize using terraform init

→ Plan the changes using terraform plan

→ Apply the changes using terraform apply

→ Grab the endpoint from API Gateway

output "api_url" {
  value = "${aws_apigatewayv2_api.http_api.api_endpoint}/${aws_apigatewayv2_stage.dev.name}/"
}

Test the API

curl https://<api-id>.execute-api.us-west-1.amazonaws.com/dev/

Make sure the route is GET /, not /dev or /ping unless explicitly defined.

Cleaning Up

To destroy all resources

terraform destroy

Follow for More

If this helped or sparked an idea, drop a comment, a clap, or reach out!

[Github Repo](https://github.com/ifaakash)
[My Portfolio](https://hey-its-aakash.lovable.app/)
[LinkedIn](https://www.linkedin.com/in/aakashch2/)

Manually created cloud Infrastructure?

Aakash Choudhary — Fri, 13 Jun 2025 19:28:42 +0000

I recently faced this scenario where there were a bunch of cloud resources built manually, with no version control or automation in place. Rebuilding everything from scratch wasn't an option. So, I used the feature of terraform import

Below is a medium article which I thought of sharing with the community, which focuses on:

--> When to use terraform import

--> A step-by-step walkthrough

--> How to regain control over wild infra

Check it out here

https://medium.com/@aakashc.dev/how-to-import-an-existing-cloud-infra-using-terraform-ff52a785a8f7

Please share your thought on this.