Cloud FinOps on AWS: Which Cost Number Should You Report?

Every cloud FinOps programme we have been brought into already had a dashboard. Most of them did not have an agreed definition of the word cost, which is why two people in the same meeting quote different totals for the same month and both of them are right.

AWS will give you five numbers for September. All five are legitimate. They are not interchangeable, and the distance between them is wide enough to decide whether last quarter's migration looks like a success.

So here is the position. Choose one cost metric, put its name in the title of the dashboard, and report everything against it. Until that is settled, every optimisation argument in the company is secretly an argument about units.

Why does a cloud FinOps practice stall on its first report?

Because the first report has to choose a metric, and nobody in the room knows there is a choice. AWS lists them under advanced options in Cost Explorer: unblended, amortized, blended, net unblended and net amortized.

Three of them matter. Unblended cost "reflects the cost of the usage". Amortized cost "reflects the effective cost of the upfront and monthly reservation fees spread across the billing period". Net amortized, per the Cost Explorer data guide, "reveals the true cost by showing how post-discount fees amortize over the period of time that the upfront or recurring fee applies".

Buy a three-year partial upfront commitment in March and unblended cost draws a cliff in March and a cheap April. Amortised draws a flat line through both. Same account, same money, two charts supporting opposite conclusions about whether the platform team is doing well.

Blended cost is the one to leave alone. AWS defines it as "the average cost of usage across the consolidated billing family", which describes how consolidated billing shares a rate rather than anything about an account inside it. We have twice found it quietly powering a chargeback report.

Unblended or net amortised: which one goes in the report?

Our rule, and we will defend it: net amortised for every internal number, unblended for reconciliation against the invoice.

The reasoning is that a commitment you have already paid for should not make a service look free for the eleven months afterwards. Engineering decides on the internal number, so it has to carry what the capacity costs to hold. Finance ties a figure to money that left the bank, and that is unblended.

Credits are the trap underneath both. Net metrics remove discounts; credits sit on top as their own charge type. Draw the chart net of credits and you have drawn a fall in run rate that never happened, expiring on a date somebody else knows. Where that money comes from is the subject of who actually pays for AWS consulting work. Keep credits as their own line.

The honest concession: if you have never bought a Savings Plan or a Reserved Instance, unblended and amortised are the same number and this section is theory. Report it, and revisit the question the week you make your first commitment.

What does AWS's cost efficiency score actually measure?

Less than the name suggests, and it is still worth switching on. AWS publishes the formula in the cost efficiency documentation for Cost Optimization Hub: "Cost efficiency = 1 - (Potential Savings / Total Optimizable Spend) × 100%", worked through as $100,000 of optimisable spend and $10,000 of identified savings giving 90%.

Read the denominator first. Total optimisable spend covers twelve named services and "uses your Net amortized costs after removing any credits and refunds you might have". The numerator is whatever the Hub finds by itself: rightsizing, idle resources and commitments, deduplicated so an idle instance is not counted twice.

So 92% does not say your architecture is efficient. It says there is not much left that this one tool knows how to look for. Only one of those claims survives a question from someone who has read the documentation.

Two more properties before anyone sets a target on it. The metric is "based on a rolling 30-day spend and today's savings opportunity", so it moves when a recommendation appears rather than when you act. And it needs Compute Optimizer, with AWS noting that if you see nothing, "it could be due to high variance in your AWS usage". A payments company whose traffic triples around a settlement window is that shape exactly.

Which of your spend does no optimiser look at?

This is where a FinOps practice earns its budget. The twelve services in that denominator are EC2 instances, ECS, EKS, EBS volumes, RDS, SageMaker, Redshift, Lambda, OpenSearch, MemoryDB, DynamoDB and ElastiCache. Compute and databases.

Now write out what a regulated fintech actually argues about on its bill. CloudWatch logs and custom metrics. KMS requests. AWS Config evaluating a rule on every change. GuardDuty across every account. Cross-zone data transfer. Marketplace. None of it is in the twelve.

The sharpest case is the NAT gateway. It appears in Cost Optimization Hub's list of supported resources, so you get a recommendation about the gateway, while the per-gigabyte processing charge that is the actual bill sits outside the efficiency metric altogether. What that charge does to a private subnet architecture is in what a fintech can cut without failing an audit.

