Cloud Cost Optimization Services: Who Keeps the Saving?

A proposal for cloud cost optimization services opens with two numbers: how much of your AWS bill the firm believes it can remove, and the share of that it keeps. Both are measured against a baseline nobody has written down, and the contract is usually signed before anyone does.

The list the number comes off is not the vendor's work. Most of it is Cost Optimization Hub, which is part of Billing and Cost Management, costs nothing, and "makes recommendations on resource rightsizing, idle resource deletion, Savings Plans, and Reserved Instances" across every account in your organisation. You can open it this afternoon.

So, the position. Buy the engineering, not the saving. Pay named people against a scope you can read, settle the baseline in writing before anyone holds a role in your account, and keep every commitment purchase in a payer account with your name on it.

What are cloud cost optimization services actually selling?

Not the list. AWS gives you the list.

Cost Optimization Hub covers about two dozen resource types, from EC2 and EBS through RDS, ElastiCache and NAT gateways, and it "accounts for your specific commercial terms with AWS, such as Reserved Instances and Savings Plans", so the figures reflect your discounts rather than list price. Compute Optimizer supplies the rightsizing underneath. AWS also has a FinOps agent in public preview that correlates cost changes with CloudTrail events to find a root cause, free during the preview up to a monthly usage limit.

What is left over is the hard part, and all of it is human. Somebody has to tell the team that owns the oversized RDS instance that it is oversized, and be right. Somebody writes the Terraform, puts it through review, and is awake if the smaller instance cannot take Monday morning. Somebody decides what to leave alone, which is most of the judgement and the subject of which AWS recommendations to ignore.

Price the proposal on that work. A share of a dashboard reading is a fee for something with a free substitute in your own console.

Whose baseline is the saving measured against?

Contingency pricing breaks here, and AWS's own documentation explains why. The page on estimating monthly savings prices each recommendation over "a 730-hour period", as though "you had implemented the recommended action 730 hours ago", normalising shorter lookbacks to the same window. Then it says the quiet part out loud: "your estimated monthly savings is a quick approximation of future savings. The actual savings that you realize is dependent on your future AWS usage patterns."

Read that as a billing clause rather than a help page. A share of the estimate is a share of a forecast built from last month, for an account whose usage is about to move anyway. Three things have to be settled before it becomes an invoice:

• Identified, or realised? A report of opportunities is not a smaller bill. Tie the fee to the invoice, with the measurement month named.
• Which cost number? Unblended, amortised and net amortised can differ by a fifth on the same account, and the choice decides the size of the fee. That argument is in which cost number to report.
• Deduplicated? The Hub says it will "aggregate and deduplicate savings across related cost optimization opportunities". A spreadsheet carrying three recommendations for the same instance will happily add all three.

None of this is sharp practice. Two competent firms reading the same account produce different numbers, because the lookback window and the overlap rules are choices. Which is why the baseline belongs in the contract, not the kick-off deck.

Is that a saving, or a cost you were never going to pay?

Two different things get invoiced as one. A saving is a fall in what you spend. An avoided cost is spend that never arrived.

The clearest case is an anomaly. A runaway job that would have cost three lakh over a weekend gets killed on Saturday morning, and the difference between the projected weekend and the actual one is reported as a saving. It was good work. It is also not money your finance team can find, because the projection was never in the run rate.

Count avoidance if you like, but count it separately and label it. The test is simple enough to put in a statement of work: if the saving is real, it shows up as a lower invoice next month for a named list of accounts. If it only exists in the vendor's deck, it is a forecast, and a forecast is not a basis for a payment.

Who should hold the Savings Plan?

The largest single lever in most of these engagements is a commitment, and a commitment outlives the engagement. Savings Plans run for "a one or three year period", defined as 365 days or 1,095 days, and the price you pay for usage stays the same for the whole of it.

