DEV Community: KithupaG

Building a Production Grade AWS Infrastructure Project (Part 5): RDS

KithupaG — Fri, 24 Jul 2026 14:57:36 +0000

Continuing the Build

In my previous post, I set up the security group module that acts as the network firewall for everything in the VPC. With networking and permissions sorted, the next logical piece is the database.

The architecture plan is coming together:

VPC → IAM → Security Groups → RDS → ALB → EC2 ASG → S3+CDN → Monitoring → CI/CD

The backend needs a database, and RDS is the managed choice. It's relatively self-contained once it has a subnet group and security group reference, both of which we now have.

Why RDS Now?

You might wonder why not ALB or EC2 first. The dependency chain is straightforward: RDS needs a VPC (for subnets) and a security group (for network access). Both are done. The ALB needs the VPC and SG too, but the ASG also needs the ALB target group to attach to. RDS is the leaf node in the dependency tree, nothing else depends on it being ready first, so it unblocks the database layer early.

The Module Structure

I created a dedicated modules/rds directory. The module interface is intentionally minimal:

variable "security_group" {}
variable "subnet_ids" {}

That's it. Two inputs, the security group ID (wrapped in a list because AWS expects a list) and the private subnet IDs for the DB subnet group.

Configuring the Database Instance

First, the basics: identifier, engine, and storage.

identifier     = "postgres-db-dev"
db_name        = "notetaker"
engine         = "postgres"
engine_version = "16.3"
allocated_storage = 20

Pin the minor version. I learned this the hard way in other projects — if you don't pin 16.3, Terraform will pick up 16.4 or 16.5 on a fresh apply, and minor version upgrades can introduce subtle behavior changes. In production, you want explicit control.

username = "postgres"
port     = 5432

Standard PostgreSQL defaults. The username postgres is the default superuser, in production you'd create a dedicated application user with limited privileges, but for this project the default is fine.

Parameter Groups: The "Advanced Settings" Nobody Talks About

By default, AWS launches RDS with stock configuration. Parameter groups let you tune the database engine behavior. The community module I'm using (terraform-aws-modules/rds/aws) defaults to MySQL parameters, so I had to swap them out.

Original (MySQL defaults):

parameters = [
  { name = "character_set_client",  value = "utf8mb4" },
  { name = "character_set_server",  value = "utf8mb4" },
]

Changed to PostgreSQL-appropriate logging:

parameters = [
  { name = "log_connections",   value = "1" },
  { name = "log_disconnections", value = "1" },
]

Why these? Connection logging is invaluable for debugging connection pool exhaustion, leaked connections, or unexpected traffic patterns. These parameters are PostgreSQL-specific, MySQL uses different parameter names entirely. The module's defaults assumed MySQL because that's what the example configuration shipped with.

Key insight: Parameter groups are engine-specific. If you switch from MySQL to PostgreSQL (or upgrade major versions), you need a new parameter group family (postgres16 vs mysql8.0).

Option Groups: The Audit Plugin Situation

The module also included a MariaDB audit plugin by default:

options = [
  {
    option_name = "MARIADB_AUDIT_PLUGIN"
    option_settings = [
      { name = "SERVER_AUDIT_EVENTS",       value = "CONNECT" },
      { name = "SERVER_AUDIT_FILE_ROTATIONS", value = "37" },
    ]
  },
]

I removed this entirely. It's a MariaDB-specific plugin. PostgreSQL has its own auditing extensions (pgaudit), but they require a different setup — you enable them via shared_preload_libraries in the parameter group, not through an option group. For this project, connection logging via parameter group is sufficient.

Lesson: Don't blindly copy example configurations. The community module's defaults are MySQL/MariaDB-centric.

Monitoring Interval: Integer, Not String

Small but frustrating gotcha:

monitoring_interval = 30  # integer, not "30"

The Terraform provider expects a number. Passing a string causes a type mismatch error at apply time. The example in the module docs showed it as a string, which cost me a debug cycle.

Subnet Groups and Security Groups: The Wiring

This is where the module connects to the rest of the infrastructure:

vpc_security_group_ids = [var.security_group]
subnet_ids             = var.subnet_ids

The security group variable is a string, but vpc_security_group_ids expects a list. Wrapping it in [var.security_group] satisfies the type requirement.

The subnet_ids comes from the VPC module's private subnets output — these are the subnets without a route to the internet gateway, which is exactly where a database should live.

Module Version Pinning

module "rds" {
  source  = "terraform-aws-modules/rds/aws"
  version = "6.0.0"
  # ...
}

Always pin module versions. If you don't specify a version, Terraform pulls the latest on every init. A module update could introduce breaking changes — renamed variables, changed defaults, removed outputs, and your pipeline would fail mysteriously. Pin to a specific version (or use a version constraint like ~> 6.0) and upgrade intentionally.

