In my last two posts I explored the foundations of reserved instances and uncovered their cost benefits to single and multi account holders. The last installment in this series aims to remove the headaches and tediousness of planning a Reserved Instance purchase by looking at planning an RI purchase and modifying the reservations.
Making your first AWS RI purchase can be a daunting task. In addition to the complexity of reserved instances (i.e. reservation type, instance type, availability zone, term, count, VPC/Classic, marketplace), there is also the added complexity of predicting your usage across different teams, applications and functions across your cloud infrastructure.
It’s easy to get caught up in the complexity, so if you are struggling with a process, here is a simple process to get started:
At any reasonable scale, purchasing RIs on a per instance basis will be almost certainly unmanageable. To simplify the decision process, it is important to group your instances based on one or more topics (e.g. environments, function, application). The most common approach is to group instances based on their application / functional purpose (e.g. MongoDB, web servers).
Amazon has different costs for different types of images (e.g. Linux, Windows) that can be launched and each type has different pricing. When grouping your instances, it is advisable to not include different types of images in the same group, since it will substantially complicate your evaluation.
Once you have grouped your infrastructure, start by assessing the potential use of RIs by focusing on the most expensive group first (e.g. MongoDB servers). Since the RIs are really targeted at “always-on” infrastructure, you can choose to not evaluate groups whose infrastructure is only on < 65% of the time.
The key questions you want to ask are:
Before making a purchase you will need to identify, more specifically, the reservations within each group you want to purchase. The additional key items you need to specify include:
While the all upfront RI offering will always provide the highest cost savings, sometimes that savings is not enough to justify the additional cash outlay for the upfront fees. In example below, purchasing an all upfront reservation will require an upfront payment of an additional $308, over a partial reservation, in return for a 2% savings over on-demand.
Many customers have decided against all upfront reservations due to the economics and sometimes ineffective use of capital caused by the low savings. We recommend, however, you evaluate this on an instance type, by instance type basis since there are some types for which the additional savings can be compelling.
If you have more than one account linked in a consolidated bill, an obvious question arises - In which account should you make the purchase of reservations? There are two common approaches:
The general best practice is to purchase reservations in the accounts you have specific instance usage.
While Reserved Instances are an easy way to guarantee capacity for your instances and reduce your cloud computing costs, your usage needs may not always match your reservations. This is why it is so important to modify your reservations on a regular basis to maximize their cost benefit.
AWS makes it easy to modify your entire reservation or just a subset of them in the following ways:
As long as the instance size footprint of the reservation (e.g. 1 m1.large for 4 m1.small instances or vice-versa) remains the same, provided that capacity is available, Linux (minus Red Hat) instances can be modified to match your current usage needs.
If it’s not already, continuously modifying your reservations should be a part of your overall RI management strategy in order to reap their cost and capacity reservation benefits. This is, after all, why you bought them. The following example highlights a compelling reason modifying your reservations:
Let’s assume you have 2 c3.4xlrg reservations in the eu-central-1b region with no matching on-demand usage but 4 c3.2xlrg instances being used 100% of the time in eu-central-1a. The on-demand monthly charges for each of the c2.2xlrg instances will cost you $752.95 per month. If you modify and split and your 2 c3.4xlrg -1b reservations into 4 c3.4xlrg instances in the 1a availability zone, you guarantee the capacity reservation and will benefit immediately from the cost savings, all while ensuring that your prepaid reservation is being used.
Modifications, like purchases, can be submitted through the AWS console, directly through the API or automatically with CloudHealth.
Since this process can be very manual and time consuming, you can save a lot of time and stress using CloudHealth Technologies’ Reserved Instance Optimizer. Stay tuned for our eBook which will include detailed examples, how-to’s and policies for purchasing and maintaining your Reserved Instances.