- Default: share. Purchase commitments centrally and share across accounts/subscriptions. Higher utilization, more savings.
- Exception: keep local when showback or chargeback accuracy matters more than the last few percent of savings.
- Not a binary choice. You can share some commitments and keep others local. Match the mechanism to the workload.
The default case for sharing
RIs and Savings Plans are usually bought by the central FinOps team. That makes sense — optimising rates across the whole organisation is a centralised concern. It also opens a simple question: once you buy a commitment, do you share it with every account or keep it in the account that bought it?
On paper, sharing wins. One commitment pool floating across all accounts gets more chances to match running resources, which lifts utilization, which lifts savings.
The mechanics on each cloud:
- AWS — Purchase in the management (payer) account. Any linked account with RI Sharing enabled automatically inherits the discount. Accounts with sharing disabled get skipped.
- Azure — Set the scope to Shared when purchasing. The discount applies across all eligible resources in the enrollment.
- GCP — Different model. CUDs are purchased and consumed inside a project by default. Sharing across projects is possible via commitment sharing at the billing account level, but the default is local.
┌─────────── Shared commitment (AWS / Azure) ──────────┐
│ │
│ ┌───────────────────┐ │
│ │ Management / │ Buys RI │
│ │ Payer account │ │
│ └─────────┬─────────┘ │
│ │ │
│ ┌───────────────┼───────────────┐ │
│ ▼ ▼ ▼ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Acct A │ │ Acct B │ │ Acct C │ │
│ │ m5.large │ │ m5.large │ │ (idle) │ │
│ │ uses RI │ │ uses RI │ │ │ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ │
│ Unused hours in Acct C flow to A and B. │
│ Result: higher utilization, lower waste. │
│ │
└──────────────────────────────────────────────────────┘
┌── Local commitment (GCP default, or AWS/Azure with sharing off) ──┐
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Acct A │ │ Acct B │ │ Acct C │ │
│ │ Buys RI │ │ No RI │ │ Buys RI │ │
│ │ m5.large │ │ pays │ │ m5.large │ │
│ │ uses RI │ │ On-Demand│ │ IDLE 8h │ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ │
│ Acct B cannot use unused RI hours from Acct C. │
│ Result: more waste, but cleaner per-account accounting. │
│ │
└───────────────────────────────────────────────────────────────────┘So why would anyone choose the local option?
Why local can still be the right call
If sharing always saves more money, the only reason to go local is that savings is not the only thing you are optimising for.
Showback and chargeback. When a commitment is shared, the discount gets redistributed across accounts by the cloud’s own allocation rules. Those rules are not always easy to explain to a business unit that wants to know exactly what its cloud spend was this month. Local commitments are simple: the account that bought the RI pays for the RI and benefits from the RI. Clean line-item, clean chargeback.
Total Cost of Ownership (TCO) calculations. Same logic. If a team owns a workload end-to-end and needs to report its true cost — for pricing a product, for an internal P&L, for a migration ROI — shared commitments muddy the picture. The commitment value gets sprayed across the accounts that happened to use the hours.
Guaranteed local utilization. If a commitment is going to be 100% consumed locally anyway (a production database running 24/7 in one account), sharing does not add anything. Buying it locally costs nothing and gives you the accounting clarity for free.
The pattern is: sharing raises utilization only when accounts have mismatched usage shapes. When one account already uses the commitment fully, there is nothing to share.
How to decide — a simple rule
Ask one question per commitment: does the workload that will consume this commitment live entirely in one account?
- Yes, and it will run 24/7 → buy local. No downside.
- Yes, but usage is variable → buy local if chargeback accuracy matters. Otherwise share.
- No, usage spans multiple accounts → share. This is where shared commitments earn their keep.
You do not need to pick one mode for the whole organisation. In my experience, the cleanest setup is shared by default, with specific local commitments carved out for the workloads that need strict cost attribution.
Summary
- Share commitments to maximise savings through higher utilization.
- Keep them local when clean showback, chargeback, or TCO reporting matters more than the marginal extra savings.
- Decide per commitment, not per organisation. Mixed strategies are normal.
Thanks for reading. If this helped, share it. Questions or topic suggestions — send them through.