The escape hatch is narrow. Per the Savings Plans FAQ, "any Savings Plans that has an hourly commitment of $100 or less, purchased in the past 7 days and in the same calendar month can be returned". Above that line, or a week later, you own it for the term. A three-year plan recommended in month two of a six-month engagement is a decision the vendor books and you carry.

Then ownership. By default "the benefit provided by Savings Plans is applicable to usage across all accounts within an AWS Organization/consolidated billing family", and an organisation can "choose to restrict the benefit of Savings Plans to only the account that purchased them". So ask which payer account the purchase lands in. If your accounts sit under a partner's organisation, the commitment sits in their name and the discount is theirs to direct, which is the same problem as a dashboard that is not your invoice, covered in does the dashboard match the invoice. How much to commit in the first place is its own question.

Who signs off a change that touches a control?

You do, and the RBI leaves no room to read it otherwise. Section 4(1) of the Outsourcing of Information Technology Services Directions, 2023 says "outsourcing of any activity shall not diminish RE's obligations as also of its Board and Senior Management, who shall be ultimately responsible for the outsourced activity". Section 17(6) adds that where several providers are involved, "the RE remains responsible for understanding and monitoring the control environment of all service providers".

That matters because some of the cheapest recommendations in a regulated account are the ones a regulator asked for. The warm standby a rightsizing tool reads as idle. The second trail nobody can switch off. The log copy that has to survive 180 days rather than 90. We went through those line by line in what a fintech can cut without failing an audit, and the pattern holds: a saving that removes evidence is a cost deferred to your next audit.

Two smaller things belong in the same conversation. What the vendor's role can read, because a cost tool asking for more than billing data is asking for your resource configuration too, and that is worth settling before you create the role. And where the analysis runs: AWS's FinOps agent is available in US East (N. Virginia) only, managing costs across other regions from there, a decision to take deliberately rather than discover, for the reasons in what RBI data localisation actually requires.

What can you run on Monday?

Two commands, ten minutes. Between them they give you the baseline the proposal will be argued against, and you want it before the engagement starts.

First, what AWS already thinks is available, with the effort rating it attaches to each one:

aws cost-optimization-hub list-recommendations \
  --region us-east-1 \
  --query 'items[].{type:currentResourceType,action:actionType,
            effort:implementationEffort,saving:estimatedMonthlySavings}' \
  --output table

Then your real spend, on the basis the fee will be measured on, for the three months before anybody touched the account:

aws ce get-cost-and-usage \
  --region us-east-1 \
  --time-period Start=2026-08-01,End=2026-11-01 \
  --granularity MONTHLY \
  --metrics NetAmortizedCost \
  --group-by Type=DIMENSION,Key=LINKED_ACCOUNT

Save both outputs with the date on them. That file is your baseline, and worth more in the negotiation than anything in the deck. If the totals disagree with what a vendor quotes as identified savings, the gap is the conversation.

When is a share of the saving the honest answer?

More often than the argument above suggests. Three situations.

When you have nobody to do the work. A contingency fee with a defined baseline and a cap beats a retainer you will not draw down, and it beats a rightsizing project that sits on the roadmap for a year.

When the vendor brings a rate instrument you cannot reach alone, such as aggregated commitment across an estate much larger than yours. A real product, not a reading of your console.

And when the share is small, capped, and paid against invoice reductions you can see in your own billing data. We would rather be paid for the engineering, and we say so in proposals, but a capped share of a measured reduction is a fair contract. What is not fair is an uncapped percentage of a forecast nobody defined, which fails the same way as the undefined percentage of spend in what a DevOps fee actually buys.

The short version

Open Cost Optimization Hub and read the list yourself, this week. It is free, and it is the same list the proposal is built on.

Then, before signing: capture the baseline with the two commands above and attach it to the contract. Define the fee against realised reductions in net amortised cost, for named accounts, in named months. Cap it. Keep commitment purchases in a payer account you own, and keep a named person on your side signing off anything that touches a control a regulator asked for.

Pay for the engineering. The list was always free.

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.