EC2, Lambda, DynamoDB, and RDS Cost and Architecture Trade-offs
Context
In a multi-platform learning environment where users can advance through courses using both Web and Mobile applications, maintaining a single, consistent view of user progress is critical.
In this scenario:
- The Web App is powered by LearnWorlds.
- The Mobile App uses Firebase.
- Users must seamlessly switch between platforms.
- The system must scale to high request volumes.
- The solution must be deployed on AWS.
This leads to a key architectural decision: introducing a third, independent “source of truth” for course progress.
Architectural Goal
The objective is to design a Progress Service that:
- Decouples LearnWorlds and Firebase.
- Owns the canonical progress model.
- Scales predictably under high traffic.
- Keeps infrastructure and operational costs under control.
Architecture Options Considered
1. EC2-Based Service (Always On)
Components
- EC2 instance running the Progress API.
- DynamoDB or RDS as the persistence layer.
Characteristics
- Fixed monthly cost.
- No cold starts.
- Manual or semi-automatic scaling (Auto Scaling Groups).
- Operational overhead (patching, monitoring, capacity planning).
Typical EC2 Costs (24×7, us-east-1)
| Instance | Monthly Cost |
|---|---|
| t3.small | ~USD 15 |
| t3.medium | ~USD 30 |
| m7g.large | ~USD 60 |
2. Fully Serverless (Lambda + API Gateway)
Components
- API Gateway (HTTP API).
- AWS Lambda for the Progress API.
- DynamoDB (on-demand).
Characteristics
- Pay per request.
- Automatic scaling.
- No servers to manage.
- Cold starts and per-request cost must be considered.
Average cost per 1M requests
- Lambda + API Gateway ≈ USD 1.41 / 1M requests
Rule of thumb
- Below ~10–11M requests/month → Lambda is cheaper than EC2 t3.small
- Above that → EC2 or containers tend to be more cost-effective.
3. Docker-Based Service (ECS Fargate)
Components
- Dockerized Progress API.
- Amazon ECR.
- ECS Fargate.
- Application Load Balancer.
- DynamoDB or RDS.
Characteristics
- No server management.
- No Lambda cold starts.
- Better for sustained high traffic.
- Cost scales with allocated CPU/RAM, not per request.
This option sits between EC2 and Lambda in both control and operational complexity.
Data Layer Cost Comparison: DynamoDB vs RDS
Assumption:
- 10 million operations/month (reads + writes).
- Small items (≤1 KB).
- us-east-1 region.
DynamoDB (On-Demand)
Pricing (approximate):
- Writes: USD 0.625 / 1M
- Reads: USD 0.125 / 1M
Typical monthly cost
- 50% reads / 50% writes → ~USD 3.75
- 1 read + 1 write per operation (20M total ops) → ~USD 7.50
RDS (Fixed Cost)
| Instance | Monthly Cost |
|---|---|
| db.t3.micro | ~USD 13 |
| db.t3.small | ~USD 36 |
This cost is fixed, regardless of usage, and does not include storage, I/O, or backups.
DynamoDB vs RDS: Cost Equilibrium
The break-even point depends on the write ratio.
| RDS Instance | Write Ratio | DynamoDB Break-Even |
|---|---|---|
| db.t3.micro | 50% | ~35M ops/month |
| db.t3.micro | 80% | ~25M ops/month |
| db.t3.small | 50% | ~97M ops/month |
| db.t3.small | 80% | ~70M ops/month |
Conclusion
- At 10–20M operations/month, DynamoDB is significantly cheaper.
- RDS becomes cost-competitive only at much higher volumes or when SQL features are mandatory.
Practical Decision Matrix
| Scenario | Recommended Stack |
|---|---|
| Low / variable traffic | Lambda + API Gateway + DynamoDB |
| Sustained high traffic | ECS Fargate + DynamoDB |
| Strong SQL needs | EC2/ECS + RDS |
| Minimal ops, fast start | Lambda + DynamoDB |
Final Recommendation
For a course progress system with high write frequency, simple access patterns, and growth uncertainty:
- DynamoDB is the most cost-efficient and scalable data store.
- Start with Lambda if traffic is uncertain or bursty.
- Move to ECS Fargate (Docker) when traffic becomes sustained and predictable.
- Use EC2 only if you explicitly need full host-level control.
This approach minimizes cost early while preserving a clear migration path as scale increases.