Wiring It Into the Environment

In environments/dev/main.tf:

module "dev_rds" {
  source         = "../../modules/rds"
  security_group = module.dev_sg.main_sg
  subnet_ids     = module.dev_app_vpc.private_subnets
}

The security group comes from the security group module output (main_sg), and the private subnets come from the VPC module. This is the dependency chain in action, the RDS module can't be applied until both of those exist.

What I Learned

Parameter groups are engine-specific. Don't copy MySQL configs for PostgreSQL.
Option groups ≠ parameter groups. Options are for engine features (audit plugins, TDE, etc.); parameters are for engine configuration (logging, memory, timeouts).
Pin module versions. Always. No exceptions.
Security group IDs need list wrapping. vpc_security_group_ids expects list(string), not string.
Minor version pinning matters. engine_version = "16.3" not "16".
Monitoring interval is a number. Not a string. The provider will yell at you.

What's Next: The ALB Module

With the database ready, the next piece is the Application Load Balancer. The ALB sits in front of the compute layer (EC2 Auto Scaling Group or ECS), terminates TLS, and routes traffic to healthy targets. It needs the VPC, subnets, and security group, all of which are now in place. That's coming up next.

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 4): Security Groups Terraform

KithupaG — Tue, 21 Jul 2026 16:13:06 +0000

Continuing the build

In my previous post, I set up IAM roles for the ECS agent and the application. With permissions in place, the next piece of the puzzle is security groups.

Security groups are the firewall rules for your VPC. Without them, nothing launches RDS, ALB, ECS tasks, none of it. Every AWS service that touches the network needs a security group reference, so this had to come early.

If you want to follow along with the full series, here's the architecture plan:

VPC -> IAM -> Security Groups -> RDS -> ALB -> EC2 ASG -> S3+CDN -> Monitoring -> CI/CD

What is a Security Group?

A security group is a stateful firewall that controls inbound and outbound traffic for resources inside a VPC. Think of it as a bouncer at a door, it decides what gets in and what gets out.

The key thing to understand: security groups are stateful. If you allow inbound traffic on port 5000, the response traffic on that connection is automatically allowed back out, regardless of your egress rules. You don't need to open both directions manually.

Starting from the Terraform template

I started by copying the AWS provider's example template:

resource "aws_security_group" "allow_tls" {
  name        = "allow_tls"
  description = "Allow TLS inbound traffic and all outbound traffic"
  vpc_id      = aws_vpc.main.id

  tags = {
    Name = "allow_tls"
  }
}

resource "aws_vpc_security_group_ingress_rule" "allow_tls_ipv4" {
  security_group_id = aws_security_group.allow_tls.id
  cidr_ipv4         = aws_vpc.main.cidr_block
  from_port         = 443
  ip_protocol       = "tcp"
  to_port           = 443
}

resource "aws_vpc_security_group_egress_rule" "allow_all_traffic_ipv4" {
  security_group_id = aws_security_group.allow_tls.id
  cidr_ipv4         = "0.0.0.0/0"
  ip_protocol       = "-1"
}

There are three resources here:

The security group itself — the container for the rules
Ingress rule — controls what traffic can come in
Egress rule — controls what traffic can go out

The template was a starting point. I needed to replace it with rules that actually match my application.

The Security Group Module

I created a dedicated modules/security/ directory with a main.tf file. The module takes three variables:

variable "vpc_id" {}
variable "cidr_cidr_block" {}
variable "environment" {}

vpc_id — which VPC does this security group belong to?
cidr_cidr_block — the CIDR range of the VPC, used to allow internal traffic
environment — for tagging purposes (dev, prod, etc.)

Then the security group resource:

resource "aws_security_group" "ap_sg" {
  name        = "app_security_group"
  description = "Security group for the task manager application"
  vpc_id      = var.vpc_id

  tags = {
    Name        = "allow_tls_ssh"
    Environment = var.environment
  }
}

Nothing fancy here. The important part is that vpc_id is set from the variable, meaning this module doesn't hardcode a VPC, it gets passed in from the environment configuration. This makes the module reusable across dev and prod.

Ingress Rules: What gets in

Now for the actual firewall rules. I created separate ingress resources for each port the application needs:

resource "aws_vpc_security_group_ingress_rule" "application_frontend" {
  security_group_id = aws_security_group.ap_sg.id
  cidr_ipv4         = var.cidr_cidr_block
  from_port         = 80
  ip_protocol       = "tcp"
  to_port           = 80
}

resource "aws_vpc_security_group_ingress_rule" "allow_SSH" {
  security_group_id = aws_security_group.ap_sg.id
  cidr_ipv4         = var.cidr_cidr_block
  from_port         = 22
  ip_protocol       = "tcp"
  to_port           = 22
}

