DEV Community: KithupaG

Building a Production Grade AWS Infrastructure Project (Part 3): IAM Terraform

KithupaG — Mon, 20 Jul 2026 10:10:23 +0000

Building a Production Grade AWS Infrastructure Part 3: IAM Roles

In my previous post, I containerized the frontend and backend using Docker Compose with Postgres. Now that the app runs locally, it's time to start building the AWS infrastructure.

But where do you even begin? AWS has a deny-by-default permissions model, meaning nothing works until you explicitly give it permission. That makes IAM the logical starting point, before you can spin up a VPC, launch an ECS task, or write to S3, you need roles and policies in place, otherwise all your services will fail from the start.

The IAM Mindset: Roles, not Users

When I first started learning IAM, my mind automatically went to users, creating someone a username, password, access keys. I had to remind myself: this is infrastructure, not a team. In production, your services don't log in. They assume roles.

The difference is important:

IAM User : person with a password and/or access keys
IAM Role : a set of permissions that a service can assume temporarily

The two are backed by the same core concept: an IAM identity. It's just that roles are designed for machines and services, not people. Since our app runs on AWS infrastructure, roles are the way to go.

trust_policy_permissions: what?

When you look at the role block in Terraform, the first thing you'll see is the trust policy:

trust_policy_permissions = {
    TrustRoleAndServiceToAssume = {
      actions = [
        "sts:AssumeRole",
        "sts:TagSession",
      ]
      principals = [{
        type = "Service"
        identifiers = [
          "ecs-tasks.amazonaws.com",
        ]
      }]
    }
  }

TrustRoleAndServiceToAssume is just a friendly label given by the terraform module, it could be labeled anything. Like TrustThisServicePlease. The important part is the actions:

sts:AssumeRole : This tells AWS to issue a temporary security credential (valid for about an hour by default) to the service specified in the principals block. It's how AWS allows one identity to borrow another identity's permissions temporarily.
sts:TagSession : More of an auditing tool. This attaches metadata tags to that session so you can trace which service, container, or user requested the credentials. Very useful for debugging later.

Now here's something beginners often get wrong — the principals block. I initially had:

type = "AWS" → changed to "Service"
identifiers = ["ec2.amazonaws.com"] → changed to "ecs-tasks.amazonaws.com"

Use type = "Service" when the entity that needs the role is a service like EC2, ECS, or Lambda. Use type = "AWS" when it's a user or account.

I also removed the condition block:

condition = [{
    test     = "StringEquals"
    variable = "sts:ExternalId"
    values   = ["some-secret-id"]
}]

This block is specifically for external services, for example, if a third-party SaaS needs to access your AWS account. The ExternalId ensures that even if someone steals your role ARN, they can't use it without that secret ID. Since our application runs on ECS, which is an internal service, we don't need this.

Why two roles? The ECS role architecture

A common beginner mistake is to create a single role for everything. But if you're using ECS, there is a much better split:

1. Task Execution Role (`app-execution-role`)

This role belongs to the ECS agent, it's the AWS service itself. Its job is to bridge the gap between the container specification and the services ECS needs to start your app.

Policies attached:

policies = {
    getSecretsPostgres = "arn:aws:iam::aws:policy/AWSSecretsManagerClientReadOnlyAccess"
    pullImageFromECS   = "arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy"
}

AmazonECSTaskExecutionRolePolicy : Allows the ECS agent to pull images from ECR and write logs to CloudWatch
AWSSecretsManagerClientReadOnlyAccess : Allows the ECS agent to read secrets from Secrets Manager

Think of this as the valet parking guy: he parks your car (the container) in the right spot, but he doesn't drive it anywhere.

2. Task Role (`app-task-role`)

This role belongs to the application itself, the code running inside the container. If your Node.js app needs to read an S3 bucket, send an email via SES, or access DynamoDB, this is where you attach those permissions.

But here's the thing: right now, our application only talks to PostgreSQL via standard network drivers. It doesn't need IAM permissions.

policies = {

}

Notice the empty policies block. I intentionally left it that way.

