Bill Teardown #4: Multi-Account Savings Plan Leakage

AWS Bill Teardown #4: Multi-Account Commitment Leakage — Savings Plans Bought in the Payer, Consumed in the Wrong OU

Quick summary: A 22-account AWS Organization spent $1.1M/yr on Compute Savings Plans but applied only 61% to production. Dev sandboxes burned the commit while prod stayed On-Demand. Group Sharing (April 2026) fixed attribution. The waste was $312k/yr before they restructured purchases.

Key Takeaways

A 22-account AWS Organization spent $1.1M/yr on Compute Savings Plans but applied only 61% to production
Group Sharing (April 2026) fixed attribution
The waste was $312k/yr before they restructured purchases
On April 21, 2026, AWS shipped Savings Plans Group Sharing, with Prioritized and Restricted modes that route commitment discounts to the accounts you intend
This teardown covers the year before that fix, when a payer-level 3-year Compute Savings Plan looked healthy in aggregate while production bled On-Demand spend

On April 21, 2026, AWS shipped Savings Plans Group Sharing, with Prioritized and Restricted modes that route commitment discounts to the accounts you intend. This teardown covers the year before that fix, when a payer-level 3-year Compute Savings Plan looked healthy in aggregate while production bled On-Demand spend.

Account snapshot (anonymized)

Attribute	Value
Industry	B2B SaaS + internal data platform
Linked accounts	22
Steady-state AWS spend	~$920k/mo
Compute SP commitment	~$1.1M/yr effective rate
SP utilization (payer view)	94%
Production SP coverage	61%

Finding 1: The commitment followed convenience instead of spend

FinOps purchased SP at the management account in 2024 using blended organization usage. Over 18 months, sandbox and CI accounts grew from 12% to 31% of compute hours . Ephemeral environments with high churn consumed SP hours that could not be reclaimed for long-running prod clusters.

Monthly leakage modeled: production On-Demand premium ~$26k/mo above what coverage would cost if SP followed prod accounts, or ~$312k/yr.

Finding 2: No Cost Category guardrails

Environment=dev workloads lacked automated shutdown; SP did not distinguish dev from prod because purchases were not tied to Cost Categories. Tag coverage on EC2 was 78%, which is good, but SP benefit allocation ignored tags until Group Sharing policies existed.

Finding 3: RDS still 100% On-Demand

While fighting EC2 SP leakage, $140k/mo RDS had zero Reserved Instances. Compute SP does not apply to RDS. A separate 1-year No-Upfront RI program on stable Multi-AZ primaries modeled $38k/mo additional savings unrelated to the SP fix.

Remediation (90 days)

Enabled Restricted Group Sharing: prod OU consumes SP first; sandboxes excluded from primary commit.
Bought a smaller 1-year No-Upfront SP scoped to non-prod for baseline CI, capped at 40% of dev compute.
Purchased RDS RIs on three largest primaries after 30-day utilization proof.
Weekly coverage-by-account report from CUR 2.0 to Slack #finops. Query patterns: CUR 2.0 and Athena FinOps queries.

After

Metric	Before	After
Prod SP coverage	61%	89%
On-Demand prod compute premium	$26k/mo	$7k/mo
RDS On-Demand share	100%	62%
Modeled annual savings	-	~$340k

Takeaway

Aggregate SP utilization says little about where the benefit lands. Until benefits land on the accounts that own prod revenue, you are subsidizing sandbox sprawl. After April 2026, configure Group Sharing before the next commitment signature, not after the quarterly review surprises you.

Model commitments: Savings Plans ROI Calculator · Commitment Level Optimizer · Free cost audit

Previous: Teardown #3: Retail data transfer. Hub: AWS cost optimization resources.

Frequently asked questions

Can Savings Plans be restricted to specific accounts?

Yes, as of April 2026 AWS Group Sharing lets you define Prioritized or Restricted groups so commitment benefits apply to designated accounts or Cost Categories first, or only within a group.

How do you detect commitment leakage?

In Cost Explorer, filter Savings Plan coverage by linked account. If production accounts show low coverage while payer-level utilization is high, benefits are being consumed elsewhere. CUR 2.0 line_item_savings_plan_savings_plan_a_r_n attribution columns confirm per-account consumption.