Amortized vs unblended cost in AWS (2026)

A Cost and Usage Report gives you at least five different answers to "what did this cost", and picking the wrong one is how a chargeback report ends up billing a team for a commitment it does not own. The columns are not interchangeable and AWS does not pick one for you.

What is AWS amortized cost?

Amortized cost spreads an upfront commitment fee across the usage it paid for, instead of dropping the whole fee on the day you bought it. The Cost Explorer documentation describes it as showing "the cost of your AWS commitments, such as Amazon EC2 Reserved Instances or Savings Plans, spread across the usage of the selection period", calculated "by combining the unblended upfront and recurring reservation fees" into "the effective rate over the period of time that the upfront or recurring fee applies".

Unblended cost does the opposite. It records cash as it is charged. Buy a three-year All Upfront Reserved Instance in March and unblended puts the whole payment in March, then reports zero for that instance for the next 35 months. Both numbers are correct. They answer different questions.

What is net amortized cost in AWS?

"Net" means after discounts. AWS defines net amortized as showing commitment cost "after discounts with the additional logic that shows how the actual cost applies over time", so that "the net amortized cost dataset reveals the true cost by showing how post-discount fees amortize over the period of time that the upfront or recurring fee applies".

The important operational detail is that the net columns are conditional. The CUR line item column reference says of lineItem/NetUnblendedCost: "This column is included in your report only when your account has a discount in the applicable billing period." The same sentence repeats across every net column in the reservation and Savings Plans groups.

So a query that sums a net column is a query that returns nothing on an account with no private pricing agreement, and returns nothing for the months before the agreement started on an account that has one. It does not error. The column is absent, or null, and the total is zero. If you are building a dashboard for more than one tenant, coalesce.

Which cost column should you actually use?

There are five in the line item group, and two more that only appear once commitments are involved. This is the whole set, quoted from the AWS dictionary.

There is no single amortized_cost column. Cost Explorer computes amortized cost for you; in the CUR you assemble it, by taking the effective cost where a commitment applied and the unblended cost where none did. Which is why the amortized total from a hand-written query so often fails to match Cost Explorer, and why that is one of the six documented reasons the two disagree.

The commitment-side columns have their own reference pages, and they are worth opening once rather than guessing at names: the reservation details page defines EffectiveCost as the amortizedUpfrontCostForUsage added to the recurringFeeForUsage, and the Savings Plans details page lists which services each column applies to, currently EC2, Fargate, Lambda and SageMaker AI.

Why is blended cost the wrong answer?

Blended cost exists for one purpose and it is not chargeback. AWS defines the blended rate as "the average cost incurred for each SKU across an organization", and the consolidated billing documentation explains the mechanism: "Blended rates are the averaged rates of the Reserved Instances and On-Demand Instances that are used by member accounts in an organization ... AWS calculates blended costs by multiplying the blended rate for each service with an account's usage of that service."

Averaging across the organization means a member account that bought nothing is charged part of another account's reservation benefit, and the account that did buy it is credited less than it paid. AWS's own note settles the question: "AWS shows each member account their charges as unblended costs." If AWS does not use blended cost for its own member-account view, neither should your chargeback report.

One more reason not to build on it, from the line item reference: "BlendedCost is blank for line items that have a LineItemType of Discount." A sum over blended cost silently drops your discounts.

How do the line item types change the answer?

Summing any cost column across the whole report double counts, because Savings Plans appear on two rows that cancel. The LineItemType definitions are explicit: SavingsPlanCoveredUsage is "any on-demand cost that is covered by your Savings Plans", and those line items "are offset by the corresponding Savings Plans negation items", which arrive as SavingsPlanNegation.

So the on-demand price of covered usage is present as a positive number and cancelled by a negative one, and the real cost is carried separately in savings_plan_savings_plan_effective_cost. A naive SUM(line_item_unblended_cost) nets those two to roughly the right total by accident, but a query filtered to a single service, team or tag can easily pick up one side and not the other.

The RI case is the one that catches people first. AWS states that "For Amazon EC2 and Amazon RDS line items that have an RI discount applied to them, the UnblendedRate is zero." Group unblended cost by team and every team running on reserved capacity looks free.

AWS publishes worked examples of the Savings Plans line item pairs in Understanding Savings Plans in the CUR, which is the page to read before writing any query that filters rather than totals. Note also FlatRateSubscription in the type list, "any hourly subscription fee AWS applied to your bill for services with subscription fee". It is a newer type, which means every query written before it existed silently excludes it.

What does this look like as a query?

This is the shape we run over a partitioned CUR. It builds amortized cost the way Cost Explorer does, taking the effective cost where a commitment applied.

SELECT resource_tags['team'] AS team,
       SUM(line_item_unblended_cost) AS cash_cost,
       SUM(
         CASE line_item_line_item_type
           WHEN 'SavingsPlanCoveredUsage' THEN savings_plan_savings_plan_effective_cost
           WHEN 'DiscountedUsage'         THEN reservation_effective_cost
           WHEN 'SavingsPlanNegation'     THEN 0
           WHEN 'SavingsPlanRecurringFee' THEN 0
           WHEN 'RIFee'                   THEN 0
           ELSE line_item_unblended_cost
         END
       ) AS amortized_cost
FROM   cur
WHERE  billing_period = '2026-07'
  AND  line_item_line_item_type NOT IN ('Tax', 'Credit', 'Refund')
GROUP  BY 1
ORDER  BY amortized_cost DESC;

Three notes on running it. The tag key in CUR 2.0 is team inside the nested tags column, not the resourceTags/user:team form the original CUR used, and it stays empty until the tag is activated, which is a separate step from applying it: tagging is not activation. The RIFee and SavingsPlanRecurringFee rows are zeroed because the commitment fee is already distributed across the effective-cost rows, so counting it again doubles it. And the two totals should differ. If cash_cost and amortized_cost match to the cent, you have no commitments, or your query is not seeing them.

For the table setup, partition projection over the CUR avoids crawlers entirely. If you are choosing between export formats first, CUR 2.0 and FOCUS are not alternatives: FOCUS normalises cost columns across clouds and gives up the AWS-specific ones this post is about.