Bought in one account, spent in another

Business Challenge

The previous post built an allocation model: tags for what can be labelled, backfill for what was labelled late, split charge rules for what has no single owner. It works on the numbers that reach it. This post is about the layer underneath, which has already moved the money by the time those numbers exist.

A platform team buys a three-year Compute Savings Plan from the shared services account, because that is where the commitment budget lives and where finance wanted the purchase recorded. The following month, shared services shows almost none of the benefit. A product account nobody consulted shows most of it. Nothing is wrong, nobody misconfigured anything, and the report is accurate.

It happened because a commitment is not attached to the account that bought it. It is applied, hour by hour, to whichever eligible usage saves the most — owner first, then everyone else.

1The discount goes where the saving is largest

The rule is explicit. Savings Plans “are applied to your highest savings percentage first”, with ties broken by “the first usage with the lowest Savings Plans rate”. Across an organisation, “accounts with the largest calculated savings are prioritized”.

So the benefit follows the shape of usage, not the shape of your org chart. An account running expensive Windows instances and an account running cheap Linux ones will not receive the same share of the same commitment, and the split changes as their workloads change.

Fix

Stop treating the purchase account as the beneficiary. It is the payer of record, not the recipient.

2The allocation is provisional until the last day of the month

This is the detail that turns a reporting inconvenience into a reporting trap. AWS: “each estimated bill is computed by using the last set of preferences. The final bill for the month is calculated based on the preferences set at 23:59:59 UTC time on the last day of the month.”

A sharing preference changed on the 30th does not apply from the 30th. It applies to the whole month. Every hour since the 1st is recomputed against it, so a chargeback figure circulated on the 15th can be wrong by month end without anybody touching a workload.

Fix

Treat mid-month commitment allocation as an estimate, and say so on the report. Freeze sharing preferences during the month if finance needs stability.

3An account leaving can switch the discount off

“If a Savings Plans owner account leaves the organization, Savings Plans no longer apply to the consolidated bill.” The commitment is still paid for. It simply stops discounting everyone else.

That makes an account migration — a divestment, a reorganisation, moving an account between organisations — a financial event as well as an administrative one, and it is rarely on the checklist for either.

Fix

Know which account owns each commitment, and make owner-account moves a change that requires sign-off from whoever bought it.

Architecture

Two mechanisms decide where a discount lands: the order commitments are applied in, and the sharing mode that scopes who is eligible.

The application order

Reserved Instances are consumed before Savings Plans. Then EC2 Instance Savings Plans, which are narrower, before Compute Savings Plans, which AWS applies later precisely because they have broader applicability — spending the specific commitment first leaves the flexible one available for whatever is left. Anything still uncovered is billed On-Demand.

Inside that, the commitment is spent on the highest discount percentage available. AWS's own worked example has an r5.4xlarge at $1.00 On-Demand against $0.70 under a Compute Savings Plan — a 30% saving — and Fargate at 25%, so the r5 usage is covered first even if the Fargate usage belongs to a different team.

And none of it banks: “each hour's commitment can only be used within that hour and cannot be carried over”. An idle hour is simply spent. That is the real argument for sharing being on — not fairness, but that unused commitment is money already gone.

The three sharing modes

Organization-wide

Owner first, then remaining benefit is available to any account in the organisation. AWS's framing: it maximizes overall commitment discount rates. Best utilisation, least predictable allocation.

Prioritized group

Owner first, then a defined group, then the rest of the organisation. A middle position: a business unit gets first refusal on what it paid for, and nothing is wasted if it does not use it all.

Restricted group

Owner first, then the group, and nowhere else — AWS notes no sharing occurs outside designated groups even with unused capacity. Predictable, and it can leave commitment unspent.

Per-account deactivation

Sharing can be switched off for individual accounts. Both the purchasing account and the receiving account must have it on for a discount to flow between them.

Group sharing is built on Cost Categories, with real constraints

