Key takeaways
- Every AWS cost number is an aggregation of CUR line items; disagreements between tools are almost always rate-type mismatches
- Unblended, blended, amortized, and net cost answer four different questions, and only one of them is right for any given report
- RI and Savings Plan discounts float across a consolidated bill by default, landing where usage matched first, not where the commitment was bought
- Showback that ignores amortization punishes teams in upfront-payment months and flatters them the rest of the year
Every team that takes AWS cost seriously eventually hits the same wall: the invoice says one number, Cost Explorer says another, the finance export says a third, and all three are technically correct. This guide explains the machinery underneath, the Cost and Usage Report, the four rate types, and the way commitment discounts and credits actually land, so that when two reports disagree, you know which one is answering the question you asked.
Nothing here requires third-party tooling. It is the mechanics of the bill itself, as AWS publishes it, laid out in the order the money flows.
Where every number comes from
Cost Explorer, the invoice PDF, AWS Budgets, and every third-party cost tool are aggregations of this same data at different granularities, with different default rate columns, different handling of credits, and different refresh timing. When two of them disagree, the explanation is almost never a bug. It is a different aggregation choice, and the rest of this guide is a map of those choices.
The four rate types
The practical rule: reconcile cash with unblended, report trends and showback with amortized, and never mix the two in one table. A surprising share of "our costs jumped 40 percent" alarms are an upfront commitment purchase read through the cash column by a report that should have been amortized.
One instance, four numbers
A worked example makes the columns concrete. Take an m7i.xlarge in us-east-1, on-demand rate $0.2016 per hour, running the full 730-hour month, covered by a one-year all-upfront EC2 Instance Savings Plan bought for $1,020 by a different account in the same organization.
Four numbers, one instance, every one of them correct. The report is only wrong when the column and the question do not match.
Working with the CUR directly
Cost Explorer answers most day-to-day questions, but the CUR is where disputes get settled, and querying it directly is less work than its size suggests. AWS delivers it in Parquet, and the standard pattern is Athena over the delivery bucket; AWS provides the table definition, and from there it is SQL.
A handful of columns do most of the work:
line_item_line_item_typeclassifies every row and is the first filter in almost every query:Usage(on-demand),DiscountedUsage(RI-covered),SavingsPlanCoveredUsage,FeeandRIFee(commitment charges),SavingsPlanNegation(the offsetting entries that keep covered usage from double-counting),Credit,Refund, andTax. Summing costs without understanding these types is the single most common way to build a wrong number from correct data.line_item_usage_typenames what was consumed (BoxUsage:m7i.xlarge,NatGateway-Bytes,TimedStorage-ByteHrs) and carries a region prefix outside us-east-1 (USW2-BoxUsage:...). It is the key for any analysis finer than service level.line_item_unblended_costplus thereservation_andsavings_plan_column families supply the rate types: amortized cost is assembled from effective-cost columns rather than read from a single field, which is exactly why tools differ in the decimals.resource_tags_columns carry activated cost allocation tags, one column per tag key.
bill_billing_period_start_date rather than usage dates alone; late-arriving rows are assigned to billing periods in ways that surprise date filters. Second, treat any month as provisional until several days after close, because AWS restates the file as late charges and support fees settle.None of this requires standing infrastructure beyond the delivery bucket and an Athena workgroup. For a finance-facing team, one saved query per reporting convention, each with the rate type, credit handling, and filters written down in the query itself, is a serviceable single source of truth.
How commitment discounts actually land
Reserved Instances and Savings Plans are bought by one account but, by default, discount matching usage anywhere in the organization. AWS applies them in a fixed order, every hour: RI discounts first, matched to usage with the same attributes, then Savings Plans, applied to whatever eligible usage remains, sorted by discount percentage so the commitment dollars go to the highest-discount usage first.
Two consequences follow, and both surprise teams the first time.
First, the discount lands where the usage matched, not where the commitment was bought. A production account's Savings Plan can spend its hours discounting a development account's instances if development's usage happened to match at a higher discount rate. The purchasing account's bill looks worse than expected; another account's looks better; the organization total is right.
Sharing is also a control surface. Discount sharing can be turned off per account, which pins an account's commitments to its own usage. Organizations doing internal chargeback or reselling to external customers need a deliberate position on sharing, because the default silently redistributes real money between cost centers every hour.
Credits, and the order of subtraction
Credits, promotional, migration, or negotiated, apply at the consolidated bill level, and AWS decides which line items they offset unless you use the payer-level allocation controls. For reporting, the question is whether you want them in the rate (net columns) or as a separate line. Both are defensible; mixing them is not. A team that reports gross cost while finance reconciles net cost will disagree by exactly the credit amount and spend an afternoon rediscovering why.
One more subtraction trap: refunds and adjustment line items land in the CUR with negative amounts, dated to the billing period in which they were issued, not the period they compensate. A month with a large refund in it will look artificially cheap in trend lines unless refunds are filtered or reallocated.
Cost allocation: tags decide what can be attributed
Everything above concerns how much; attribution, whose spend is this, runs entirely on cost allocation tags and account structure. Two facts govern what is achievable.
Tags only enter the CUR after they are activated as cost allocation tags in the payer account, and activation is not retroactive: history before activation has no tag values. The earlier tags are activated, the longer the attributable history. AWS does offer a backfill for previously existing tags, but there is a window on how far back it reaches, so activation remains an act-now decision.
Untaggable and untagged spend is structural, not a discipline failure to be driven to zero. Data transfer, some request charges, and shared platform services resist per-team tagging. Mature allocation models attribute what tags can carry, allocate the shared remainder by an agreed formula, and publish the split, rather than pretending a 100 percent tagged bill is achievable.
Account boundaries remain the strongest allocation primitive. Spend in an account belongs to that account with no tagging effort at all, which is why organizations that shape their account structure around ownership get attribution nearly for free, and organizations with one big shared account fight the tagging war forever.
The line items that break naive reports
Beyond usage and commitments, a handful of line item families exist only at certain scopes or follow their own rules, and each one has broken somebody's dashboard.
None of these require special handling beyond awareness: a filter set that names them explicitly, in or out, keeps every downstream number defensible.
Why your tools disagree: a reconciliation checklist
When two numbers for the same month diverge, walk this list in order; the culprit is almost always in the first three.
- Rate type. Unblended versus amortized explains most gaps, especially in months containing commitment purchases. Check what each tool defaults to.
- Credits and refunds. Gross versus net, and whether a refund issued this month belongs to this month's story.
- Scope. Payer-level views include every linked account; account-level views do not. Support charges and some fees exist only at the payer.
- Timing. The CUR is revised continuously for up to several days after month close, and Cost Explorer refreshes on its own cadence. Numbers pulled on the 1st and the 5th legitimately differ.
- Filters. Tax, support, marketplace charges, and reservation fees are included or excluded differently across tools. Two "compute spend" figures rarely define compute identically.
A team that documents its answers to these five, one rate type, one credit treatment, one scope, one snapshot day, one filter set, and applies them everywhere, eliminates nearly all recurring reconciliation work. The disagreements that remain are real, and real disagreements are worth investigating.
The foundation pays for itself
None of this reduces the bill by a dollar on its own. What it does is make every downstream decision trustworthy: a rightsizing win measured in amortized cost survives finance review; a commitment sized against hourly usage holds up in month eighteen; a showback report built on documented conventions ends arguments instead of starting them. The optimizations are covered elsewhere in our research; this is the layer that makes their numbers mean something.
