If you're running multiple AWS accounts under one organization, a Savings Plan purchased in one account is already covering usage in your other accounts. That's not a configuration you set up, it's how consolidated billing works by default.
For most teams, this is fine. One purchase, org-wide coverage, AWS handles the allocation automatically. The discount flows to wherever it generates the most savings across your accounts.
The part that gets complicated is everything that happens next. Which account gets priority? What if you need to restrict sharing for chargeback requirements? What happens to your coverage when an account moves between organizations? And how do you actually see which accounts are consuming a shared Savings Plan?
How Consolidated Billing Works
AWS Organizations uses consolidated billing to merge usage and payments from all member accounts into a single bill, processed through the management account. The management account pays the total charge. Each member account still generates its own usage data, but discounts, Savings Plans, Reserved Instances, volume pricing are calculated across the aggregate.
The key operational implication: a Savings Plan purchased in Account A will automatically discount usage in Account B, C, and D unless sharing is explicitly restricted.
If you want a full breakdown of how Savings Plans work before getting into the multi-account mechanics AWS Savings Plan: A Complete Guide to Maximizing Savings
How Savings Plans Apply Across Accounts
The application sequence follows a strict priority order.
Step 1: Owner account first. The Savings Plan is applied against the usage of the account that purchased it, before any cross-account sharing occurs.
Step 2: Spillover to the organization. Any unused commitment not consumed by the purchasing account in a given hour is automatically shared with other accounts in the org.
Step 3: Maximum savings optimization. AWS applies the remaining commitment to whichever account's usage yields the largest calculated savings not on a first-come basis.
A Savings Plan purchased in a low-usage account can, in practice, provide most of its discount value to high-usage accounts. That's by design. The risk: if the high-usage accounts are not in the same organization, or sharing has been restricted, that commitment sits partially unused.
The Four Sharing Modes
AWS supports four distinct sharing configurations, managed via AWS Cost Categories (RI/SP Group Sharing).
Organization-wide (default): All accounts in the org benefit. No restriction is possible; unused commitment spills to all accounts automatically.
Group-based (RISP Group): Sharing is limited to a defined account group via Cost Categories. The group is prioritized first, then spillover goes org-wide.
Prioritized: Owner first, then the defined group, then the rest of the org. Hierarchical spillover applies.
Restricted: Group only, no spillover outside the group. Unused commitment stays within the group and is not shared org-wide.
Deactivated (per account): The purchasing account only. The management account controls this. No sharing in or out.
RISP Group Sharing is a feature in AWS Cost Categories that lets the management account define subsets of accounts and restrict Savings Plans discount sharing to those subsets enabling chargeback-aligned cost allocation without losing discount efficiency within the group.
What Happens When Sharing Is Deactivated
The management account can disable Savings Plans sharing for any individual member account. Two things happen:
- Outbound sharing stops. Commitments purchased in that account apply only to its own usage. If that account's usage is lower than its purchased commitment, the unused portion generates no savings for anyone; it becomes waste.
- Inbound sharing stops. Usage in that account reverts to on-demand rates even if the organization has surplus Savings Plans capacity elsewhere.
Deactivation is the right call in specific scenarios: reseller or MSP models where discount allocation must stay per-tenant, regulatory separation requirements, or internal chargeback models that need clean per-account P&L. Outside those cases, deactivating sharing reduces the organization's aggregate utilization rate and increases total cloud spend.
The management account's consolidated bill doesn't change in total, but the discount line items shift. The deactivated account shows higher effective spend. Other accounts absorb whatever surplus commitment exists from the rest of the org.
The Utilization Reporting Problem
This is where most engineering teams run into operational problems. AWS Savings Plans utilization is reported at the purchasing account level by default in the console. Under consolidated billing, the "utilization %" shown for a given Savings Plan reflects all usage covered across the entire organization, not just the purchasing account.
A plan showing 95% utilization could be covering usage from four different accounts. If one of those accounts changes its compute footprint significantly, utilization drops and you won't immediately know which account drove the change from the top-level console view.
To get per-account utilization attribution under consolidated billing, you need:
- Cost and Usage Report (CUR): The savingsPlanEffectiveCost and savingsPlanRate columns, split by lineItem/UsageAccountId
- AWS Cost Explorer: Savings Plans Utilization report filtered by linked account (data refreshes every 24–72 hours)
- Management account access: Member accounts can see only their own share of the commitment; only the management account can view org-wide utilization
The refresh delay is a real operational risk at scale. For a multi-account organization running $50K+/month in on-demand compute, a 72-hour blind spot on utilization shifts translates to 3 days of undetected waste compounding before any recommendation engine can respond.
If you're trying to make sense of how amortized cost shows up in Cost Explorer Understanding Savings Plan Amortized Cost in AWS Cost Explorer
Where to Purchase Savings Plans in a Multi-Account Org
- Management account: Best for pure discount maximization across the org. Savings Plans spill over to all member accounts by default.
- Member account: Best when you have chargeback or showback requirements where specific teams must be assigned the cost and savings of their own commitments.
- Central payer / dedicated commitment account: Common FinOps pattern at enterprise scale when you want centralized commitment management without using the management account for financial instruments.
How to Enable or Disable Sharing
Sharing is enabled by default. The management account can modify it at any time.
To disable sharing for a specific member account:
- Sign in to the management account
- Navigate to Billing and Cost Management → Savings Plans → Savings Plans settings
- Find the member account, toggle Discount sharing off
- Confirm, takes effect for the next billing period calculation
Changes do not retroactively affect past billing periods. There's no penalty or waiting period for re-enabling.
The Most Common Sharing Mistakes
Purchasing in a member account that later gets deactivated from sharing. If that account is isolated for chargeback, compliance, or org restructuring, any surplus commitment becomes siloed waste.
Assuming utilization percentages reflect a single account. The org-level utilization number aggregates all covered usage. A team reporting "98% utilization" may have three accounts contributing and a fourth that just scaled down but is being masked by the aggregate.
Not monitoring utilization per account after org changes. When an account leaves the organization or moves to a different payer, any Savings Plans it was relying on for shared discounts immediately stop applying. The account reverts to on-demand pricing.
Setting Restricted sharing mode without modeling the utilization impact. If the group's usage drops below the committed amount, the waste is trapped inside the group rather than being absorbed by the rest of the org.
Fixing the Multi-Account Visibility Gap
AWS Cost Explorer refreshes Savings Plans recommendations every 24–72 hours. In a 10-account organization where three accounts have materially different usage week-over-week, that lag means commitment sizing decisions are being made on data up to 3 days old. At a conservative $6–12K/day in uncovered on-demand spend per account, a 72-hour refresh cycle can represent $18K–$36K in avoidable spend per recommendation cycle per account.
Usage.ai refreshes commitment recommendations every 24 hours, a 3-day advantage over AWS native tooling. It provides per-account attribution across all linked accounts without requiring manual CUR queries or custom Athena pipelines, and includes a cashback guarantee on underutilized commitments when sharing is restricted or disrupted by org changes.
Customers like EVGo (NASDAQ: EVGO) have achieved $5.2M in annual savings, and Motive has realized $2.3M annually, both in AWS-heavy environments where multi-account commitment management was a core challenge.
For a deeper look at buying strategy across a multi-account org AWS Savings Plan Buying Strategy: Layering, Timing & Right-Sizing Commitment
Have you run into issues with shared Savings Plans after an account move or org restructure? What was your approach to fixing the coverage gap?
Continue with the complete technical article here → How AWS Savings Plans Share Across Consolidated Billing Accounts
