Component-to-Service Mapping
The first step is translating architecture components into AWS services. This mapping is opinionated — the defaults are conservative and boring, chosen because they work reliably at the widest range of scales without requiring deep AWS expertise to operate.
| Architecture Component | Default AWS Mapping | Alternatives Modeled |
|---|---|---|
| Application server (stateless) | EC2 (t3/t4g family) or ECS Fargate | Lambda for request-based workloads |
| Load balancer | Application Load Balancer | Network Load Balancer for L4 |
| Cache layer | ElastiCache for Redis | DAX for DynamoDB-adjacent workloads |
| Relational database | RDS (PostgreSQL) Multi-AZ | Aurora Serverless v2 |
| Object storage | S3 Standard | S3 Intelligent-Tiering for unknown access patterns |
| Message queue | SQS Standard | SQS FIFO, MSK for high-throughput streaming |
| CDN | CloudFront | None (regional-only is an option) |
t4g instances because they're the cheapest general-purpose compute with consistent performance. RDS Multi-AZ because single-AZ databases in production architectures are a mistake that costs more later. Application Load Balancer because you probably need path-based routing eventually.
Each default can be overridden in the estimator. If you're building something with extremely spiky traffic, the Lambda path for application servers produces a meaningfully different cost curve — the estimator shows both so you can compare.
How the 10K RPS Example Works Out
A concrete example: a standard three-tier web application targeting 10,000 requests per second at peak, P99 latency target of 200ms, mostly read traffic (80/20), stateless application layer, PostgreSQL backend.
t4g.medium behind ALB — each handles ~1,200 RPS with headroomcache.r7g.large (2 vCPU, 13GB) — sized for working set covering 80% of readsdb.r7g.large (2 vCPU, 16GB) — ~2,000 writes/s to DB after cache absorptionThe CDN isn't optional at this scale — it's the architecture decision that determines whether the cost is reasonable. The estimator shows this breakdown interactively. You can toggle CloudFront on/off and watch the total change. A spreadsheet can give you the same insight, but requires knowing to ask the question first. The tool asks it for you.
Where the Estimates Are Wrong
Honest accounting of what the estimator gets wrong, and why.
-
Reserved Instances and Savings Plans
All estimates use on-demand pricing. In production, a 1-year Reserved Instance commitment on compute reduces EC2 costs by ~35%. The estimator doesn't apply RI discounts by default because they require commitment decisions that depend on your company's financial situation, not just the architecture. There's a toggle to apply them.
-
Intra-AWS data transfer pricing
EC2 to RDS in the same AZ is free. Cross-AZ traffic (which happens with Multi-AZ RDS) is $0.01/GB. At high volumes this adds up. The estimator uses same-AZ assumptions for the app-to-DB path and cross-AZ assumptions for ALB-to-EC2. These assumptions may not match your actual architecture.
-
Operational complexity costs
The estimator measures AWS bill, not total cost of ownership. A Multi-AZ RDS setup costs more to operate than a single-node database, not because of the AWS bill but because of the expertise required. That's outside the tool's scope.
-
Bursty vs. sustained traffic
The model assumes traffic is roughly sustained at the target RPS for billing purposes. If your 10K RPS is a one-hour peak and you're at 500 RPS the rest of the day, auto-scaling changes the economics significantly. The estimator has a "peak/average ratio" input that adjusts compute estimates, but it's a simplification.
Using This for Architecture Decisions
The estimator is most useful in three specific scenarios where cost differences between options are large enough to drive architectural choices.
Choosing between compute approaches early
EC2 vs. ECS Fargate vs. Lambda has dramatically different cost profiles at different request rates. The crossover point is typically around 1–3M requests/day depending on request duration. The estimator plots this curve so you pick the right model before building the wrong one.
Justifying CDN investment
Data transfer costs are the most commonly underestimated line item in AWS architectures. The estimator makes the CDN ROI calculation explicit. At 10K RPS with typical response sizes, CloudFront usually pays for itself before the end of the first month.
Comparing database tier options
RDS vs. Aurora Serverless v2 vs. DynamoDB have different cost structures at different access patterns. Aurora Serverless v2 is often more expensive than RDS at sustained load but cheaper at intermittent load due to ACU-based billing. The estimator models both with the same workload — apples to apples.
The most effective pattern is to run the estimator at 2×, 5×, and 10× your current traffic load before choosing an architecture. This shows where the first bottleneck appears and whether addressing it requires horizontal scaling (more instances, same architecture) or architectural change (caching tier, different database, CDN). That's a much cheaper question to answer now than after deployment.
Running an Estimate
The estimator is on the main canvas — no account required, no data leaves the browser. Draw your architecture components, set your target RPS and region, and the cost panel updates in real time.
Draw a load balancer, app tier, cache, and database. Set 10K RPS. Watch CloudFront reduce the total from $12K to $1.8K per month as you toggle it on.
Open Simulator →If you want to understand the simulation architecture the estimator is built on, see /how-it-works — it covers the Rust and WASM stack. If you're building agents that interact with the simulator programmatically, /mcp-agent-architecture covers the MCP tool interface.