AWS Reserved Instance
Does ZopNight manage AWS Reserved Instance?
Reserved Instances trade a 1- or 3-year commitment for discounted rates on specific instance usage, and an unused reservation pays commitment fees while workloads bill on-demand elsewhere. ZopNight tracks utilization and coverage against actual usage from Cost Explorer or CUR 2.0 and flags underused RIs and coverage gaps.
Rules that fire on AWS Reserved Instance
No active rule family targets AWS Reserved Instance 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 Reserved Instance (RI) is a one- or three-year commitment to specific instance usage in exchange for a discount over on-demand rates. Unused or mismatched reservations mean paying commitment fees while workloads bill at on-demand rates elsewhere.
Paying in advance for a shape of usage
An RI is not a resource; it is a billing instrument. The account commits to a particular instance family for one or three years, with no-upfront, partial-upfront, or all-upfront payment. The discount applies automatically whenever running instances match the reservation’s attributes. The meter risk is the mismatch: the commitment bills regardless, so an RI for a family the fleet migrated away from pays full freight while the replacement instances pay on-demand. Two wrongs, simultaneously, both invisible unless someone reconciles the two sides.
Utilization and coverage, reconciled
ZopNight’s dedicated reservations provider tracks both halves of that reconciliation from Cost Explorer or CUR 2.0. Utilization answers whether each reservation is being consumed (hours matched against hours committed) and flags RIs drifting toward waste. Coverage answers the opposite question: how much steady on-demand usage is running unreserved, where a new commitment would capture a discount. The recommendations surface both, because an account can simultaneously waste existing commitments and miss obvious new ones after a fleet migration.
How reservations drift out of match
Instance-family migrations are the main killer: a move from one generation to the next, or a shift to Graviton, orphans every size-inflexible RI overnight. Regional-versus-zonal scoping bites too: a zonal RI stops matching when the workload moves AZs. Convertible RIs mitigate drift but only if someone actually exchanges them, and standard RIs for workloads that got containerized simply outlive their purpose, ticking down their term while matching nothing.
Where to see reservation health natively
The EC2 console lists reservations with their state and term, but the useful views are Cost Explorer’s RI utilization and coverage reports, which chart matched-versus-committed hours over time. Anything persistently under full utilization is either an exchange candidate (convertible), a Marketplace listing candidate (standard), or an argument for letting the term lapse.