Groups are defined with AWS Cost Categories, and the rules are narrow: each account can belong to only one sharing group, the payer account cannot be part of a sharing group, and only the Accounts dimension may be used. If you have already built Cost Categories for the allocation model in the previous post, they are probably not reusable here without checking those conditions first.

Why This Architecture Holds Up

Utilisation and attribution are in direct tension

The three modes are a single dial between two things you cannot have at once. Organization-wide sharing maximises the chance a commitment is fully consumed, and makes the beneficiary unpredictable. Restricted group sharing makes the beneficiary predictable, and AWS says plainly it “might result in some underutilized commitments”.

There is no configuration that gives both, and the choice is a finance decision rather than an engineering one. The engineering contribution is making the trade explicit: restricted sharing has a price, and that price is unspent commitment on a plan already paid for.

Turning sharing off is not a neutral act

AWS states it directly: “deactivating Reserved Instance and Savings Plans discount sharing can result in higher monthly bills”. It is sometimes still the right call — a regulated subsidiary that cannot receive cross-entity benefit, an account being prepared for divestment — but it should be taken as a decision with a number attached, not as tidying.

What this does to the allocation model from #49

The previous post's mechanisms all operate on costs that already exist. Commitment discounts operate before that: they decide what the cost is for a given account-hour. So a tag cannot attribute a discount, and a split charge rule cannot redistribute one, because by the time either runs the money has already moved.

That is why commitment reporting usually needs its own treatment rather than folding into the tag model — and why the honest version of a chargeback statement separates usage attributed by tag from discount received by commitment sharing. They answer different questions and only one of them is under the receiving team's control.

Key Architecture Decisions

Decision	Choice	Reasoning
Default sharing mode	Organization-wide, unless there is a reason not to	Unused commitment does not carry to the next hour. Maximum utilisation is the default that wastes least.
When predictability matters more	Prioritized group before restricted	It gives a business unit first claim on what it bought without stranding the remainder, which restricted mode can.
Purchase account	Treated as payer of record, not beneficiary	Owner is served first, but the rest follows savings percentage. Expect the benefit to land elsewhere.
Mid-month reporting	Labelled as an estimate	The final bill uses the preferences in force at 23:59:59 UTC on the last day, applied to the whole month.
Owner account moves	Gated, with the commitment owner consulted	If the owner leaves the organisation, the Savings Plans stop applying to the consolidated bill entirely.
Chargeback statement	Usage and commitment benefit reported separately	One is attributable to the team, the other is an artefact of organisation-wide optimisation. Merging them makes both unarguable.

The sequencing detail that catches people out

Both sides must be switched on. AWS states that both purchasing and benefit receiving accounts must have sharing activated to share discounts, and separately that the Savings Plans owner account “must be active in the RI and Savings Plans discount sharing preferences” for the discount to reach other accounts at all.

That produces a quiet failure mode. Deactivating sharing on the purchasing account — perhaps to stop it receiving other teams' discounts — also stops its own commitment from benefiting anybody else. The plan keeps billing and the discount stops flowing, and nothing announces it.

Closing Thought

Fifty posts in, the recurring finding has not changed much: most cost and security controls are real, correctly configured, and answering a narrower question than the sentence used to describe them. Commitment sharing is the purest example yet, because here the gap is not in the tooling at all. AWS documents the behaviour precisely. It is just that almost nobody reads the application order before buying, and the mental model — we bought it, so we have it — is wrong in a way that produces a correct report nobody believes.

The useful reframe is to stop thinking of a commitment as an asset held by an account and start thinking of it as a discount schedule applied to the organisation, hour by hour, in a fixed order, finalised at the end of the month. Every confusing thing about it follows from that sentence, and so does every sensible decision: why sharing should usually be on, why restricted mode costs something real, and why a mid-month chargeback number is an estimate.

Next in this series

Cost & Governance — budgets and anomaly detection: why a budget alert almost always arrives after the money is spent, what anomaly detection actually models, and the difference between a control that warns you and one that stops you.

AWS Architecture Series #50 — Bought in one account, spent in another