Expense Tracker: Multi-Tier AWS Infrastructure & Deployment Lab

Moving Beyond Single-Host Docker Compose

In local development and entry-level setups, deploying a multi-service web application often starts and ends with a single docker-compose.yml file running on a single virtual machine. While effective for prototyping, single-host hosting obscures real-world cloud infrastructure concerns: network boundaries, least-privilege security groups, zero-trust deployment pipelines, and isolated database subnets.

I built the Expense Tracker lab as a hands-on learning environment to bridge that gap. The goal was to build the infrastructure surrounding an application from scratch on AWS:

• Physical Network Segmentation: Provisioning a custom VPC with dedicated public, private application, and isolated database subnets across two availability zones (ap-south-1a and ap-south-1b).
• Zero-SSH Administration: Completely closing inbound port 22 to the world, managing compute instances solely through the AWS Systems Manager (SSM) agent.
• Declarative Infrastructure as Code: Codifying every VPC route table, NAT Gateway, security group, and IAM policy in Terraform.
• Automated CI/CD Delivery: Automating Docker container builds with GitHub Actions, pushing images to Amazon ECR, and triggering remote deployments via SSM run commands.
• Configuration Management: Using Ansible with dynamic EC2 inventory plugins to configure Docker runtimes on Amazon Linux 2023 instances over SSM.

AWS Network Topology & Traffic Boundaries

The architecture enforces strict network isolation across three distinct tiers in the ap-south-1 region. Each tier is partitioned across availability zones ap-south-1a and ap-south-1b:

Network Topology: Public subnets with NAT Gateway & Frontend EC2, Private app subnets with Backend EC2 & S3 Gateway Endpoint, and isolated Database subnets hosting Single-AZ RDS PostgreSQL 17.

Traffic Path: Client browsers access public frontend EC2 instances hosting Nginx. Nginx serves the client UI and reverse-proxies REST calls to backend EC2 instances residing in the private application subnets. The Flask backend processes transactions and communicates with Amazon RDS PostgreSQL over internal port 5432. All outbound traffic from the private subnets (such as pulling ECR images or updating system packages) routes through the NAT Gateway.

Declarative Provisioning with Terraform

All AWS cloud resources were codified in modular Terraform files under terraform/. By managing infrastructure as code, the network routing tables, security group rules, EC2 compute instances, and RDS database can be planned, verified, and torn down systematically without manual console configuration.

resource "aws_db_subnet_group" "expense_db_subnet_group" {
  name       = "expense-db-subnet-group"
  subnet_ids = [aws_subnet.private_db_1.id, aws_subnet.private_db_2.id]
}

resource "aws_db_instance" "expense_db_instance" {
  identifier                  = "expense-tracker-db"
  db_name                     = "expense_db"
  username                    = var.db_username
  manage_master_user_password = true
  engine                      = "postgres"
  engine_version              = "17"
  instance_class              = "db.t3.micro"
  allocated_storage           = 20
  storage_type                = "gp3"
  db_subnet_group_name        = aws_db_subnet_group.expense_db_subnet_group.name
  vpc_security_group_ids      = [aws_security_group.db_sg.id]
  publicly_accessible         = false
  storage_encrypted           = true
  deletion_protection         = true
}

Docker, Amazon ECR & Zero-SSH Delivery via AWS SSM

The frontend and backend services are decoupled into separate container images. The deployment pipeline is engineered to eliminate static cloud credentials and open management ports:

- name: Configure AWS Credentials (OIDC)
  uses: aws-actions/configure-aws-credentials@v4
  with:
    role-to-assume: ${{ env.ROLE_TO_ASSUME }}
    aws-region: ${{ env.AWS_REGION }}

- name: Deploy Backend Containers via AWS SSM
  run: |
    COMMAND_ID=$(aws ssm send-command \
      --region ${{ env.AWS_REGION }} \
      --targets "Key=tag:Role,Values=backend" \
      --document-name "AWS-RunShellScript" \
      --parameters '{"commands": [
        "aws ecr get-login-password --region ${{ env.AWS_REGION }} | docker login --username AWS --password-stdin ${{ env.ECR_REGISTRY }}",
        "docker pull $BACKEND_IMAGE",
        "docker stop expense-backend || true",
        "docker rm expense-backend || true",
        "docker run -d --name expense-backend --restart unless-stopped -p 8000:8000 -e DB_SECRET_ARN=${{ env.DB_SECRET_ARN }} $BACKEND_IMAGE"
      ]}' \
      --query "Command.CommandId" --output text)

Ansible Over Systems Manager

To configure host servers consistently without maintaining static SSH keys or bastion hosts, I used Ansible with the Amazon EC2 dynamic inventory plugin and the AWS SSM connection plugin:

Problems Encountered, Resolved vs. Unresolved Issues & Trade-offs

Implementation Status & What Building This Taught Me

Practical Improvements for Future Iterations