EC2 Compute Savings Plan Opportunity
What does ZopNight detect here?
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.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-091 |
| Category | discount |
| Severity | low |
| Metric | none — pure configuration read |
| Source | savings_plan.go |
Where it applies
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, 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
- Review AWS Cost Explorer Savings Plans recommendations
- Identify consistent EC2/Fargate/Lambda spend over the last 30 days
- Purchase a Compute Savings Plan for the recommended hourly commitment
- Tag covered instances with savings_plan=true for tracking