resource "aws_vpc_security_group_ingress_rule" "allow_backend_access" {
  security_group_id = aws_security_group.ap_sg.id
  cidr_ipv4         = var.cidr_cidr_block
  from_port         = 5000
  ip_protocol       = "tcp"
  to_port           = 5000
}

resource "aws_vpc_security_group_ingress_rule" "allow_database_access" {
  security_group_id = aws_security_group.ap_sg.id
  cidr_ipv4         = var.cidr_cidr_block
  from_port         = 5432
  ip_protocol       = "tcp"
  to_port           = 5432
}

Breaking down each rule:

Port	Purpose	Why it's open
80	Frontend (HTTP)	The React app served by Nginx
22	SSH	For remote access and debugging
5000	Backend (Node.js)	Frontend-to-backend communication
5432	PostgreSQL	Backend-to-database communication

CIDR Blocks: Who can reach these ports?

You'll notice every ingress rule uses var.cidr_cidr_block as the cidr_ipv4 value. This is the CIDR range of the VPC (something like 10.0.0.0/16).

This means only resources inside the VPC can reach these ports. The private subnets (10.0.1.x, 10.0.2.x, 10.0.101.x) all fall within the 10.0.0.0/16 range, so they're allowed. But traffic from the public internet is blocked.

If you wanted to allow traffic from anywhere on the internet, you'd use:

cidr_ipv4 = "0.0.0.0/0"

That's every IP address on earth. For a production app, you generally don't want that on your database or backend ports. Keeping everything scoped to the VPC CIDR means services can only talk to each other internally.

Egress Rules: What gets out

resource "aws_vpc_security_group_egress_rule" "allow_all_traffic_ipv4" {
  security_group_id = aws_security_group.ap_sg.id
  cidr_ipv4         = "0.0.0.0/0"
  ip_protocol       = "-1"
}

I enabled all outbound traffic. The -1 protocol means "all protocols" — TCP, UDP, ICMP, everything.

Why allow everything out? Because the application needs to reach external services: pulling Docker images from ECR, downloading system updates, connecting to CloudWatch for logging. If you lock down egress too aggressively, things break in ways that are hard to debug.

For most applications, allowing all outbound is the practical choice. You can always tighten it later if your threat model demands it.

Connecting the Module to the Environment

The security group module doesn't know about your VPC or environment variables until you wire them up. In the environment's main.tf:

module "dev_sg" {
  source = "../../modules/security"

  vpc_id          = module.dev_app_vpc.vpc_id
  cidr_cidr_block = var.vpc_cidr
  environment     = var.environment
}

This is where the dependency chain becomes clear. The security group needs the VPC ID, so the VPC module has to be created first. That's why the architecture order matters, you can't build security groups before the VPC exists.

The Outputs

Without an outputs file, the security group is trapped inside its module. No other module can reference it.

output "main_sg" {
  description = "Main sg for the application to access tls, ssh, and allow all outbound connections"
  value       = aws_security_group.ap_sg.id
}

output "vpc_cidr_output" {
  description = "Outputs cidr value for vpc"
  value       = aws_security_group.ap_sg.vpc_cidr_block
}

main_sg — exports the security group ID so RDS, ALB, and ECS can reference it
vpc_cidr_output — exports the CIDR block for use in other networking rules

The security group ID is what gets passed into every future module that needs network access. RDS needs it for its own security group, the ALB needs it to define listener rules, and ECS tasks need it for their network configuration.

What I learnt

Security groups are stateful, you only need to define one direction for a connection
Separate ingress rules per port makes the config readable and auditable
Scoping CIDR to the VPC range keeps everything internal by default
Always allow all egress unless you have a specific reason not to — debugging blocked outbound traffic is painful
Modules need outputs to be useful, a security group that can't be referenced is just dead code

Next up: The RDS module

With the security group in place, we can finally set up the database. RDS needs a subnet group and a security group reference, both of which we now have.

If you've ever had to debug a security group rule that was too restrictive, or forgotten to output a module value and spent an hour wondering why Terraform couldn't find it, 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

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 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

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 5): RDS

Continuing the Build

Why RDS Now?

The Module Structure

Configuring the Database Instance

Parameter Groups: The "Advanced Settings" Nobody Talks About

Option Groups: The Audit Plugin Situation

Monitoring Interval: Integer, Not String

Subnet Groups and Security Groups: The Wiring

Module Version Pinning

Wiring It Into the Environment

What I Learned

What's Next: The ALB 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 4): Security Groups Terraform

Continuing the build

What is a Security Group?

Starting from the Terraform template

The Security Group Module

Ingress Rules: What gets in

CIDR Blocks: Who can reach these ports?

Egress Rules: What gets out

Connecting the Module to the Environment

The Outputs

What I learnt

Next up: The RDS 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 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`)