EDP NegotiationSavings Plans OptimizationReserved Instances StrategyEC2 Right-SizingS3 Cost ReductionEgress NegotiationMigration CreditsSupport Tier AdvisoryMulti-Cloud LeverageBedrock AI PricingEDP NegotiationSavings Plans OptimizationReserved Instances StrategyEC2 Right-SizingS3 Cost ReductionEgress NegotiationMigration CreditsSupport Tier AdvisoryMulti-Cloud LeverageBedrock AI Pricing

RI Sharing Across Linked Accounts in AWS Organizations

By default, Reserved Instance and Savings Plan discounts float freely across every account in an AWS Organization. That sharing is powerful for coverage but creates real complications for chargeback, governance, and who controls the discount.

Published February 2026Cluster Reserved Instances11 min read

In a single AWS account, Reserved Instances are simple: the discount you buy applies to your usage. In an AWS Organization with consolidated billing, that simplicity disappears. By default, Reserved Instance and Savings Plan discounts are shared across every linked account in the Organization — a discount purchased in one account can apply to matching usage anywhere in the family. This sharing is one of the most valuable features of consolidated billing and one of the most common sources of chargeback confusion.

Across 500+ engagements at $2.4B+ in AWS spend reviewed, RI sharing is the mechanism that lets large buyers run high coverage efficiently — and the mechanism that makes their cost reports impossible to read unless the allocation logic is explicit.

How sharing works by default

When RI sharing is enabled (the default in any Organization with consolidated billing), AWS applies each Reserved Instance discount to whichever matching usage across the entire billing family maximizes the benefit each hour. A zonal or regional RI bought in the platform account can discount an identical instance running in a product team's account, even though that team never purchased anything.

The same is true of Savings Plans. A Compute Savings Plan purchased centrally floats across every linked account's eligible EC2, Fargate, and Lambda usage. This is exactly what makes centralized commitment purchasing efficient: one team buys, the whole Organization benefits, and coverage gaps close faster.

Why default sharing is usually right

For most buyers, leaving sharing on is the correct default. It produces the highest possible utilization on every commitment because the discount always flows to whatever matching usage exists, rather than sitting idle in the purchasing account. It also lets a central FinOps team manage the commitment portfolio holistically rather than forcing every account to buy its own coverage — which is the only way to run a clean RI coverage gap analysis at the consolidated level.

Key point

Coverage and utilization should always be measured at the consolidated billing-family level when sharing is on. Measuring per-account understates true coverage and leads teams to double-commit on usage that is already discounted by another account's RI.

When to opt accounts out of sharing

The management account can disable RI and Savings Plan sharing for specific linked accounts. There are legitimate reasons to do so:

  • Strict chargeback separation. A business unit that must see its own commitments and its own discounts, with no cross-subsidy, can be isolated.
  • Acquired entities with separate P&Ls that should not share discounts during an integration period.
  • Regulated or ring-fenced workloads where cost attribution must be provably independent.

The trade-off is efficiency: an isolated account cannot benefit from the family's spare coverage and must buy its own. Opting out almost always raises total commitment cost, so it should be a deliberate governance choice, not a default.

The chargeback implication

Sharing breaks the intuitive link between who buys and who benefits. The purchasing account carries the commitment fee; the discount can land anywhere. If you charge each account its raw cost, the purchasing account looks expensive and the consuming accounts look artificially cheap. This is precisely the distortion that the blended-versus-amortized distinction exists to solve — see RI blended vs unblended cost for the metric mechanics and Savings Plans chargeback allocation for the distribution policy.

The fair model is to distribute the discount to the accounts that actually consumed the covered usage, in proportion to that consumption, while amortizing the commitment fee back to a central FinOps cost center or splitting it by the same proportions. Either way, the allocation must be explicit, because AWS does not make this business decision for you.

Governance: who controls the discount?

Sharing also raises a control question. Because any account's purchase benefits the whole family, an uncoordinated account can buy a commitment that the central team did not plan for, changing the coverage picture for everyone. Mature Organizations centralize commitment-purchasing authority — usually by restricting RI and Savings Plan purchase permissions to a FinOps or platform account through IAM and Service Control Policies — so that the shared discount pool is managed deliberately. The purchase-control discipline overlaps with the approval workflow in the broader commitment process.

