JSTAcademy
0 XP
Dashboard
Crash Courses
Capstone — Architect & Deploy a Production App on AWS
22 min
PhD+280 XP
Crash Courses · PhD

Capstone — Architect & Deploy a Production App on AWS

Design a full-stack architecture from scratch: VPC, ECS, RDS, S3, CDN, CI/CD, monitoring
22 min read+280 XP on completionCert: AWS Crash Course
Tap any word in the text below to start reading from there.

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?

OptionTrade-off
ECS FargateFull SSR/ISR support, auto-scaling, production-ready
Lambda + API GWCheaper at low traffic, cold starts hurt SSR
S3 + CloudFrontStatic-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-processing

4. 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 tasks

Zero-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):

ServiceCost
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:

  1. NAT Gateway — most expensive for small apps. Use a NAT Instance ($3/mo) or VPC Endpoints for common services
  2. RDS — use Aurora Serverless v2 for dev (scales to zero)
  3. 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:

  1. Reliability: What happens if one AZ fails? (Answer: multi-AZ everywhere)
  2. Security: Is there any path from the internet to the database? (Answer: should be no)
  3. Cost: Is NAT Gateway running for dev environments 24/7? (Answer: turn off dev after hours)
  4. Performance: Where will you see the first bottleneck at 10× current load? (Answer: RDS — add read replica)
  5. Operations: If an alert fires at 3am, can you diagnose from CloudWatch alone? (Answer: structured logs + dashboards)
0%