DEV Community

Cover image for Building an AWS Microservices Infrastructure with Terraform — First Industry-like approach
Destiny Obs
Destiny Obs

Posted on

Building an AWS Microservices Infrastructure with Terraform — First Industry-like approach

#terraform #devops #aws #newbie

It all started with food.
Yeah… food.

I was minding my business, doing my daily scroll through food content (don’t judge), when a friend dropped a Twitter link.
“See what I’m working on,” he said.
Spoiler alert: it was not jollof rice.

It was a Task definition thread on setting up an AWS infrastructure using Terraform. I had never done it before. But hey, curiosity (and maybe hunger) kicked in. So I tried it.

Why This Article Tastes Different

Let’s be honest — I’m not your go-to “10 years in the trenches” DevOps guy. I’m just someone who’s curious, hungry (literally and metaphorically), and absolutely allergic to boring tech content.

This is my first clean, modular, industry-grade Infrastructure as Code setup.
Yes, something might break.
Yes, you’ll probably fix something when you try it yourself.
And yes, I’m totally okay with that.

So grab a snack and vibe with me as we walk through:

  • How I planned the whole setup (inspired by that wild Twitter link)
  • Why Terraform modules became my besties
  • The microservices app I didn’t containerize — but my friend did
  • My “trust me, it works” folder structure

Project Overview

Here’s what I built: an AWS infrastructure to host a microservices-based app made up of:

  • A React frontend
  • Two APIs — one in Node.js, one in Go
  • A PostgreSQL database
  • A Python load generator to keep things spicy

All deployed on ECS Fargate, orchestrated by the real MVP: Terraform.

Architecture Flow

  • Public Subnets – for the ALB to accept traffic like a bouncer at an exclusive party.
  • Private Subnets – where ECS and RDS live in peace, away from public scrutiny.
  • Secrets Manager – because plain-text passwords are a crime.
  • CloudWatch – watching so I don’t have to.
  • ALB → ECS → RDS – like a well-oiled relay team.

Image description

Folder Structure 

.
├── env/
│   └── dev/
│       ├── backend.tf         # S3 state backend
│       ├── main.tf            # Main config
│       ├── outputs.tf         # What Terraform spits out
│       ├── providers.tf       # AWS provider config
│       ├── terraform.tfvars   # Your environment’s juicy secrets
│       └── variables.tf       # Input variables
├── modules/
│   ├── alb/                   # Load balancer setup
│   ├── ecr/                   # ECR repos
│   ├── ecs/                   # ECS cluster
│   ├── monitoring/            # CloudWatch logs + alarms
│   ├── rds/                   # PostgreSQL config
│   ├── secrets_manager/       # For hiding your sins (passwords)
│   ├── security_groups/       # Fine-grained access control
│   └── vpc/                   # VPC + networking
├── .gitignore
└── README.md
Enter fullscreen mode Exit fullscreen mode

Modular. Reusable. Tidy. Just like the way I my kitchen looks.

Modules Breakdown

VPC

  • Sets up networking: public + private subnets, NAT, IGW, route tables.
  • Outputs subnet IDs for other modules to use.

Security Groups

  • ALB talks to the world.
  • ECS talks to ALB.
  • RDS? Strictly ECS only. No loose lips.

ECR

  • One repo per service: frontend, node API, go API, load generator.
  • Push your Docker images here. Clean, secure, efficient.

RDS

  • PostgreSQL DB in a private subnet.
  • Encrypted. Multi-AZ. Passwords stored in Secrets Manager.
  • Fancy, right?

Secrets Manager

  • All environment variables + credentials stored here as a single JSON blob.
  • Because leaking secrets is so 2015.

ECS

  • Fargate cluster — because I don’t babysit EC2s.
  • (Tasks and services coming soon.)

ALB

  • In public subnet, routing traffic to ECS via target groups.
  • Listener rules? We’ll wire those up later.

Monitoring

  • CloudWatch log groups + a CPU alarm.
  • (Still cooking memory + RDS alarms.)

How the App Connects (from Docker Compose to ECS)

My friend had the app in Docker Compose.
I mapped each service to a future ECS task:

  • Client (React) → ALB → ECS Task
  • Node API & Go API → ALB paths → ECS
  • PostgreSQL already containerized, now replaced with managed RDS
  • Load Generator → ECS task to simulate real-world chaos

All environment variables are injected from Secrets Manager.
Container images are stored in ECR, pulled at deploy.

Deployment Steps

  1. Clone the repo 
git clone https://github.com/DestinyObs/terraform-ecs.git
cd terraform-ecs/env/dev
Enter fullscreen mode Exit fullscreen mode
  1. Initialize Terraform 
terraform init
Enter fullscreen mode Exit fullscreen mode
  1. Preview your infrastructure 
terraform plan
Enter fullscreen mode Exit fullscreen mode
  1. Apply the config 
terraform apply
Enter fullscreen mode Exit fullscreen mode
  1. Destroy it when you’re done playing God 
terraform destroy
Enter fullscreen mode Exit fullscreen mode

What’s Next (on My DevOps Menu)

  • Add ECS task definitions + services
  • ALB listener rules for routing by path (/api, /client, etc.)
  • Memory + DB monitoring
  • SSM integration for better secret hygiene
  • Full CI/CD pipeline for image builds + infra deploys

Final Thoughts

This project was:

  • curiosity
  • hunger
  • pure Terraform joy

If you’re just starting with cloud infra, this is a fun sandbox.
If you’re an experienced engineer, fork it and show me what I missed.

The goal isn’t perfection. The goal is progress — and maybe a snack break along the way.

Try the code or roast my setup here:
GitHub: DestinyObs/terraform-ecs

I’m DestinyObs
iDeploy | iSecure | iSustain | iLikeFood

Top comments (0)