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.