Build1 publisher2 min readPublished
Committing $10 an hour locks in $87,600 of spend for the year
Savings Plans price a spend rate you owe in every hour of the term. Reserved Instances price a configuration you might migrate off, and a dev.to framework sets out which one a given workload should buy.
The Engineer · Build desk

What happened
- A Savings Plan commits a dollar amount of spend per hour, the post's example being $10 an hour, for a one or three year term, with the discount applied to usage up to that rate.
- A Reserved Instance commits to a configuration instead: instance family, region, and for standard RIs a largely locked-in set of attributes, over the same one or three year terms.
- The Compute Savings Plan discount follows usage across instance families, regions and operating systems, and reaches Fargate and Lambda as well as EC2, at a smaller discount than the most locked-in RI.
- Savings Plans reach only EC2, Fargate and Lambda, so RDS, ElastiCache, Redshift and OpenSearch commitments still have to be bought as Reserved Instances or reserved nodes.
- The setup the post recommends pairs a Compute Savings Plan over the steady EC2, Fargate and Lambda baseline with RIs for production RDS and ElastiCache, on-demand for burst and spot for interruptible work.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- decision Until a team trusts its baseline number, the choice the framework forces is a one-year no-upfront plan, because the three-year all-upfront purchase carries both the largest discount and the largest risk.
- constraint Sizing to the always-on floor rules out covering burst with a commitment, so spiky and uncertain workloads stay on on-demand or spot however good the discount looks.
- exposure A commitment bought before rightsizing turns a sizing error into a term-length liability, and the team that signed it keeps paying for the oversized instance for a year.
- capability Convertible RIs buy the option to move families later, so a team that expects to migrate can still take a commitment discount now at a smaller rate.
Ten dollars an hour is the example rate in the dev.to write-up, and the discount applies to usage up to it [1]. Across a one-year term that rate is 8,760 hours and $87,600 of committed spend [3]. Hours when the fleet runs below the rate are what the post is describing when it says "Over-committing is worse than under-committing, because unused commitment is pure waste" [2].
Within the RI family the tradeoff is discount against flexibility. Standard RIs carry the biggest discount and the least flexibility, while convertible RIs take a smaller discount and can be exchanged for different families later [5]. The EC2 Instance Savings Plan sits between the two, committing to one family in one region for more discount than a Compute plan and more flexibility than a standard RI inside that family [8].
Family churn is the variable that decides it. The post's default for most teams is a Compute Savings Plan, trading a few points of discount for not being locked to a family you might migrate off [13]. Committing to a configuration has three justifications in the same post. An RI can reserve capacity, guaranteeing you can launch that instance in that AZ [6]. The bigger discount is worth the lost flexibility for a large, stable workload certain to stay on a specific family [14]. And RDS, ElastiCache, Redshift and OpenSearch have no Savings Plan option at all, so a database commitment is a reserved purchase or nothing [9].
The paralysis is the one part of the argument with no number attached. The post says teams freeze because there are two mechanisms, several flavors of each, and a real risk of locking in the wrong thing for a year [18]. The only figure on the other side is the discount band, often 30 to 70% [10]. That band covers both mechanisms and both term lengths [10], so for the top of it to describe your bill, the workload has to be the large stable single-family fleet the post reserves for standard RIs and EC2 Instance plans [14].
Then there is the tooling. Cost Explorer will generate Savings Plans and RI recommendations from your usage history [16], and that history predates the rightsizing the post puts first [11]. A recommender fed a year of oversized instances proposes a commitment sized to oversized instances. The post treats the output as a fine starting point and says to run it through the rules instead of buying what it suggests blindly [16].
What to watch
- Any extension of Savings Plans coverage to RDS or ElastiCache would remove the one forced reserved purchase in this framework.
- Published discount rates broken out by flavour and term would test the 30 to 70% band the post gives as a single range.
- Whether Cost Explorer starts sizing recommendations against rightsized usage instead of raw billing history.