I was doing a project for a hackfest at FusionAuth recently (big fan of hackfests and have been for years).

I was looking at ways to decrease our hosting bill (we host with AWS). There are, of course a variety of ways to accomplish this, but I spent some time looking at EC2 savings plans and RDS reserved instances.

After the short presentation I gave at the end of the day, someone asked “What about Compute Savings Plans?”

I looked at them briefly and they seem like an no-brainer.

With this option, you commit to a certain amount of compute spend (any amount you choose, basically) for a certain period of time (one year or three years) with a certain payment plan (all up front, partial upfront, or no upfront). Then AWS gives you the discount in exchange for this guaranteed income.

Plans are controllable via API and purely a billing construct. Being on a plan doesn’t affect the performance or availability of your compute resources. This is unlike other ways to save money such spot instances.

A Compute Plan, notably is not tied to a region, compute option, or instance type. It covers hours spent across EC2, Lambda and Fargate. It’s quite broad. Other options tie you to a region or a instance type family.

Therefore, this seems like an obvious choice to save money while retaining some flexibility, such a key selling point of the cloud.

Anything this obvious raises suspicion in my mind. So I thought I’d look at it the other way and consider why you wouldn’t use a Compute Savings Plan. Here are the reasons I thought of:

• First, you might not know about it. I didn’t. Hopefully this blog post does a small bit to educate you.
• Second, you might not be running anything on AWS EC2, Lambda or Fargate. In that case, a plan is useless, of course.
• You might have highly variable compute needs, which frequently go to zero. In this case, committing to a certain number of hours a year might not be worth it. It depends on how many hours a year you will use and what the savings might be.
• You might be planning to depart from AWS for any number of reasons. Depending on how serious you are, you could lose money with a commitment to a plan. That said, most migrations take longer than you think. You can probably lower the amount of commit to the point where it makes sense.
• You don’t have the money to pay upfront. In this case, you can still use the “no upfront” option and save some money. Less, but still some.
• If you have extremely stable compute needs, you can use Reserved Instances or EC2 Savings Plans (or, frankly, other hosting providers offering less flexibility, such as data center providers) to save more money. Totally possible, but I haven’t run across it. I’ve heard tell of them, though.
• You prefer Amazon to have your money rather than you. If this resonates and you are open to changing who you give your money to, please contact me. I can use more money.

What am I missing? Are there other reasons why a Compute Savings Plan for AWS is not a good idea?

Finally, here’s more information from The Duckbill Group about Savings Plans, in particular how the savings are calculated and applied.