# Savings Plan Coverage Below 30%

> A running EC2 instance absent from the CUR-derived `ReservationCoverage` map triggers a break-even check against the 1-year No-Upfront Compute SP rate. Coverage is a label here, never a percentage. ZopNight recommends only when the SP rate times 730 hours beats actual monthly cost, requiring 60 days of history and never substituting the deeper RI rate.

Source: https://zop.dev/integrations/aws/recommendations/savings-plan-coverage-below-30
Updated: 2026-08-19

---

## Instances missing Savings Plan coverage

- resource.Status: running
- CUR-derived ReservationCoverage[uid]: the coverage gap is driven by this signal, not the phantom sp_coverage_pct tag (which was tag-gated-dead, no producer; Principle 5). An instance absent from the map (or present with neither Reservation nor SavingsPlan) is uncovered and draws the check; one already covered must never draw a buy rec → abstain.
- EvaluationContext: measured uptime + CommitmentEligible + committed-tier rates, specifically TierRates.SP1yrCompute (for CommitmentBreakEvenSP), the Compute-SP-specific rate rather than the RI rate. Producer (real): the aggregator ingests the 1yr No-Upfront Compute Savings Plan Linux/shared hourly rate per instance type from AWS's AWSComputeSavingsPlan feed (aggregator/internal/pricing/aws/savings_plan.go) into pricing_cache under purchase_type=savings_plan, keyed identically to the on-demand/RI rows; weekly pricing-sync, 15-day GetTierRates freshness gate.

## Coverage is a label, not a percentage

There is no coverage-percentage gate. The rule reads the CUR-derived
`ReservationCoverage` map and tests membership: an instance labelled `Reservation`
or `SavingsPlan` is already covered and the rule abstains, and an instance absent
from the map draws the break-even check. An instance sitting at a partial
coverage percentage is not measured, because no percentage is available to
measure. The rule's own source carries the note that the earlier
"below 30% threshold" framing was ungated and was removed.

## Break-even at the Compute SP rate, not the RI rate

concrete-or-abstain (cost-driven discount). A CommitmentEligible discipline gate (≥60d history, high uptime, meaningful util) and a long-off uptime suppression (SuppressCommitmentForUptime; an SP bills 730h/mo for the term, the wrong lever on a part-time/stopped box) gate the rec. The only savings path is the real SP break-even net via CommitmentBreakEvenSP, which prices the commitment at the Compute-SP-specific rate (SP1yrCompute×730), not the Reserved-Instance rate. A Compute SP is a shallower discount than a Standard RI for the same term/payment option ([AWS publishes Compute SP at up to 66% off On-Demand](https://aws.amazon.com/savingsplans/compute-pricing/) vs Standard RI up to 72% off), so reusing the RI rate would systematically overstate the advertised SP savings. Recommends only when SP1yrCompute×730 is less than the instance's actual current monthly cost: savings = currentCost − SP1yrCompute×730, capped at cost. Abstains when break-even inputs are unavailable (ok==false strictly means SP1yrCompute is absent/non-positive, since cost>0 is already guaranteed). The dropped DeriveCommitmentFraction(tiers, 0.40) flat-fraction fallback is gone, and there is no fallback to the RI rate either; no fabricated or mis-priced saving. With the savings-plan ingestion live (see the producer note above), abstain is the missing/stale-rate edge case for a SKU/region, not the steady state. Mirrors RC-014.

## Choosing and buying the right Savings Plan

1. Review Savings Plan recommendations in AWS Cost Explorer
2. Compute Savings Plans are the most flexible: they apply across instance families, regions, and OS
3. EC2 Instance Savings Plans offer deeper discounts but are less flexible
4. Start with a 1-year No Upfront commitment to minimize risk