FinOps
AWS Savings Plans vs Reserved Instances vs scheduling
Savings Plans reduce the rate for usage you commit to. Scheduling removes idle runtime. They solve different parts of the AWS bill, and many teams need both.
Start with the workload, not the discount
A commitment only saves money when eligible usage continues through the commitment period. A schedule works in the opposite direction: it removes hours that do not need to run. Buying a commitment before removing idle development and staging runtime can lock in spend that the team could have avoided.
Compute and Database Savings Plans cover different usage
Compute Savings Plans apply to eligible EC2, Fargate, and Lambda usage. AWS measures the commitment in dollars per hour for a one-year or three-year term. Database Savings Plans apply to eligible database usage, including RDS and Aurora, through a one-year hourly commitment. They can follow supported changes in engine, instance family, size, deployment option, or Region.
Coverage is an account-level billing signal. A coverage value of 0% means eligible usage was billed without a Savings Plans discount during the measured period. It does not prove that buying a plan is the right next action.
RDS Reserved Instances are narrower
An RDS Reserved Instance is a billing discount for matching database usage, not a separate physical database. AWS offers one-year and three-year terms. Eligibility depends on attributes such as Region, engine, instance class, and deployment configuration. The discount covers instance usage, not storage, backups, or I/O.
Database Savings Plans trade some maximum discount for broader movement across supported database services and configurations. AWS does not combine a Database Savings Plans discount and an RDS Reserved Instance discount on the same workload.
Compare the four controls
| Option | Coverage | Commitment | Best fit |
|---|---|---|---|
| Compute Savings Plans | EC2, Fargate, and Lambda | A USD-per-hour commitment for 1 or 3 years | A stable compute baseline that may move between services or Regions |
| Database Savings Plans | Eligible RDS, Aurora, and other supported database usage | A USD-per-hour commitment for 1 year | A stable database baseline that may change engine, family, size, or Region |
| RDS Reserved Instances | Matching RDS instance usage | A 1-year or 3-year reservation | Predictable RDS usage with stable attributes |
| Scheduling | Selected non-production RDS and EC2 resources | No AWS commitment | Development and staging resources that are idle outside working hours |
Schedule first, then measure the baseline
Start by scheduling development and staging resources that have clear off-hours. Measure the remaining On-Demand usage over a representative period. Use AWS recommendations and Purchase Analyzer against that lower, steadier baseline. Compare Database Savings Plans with RDS Reserved Instances when the remaining database usage is continuous.
Scheduling does not remove every charge. RDS storage, backups, and provisioned I/O can remain billable while an instance is stopped. The saving comes mainly from avoided instance runtime.
What SnoozeDB does
SnoozeDB imports aggregate coverage and surfaces AWS recommendations when the relevant read-only module is enabled. SnoozeDB never purchases, modifies, or cancels a Savings Plan or Reserved Instance. Purchase decisions stay in AWS Billing and Cost Management.
Review your recommendations