System: Cloud Expense Tracker
Category: AWS · Personal cloud lab
Reading Time: 8 min read
What the Expense Tracker recordings actually show
A personal AWS lab: dual-AZ subnets, public frontend instances, a private backend, and a single-AZ database.
Covered: AWS · Terraform · VPC · EC2 · RDS PostgreSQL 17 · Docker · GitHub Actions · Ansible
01. WHY I BUILT IT
The Trigger & Underlying Problem
The Trigger: I wanted a personal project where the application was an excuse to practice the infrastructure around it.
The Core Problem: I could describe a VPC, a pipeline, and a playbook from documentation. I had not yet recorded myself creating the network, building the images, and reaching the instances.
Why Standard Solutions Were Insufficient: An expense form needs a database and a place to put uploads, so the lab had a reason to include RDS and S3 instead of stopping at an empty VPC.
02. PRACTICAL IMPACT
What It Solves in Practice
PRACTICAL PROBLEM
Gives me a small app I can deploy into a VPC I provisioned, with separate frontend and backend instances.
BENEFICIARIES
Me, as a learning record. The CI/CD recording opens the app at projects.yamandeep.in. That hostname is not a claim of production traffic.
BEFORE THIS SYSTEM
Cloud practice that stayed in notes, without a console recording of the VPC or a pipeline log.
03. IMPLEMENTATION
Architecture & Key Engineering Decisions
ap-south-1. The console recording shows expense-tracker-vpc with public, private, and private database subnets in ap-south-1a and ap-south-1b, plus an internet gateway, a NAT gateway, and an S3 endpoint. The architecture diagram places Nginx frontend EC2 in the public subnets and Flask backend EC2 in the private app subnets. The database is drawn as single-AZ. The visible rds.tf sets engine postgres, engine_version 17, instance_class db.t3.micro, publicly_accessible false, and storage_encrypted true.
Key Decisions:
- Frontend and backend are separate images. The Actions log builds the frontend from nginx:alpine and deploys frontend and backend containers through SSM.
- The workflow log includes a step named Configure AWS Credentials (OIDC). I am not publishing an account id or role ARN from that log.
- Ansible uses inventory/aws_ec2.yml. The recording shows groups for frontend and backend, a ping play, and a Docker play.
File: example only — not a captured workflow file
# EXAMPLE SHAPE. The recording shows these step names. # It does not show this file, and no account id is included here. # - Configure AWS Credentials (OIDC) # - Log in to Amazon ECR # - Build and push frontend image (nginx:alpine) # - Build and push backend image # - Deploy backend containers via AWS SSM # - Deploy frontend containers via AWS SSM
04. CHALLENGES & SOLUTIONS
What Failed in Practice & How It Was Addressed
WHAT WENT WRONG
- The Ansible terminal reports that playbooks/install-docker.yml could not be found.
- The same terminal warns: Found variable using reserved name tags.
- A browser tab during the CI/CD recording is titled like a 502. The recording never shows that page, so the cause is not in the evidence.
HOW I SOLVED IT
- The recording does not show a separate fix for the missing playbook. After the error, playbooks/docker.yml runs and returns ok while gathering facts on the instances in the inventory.
- The tags warning is still visible in that later frame. I am not claiming it was cleared.
05. REFLECTION & LESSONS
Takeaways & Future Iterations
What I Learned:
- The frontend instances are in public subnets. Calling the whole compute tier private does not match the diagram.
- A second database subnet is not the same thing as a Multi-AZ standby. The diagram labels the database single-AZ.
- The useful CI evidence is the job log: two image builds, ECR, an OIDC step, and SSM deploys.
WHAT I WOULD CHANGE NOW:
I would retitle the diagram so it does not say production architecture. A later lab can add a real Multi-AZ database. This one does not have one.