The Pricing Calculator offers two estimate types: workload estimates and bill estimates. Before-discount and after-discount rates apply only to workload estimates - which is exactly the calculation to run before buying a commitment. Two limits are rarely mentioned.
The earlier pages all deal with what happens after money is spent: optimising the bill, tracing a spike, why transfer costs what it does. But one thing happens before you spend, and it sets the starting point for everything else - working out the cost first.
AWS provides a free tool for that: the AWS Pricing Calculator. It is often filed away as "a tool for estimating before you go to the cloud", when its most valuable use is something else - working out the before-and-after numbers before you buy a commitment discount.
What it does: five uses
AWS lists five uses, and they are broader than "get a price":
- Model a solution before you build it: work out what an architecture will cost while it is still a design.
- Explore service price points: compare specifications and payment options.
- Review the calculation behind your estimate: AWS emphasises transparent pricing - you can see how each line was derived rather than being handed a total.
- Plan your AWS spend: lay out expected cost over a period.
- Find cost saving opportunities: the most overlooked one - it is a cost optimisation tool, not only a quoting tool.
Four features decide how usable it is: groups for hierarchical estimates (costs grouped by architecture rather than one lump total), saved estimate links (estimates are stored on AWS public servers and can be shared), CSV or PDF export (for internal approvals), and transparent pricing (you can see the calculation).
A useful habit: build your estimate groups to match your architecture layers (edge / application / data / network) rather than listing services flat. The estimate then lines up with your architecture diagram, and when you come to optimise you can see at a glance where the money sits.
Two estimate types: workload estimates and bill estimates
This is the most overlooked and most consequential detail: the calculator does not produce only one kind of estimate. AWS splits them into two, with completely different uses:
| Workload estimate | Bill estimate | |
|---|---|---|
| Based on | A configuration you enter by hand (type, quantity, hours…) | Your existing usage |
| Answers | "If I build it this way, what will it cost?" | "At current usage, roughly what will it cost?" |
| When | Design stage, before anything is running | Already running; converting usage into cost |
| Before / after discount rates | Apply | Do not apply |
⛔ This distinction decides which one to use: if nothing is running yet and you want to know what a design would cost, use a workload estimate; if it is already running and you want to know what current usage costs, use a bill estimate. Both are called estimates but the inputs are completely different, and using the wrong one produces a result that looks reasonable and is not.
Before and after discount rates: why they only apply to workload estimates
The documentation states one key line: before-discount and after-discount rates apply only to workload estimates.
The restriction is logical, and understanding it is more useful than memorising it:
- A workload estimate describes something that has not happened yet: you entered a planned configuration with no actual usage, so the tool can price it both ways and show you what the discount is worth.
- A bill estimate describes something that has happened: it is based on existing usage, and your effective rates already reflect discounts in force. Publishing a "before" rate on top would misrepresent your actual position.
This is the calculation to run before buying a commitment: use a workload estimate, put the before and after figures side by side, and the difference is what the commitment discount saves. Judge that difference against how long you would lock in and how much you would commit - far steadier than buying on instinct. Which commitment and how much is in how to buy AWS Savings Plans.
Where the prices come from, and two limits to know
Two limits are stated explicitly by AWS, and both cause "the numbers do not match" in practice:
- Estimates exclude taxes. The calculator returns the service cost itself; tax is not included. Budget for it as a separate layer.
- If prices on the marketing pages differ from those in the calculator, the marketing page prices are used. That is the official wording - so the calculator is not the final authority; its data comes from the AWS price list API, while published pricing is what the marketing pages state.
What that means practically: the calculator is best for relative comparison and structural judgement (which design is dearer, what a discount is worth, which layer dominates cost) rather than line-by-line reconciliation. For exact unit prices, go back to the official pricing pages.
One more distinction often blurred: the price in an estimate is not your actual bill. It is a plan, not a statement. What the bill looks like depends on what you really use, and what to do when the bill misbehaves is a separate process - see why your AWS bill jumped.
Three practical scenarios
Putting it together, three situations where it earns its keep:
- Before buying a commitment discount. Use a workload estimate to get both the before and after figures and quantify the difference; then decide the quantity based on how stable usage really is. Over-committing wastes money; under-committing leaves coverage short.
- Comparing regions and specifications. Laying out the same configuration across regions or sizes in an estimate is faster than reading pricing pages, and easier to show to non-technical colleagues.
- Validating an architecture change. If you are considering moving to better price-performance silicon, or pulling chatty cross-zone calls into one zone, estimate before and after first, then decide whether the change is worth doing.
All three share one trait: they happen before anything is touched. That is exactly where the calculator is most often skipped and most valuable - once resources are running you can use bills and usage data instead, and no longer need an estimate.
An estimate is not a bill
The last section is expectation management, which is why some teams come away from the calculator disappointed:
| Estimate | Actual bill | |
|---|---|---|
| Reflects | Planned usage | Usage that actually happened |
| Includes tax | No | Yes |
| Covers all usage | Only what you entered | Everything that incurred a charge, including what you forgot |
| Does it change | No (unless you edit it) | Every month |
So "estimate 500, bill 780" does not mean the estimate was wrong - the extra 280 is often something you never entered (traffic you did not design for, resources you forgot to terminate, resources other services created for you). Tracing that gap is exactly what the seven persistent-charge sources in why your AWS bill jumped are for.
A more useful mindset: treat the estimate as a decision tool, not a reconciliation tool. Its value is giving you numbers before a decision, not predicting the future bill precisely. Expectation gaps shrink a lot when it is framed that way.
FAQ
Does the Pricing Calculator cost anything, or need an AWS account?
It is free, and AWS states that no cloud computing or AWS experience is needed to use it. Saved estimates are stored on AWS public servers and get a shareable link - note that: do not publish estimate links that contain sensitive architecture detail.
Why does my estimate not match the actual bill?
Three common reasons: estimates exclude taxes; you entered planned usage whereas the bill includes everything that actually incurred charges (forgotten resources, undesigned traffic); and rate provenance - AWS states that where marketing page prices differ from the calculator, the marketing pages are used. Identify which one applies before optimising anything.
Can I use it to work out what Savings Plans would save?
Yes, and this is precisely what the before and after discount rates are for - they appear only in workload estimates. Take the difference between the two figures and weigh it against the commitment term and amount. The buying method itself is in how to buy AWS Savings Plans.
Are the estimate prices the official final prices?
Not entirely. The official wording is that calculator prices come from the AWS price list API, and if they differ from the marketing pages, the marketing pages apply. So use it for structural judgement and relative comparison; for unit prices, use the official pricing pages.
When should I not use the calculator?
When the resources are already running - the bill and usage data are more accurate. The calculator value is concentrated "before you touch anything"; once real usage exists, cost analysis (drilling down by service, usage type and tag) is the main path - see AWS billing: six actions that actually work.
The estimate looks expensive - what is step one?
Fix structure before buying discounts: a commitment discount applies to your current usage, so if the architecture is inherently costly, committing locks the waste in for a year or more. The order is right-size, then architecture (better price-performance silicon, for example), then commitment. Official commitment discounts and settling through a channel act on different layers and can run in parallel - see cloud discount mechanisms compared, and the channel-side route to lowering what you actually pay without touching the architecture in AWS discounts and reseller pricing.