Amazon’s New Resizing Policy on Reserved Instances Explained
Reserved instances are probably the most challenging aspect of managing complex cloud deployments on AWS. Last month, we posted about relocating existing reservations between availability zones (AZs). Soon after, Amazon raised the bar even further by enabling AWS users to modify instance types. This has opened the door to many new opportunities to resize existing reservations and optimizing your deployment’s performance even further. Not only can you relocate an entire reservation from one availability zone to another – you can now split up existing reservations, providing you don’t increase your normalization factor.
Nailing Down the Normalization Factor for Optimal Sizing
Within instance families, types range from small to 8xlarge. The normalization factor is Amazon’s metric for measuring instance units. Small is assigned a single normalized instance unit, which then increases exponentially by the power of 2 (i.e. 2 units for medium, 4 for large, and up to 64 for 8xlarge). For example, if you reserve one 8xlarge machine, you could modify that reservation to include 64 smalls, 32 mediums, 16 larges etc. With Amazon’s new flexibility, you can easily split up or merge your reserved instances to improve your deployment’s performance without inflating your AWS bill.
Proactive Management of Unused Reserved Capacity
Deciding which reservations to buy based on your usage history and planned capacity is key to getting max ROI from your cloud deployment.
But even with the best laid plans, sometime projects unexpectedly end and reserved capacity might exceed demand.
Cloudyn’s new, Unused RI Detector allows you to not only identify excess capacity, but see where it can be recycled – either by moving to a different AZ with a matching On-Demand instance, or by modifying the reservation instance type to be applied against other, existing On-Demand instances.
Revisiting Sizing Recommendations on Cloudyn
In many cases, DevOps teams tend to purchase instance sizes that don’t yield optimal cost/performance. For example, our analysis has shown that 2 m1 mediums perform better than a single large. From a cost perspective, there is no difference. But now, even if you’ve purchased a reserved instance, you can always go back and change the instance type, assuming your updated normalization factor doesn’t exceed your original reservation.
Making that commitment to RI purchasing doesn’t have to mean compromising on flexibility. You can always relocate that reservation, and even split it up into several different instance types. Working with AWS reserved instances is always a balancing act – getting the best performance from your deployment while keeping a close watch on cost management.