Blended, Unblended, Amortized, Net: What the Numbers on Your AWS Bill Actually Mean

Open the AWS billing console, Cost Explorer, and the Cost and Usage Report on the same afternoon and you will get three different numbers for the same month. None of them is wrong. They are answers to different questions, and nobody tells you which question you asked.

There are eleven distinct cost figures describing the same dollar of AWS spend. This is what each one means, how every kind of discount shows up, and which number to use for which job.

Why the numbers never match

Three surfaces, three purposes. The invoice is what you owe — cash, this month, including tax. Cost Explorer is an analysis tool that defaults to a different metric than the invoice and offers five more. The Cost and Usage Report is the raw ledger, one row per resource per hour, with several cost columns per row and no opinion about which you should use.

If you have never reconciled them, the reason is almost always that you compared an amortized figure to a cash figure, or included tax in one and not the other.

The three base metrics

Unblended — what you were actually charged, when

Unblended cost is the rate for a line item multiplied by the usage. It is cash-basis accounting: the cost appears on the day AWS charged you for it. This is Cost Explorer's default and the one that reconciles to your invoice.

Its quirk shows up the moment you own commitments. Usage covered by a Reserved Instance has an unblended rate of exactly $0, and carries the line item type DiscountedUsage. The money was spent when you bought the RI, not when you ran the instance. So an all-upfront RI purchase produces one enormous January and eleven suspiciously cheap months — which is accurate, and useless for spotting a trend.

Amortized — what it cost to run, spread evenly

Amortized cost is accrual-basis. It takes those upfront and recurring commitment fees and spreads them across the period the commitment covers, so each day carries its fair share. The January spike disappears and each month reflects what running the workload actually costs.

If you own Savings Plans or Reserved Instances, this is almost always the right metric for analysis, and the only honest way to measure whether a commitment is paying off.

An important trap: Cost Explorer will happily show you "Amortized" and "Net amortized" — but there is no amortized column in the CUR. No lineItem/AmortizedCost, no lineItem/NetAmortizedCost. You have to compute it, using reservation/EffectiveCost for RI-covered rows and savingsPlan/SavingsPlanEffectiveCost for Savings Plan rows. Teams lose afternoons searching for a column that does not exist.

Blended — the one you should not use

Blended cost exists because of consolidated billing. When several accounts share an organization, AWS averages the rates paid across the whole family and charges every account that average.

AWS's own worked example shows why this is dangerous. An organization owns three Reserved Instances and runs one On-Demand instance. Total real cost for the month is $16.56, across 2,880 instance-hours — a blended rate of $0.00575/hour applied to everybody.

The account that spent nothing appears to have spent $12.42. The account responsible for the entire real bill appears to have spent $4.14. If you run chargeback on blended cost, you are billing your teams numbers that are not just imprecise but backwards. AWS itself now notes blended costs are "not used frequently," and shows member accounts their unblended costs.

What "net" actually means

"Net" simply means after your discounts. Net unblended is unblended cost after private pricing, reseller, and bundled discounts are applied. Net amortized is the same adjustment on the amortized figure.

Two things worth knowing. First, AWS defines lineItem/NetUnblendedCost as "the actual after-discount cost that you're paying" — so if you have negotiated pricing, this is your real number and plain unblended overstates your spend.

Second, and this breaks queries: the net columns only appear in the CUR when your account had a discount in that billing period. A dashboard built on NetUnblendedCost works fine for a customer with a PPA, then returns nothing for one without. Always fall back.

Every discount type, and where it appears

Discounts are not adjustments to a usage row. Each one is its own line, with its own type and a negative amount. These are the ones you will meet.

Notice the generic Discount row. AWS's documented list stops there, with the note that the name "may vary and require parsing based on the discount." In real reports that single type resolves into several distinct values you have to know about:

• EdpDiscount — your Private Pricing Agreement discount, still carrying the older EDP name.
• PrivateRateDiscount — negotiated private rates on specific services.
• DistributorDiscount and SppDiscount — the reseller or distributor discount. If you buy AWS through a partner, this is where your partner discount lands.
• RiVolumeDiscount — volume-related adjustments against reservation fees.

This is the single biggest reason home-grown cost queries under-report savings: they filter on the documented type list, and the discount lines quietly fall outside it. Group by lineItem/LineItemType across a full month and look at what you actually have before you write the filter.

One more: blended cost is blank for discount line items entirely. Discounts are computed on unblended cost only. Another reason blended cannot be trusted for anything financial.

Where commitments hide

Reserved Instances and Savings Plans scatter themselves across several line item types, and the Savings Plan pair catches nearly everybody.

Reserved Instances appear as Fee for the upfront payment, RIFee for the monthly recurring charge, and DiscountedUsage for the covered usage at a $0 rate. The real per-hour economics live in reservation/EffectiveCost, which folds the upfront and recurring fees back into the usage rows.

Savings Plans are the trap. Covered usage appears as SavingsPlanCoveredUsage at its full On-Demand value, and is then cancelled by a matching negative SavingsPlanNegation line. They are a pair. Sum unblended cost naively across a CUR and you will double-count every Savings Plan dollar. What you actually paid is in savingsPlan/SavingsPlanEffectiveCost, or its net variant.

Gross usage versus net invoice

"What did we spend?" is an ambiguous question, and the gap between the two honest answers is often large.

Gross usage is what you consumed at list rates before anything is applied. It is the right number for measuring engineering efficiency, because it does not flatter you with commercial discounts you negotiated once and now coast on.

Net invoice is what leaves the bank: gross usage, minus commitment benefits, minus private pricing and reseller discounts, minus credits, plus tax. This is the number your CFO means.

Track both. A team can drive gross usage down while the net invoice rises because credits ran out, and if you only watch the invoice you will conclude the optimization work failed when it in fact succeeded.

Which number for which job

Five queries that are silently wrong

The short version

Use unblended to reconcile with the invoice. Use net unblended if you have negotiated or partner pricing, and always have a fallback for when the column is missing. Use amortized the moment you own a Savings Plan or a Reserved Instance, because it is the only metric that tells you what running the workload actually costs. And do not use blended for anything.

Once those are straight, the commitment decisions become tractable — which is the subject of our three-part series on Savings Plans and Reserved Instances, starting with the instruments and their trade-offs. Read this one first; you cannot measure a commitment with the wrong metric.