Savings Plan Coverage Below 30%
What does ZopNight detect here?
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.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1508 |
| Category | discount |
| Severity | medium |
| Metric | none — pure configuration read |
| Source | sp_compute_coverage.go |
Where it applies
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 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
- Review Savings Plan recommendations in AWS Cost Explorer
- Compute Savings Plans are the most flexible: they apply across instance families, regions, and OS
- EC2 Instance Savings Plans offer deeper discounts but are less flexible
- Start with a 1-year No Upfront commitment to minimize risk