case study · serverless
Jazz en la Jungla
A serverless web platform on AWS — static content delivered globally through CloudFront, a Lambda-backed API behind API Gateway, and DynamoDB for persistence. Infrastructure defined in Terraform and shipped continuously with GitHub Actions.
architecture
System architecture
Request flow: the browser hits CloudFront, which serves static assets from S3 and routes /api/* to API Gateway → Lambda → DynamoDB. IAM enforces least-privilege access.
overview
What it is & why I built it
Jazz en la Jungla is a production web platform built to a fully serverless design — no servers to patch, pay-per-use, and able to scale to zero. It was my vehicle for putting an end-to-end AWS architecture into practice: global static delivery, a managed API, and a NoSQL data layer, all reproducible from code.
The goal was an architecture a team could trust: reproducible through infrastructure as code, automated through CI/CD, and secure through least-privilege IAM.
Highlights
- Global, cached delivery — static front end on S3, distributed by CloudFront with HTTPS at the edge.
- Managed API — API Gateway routes requests to Lambda functions; no servers to maintain.
- NoSQL persistence — DynamoDB for fast, scalable, fully managed storage.
- Infrastructure as code — the whole stack is defined in Terraform and version-controlled.
- Continuous deployment — GitHub Actions builds and ships changes on every push.
engineering decisions
Key decisions
// why serverless?
Serverless over EC2
No instances to manage or patch, automatic scaling, and pay-per-request economics — ideal for variable, unpredictable traffic.
// why CloudFront + S3?
CDN-first delivery
Caching static assets at the edge cuts latency worldwide and offloads origin traffic, while S3 gives durable, cheap hosting.
// why Terraform?
Infrastructure as code
Declarative, reviewable and reproducible. The environment can be torn down and rebuilt identically — no console click-ops drift.
// why GitHub Actions?
Automated delivery
Every push runs the pipeline, keeping deploys consistent and removing manual, error-prone release steps.
tech stack
Stack & responsibilities
| Technology | Layer | Responsibility |
|---|---|---|
| Amazon S3 | Storage | Hosts the static front end (HTML, CSS, JS). |
| CloudFront | Delivery | Global CDN with HTTPS and edge caching. |
| API Gateway | API | Exposes REST endpoints and routes to Lambda. |
| AWS Lambda | Compute | Runs backend logic on demand, no servers. |
| DynamoDB | Data | Managed NoSQL persistence layer. |
| Terraform | IaC | Declarative provisioning of all resources. |
| GitHub Actions | CI/CD | Builds and deploys on every push. |
| IAM | Security | Least-privilege roles and policies. |
delivery pipeline
From push to production
A simplified view of the GitHub Actions workflow that provisions infrastructure and ships the site.
# Triggered on every push to main on: push: branches: [ main ] jobs: deploy: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - terraform init - terraform apply -auto-approve # provision AWS - aws s3 sync ./site s3://$BUCKET # publish front end - aws cloudfront create-invalidation # bust the cache
Want the full walkthrough?
See the live site and the source, or get in touch to talk through the architecture.