Reserved Instances (RIs) are a great way to save on AWS EC2. But there can be hidden costs to planning if you prioritize for capacity certainty. We’ll walk through the key costs of planning for capacity certainty and offer a recommendation for a more a flexible approach.
Reserving for capacity certainty versus cost savings
As discussed in our Reserved Instances 101 eBook, there are two distinct reasons you may make a capacity reservation. The first and most obvious reason is that you’ll get a lower hourly rate over paying on demand. Of course you’ll want to make sure you minimize RI waste by creating a waterline strategy, which makes sense for your AWS environment.
The other benefit is that you are getting a level of capacity certainty from AWS. If there’s contention for a specific instance type in a region, you’ll be first in line to provision a new instance. This can be very important if you have a critical workload that you can’t afford to be offline and require this provisioning certainty. However, we’ve seen this requirement gradually lose focus (it was more prominent in the good ol’ days of everyone piling into the us-east-1 region and concentrating on the m1 series).
When purchasing for capacity certainty, make sure you do so in the account where the instances are actually running and in the exact Availability Zone (AZ). If you don’t, then you lose the guarantee for capacity. With all of this in mind, let’s look at three very real downsides when prioritizing for capacity certainty.
Increased administration overhead
As mentioned, purchasing for capacity certainty means purchasing in every linked account for usage contained there. Many of our customers have tens to hundreds of AWS accounts. The administration overhead increases proportionally with the number of accounts you have.
These costs include the cloud cost analysis your team should do to establish usage patterns and individual savings (Cloudability can help make this aspect easier), the communication and decision making with internal stakeholders, and the purchase of the reservations in the AWS console.
For example, let’s say you have 20 common instance type/AZ/Operating System combinations you need to purchase RIs for across a total of 10 linked AWS accounts. With a consolidated buying approach (purchasing for savings by rolling all usage up at the Master Payer level), this would be 20 individual purchases. Purchasing for capacity certainty within each account would be 200 purchases.
Lower overall savings
From our experience with users, there are fewer savings achieved when planning for capacity certainty. When considering your options, one thing that’s easy to miss is that you are likely to gain more savings overall with a consolidated approach. As covered In the aforementioned case study we did with Atlassian around establishing a waterline, RI decision making needs to be based on building a histogram of usage hours.
This means working out how many instances are running for each hour of the day and targeting a high utilization of any RI that is purchased. If you are purchasing on many individual “thinner” accounts as you do when prioritizing capacity certainty, there are likely to be more holes in the histogram and less RIs purchased.
If you can combine multiple accounts together as you do in the consolidated approach, you can get an effect somewhat like destructive interference, where troughs in some usage will be buffered by peaks in other usage. Analyzing in this way will lead to higher RI coverage overall and greater savings.
Loss of flexibility
Purchasing RIs in an unconsolidated manner can lead to a loss of flexibility as your infrastructure changes. One of the things you can do with Cloudability is get modification recommendations for your RIs so they can keep up with your ever shifting infrastructure. Our customers or those trying out our tool can get in touch and we can fully automate this process for you. This is tougher to do when prioritizing capacity certainty. For example, when infrastructure changes, and hence mismatches your RI portfolio in that account what do you do?
You may have resources in other linked accounts that could take advantage of the RI if it was to be modified — if you do this you are moving away from a focus on capacity reservation to a focus on savings. Maybe that’s fine, but it’s sure going to complicate how you and your team manage your RI costs over time.
A special consideration: Regional Scoped RIs
As we blogged about late last year, AWS released a new and important option when purchasing your RIs: whether to scope the location of the reservation to a specific AZ or to an entire region. It’s very important you make the right decision during purchasing. If you scope it to a region (e.g. ap-southeast-2 for Sydney) then the capacity component doesn’t apply at all.
If you are looking for that capacity certainty, make sure that you reserve at the AZ level. On the contrary, if you’re just looking for savings, choose the Regional Scope option. This will lower maintenance efforts even further with far fewer RI combinations and will lead to greater overall savings. If anything, the region scope option further underscores what you give up when reserving for capacity certainty.
Pro tip: If you have previously purchased your RIs solely for savings, you may want to change the scope from Availability Zone to Region for your whole fleet.
How about a “hybrid” approach?
There are plenty of organizations that require capacity certainty, and we know everyone loves to save on AWS. One approach could be to cherrypick how and when you purchase for capacity certainty.
For example, purchase for capacity certainty in regions which are known to have contention issues for specific instance types. Or, do it just for your critical production infrastructure where every second of downtime is absolutely crucial. For the remainder of your environment, we highly recommend you prioritize savings and simplicity.
See this kind of RI planning at work with Cloudability by starting a Free Trial today. Or, get in touch with our Reserved Instance experts for more information.