Rightsizing (subchapter 25.3) saves by adjusting the size of resources. Now we’ll look at another very powerful savings lever, but through a different path: getting significant discounts (up to 70%) in exchange for committing to use AWS for a period of time. The two ways to do this are Savings Plans and Reserved Instances. Understanding the difference can save you a lot of money.

By default, in AWS you pay on-demand: you use a resource for an hour, you pay for that hour, no strings attached. It’s flexible, but it’s the most expensive option. AWS offers you a deal: if you commit to using a certain amount of resources for 1 or 3 years, they give you a big discount (up to 70%).

Analogy: it’s like a public transport pass vs. single tickets. The single ticket (on-demand) you buy whenever you want, no commitment, but it’s expensive if you travel a lot. The monthly or annual pass (the commitment) requires you to pay upfront for a period, but the price per trip is much cheaper. If you know you’ll use transport consistently, the pass saves you a lot. AWS works the same way: if you know you’ll use resources continuously, committing is very worthwhile.

This makes sense for AWS (you guarantee them stable usage, they can plan) and for you (you pay much less for what you were going to use anyway).

The key is predictability. Commitment is worthwhile for the part of your usage that is stable and constant, that “base” you know you’ll need no matter what for months or years:

The smart strategy: cover your base usage (what you always need) with commitments (discount), and leave the variable peaks on-demand (flexibility). This way you combine savings and flexibility.

⚠️ The risk of commitment: if you commit to using a certain amount and then don’t use it (because your project shrank or changed), you pay anyway (you already committed). That’s why you should only commit the part you’re sure you’ll use. For the uncertain part, better to use on-demand.

Reserved Instances (RI) are the classic way to commit, and they are specific: you reserve a specific type of resource (for example, “a type X server in region Y”) for 1 or 3 years, in exchange for the discount. Since they are specific, they are somewhat rigid: the discount applies to that specific type.

Savings Plans are the more modern and flexible option. Instead of committing to a specific type of resource, you commit to spending a certain amount of money per hour (for example, “I commit to spending at least €10 per hour on compute”) for 1 or 3 years, and you get the discount. The big advantage: that commitment is applied flexibly to whatever you use (different server types, different regions, even Lambda or Fargate, depending on the plan).

Analogy: a Reserved Instance is like a pass for a specific subway line (it only works for that line). A Savings Plan is like a transport pass that works for subway, bus, and train interchangeably: you commit to a spend, but you use it for whatever you need. Much more flexible if your needs change.

General recommendation: for most cases, Savings Plans are the preferred option today due to their flexibility (you get a similar discount but adapt better to changes). Reserved Instances still make sense in very specific and stable cases.

Real world example: a company has been on AWS for a while and sees, with Cost Explorer, that it has a very stable base usage of compute (its production applications run 24/7 all year). Until now they paid everything on-demand. They purchase a 1-year Savings Plan that covers that base usage, committing to an hourly spend they know they’ll have anyway. Result: a 55% discount on that part of their bill, without changing anything in their infrastructure. And since they chose a Savings Plan (not RI), when they later migrated some servers to other types, the discount kept applying automatically. They left the occasional peaks on-demand to maintain flexibility.

💡 Important order: do rightsizing first and then buy Savings Plans. If you commit to oversized resources, you’ll be “locking in” waste for years. Adjust the size first, and only commit to what you really need.

• By default you pay on-demand (flexible but more expensive). AWS offers big discounts (up to ~70%) in exchange for committing to use resources for 1 or 3 years. Like a transport pass vs. single tickets.
• It’s worthwhile for your stable and predictable base usage; leave the variable peaks on-demand. ⚠️ If you commit and don’t use it, you pay anyway: only commit what’s certain.
• Reserved Instances (RI): classic form, you commit to a specific type of resource. More rigid.
• Savings Plans: modern and flexible form, you commit to a spend amount per hour that is automatically applied to whatever you use (different types, regions, Fargate/Lambda). Recommended in general for their flexibility.
• 💡 Do rightsizing first and then buy commitments, so you don’t “lock in” oversized resources.

In the last subchapter of the chapter we’ll look at the discipline that encompasses all this cost management as a team practice: FinOps.