$12,000 per month or $1,800. Same architecture. Same traffic. Same instance types. One architecture decision different.
That decision is whether you put a CDN in front of your origin. Not a specific vendor button. Not a pricing-calculator checkbox. Just the architectural choice to add an edge cache between users and the services that would otherwise serve every read directly.
The reason most cost estimates miss this is that most estimates start from the wrong place: service configuration instead of architecture.
Here is what typically happens. An engineer needs to estimate AWS costs for a new service. They open the AWS Pricing Calculator, select EC2, guess an instance type, type in some hours. Then RDS, ElastiCache, maybe a load balancer. They add it up, present the number, and move on.
The problem is that by the time you are filling in that calculator, you have already made the three or four architectural decisions that determine whether the bill is reasonable or catastrophic. The calculator is just arithmetic on top of those decisions. If the decisions are wrong, precise arithmetic makes things worse, not better.
The line item everyone underestimates
Data transfer out is the most expensive surprise in AWS billing. It does not look expensive per unit. A few cents per GB sounds harmless until you do the multiplication.
A standard web application at 10,000 requests per second with an average response size of 5KB produces roughly 130 terabytes of outbound transfer per month.
That math is simple: 10,000 RPS x 5KB x 2,592,000 seconds per month. At roughly $0.09/GB, that is around $11,700 per month from data transfer alone, before you have paid for a single EC2 instance, database, cache, or queue.
This is not an edge case. Any application with meaningful read traffic and no CDN layer runs into this wall. The application tier, the database, and the cache are usually not the expensive part. The pipe is.
Now put a CDN component in front of the same origin. The CDN serves cached static assets, media, pages, or API responses from the edge when possible. The origin only handles cache misses and dynamic requests.
If the CDN absorbs 85 to 90 percent of read traffic, origin transfer drops by the same order of magnitude. The architecture did not need a new database. It did not need a bigger app server. It needed the read path to stop treating the origin as the first stop for every request.
That is the point most estimates miss. The CDN is not just a performance optimization with a cost. At scale, it is often a cost-control decision that also improves latency.
The three decisions that set your bill before you open any calculator
Compute model. EC2, ECS Fargate, and Lambda have fundamentally different cost structures at different request rates. Lambda charges per invocation and duration. That can be cheap at low, intermittent traffic and expensive at sustained high volume. The crossover point where EC2 or containers become cheaper than Lambda is usually workload-specific, but it often appears once traffic becomes steady rather than spiky.
Most teams pick one model and stick with it without checking where that crossover sits for their workload. Checking it before you build costs nothing. Discovering it after months of high bills is more expensive.
Data path. This is the CDN question, but it is broader than CDN alone. Are clients pulling directly from app servers, or can static assets and media come from a CDN? Are large files proxied through compute, or served from object storage? Are repeat reads hitting a cache, or falling through to the database?
These choices decide whether scale multiplies expensive origin work or gets absorbed closer to the user.
Database tier. RDS, Aurora Serverless, DynamoDB, and cache-backed database patterns all have different cost curves. A steady 24/7 API has a different answer than a batch-heavy internal tool or a bursty consumer product. The right database estimate depends on write rate, read rate, storage growth, replication, and how much traffic can be served from cache.
The wrong database tier can cost more than the wrong instance type. The wrong read path can cost more than both.
Estimate before the architecture is locked, not after
The most useful cost estimate is not "what will this cost at our current traffic." It is "what will this cost at 2x, 5x, and 10x traffic, and where does the curve bend?"
The point where cost growth accelerates tells you where the first architectural change will be required. Sometimes it is the database. Sometimes it is the cache. Sometimes it is data transfer because every request is still going back to origin.
Almost never is it only the compute instance type, which is the part engineers spend the most time optimizing.
Running this estimate before committing to an architecture means you design for the right bottleneck. Running it after means you redesign under pressure when the bill arrives.
I built a free browser-based cost estimator that starts from your architecture diagram rather than service configuration: you draw components like Load Balancer, App Server, Cache, Database, Object Storage, and CDN, set your target RPS, and see the cost breakdown update from the diagram in real time with no account required: https://syssimulator.com/aws-cost-estimator
The bill is set before the calculator opens
Cost estimation done after architectural decisions are made is just arithmetic on choices you have already locked in. The CDN question, the compute model question, the data path question, and the database tier question are what move the bill by factors of two to ten.
Instance type optimization still matters, but it usually moves the number by tens of percent. Architecture moves it by orders of magnitude.
Estimate while the architecture is still fluid. Run the numbers at 2x, 5x, and 10x. Find where the curve bends. That is where your first architectural constraint lives, and it is much cheaper to discover it on a diagram than in production.
Top comments (0)