Case Study · 2025
NotesWay — Cloud Infrastructure for Academic Collaboration
A production-oriented AWS architecture for an academic notes-sharing platform — containerized deployment, automated CI/CD, secure file storage, and infrastructure built to be operated, not just launched.
Context
NotesWay is an academic notes-sharing platform for students, professors, and institutions — upload, share, and retrieve academic resources at the core. It's built on a 3-tier AWS architecture with a containerized FastAPI backend and a fully automated delivery pipeline from commit to production.
The Problem
Getting the application running was never the hard part. The real challenge was building a deployment path that could ship updates reliably without touching a server by hand, keep compute and storage cleanly separated, and give the system enough visibility and access control to be trusted with real academic data — not just demoed once and left alone.
Process
01 — Tier before service
Defined the presentation, application, and data layers before selecting a single AWS service. Frontend delivery, backend compute, database, and file storage are each independently managed and independently replaceable.
02 — Containerize, then automate
Packaged the FastAPI backend as a Docker image and moved deployment onto Amazon ECS, with Amazon ECR as the private image registry. GitHub Actions owns the path from `git push` to a running task — build, test, image push, deploy — with no manual step in between.
03 — Secure by default, not by exception
Every request crosses WAF, TLS termination, and a load balancer before reaching compute. IAM roles are scoped per service rather than shared. Academic files never sit behind a public bucket — access is granted through short-lived S3 pre-signed URLs, upload and download alike.
Design Decisions
Containers over configured servers
The backend runs as a Docker container on ECS instead of a hand-tuned EC2 instance. A deployment is now an image tag, not a remembered sequence of manual steps — which means the environment that was tested is the exact environment that ships.
CI/CD as the only deployment path
GitHub Actions builds the image, runs tests, pushes to Amazon ECR, and triggers an ECS service update on every merge. There is no direct path to production that skips this pipeline — which makes every deployment auditable and every rollback a redeploy of a previous image tag, not a scramble.
Pre-signed URLs over public storage
Files live in private S3 storage. Every access — upload or download — goes through a scoped, time-limited pre-signed URL, so nothing academic is ever reachable by guessing a path.
Outcome
✦ A manually deployed student project became a containerized AWS deployment on ECS and ECR, shipped through a GitHub Actions CI/CD pipeline
✦ Frontend, backend, database, and file storage fully decoupled across a 3-tier architecture — each layer scales, fails, or gets replaced on its own
✦ Deployment moved from "someone SSHs in and runs a script" to "merge to main, and the pipeline handles the rest"
Reflection
“Good cloud infrastructure isn't about stacking on more services — it's about building a secure, repeatable path from code to production that you'd trust someone else to run at 2 a.m.”