AWS Savings Plans vs Reserved Instances Strategy

Committing to spend without painting yourself into a corner

Reserved Instances and Savings Plans both trade flexibility for a discount. You promise AWS a certain amount of usage for one or three years, and in return you pay less than on-demand rates. The hard part is sizing that promise: how much to commit, for how long, and with which instrument, without ending up paying for capacity you no longer run.

I spend most of my working hours buying commitments for clients as part of AWS cost optimization work, and before that I covered EC2 Spot and Graviton as a Specialist Solutions Architect at AWS. The strategy below is what I actually recommend, not a restatement of the AWS console defaults.

Savings Plans and Reserved Instances are not the same trade-off

A Reserved Instance is a commitment tied to specific attributes. For a Standard RDS RI that means an instance family, size, region, and database engine. In exchange for that rigidity you get the deepest discount AWS offers for that resource. The problem is the rigidity itself. If a newer instance generation ships, or you move a database closer to your users in another region, the RI does not follow. There is no official way to change a Standard RI after purchase. In practice, converting one means raising a support case to cancel and recreate it, dealing with the reimbursement of the previously paid upfront amount, and paying a fresh upfront for the replacement. It is slow and painful, and you often end up carrying underutilized RIs for a while.

A Savings Plan commits you to a constant hourly dollar spend rather than to specific instances. An EC2 Instance Savings Plan lets you change instance size within a family, switch operating system, and move across regions while keeping the discount. A Compute Savings Plan goes further and covers EC2, Fargate, and Lambda together. That flexibility is the whole point: your commitment keeps applying as your fleet evolves. The catch is that Savings Plans generally discount a little less than an equivalent Standard RI for the same term, and they cover a flat hourly spend regardless of whether your usage that hour is above or below the committed number.

The short version: RIs give the best price when you are certain the exact resource will stay put, Savings Plans give you room to change your mind at a slightly smaller discount.

Where Spot fits before you commit at all

Commitments only make sense for the part of your usage that is genuinely steady. Before covering everything with a Savings Plan, look at what is actually fluctuating.

Savings Plans cover a constant hourly spend. If your capacity swings throughout the day, a plan sized to the peak sits partly unused during the troughs, and a plan sized to the trough leaves the peaks uncovered. Spot capacity follows your real usage in real time, as long as Spot capacity is available, so it fits fluctuating fleets far better than a fixed commitment does. Most instance types are available on Spot at roughly the price point of a three-year Savings Plan, and if the longest commitment you can stomach is one year, Spot is usually more cost effective than a one-year plan for that variable capacity.

The requirement for Spot is tolerance to interruption. It suits stateless workloads running on interchangeable capacity, especially anything already on an Auto Scaling group with dynamic scaling. Stateful workloads pinned to specific long-lived instances are not a fit, and for those a Savings Plan is the right answer. If your systems already tolerate instance failure, for example because you practice chaos engineering, Spot savings come at very little extra risk. Tools like Karpenter for EKS, or Spot automation for Auto Scaling groups, can handle the interruption and failover to on-demand for you.

Once you have separated the steady baseline from the fluctuating capacity on top of it, the mix I recommend is:

Cover about 70% of the steady baseline with three-year Savings Plans. This is the capacity you are confident you will still be running in three years, so you take the deepest term discount on it.
Cover the remaining 30% of the baseline with rolling one-year Savings Plans that you renew every month. Staggering shorter commitments this way keeps a portion of your coverage expiring soon, so you can reduce the committed amount if the footprint shrinks.
Handle the fluctuations above the baseline with Spot and failover to on-demand, rather than extending your committed spend to cover peaks you may not see again.

The reason for splitting the baseline instead of committing all of it for three years is that a three-year commitment is a bet on three years of steady usage. The rolling one-year layer is the release valve. It costs a little more than committing everything long term, and it is worth it for the ability to walk the number down without waiting three years or fighting the RI cancellation process.

The over-commitment trap

The failure mode I see most often is treating the AWS recommendation as the target. The console typically proposes committing to 100% of your current recommended amount. If your usage later drops below that line, whether from rightsizing, a migration, or a workload going away, you keep paying for the commitment while getting less value from it. With Standard RIs that money is largely stuck until the term ends, because of the cancellation friction described above.

Commit to the floor of your usage, not the current level. The steady baseline you are sure of belongs under long commitments. Everything above it should stay flexible, on shorter plans, on Spot, or on plain on-demand until it proves it is here to stay. Over-committing is a real and common way to spend more while believing you are saving.

Where AWS database Savings Plans fall short

AWS more recently introduced Savings Plans for databases, and there was a lot of excitement about them. For the way most of my clients run, they are a letdown, and it is worth being clear about why before you rely on them.

They are offered on a single-year term. That one-year horizon defeats most of the flexibility argument for provisioned databases. Within a single year you are unlikely to change the instance type, and even less likely to change the database engine, so the flexibility you are paying for barely gets exercised. For that same one-year window a Reserved Instance gives a better price. The fact that a database Savings Plan spans many database types does not help teams who run provisioned RDS and are not about to migrate that database to a different service six months from now.

The one case where the current database Savings Plan genuinely fits is coverage for serverless Aurora. Even there I am cautious, because serverless Aurora is often expensive enough that I treat it as a temporary step for rightsizing a provisioned database rather than a steady-state configuration worth committing to.

The real need for provisioned databases like RDS runs the other way. Clients keep the same database for years but want to move it to a newer instance generation when one ships, or to another region closer to their users. Today the deep discounts live in three-year RDS RIs, but those come with large upfront payments and no official way to change them after the fact, which is exactly where the underutilized-RI problem comes from. What would actually help is a no-upfront three-year database Savings Plan with the same freedom EC2 Instance Savings Plans already give, meaning changes of instance type, database engine, and region, plus an API to convert existing RIs into it. That is the release AWS should ship next.

A practical starting point

Separate your usage into a steady baseline and the variable capacity above it. Put roughly 70% of the baseline on three-year Savings Plans, keep about 30% on rolling one-year plans you renew monthly, and serve the fluctuations with Spot where the workload tolerates interruption. Reach for Reserved Instances when you are certain the exact resource will not move and you want the deepest discount, and accept their rigidity as the cost of that discount. Above all, commit to the usage you are sure of, not the usage you happen to have this month.