If I didn't set a separate task role, the application would default to the host's IAM role (the EC2 instance's role), which could accidentally grant broad permissions. By explicitly setting an empty task role, we lock down the container: even if someone exploits a vulnerability in the Node application, there are zero permissions to leverage.

Later, when the app grows and it needs to upload user avatars to S3, or send welcome emails via SES, I'll attach the appropriate policies.

How to decide on policies

Settling on the right policies requires two questions:

1. What AWS service does my app touch?

My app is a Node.js application backed by PostgreSQL:

Compute: ECS with Fargate (needs to pull images from ECR)
Database: Amazon RDS (connection goes through the network, not IAM)
Security: AWS Secrets Manager (to retrieve db credentials)

2. What actions does my app need for each service?

Pulling images from ECR? Read-only -> AmazonEC2ContainerRegistryReadOnly
Writing logs? Write -> CloudWatchAgentServerPolicy

The golden rule: the fewer permissions, the better. Start with nothing and add as you go. AWS provides plenty of managed policies, but if none fits perfectly, you can always write a custom one.

Custom policies with data sources

If you ever need a policy that doesn't exist in AWS's managed offerings, Terraform provides the aws_iam_policy_document data source:

data "aws_iam_policy_document" "example" {
  statement {
    actions   = [""]
    resources = [""]
    effect    = "Allow"
  }
}

You can then reference module.iam_policy.arn or build inline policies. The key thing is: write exactly what your app needs, nothing more.

The outputs file: exposing your roles

Once the IAM roles are defined, your other modules can't see them without an outputs file. Think of it as an export statement.

output "execution_role_arn" {
  description = "The ARN of the ECS execution role"
  value       = module.iam_role.arn
}

output "task_role_arn" {
  description = "The ARN of the ECS task role"
  value       = module.iam_role_task.arn
}

.arn tells Terraform to fetch the resource name string generated by AWS once the role is created
The outputs will be referenced in the ECS module later
Never output plaintext secrets like database passwords. If you absolutely must, use sensitive = true

Now our VPC module (which I'll cover in the next post) and the ECS module will be able to link to these IAM role ARNs programmatically, without copy-pasting random string IDs.

What I learnt

IAM roles are for services, IAM users are for people — two sides of the same coin
ECS needs two distinct roles: one for the ECS agent and one for the app
Empty task policies are a feature: they keep the app in the most secure posture possible
Export via outputs, never hardcode ARNs

Next up: The VPC module

With IAM out of the way, the next logical step is setting up the VPC. All the networking, subnets, route tables, internet gateways. Needs to be defined before we can plug in RDS, ALB, or ECS.

If you're learning IAM roles for the first time like me, what AWS service tripped you up the most? Drop a comment below!

Want to follow along? The full code is available here:

KithupaG / aws-production-infra

A complete AWS themed production infrastructure

CloudNotes - Production Grade AWS Infrastructure

A full-stack Note Taker application designed as a sandbox for building production-grade AWS infrastructure with Terraform. The app is fully containerized with Docker and orchestrated with Docker Compose, ready to be deployed across a high-availability AWS architecture.

Architecture

                        ┌──────────────────────────────────┐
                        │         AWS Cloud (Target)       │
                        │                                  │
                        │   Route53 ─── CloudFront ─── S3  │
                        │                    │             │
                        │                    ▼             │
                        │        ┌─────── ALB ───────┐     │
                        │        │                   │     │
                        │   ┌────▼────┐        ┌────▼────┐ │
                        │   │ EC2 ASG │        │ EC2 ASG │ │
                        │   │(Backend)│        │(Backend)│ │
                        │   └────┬────┘        └────┬────┘ │
                        │        │                  │      │
                        │        └────────┬─────────┘      │
                        │                 ▼                │
                        │           ┌──── RDS ────┐        │
                        │           │  PostgreSQL │        │
                        │           └─────────────┘        │
                        └──────────────────────────────────┘
Local (Docker Compose):
┌──────────┐    ┌────────────┐    ┌──────────────┐
│ Frontend │───▶│  Backend  │───▶│  PostgreSQL  │
│ (Nginx)  │    │ (Node.js)  │    │ (15-alpine)  │
│  :3000   │    │  :5001     │    │   :5432

…

View on GitHub

Building a Production Grade AWS Infrastructure Project (Part 2): Containerization

KithupaG — Fri, 10 Jul 2026 16:53:22 +0000

The Pivot: Why Containerization First?

After careful thought and consideration, I realized that building the VPC right away wasn't the most efficient path. Instead, I went back to the drawing board and decided to containerize the application first. This ensures that the environment is consistent before we start orchestrating it in the cloud.

In my previous post, I introduced the project, the file structure, and the "why" behind this build. In this post, I'll be walking through the containerization process.

The Strategy

Since the frontend and backend are two distinct applications with different tech stacks, I wrote two separate Dockerfiles that align with the project structure.

1. The Backend (Node.js)

For the backend, the setup is relatively straightforward.

FROM node:22-slim

WORKDIR /usr/src/backend/

COPY package.json package-lock.json ./

RUN npm ci --omit=dev

COPY . .

EXPOSE 5000

CMD ["node", "server.js"]

Breaking it down:

Base Image: I used node:22-slim instead of the common alpine version. This is because the backend uses sqlite3, which requires dependencies like gcc, g++, and python to compile. The slim image handles these better than the ultra-minimal Alpine.
Dependencies: I used npm ci --omit=dev. This ignores development dependencies, keeping the production image as light as possible.
Execution: We expose port 5000 and run the app using node server.js.

2. The Frontend (React + Nginx)

The frontend utilizes a multi-stage build. This allows us to build the app in a Node environment and then serve the static files using Nginx.

# Stage 1: Build
FROM node:22-alpine AS builder
WORKDIR /usr/src/frontend/
COPY package.json package-lock.json ./
RUN npm ci
COPY . .
RUN npm run build

# Stage 2: Serve
FROM nginx:alpine AS server
COPY --from=builder /usr/src/frontend/dist/ /usr/share/nginx/html
COPY nginx.conf /etc/nginx/conf.d/default.conf
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]

Why this approach?

Lightweight: Nginx is significantly faster and smaller than keeping a Node server running just to serve static React files.
Reverse Proxy: Since React is client-side, it doesn't "know" how to route API requests to a backend in a different container. We use Nginx to handle these routes via a custom nginx.conf.
CI/CD Friendly: Building inside Docker means your CI/CD runner (like GitHub Actions) doesn't need to have Node installed. Everything happens inside the container.

Orchestrating with Docker Compose

To manage the frontend, backend, and database simultaneously, I used Docker Compose.

name: note-taker
services:
  backend:
    build: ./src/backend
    restart: unless-stopped
    ports:
      - "5001:5000"
    environment:
      NODE_ENV: production
      PGHOST: database
      PGUSER: postgres
      PGPASSWORD: ${POSTGRES_PASSWORD}
      PGDATABASE: notetaker
      PGPORT: 5432
      PGSSL: false
    depends_on:
      database:
        condition: service_healthy
    networks:
      - app-network

  database:
    image: postgres:15-alpine
    container_name: production_db
    environment:
      POSTGRES_DB: notetaker
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    ports:
      - "5432:5432"
    volumes:
      - db-data:/var/lib/postgresql/data
    networks:
      - app-network
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres -d notetaker"]
      interval: 5s
      timeout: 3s
      retries: 5

  frontend:
    build: ./src/frontend
    ports:
      - 3000:80
    depends_on:
      - backend
    networks:
      - app-network

volumes:
  db-data:

networks:
  app-network:

Key Features of this Compose file:

Health Checks: The backend waits for the database to be "healthy" (using pg_isready) before starting.
Port Mapping: I mapped the backend to 5001 and the frontend to 3000 to avoid conflicts with other local services like XAMPP or Docker Desktop defaults.
Networking: All services share app-network, allowing them to communicate via service names (e.g., the backend connects to database:5432).

Nginx Configuration

Without a custom nginx config, the frontend container would serve static files but have no idea where to send API requests. The browser makes requests to /api/notes and /health, but nginx doesn't know these belong to the backend.

server {
    listen 80;

    location /api/ {
        proxy_pass http://backend:5000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    location /health {
        proxy_pass http://backend:5000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    location / {
        root /usr/share/nginx/html;
        index index.html;
        try_files $uri $uri/ /index.html;
    }
}

The key pieces:

proxy_pass forwards /api/ and /health requests to the backend container using its service name (backend:5000). Docker's built-in DNS resolves the name across containers on the same network.
try_files handles React's client-side routing. Without it, refreshing on a route like /notes would return a 404 because nginx would look for a file that doesn't exist. This directive falls back to index.html and lets React handle the route.

Troubleshooting: The SSL Headache

While running the backend, I hit a snag. The logs showed a connection failure:

{"level":"error","message":"Failed to connect to PostgreSQL database: The server does not support SSL connections"}

The Cause

In my application code, I had logic that forced SSL if the environment was set to production:

ssl: process.env.PGSSL === 'true' || process.env.NODE_ENV === 'production'

Since the Docker Compose environment was set to NODE_ENV: production, the app was refusing any non-SSL connection from the Postgres container.

The Fix

I updated the logic in db.js to be more granular. This allows me to explicitly toggle SSL off via environment variables even in production-mode containers:

ssl: process.env.PGSSL === 'true' ? { rejectUnauthorized: false }
  : process.env.PGSSL === 'false' ? false
  : process.env.NODE_ENV === 'production' ? { rejectUnauthorized: false }
  : false

By setting PGSSL: false in the Docker Compose file, the connection was finally successful.

What's Next?

Now that the application is fully containerized and running locally, the next step is to setup the IAM roles through a terraform script.

Have you ever run into issues where "Production" environment flags caused local Docker testing to fail? How do you handle your SSL logic in dev vs. prod? Let me know in the comments!

If you want to follow along on this project, here is my github repo

KithupaG / aws-production-infra

A complete AWS themed production infrastructure

aws-production-infra

View on GitHub

Building a Production Grade AWS Infrastructure Project (Part 1)

KithupaG — Wed, 20 May 2026 15:07:03 +0000

I'm 16, self-taught, and currently studying for my AWS Solutions Architect Associate certification. Alongside the course, I'm building a production-grade AWS infrastructure from scrach and documenting the entire journey here

Why?

Certs alone don't prove you can build anything. I want something real to show for it, So writing infrastruction that reflects how things are done in production and not just dwelling inside tutorial hell. Writing about it publicly keeps me accountable.

What is my stack?

Cloud: AWS
Infrastructure as Code: Terraform (I decided to keep it modular with seperate dev and prod environments)
CI/CD : Github Actions
Containerization: Docker + Trivy (for container scanning)
Application: A minimal PERN stack notes app

Heres what my folder structure looks like

aws-production-infra/ ├── modules/ # reusable Terraform modules │ ├── vpc/ │ │ ├── main.tf │ │ ├── variables.tf │ │ ├── outputs.tf │ │ └── README.md │ ├── ec2-asg/ │ │ ├── main.tf │ │ ├── variables.tf │ │ └── outputs.tf │ ├── alb/ │ ├── rds/ │ ├── s3-cdn/ │ ├── iam/ │ ├── security/ │ └── monitoring/ ├── environments/ │ ├── dev/ │ │ ├── main.tf │ │ ├── variables.tf │ │ ├── terraform.tfvars │ │ └── backend.tf │ └── prod/ ├── app/ │ ├── Dockerfile │ └── src/ ├── .github/ │ └── workflows/ │ ├── terraform-plan.yml │ └── docker-build.yml ├── docs/ │ ├── architecture.svg │ └── cost-estimate.md ├── scripts/ │ └── destroy-expensive.sh ├── .gitignore └── README.md

They key decision I did here is seperating the modules/ folder from environments/. Both environments call the same modules but with different variable values. Dev runs cheaper, single AZ resources purely for developing purposes while Prod runs Multi-AZ, larger instances in a more contained and secure setting.

What I've done so far

The folder structure is set up and the application code is in the repo. I vibe-coded the entire PERN app to save time, and honestly the infrastructure is what its all about.

My build order is

- Write all the terraform infrastructure first.
- Write the Dockerfile and get Trivy scanning running in CI
- Wire everything together with the GitHub actions deployment pipeline

Next post will cover building the VPC modules (building subnets, route tables, NAT gateway, and flow logs)

Repo is here if you want to follow along: https://github.com/KithupaG/aws-production-infra

Building a Simple Server Monitoring Script in My Homelab

KithupaG — Wed, 27 Aug 2025 16:47:01 +0000

*Why monitoring matters *

Monitoring matters because it provides a shared feedback loop, necessary visibility in the system metrics, performance, security, it also enables rapid issue detection, and continous improvement

See my code in my github here:- https://github.com/KithupaG/Homelab/blob/main/monitoring/server-stats.sh

How I built it

I used functions to house the processes, adhering to the laws of writing code, inside those functions I housed the shell commands such as top, free, df, ps etc to fetch the data and used awk to tabularize the data.

Demo output.

Future plan
Add logging to a file → server_stats.log.
Output as JSON so it integrates with Prometheus/ELK.
Connect to Grafana and make dashboards.

DEV Community: KithupaG

Building a Production Grade AWS Infrastructure Project (Part 3): IAM Terraform

Building a Production Grade AWS Infrastructure Part 3: IAM Roles

The IAM Mindset: Roles, not Users

trust_policy_permissions: what?

Why two roles? The ECS role architecture

1. Task Execution Role (app-execution-role)

2. Task Role (app-task-role)

How to decide on policies

Custom policies with data sources

The outputs file: exposing your roles

What I learnt

Next up: The VPC module

KithupaG / aws-production-infra

A complete AWS themed production infrastructure

CloudNotes - Production Grade AWS Infrastructure

Architecture

Building a Production Grade AWS Infrastructure Project (Part 2): Containerization

The Pivot: Why Containerization First?

The Strategy

1. The Backend (Node.js)

2. The Frontend (React + Nginx)

Orchestrating with Docker Compose

Nginx Configuration

Troubleshooting: The SSL Headache

The Cause

The Fix

What's Next?

KithupaG / aws-production-infra

A complete AWS themed production infrastructure

aws-production-infra

Building a Production Grade AWS Infrastructure Project (Part 1)

Building a Simple Server Monitoring Script in My Homelab

1. Task Execution Role (`app-execution-role`)

2. Task Role (`app-task-role`)