The cadence that works is dull. Once a month one engineer reads the tail by service, largest increase first, and asks who turned each thing on. Tools handle compute. The tail needs a person.

What is the unit metric, and who owns the denominator?

A total is not a FinOps metric. Cost per thousand payment authorisations is. So is cost per KYC check, cost per active tenant, cost per million API calls.

Two halves have to meet in one query. The numerator is cloud cost allocation, the split by account, cost category or tag that we argued out in who owns which number. The denominator is a volume the business already counts.

That second condition is the one teams skip, and it decides whether the metric lasts a quarter. If finance does not already report the volume, nobody trusts a cost per unit built on it, and the first time the number moves the meeting becomes a debate about the denominator. A slightly wrong denominator everyone has agreed to beats a better one nobody has.

Where we concede ground: below roughly twenty thousand dollars a month, unit economics costs more attention than it returns. The whole practice at that size is one metric, a list of idle resources, and somebody actually reading the bill.

Does the billing data have to sit in India?

No, and saying so saves teams a fortnight. The RBI's direction on storage of payment system data requires that "the entire data relating to payment systems operated by them are stored in a system only in India", scoped to "the full end-to-end transaction details / information collected / carried / processed as part of the message / payment instruction". A cost and usage export holds none of it.

Which matters, because AWS's FOCUS 1.2 export is created in US East (N. Virginia) and carries usage from every region. That is not a localisation problem, though the bucket still belongs in an account you own, since the export lists your organisation structure. Where residency genuinely does bite is in what RBI data localisation actually requires.

FOCUS also gives you four standard cost columns, ListCost, ContractedCost, BilledCost and EffectiveCost, named the same way across vendors. The five-metric confusion above is AWS-specific, and once lock-in starts costing real money a shared schema is cheap insurance.

What can you run on Monday?

Fifteen minutes and two API calls tell you which number your reports are built on. Cost Explorer is a single global endpoint, so point it at us-east-1 wherever you run.

aws ce get-cost-and-usage \
  --region us-east-1 \
  --time-period Start=2026-09-01,End=2026-10-01 \
  --granularity MONTHLY \
  --metrics UnblendedCost NetAmortizedCost \
  --group-by Type=DIMENSION,Key=SERVICE \
  --query 'ResultsByTime[0].Groups[].{service:Keys[0],
            unblended:Metrics.UnblendedCost.Amount,
            amortised:Metrics.NetAmortizedCost.Amount}' \
  --output table

Any service where those two columns disagree is a service whose cost depends on a choice nobody wrote down. Then find out how much of the month was credit:

aws ce get-cost-and-usage \
  --region us-east-1 \
  --time-period Start=2026-09-01,End=2026-10-01 \
  --granularity MONTHLY \
  --metrics UnblendedCost \
  --group-by Type=DIMENSION,Key=RECORD_TYPE \
  --output table

Three things come out of that quarter of an hour: the metric your dashboard is drawing, the services where the choice changes the answer, and the credit line. Then write the chosen metric into the dashboard title. It is the smallest item here and it ends the most arguments.

When is a cloud FinOps practice not worth standing up?

When the bill is small enough that one person already reads it, and when the architecture is about to change anyway.

Under a few thousand dollars a month, a weekly look at Cost Explorer and a list of resources nobody has logged into beats any process you could design. If you are eighteen months from product-market fit and funded by credits, most of what you optimise now gets deleted in the rewrite anyway. Tag as you build, keep the export running, and spend the attention on the product.

It earns its overhead when more than one team can move the bill and no single person can explain it, which is usually the second product line rather than a dollar figure.

The short version

Report net amortised internally and unblended for reconciliation, and put the name of the metric on the dashboard this week. Keep credits as a visible line so their expiry is a date rather than an incident.

Treat the cost efficiency score as a trend for compute, and read the tail outside its twelve services by hand once a month. Build a unit metric only on a volume the business already reports.

If you want the fast version: run the two commands above, find the services where the columns disagree, and start the argument there.

This is engineering guidance, not legal advice. Regulations and their annexures are amended over time; read the current text and take your compliance position from counsel.