# EC2 Compute Savings Plan Opportunity

> Production EC2 instances running on-demand with at least 60 days of observed history, high uptime, and no existing reservation coverage qualify for a Compute Savings Plan recommendation. ZopNight prices the commitment off the real 1-year Compute SP rate times 730 hours, abstaining entirely when that rate is unavailable.

Source: https://zop.dev/integrations/aws/recommendations/ec2-compute-savings-plan-opportunity
Updated: 2026-08-19

---

## Which production instances clear the commitment gate

- resource.Status: running
- CUR-derived ReservationCoverage[uid] (Reservation/SavingsPlan) => skip (already committed)
- tag: savings_plan=true
- tag: ri_covered=true
- metadata: lifecycle=spot / purchase_type=Spot => skip; Savings Plans do not cover Spot usage (issue #1657; shared isSpotLifecycle helper)
- EvaluationContext TierRates (RI / SP1yrCompute / OnDemand) + measured uptime + CommitmentEligible: the saving and the eligibility gates are computed from these
fires only on production-identified workloads (isProdName or isProdEnvTag), the exact complement of the scheduling rule (RC-093, which absorbed the retired RC-015), so commitment (always-on lever) and scheduling (non-prod lever) partition the fleet and never both fire on the same box. Then a Wave-7 commitment-discipline gate (CommitmentEligible: ≥60d observed history, high uptime, meaningful CPU/mem util) must pass before any 1-/3-yr lock-in is recommended.

## Pricing off the Compute SP rate, not the RI rate

RC-091 recommends a Compute Savings Plan, so it prices the commitment off the SP-specific rate via CommitmentBreakEvenSP (TierRates.SP1yrCompute), not the Reserved-Instance rate. A Compute SP is [its own pricing instrument, shallower than a Standard RI](https://aws.amazon.com/savingsplans/compute-pricing/), and reusing the RI rate would systematically overstate the SP saving. CommitmentBreakEvenSP prices SP1yrCompute×730 and recommends only when that is less than the instance's compute-only monthly basis (min(cost, OnDemand×730); on a bare EC2 the cost is the compute line, so the cap is ~inert, applied defensively per the RC-031 idiom), so savings = breakEvenBasis − SP×730 (a commitment costing more than today's spend is rejected), then gated by an uptime-hysteresis suppressor. Abstains (returns nil) when the live SP rate is unavailable (SP1yrCompute absent/non-positive). This is the intended behaviour change: RC-091 no longer falls back to the RI rate, to DeriveSavingsPlanFraction, or to any flat fraction (the 0.20 fallback and savingsPlanNoRateSentinel are gone). A Savings-Plan saving is backed by a real SP rate or it emits nothing; the headline ~%d%% is derived from the real net applied.

## Buying the Compute Savings Plan

1. Review AWS Cost Explorer Savings Plans recommendations
2. Identify consistent EC2/Fargate/Lambda spend over the last 30 days
3. Purchase a Compute Savings Plan for the recommended hourly commitment
4. Tag covered instances with savings_plan=true for tracking