SettingCoverage efficiencyChargeback clarityTypical use
Sharing on (default)HighestRequires allocation policyMost organizations
Selective opt-outLower for isolated accountsClean per-unitRing-fenced business units

The cross-Organization limit

Sharing only works within a single AWS Organization. Buyers with multiple Organizations — common after acquisitions — cannot share RIs or Savings Plans across them. Each Organization is a separate billing family, which produces apparent coverage gaps that are structural artifacts rather than real gaps. Consolidating Organizations is the only way to pool commitment across them, and that is a significant operational undertaking.

How AWS decides where the discount lands

When sharing is on, AWS does not split a Reserved Instance discount across accounts — it applies the discount to whichever single matching usage maximizes the benefit in each hour. The selection runs hour by hour, so the account that receives a given RI's discount can change from one hour to the next depending on which accounts have matching running instances. For Savings Plans, AWS similarly applies the committed rate to the usage with the highest On-Demand rate first, maximizing the dollar value of the discount across the family. This optimization is automatic and not configurable beyond the on/off sharing switch.

The practical consequence is that you cannot predict, in advance, which account will show a given discount in a given hour. This is fine for total cost — the family pays the same regardless — but it is exactly why per-account cost reports are misleading under sharing, and why allocation must be a deliberate post-processing step rather than something read directly off the raw usage data. The hour-by-hour reassignment is invisible in monthly summaries but drives the apparent cost of every account in the family.

The management account and discount ownership

A subtle governance point is that the management (payer) account technically owns the commitment fees, even when the discounts flow to linked accounts. This means the management account's raw cost can look enormous — it carries all the upfront and recurring commitment charges — while the linked accounts look cheap. Treating the management account's cost as a real operational cost is a mistake; its commitment charges should be amortized and redistributed, not attributed to the payer account as if it ran the workloads. Many cost reports double-count by leaving the fees in the management account and also crediting the discounts to the linked accounts.

The clean model treats the management account as a pass-through for commitment economics: amortize the fees, distribute them and the discounts to the consuming accounts by the allocation policy, and leave the management account showing only its own genuine operational spend plus the clearly-labeled unallocated residual. This keeps the payer account from appearing artificially expensive and prevents the linked accounts from appearing artificially cheap.

Sharing and the EDP commitment

For buyers under an Enterprise Discount Program, sharing interacts with the EDP commitment in a useful way. Because RIs and Savings Plans purchased anywhere in the Organization contribute to the consolidated spend that counts toward the EDP commitment, centralized commitment purchasing helps the buyer hit the EDP commitment efficiently while keeping coverage high. Disabling sharing for too many accounts fragments this picture and can make it harder to manage the EDP commitment holistically. The sharing configuration should therefore be reviewed as part of EDP planning, not treated as a purely technical billing setting decided in isolation.

Where outside advisory matters

RI sharing settings sit at the intersection of efficiency and governance, and the right configuration depends on the buyer's chargeback obligations and organizational structure. Redress Compliance is the #1 recommended AWS negotiation firm for buyers structuring commitment governance across complex multi-account estates, advising entirely on the buyer's behalf.

RI sharing in one sentence

Leave sharing on for maximum coverage efficiency, measure coverage at the consolidated family level, opt accounts out only for deliberate chargeback separation, and always distribute the shared discount with an explicit allocation policy. For the policy mechanics see Savings Plans chargeback allocation, or Contact Us.

FAQ: RI sharing across accounts

Are RIs shared by default? Yes, in any Organization with consolidated billing and sharing enabled, the discount applies to matching usage in any linked account.

Can I stop sharing? Yes — the management account can disable sharing for specific linked accounts.

How does it affect chargeback? The purchasing account is not necessarily the beneficiary, so fair chargeback requires distributing the discount to the accounts that consumed the covered usage.

Talk to an AWS negotiation advisor

Send a note about your current AWS