Software & TechnicalFree
AWS Cost Optimization Analysis by Team
Every allocation dashboard hides the unattributed slice. River leads with it, splits it into the five causes that have different fixes, and prices each one.
River reads the billing export, the resource inventory and your tagging policy, then reports what the bill actually costs each team. The first number is the share that cannot be attributed to anyone, split into the causes that each have a different fix. Then the per-team figures, restated so a team on a commitment discount is charged what it paid rather than the list price. Then the actions, ranked by saving, each with an owner.
Search this and page one is the same handful of actions: right-size, buy a commitment, delete unattached volumes, tier your storage, kill idle instances. They are all correct. They are also the part a finance team can already read off a console, and none of them survive the question every engineer asks first, which is whose spend this is. Allocation dashboards answer that with a pie chart whose largest slice is labelled other, and the slice is the whole problem.
Built for the engineer who was told to cut the cloud bill by a fifth and handed a CSV. Reach for it before the first meeting, so the conversation opens on a number somebody can act on. The infrastructure inventory establishes what is actually running and who owns it, the vendor renewal pack runs the commitment decision, and the exec update is where the saving gets reported. Where a resource has no discoverable owner at all, that absence is a finding in its own right with a name against fixing it.
Why the slice labelled other exists
Start with the oldest resources. AWS states it plainly: tags are not applied to resources that were created before the tags were created. So a tagging policy written in March does nothing for the instance launched in 2023, and no policy applied today will ever attribute last month's bill for it. That spend gets attributed by hand, exactly once, or it stays in the unallocated slice for as long as the resource runs.
Then the switch nobody flipped. Tags must be activated in the billing console before they appear on your billing reports, and after activation a key can take up to twenty-four hours to show up and another twenty-four to take effect. Worse, an account moving into another organisation loses the active status on every tag it had. Eight months of disciplined tagging above a dark bill is the ordinary outcome, not the unlucky one.
Two structural gaps remain. Container costs stay at the instance level until you turn on split cost allocation data, which divides a cluster by the CPU and memory each pod consumed, so a shared cluster is a single untagged cost until then. And the discount hides: a covered usage line carries the On-Demand cost it would have paid, offset by a separate negation line grouped by plan, operation, usage type and zone. Sum unblended cost per team and every covered team is overcharged by the size of its own discount.
How it works
Send the export
The billing export for the period, at whatever grain your account produces it.
Add the inventory
The resource list and your tag policy, including the month the policy started.
Name the owners
Which team owns which tag value, service or account, in whatever form you have.
Read the gap
The unattributed share first, then the per-team figures, and then the actions ranked by saving.
What you get
- The share of the bill that cannot be attributed, priced and split by cause
- Per-team cost restated at what the team actually paid, not at list price
- Shared cluster spend divided by the CPU and memory each workload consumed
- Every action ranked by saving, with the owner and what specifically breaks
- Resources predating your tag policy listed apart, because no policy reaches them
- Spend trend by category, so a rise is attached to the thing that actually rose
Common questions
Our tagging is a mess.
That is the finding rather than a reason to wait. The report prices the mess: how much spend is untagged, how much of it predates the policy and can never be tagged retrospectively, and how much is tagged but invisible because the key was never activated. Those three numbers are what a tagging project gets budgeted against.
Is this a cost management dashboard?
No. A dashboard reports the same shape every day and leaves the interpretation to you. This is one analysis that ends in a ranked list of actions with owners against them, written once, for a specific decision. Run it again next quarter and you compare two analyses rather than watching a line move. The spend that growth is about to force belongs in a capacity plan.
We are on Google Cloud, not AWS.
The mechanisms travel because they are consequences of how metered billing works. Labels do not reach resources that existed before them, committed use discounts land on their own line items rather than on the usage they discount, and shared Kubernetes clusters bill at the node until you enable per-workload allocation. Every one of those creates the same unattributed slice.
Will it just tell us to buy a Savings Plan?
It checks the headroom on the commitment you already hold first, because unused commitment is a saving that costs nothing and needs no approval. Only after that does it look at buying more, and the recommendation states the coverage the export actually shows rather than an aspirational rate from a calculator. What a workload actually needs at peak comes from a load test rather than from a utilisation average.
How is each saving priced?
From the effective cost in your own export, so a right-sizing on covered usage is priced at what you pay rather than at the list rate. Pricing a saving off unblended cost is how a plan promising fifteen per cent delivers four, and the difference is entirely the discount you already had.
Does it flag the risk of each action?
Every action names what specifically breaks: the redundancy that disappears, the job that runs slower, the snapshot nobody can identify. Actions whose consequence is a product trade-off are marked as decisions rather than tasks. Where the blast radius is unclear, the solution architecture document settles it before anyone deletes anything. Whether anything would page you if a deletion went wrong is what the monitoring coverage review answers.
Who reads the output?
Two audiences, one report. Engineering gets the actions with owners and consequences. Finance gets the per-team figures and the untagged share with a date against fixing it. The analysis write-up is the discipline for any single number in it that a director will challenge.
AWS Cost Optimization Analysis by Team
Fill in the form and your workspace opens with the work already underway.