Capstone — Architect & Deploy a Production App on AWS
Capstone — Architect & Deploy a Production App on AWS
The Production Architecture
You've learned every major service. Now see how they compose into a real system.
Use case: a Next.js web app with user auth, file uploads, a background job processor, and a REST API.
┌─────────────────────────────────────────────┐
│ Users │
└──────────────────────┬──────────────────────┘
│
┌───────────▼────────────┐
│ Route 53 (DNS) │
└───────────┬────────────┘
│
┌──────────────────────▼──────────────────────┐
│ CloudFront (CDN + TLS via ACM) │
│ Static assets cached at edge / S3 origin │
└──────────────┬──────────────┬───────────────┘
│ │
┌──────────────▼──┐ ┌────▼───────────────┐
│ S3 (Static │ │ ALB (Application │
│ Next.js build)│ │ Load Balancer) │
└─────────────────┘ └────────┬───────────┘
│
┌─────────────────────────────────▼──────────────────┐
│ Private Subnet │
│ ┌─────────────────────┐ ┌──────────────────────┐ │
│ │ ECS Fargate │ │ ECS Fargate │ │
│ │ (Next.js API / SSR) │ │ (Background Worker) │ │
│ └──────────┬──────────┘ └──────────┬───────────┘ │
└─────────────┼────────────────────────┼─────────────┘
│ │
┌─────────────▼──────┐ ┌────────────▼────────────┐
│ RDS PostgreSQL │ │ SQS Queue │
│ (Multi-AZ) │ │ (job queue) │
└────────────────────┘ └─────────────────────────┘
Additional services:
├── S3 bucket (user file uploads, via pre-signed URLs)
├── ElastiCache Redis (session store, caching)
├── CloudWatch (logs, metrics, alarms)
└── Secrets Manager (DB password, API keys)Critical Architecture Decisions
1. Where does the Next.js app run?
| Option | Trade-off |
|---|---|
| ECS Fargate | Full SSR/ISR support, auto-scaling, production-ready |
| Lambda + API GW | Cheaper at low traffic, cold starts hurt SSR |
| S3 + CloudFront | Static-only (no SSR), cheapest |
For a full Next.js app with auth: ECS Fargate.
2. Database sizing
Start with db.t3.micro (2 vCPU, 1 GB RAM) for dev/staging. Production: db.t3.medium minimum, scale up based on query latency (target < 10ms p99 for simple queries). Enable Multi-AZ on day one.
3. File uploads
Never route uploads through your app server — they consume memory and time. Pattern:
1. Client requests a pre-signed S3 PUT URL from your API
2. Client uploads directly to S3 (bypass your server)
3. S3 triggers a Lambda or sends to SQS for post-processing4. Secrets
Environment variable in task definition → SSM Parameter Store (free, simple)
Rotation needed (DB passwords, API keys) → Secrets Manager ($0.40/secret/month)The Deployment Pipeline
Developer pushes to main
↓
GitHub Actions
├── Run tests
├── docker build + push to ECR (tagged with git SHA)
├── cdk deploy (if infrastructure changed)
└── aws ecs update-service --force-new-deployment
↓
ECS performs a rolling deployment
├── Launches new tasks with new image
├── ALB routes to new tasks once health checks pass
└── Drains and terminates old tasksZero-downtime deployments by default with ECS rolling updates and ALB health checks.
Cost Model for This Architecture
Rough monthly costs (us-east-1, low traffic startup):
| Service | Cost |
|---|---|
| ECS Fargate (2× 0.5 vCPU, 1 GB) | ~$25/mo |
| RDS db.t3.micro Multi-AZ | ~$30/mo |
| ALB | ~$20/mo |
| CloudFront (first 1 TB free) | ~$0–8/mo |
| S3 (50 GB) | ~$1.15/mo |
| NAT Gateway | ~$32/mo |
| CloudWatch logs | ~$2/mo |
| **Total** | **~$115/mo** |
Biggest levers to reduce cost:
- NAT Gateway — most expensive for small apps. Use a NAT Instance ($3/mo) or VPC Endpoints for common services
- RDS — use Aurora Serverless v2 for dev (scales to zero)
- Fargate — use Fargate Spot (up to 70% discount for fault-tolerant workloads)
The Well-Architected Checklist
Before going to production, review these 5 key questions:
- Reliability: What happens if one AZ fails? (Answer: multi-AZ everywhere)
- Security: Is there any path from the internet to the database? (Answer: should be no)
- Cost: Is NAT Gateway running for dev environments 24/7? (Answer: turn off dev after hours)
- Performance: Where will you see the first bottleneck at 10× current load? (Answer: RDS — add read replica)
- Operations: If an alert fires at 3am, can you diagnose from CloudWatch alone? (Answer: structured logs + dashboards)