AWS Savings Plan
Does ZopNight manage AWS Savings Plan?
Savings Plans commit a fixed hourly spend for 1 or 3 years in exchange for discounted compute across EC2, Fargate, and Lambda. Overcommitting burns the unused hourly pledge; undercommitting leaves on-demand spend undiscounted. ZopNight measures utilization and coverage from Cost Explorer or CUR 2.0 and sizes recommendations from steady-state usage.
Rules that fire on AWS Savings Plan
No active rule family targets AWS Savings Plan today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
At a glance
| Field | Value |
|---|---|
| Scheduling notes | commitment tracking and recommendations only. |
A Savings Plan commits to a fixed hourly spend on compute for one or three years in exchange for discounted rates across EC2, Fargate, and Lambda. Committing too much wastes the unused commitment; committing too little leaves on-demand spend undiscounted.
A dollars-per-hour pledge, not a resource
Unlike an RI, a Savings Plan commits to an amount, a dollars-per-hour figure, rather than an instance shape. Compute Savings Plans apply across instance families, regions, Fargate, and Lambda; EC2 Instance Savings Plans commit to a family in a region for a deeper discount. Every hour, eligible usage is discounted up to the committed rate, and any committed amount left unmatched that hour is simply paid for nothing. The hourly granularity matters: usage that is spiky rather than steady can average above the commitment while still leaving unmatched hours overnight.
Sizing commitments from observed reality
ZopNight’s dedicated savings-plans provider reads utilization (how much of each hour’s pledge was consumed) and coverage (how much eligible usage ran undiscounted) from Cost Explorer or CUR 2.0. Its commitment recommendations are sized from observed steady-state usage, the floor the account never drops below, rather than from averages, which is the difference between a plan that is always fully consumed and one that leaks every night and weekend. Existing plans get flagged when utilization sags, which typically follows a workload moving off covered compute.
Commitment mistakes that repeat
Overcommitting from a peak: sizing the pledge during a busy quarter, then eating unmatched hours when traffic normalizes. Double-covering: layering a new Savings Plan on top of RIs that already cover the same instances, since RIs apply first and the plan then finds less to match. And forgetting scheduled shutdowns: an account that stops its non-production fleet nightly (as ZopNight schedules do) has a lower steady-state floor than its daytime usage suggests, and commitments should be sized to the floor.
Native views worth checking
The Billing console’s Savings Plans section shows each plan’s term, rate, and utilization; Cost Explorer’s coverage report shows what still bills on-demand. Reviewing both quarterly, and before any large migration, keeps the pledge matched to the estate it was sized for.