The most expensive mistake companies make when changing AWS instance families
When Amazon Web Services introduces new instance families, it can be tempting to jump aboard. However, making such changes to your infrastructure can have unintended consequences: namely, by replacing old instance families with new ones, you risk rendering the Reserved Instances (RIs) that you’ve purchased unusable. It’s therefore important that before changing AWS instance families, you’re able to anticipate the financial impact and make efforts to minimize any losses.
Why family matters
You can save on the costs for a particular type of instance by purchasing a Reserved Instance (RI); the RI acts as a coupon for a reduced rate on that specific instance type for a 1yr -or- 3yr duration. AWS allows you to change the size, AZ, and platform of a Reserved Instance for free after your purchase, which is fantastic for ensuring your RI purchase stays aligned with your deployment and enables prolonged savings throughout its 1yr -or- 3yr term. As such, you might be wondering why businesses don’t simply modify their reservations all the time to keep them perfectly aligned with even the slightest infrastructure changes; the reason is because there are limits.
Reserved Instance modifications are currently limited to the OS and within the instance family and region of the initial purchase. So while you can break down an m1.large linux into two m1.medium linux RIs for free, you can not break that m1.large into two c1.mediums or that m2.large RHEL into 2 m1.mediums RHEL RIs. This is the most common roadblock that businesses face when trying to keep their reservations relevant; the more instance families you introduce into your infrastructure, the more challenging it will be to modify your Reserved Instances to align them where you need them.
Justifying the economics of abandoning an RI
When you replace one instance family with another, you won’t be able to modify your reservations to apply to your new instance families. Therefore, you should only make such a change if the value that you’ll get from using the new family will exceed the sunk cost of whatever’s left of the reservation term for the instance that’s being replaced. The sunk cost will be greater the more recently you bought the reservation, because you will have had fewer hours to benefit from the reduced hourly rate that you unlocked. However, you generally do not have to use a Reserved Instance for the entirety of its 1-year or 3-year term to reach a break-even point. In fact, there are a couple of natural break-even points to be aware of. For example, the “upfront cost break-even” is the point in time at which any upfront payment to acquire the reservation is covered by savings provided by the reduced hourly rate. Then there is the “committed cost break-even”, which is the point in time where the term for which you committed monthly payments is covered by the savings provided by the reduced hourly rate.
This example features a partial-upfront reservation purchased in January with a 1 year term; the upfront cost break-even point is five months after the purchase and the committed cost break-even is seven months after the purchase. Generally, the earliest time to change instance families, or to stop using a reservation without taking a loss, would be after the RI’s committed cost break-even point. Remember though, that discontinuing use of your reservation shortly after the committed cost break-even only means that you have saved enough to cover the total cost of ownership for the RI – you’re still writing off future savings that you had originally intended to get.
But what if you wanted to change instance families before reaching the break-even point? It’s particularly important that you’re clear on the value of switching to the new family. For example, you may find that you require fewer new-generation instances to do the same job; perhaps the switch will reduce your cost per subscriber; perhaps the new-generation instances are significantly less expensive. If you’re poised to save money by making the change immediately rather than waiting to break-even or save with your existing Reserved Instances, that’s great – but it’s imperative that you do the calculations and make an informed decision. Let’s explore this scenario.
Calculating the cost of a family change
Consider the scenario where we wish to change instance families before the break-even point. Our infrastructure is running m1.large instances and we’re considering moving to the newer m4.large instance types. Currently, we have committed to a 1year term for old family RIs with a Partial-Upfront payment option. We can use the following formula to determine if the change will make sense; you will of course want to customize this formula according to the nuances of your own situation.
The “annualized cost” argument used in this formula refers to the hourly rates of your old family RIs and any new family instances, for the year. Note that if you do not intend to buy Reserved Instances for the new family, then simply use the appropriate on-demand rate and annual cost. The “old family RI write-off” argument represents the portion of the old family RI committed cost that remains at the time of the family change. Once you’ve calculated those values, plug them into the formula. If the resulting “family change % savings/loss” is negative, then the change to the new family is potentially less economical than sticking with the old one.
Adding some color to our scenario; let’s say we’re considering the switch after only having our old family RIs (m1.large) for 5 months and before we reach the break-even; this leaves us with 7 months of RI payments to which we’re committed. Additionally we’re running 10x old family (m1) instances and the change will result in only 9x new family (m4) instances being required for the same workload. Using AWS rates, our formula calculation is:
Under this scenario, the change to a newer instance family will actually result in a savings rate of 6% despite having 7 months of old family RI payments remaining. Additionally, if you proceed to purchase RIs for the new family instances, then your savings rate will be higher. But wait, there’s more – if you leverage your old family instances by reprovisioning them for your Dev or Management environments, you can leverage the old family RIs and save there too.
Out of curiosity, what if changing to the new family instances did not result in a reduction in the overall instance count ?
The change to the newer instance family will result in a -1% rate. Is this less economical rate significant enough to full stop the switch? Good question; for example, can you deploy more service nodes per new instance reducing your cost per subscriber thereby offsetting the loss ? The nuances of your deployment will help determine if proceeding with the change to a newer family instance makes sense.
Identifying candidates for change with Cloudability
If you decide to go through with an instance family change, you’ll need a method for identifying which instances to stop using first. One of the simplest ways of doing this is with Cloudability’s Usage Analytics feature.
Finally, remember that it’s important to keep tabs on which of your instances are currently using reservations. If you find that their usage levels are so low that they wouldn’t generate sufficient reservation usage anyway, go ahead and make the change – but if an instance is getting regular usage out of a reservation, strive to either reach that break-even point or confirm that the financial benefit of switching families will outweigh the sunk cost.
Building a flexible future
Whether you want to generate a report of your own instance types and their roles within your infrastructure, or see how to reallocate reservations with our Reserved Instance modification recommendations, Cloudability can help you take infrastructural changes in stride without disempowering your reservations. Simply log in or sign up for a free 14-day trial of Cloudability Pro to get started. Have fun exploring, and happy savings!