Commitment discounts: the math most teams get wrong.
Coverage vs utilization: the distinction that matters
Most teams measure commitment coverage: we have 80 percent of compute covered by Savings Plans or Reserved Instances. This is the wrong metric to optimise for.
Utilization is the number that matters: of the commitments you hold, what percentage did you actually consume? A commitment at 60 percent utilization means you committed to pay for capacity you are not using. You paid for the discount and did not capture the compute.
The target: 95 to 100 percent utilization on all commitments, with on-demand capacity covering the variable tail above that floor. Coverage follows from utilization. Not the other way around. Teams that optimise for coverage first routinely over-commit, then find themselves holding Reserved Instances they cannot consume.
Why teams over-commit
The instinct is to commit at peak usage, or at a comfortable buffer above average. Both produce the same result: reserved capacity running idle during the off-peak hours, weekends, and post-launch dips that every production workload has.
Over-committing on a 3-year Reserved Instance means paying the committed rate for capacity you are not consuming. There is no way to recover that cost. The discount that looked attractive at commitment time becomes a liability for the duration of the term.
The correct approach: pull three months of actual usage data through the AWS Cost Explorer Savings Plans recommender, or the equivalent Azure advisor. Start with the lowest recommended commitment level. Review utilization quarterly. Increase coverage only when existing commitments sit above 95 percent utilization for a sustained period, not because you expect usage to grow.
Savings Plans vs Reserved Instances vs Spot
Savings Plans apply across instance families and regions. Reserved Instances lock to a specific instance type in a specific region. For most teams, Savings Plans are the right default. Workloads change: you right-size an m5.2xlarge to m5.xlarge, migrate a service to Graviton, or shift a region. A Compute Savings Plan follows the workload. A Reserved Instance does not.
The exception is database services. RDS, ElastiCache, and Redshift use Reserved Instances and do not participate in Savings Plans. Steady-state databases that will not be resized or migrated within the commitment window are the right candidate for a 1-year Reserved Instance. 3-year terms are justified only when you have architectural certainty for the full window, which most teams do not.
Spot is not a discount mechanism for production compute. Spot is an architecture choice for interruptible, stateless, batch workloads. Job queues, ML training, and CI runners built to absorb interruptions with automatic retry save 60 to 80 percent versus on-demand. A web tier that goes down during a Spot reclamation at peak traffic is not a pricing problem. It is an architecture problem.
"Commit to your floor, not your peak. Coverage follows utilization. Not the other way around."
Danny Zak / FinOps Lead
The 1-year versus 3-year decision
A 3-year commitment on AWS delivers roughly 40 percent savings over on-demand. A 1-year commitment delivers roughly 25 percent. The additional 15 percentage points buy 24 more months of locked-in scale.
For that additional commitment to pay off, the workload must run at approximately the same scale for three years. On a fast-moving engineering team, this is rarely true for the full fleet. Services get rebuilt. Products get deprecated. The Kubernetes namespace that runs at 30 nodes today is at 12 or 50 nodes in two years.
Our default for growth-stage companies: 1-year Savings Plans, reviewed quarterly, never extended below 90 percent utilization. For stable, slow-changing workloads, such as compliance tooling, legacy services maintained for contractual reasons, and long-lived databases with no migration planned, a 3-year commitment is worth considering case by case. The rule of thumb: if you are not confident the workload exists in its current form 36 months from now, the 1-year term is the correct choice.