Cloud Music — AWS Web App, Deployed to EC2 and ECS
One backend, two deployment models, so the trade-off could be measured rather than argued.
A login-and-subscriptions music application on AWS, built by a team of four. Three DynamoDB tables behind a Flask backend, artist images in S3, a serverless path through Lambda and API Gateway, and a static frontend — with the same backend deployed twice, once onto an EC2 instance and once as a container on ECS Fargate.
How it’s put together
Built with
- PERIOD
- Cloud Computing · 2026
- ROLE
- Team of four
The hard parts
08 NOTESThe same Flask backend deployed twice — onto an EC2 instance and as a container on ECS Fargate — so the operational difference between a VM you patch and a task the platform replaces could be measured rather than argued about.
Three DynamoDB tables — login, music and subscriptions — with the music table carrying a local secondary index and two global secondary indexes so it can be queried by year, by artist and by album rather than only by its primary key.
The EC2 deployment runs Flask under gunicorn as a systemd service, so it survives a reboot rather than living in a terminal. An Elastic IP keeps the public URL stable across stop/start, and an instance profile grants DynamoDB and S3 access through the role instead of through keys baked into the image.
Provisioning is scripted in two halves that do different jobs — one script for first-time install, one for redeploying after a pull — because conflating them is how a deploy script quietly reinstalls the world every time.
The container path is the same application through ECR and ECS Fargate: a slim Python image with gunicorn on port 80, a task definition at 0.25 vCPU and 0.5 GB, and a service that holds a desired count of one and replaces the task when it dies. An Application Load Balancer sits in front with a health check on `/health`.
A parallel serverless path — four Lambda functions behind an API Gateway REST API with CORS on every method — so the same operations exist as containers, as a long-lived VM process and as functions, and the three can be compared rather than argued about.
Two S3 buckets serve the static frontend, one pointed at the EC2 backend and one at the ECS backend, identical but for a single `API_BASE` constant. It makes the decoupling literal: the same frontend, unchanged, in front of two completely different backend deployments.
One constraint worth naming, because it shaped the design: CloudFront was evaluated as the CDN in front of S3 and abandoned — the AWS Academy lab role has no permission to create a distribution. The bucket policy enforces HTTPS via `aws:SecureTransport` instead.
Want the parts that aren’t on this page — the architecture arguments, the things that broke, a live walkthrough?