Do AWS Reserved Instances and Savings Plans really reduce costs?

Allocating cloud costs is hard, and forecasting them is even harder.

Pinterest once committed to paying a smashing $170 million for AWS services in advance and was then forced to buy extra capacity at a much higher rate, spending some $20 million more than estimated. 

How are you supposed to reserve capacity in advance when you have no idea how much of it your company is going to need one or three years from now?

This is the core problem of products like AWS Reserved Instances and Savings Plans.

Keep on reading to find out why they’re so risky and what you could be doing instead.

Here’s a guide I prepared for you:

AWS Reserved Instances: the basics

Companies choose Reserved Instances because they come with substantial discounts compared to pay-as-you-go On-Demand pricing.

All it takes is committing to a specified cloud capacity for a specified period of time. In AWS, it’s one year or three years. In some cases, you also get a guarantee that certain resources will be available to you in a given hosting region. 

How do Reserved Instances work? 

It’s all just like regular instance purchases. Select an instance type, size, platform, and region - and you’re done! It’s like getting a voucher you can use to get a discount any time during your chosen reservation period, often sharing it among teams.

And the larger your upfront payment, the larger the discount.

How much can you save with Reserved Instances?

According to AWS, the EC2 Reserved Instances offer discounts of up to 75% compared to On-Demand pricing. 

But there’s a catch. 

A Reserved Instance operates on a “use it or lose it” basis. Every hour that your instance goes unused is an hour lost (together with any financial benefits).

To make the most of your Reserved Instance, you need to maximize your use of it. This means that you need to know exactly what your teams will need in advance. 

Reserving capacity in advance to get the instances you use all the time at a discount seems like a smart move. After all, you’ll keep on using these cloud resources. But it comes at a price many teams aren’t aware of.

Here’s what you risk with AWS Reserved Instances

1. You will pay a steep price for changing requirements 

When you commit to given resources or levels of usage, you’re basically assuming that your requirements aren’t going to change while the contract is running. 

But in the cloud world, a year of commitment is an eternity. 

Not even tech giants with entire departments dedicated to cost optimization are capable of making accurate forecasts.

Take Pinterest as an example. During one holiday season, its users spent so much time on the platform that the company’s cloud bill went flying over the initial estimates. At that point, Pinterest had already committed to paying $170 million to AWS. And then it had to get some extra capacity and ended up spending $20 million more than forecasted. 

2. You will get locked-in with AWS

By entering into this type of contract with AWS, you’re running the risk of vendor lock-in.

This means that you'll become dependent on AWS for one or three years. Using the products and services of another provider won’t make any sense when you’ve already paid for services upfront. It would also generate substantial switching costs. 

But what if AWS doesn’t have a solution for a challenge your team is going to face in 10 months from the moment you sign the contract? 

3. You will lose all flexibility

Your requirements might change in the future. When was the last time you had to deal with a requirement that stayed static for a year or two?

When facing a new challenge, your team might have to commit to even more or get stuck with unused capacity that you’ve already paid for. Either way, you’re on the losing side.

You’ll have no flexibility of scaling or ability to configure multi-region/zone distribution easily.

Also, setting up AWS Reserved Instances is super difficult

Selecting the optimal Reserved Instance that will meet your application’s workload needs is very complicated, to say the least.

Keeping pace with the latest AWS offerings and choosing from nearly 400 EC2 instance types is already a challenge. Add to it the need to analyze your application’s needs and workload patterns. 

Manual methods are time-consuming and imprecise, making the entire endeavor quite risky. 

Using solutions for cloud bill analysis to determine your Reserved Instances or Savings Plans requirements is a bad idea. The insights they provide might lead you to reserving capacity based on the instance you’re using now, even if they’re the wrong type and size. 

When you reserve the wrong instances, you’ll end up overprovisioning your application and wasting a lot of money in the long run.

And AWS Savings Plans aren’t going to save you

A Savings Plan could be the answer to the lack of flexibility of Reserved Instances.

When buying a Savings Plan, you’re committing to a specific amount of compute that your teams can use over 1 or 3 years. All the usage that's part of your commitment will be covered by your contract. Anything extra will incur additional payments at the On-Demand rate.

Sure, you’re not committing to specific instance types and configurations. But you’re still running the risk of locking yourself in with AWS. And you commit to paying for cloud resources that might make zero sense for your company in 1 or 3 years. 

How to deal with that? Simple, avoid Reserved Instances and Savings Plans

Instead of falling into the trap of reserving capacity upfront for a discounted price, consider cloud cost optimization techniques such as rightsizing, autoscaling, and Spot Instances.

They allow you to stay flexible and reduce your cloud bill by making sure that your teams provision just what they need. 

Try this free Savings Report before committing to a pricy Savings Plan to see how much you could potentially save while retaining the flexibility.

23

Tags:

AwsDevopsKubernetes