What Are Size Flexible RIs?
Late last year Amazon introduced the concept of ‘Regional’ EC2 reservations’. If you aren’t already familiar with the concept, take a moment to get acquainted with this offer and come back once you’ve stopped worrying about what instances are running in each AWS zone. It’s all good now, right? Unless of course purchase RIs for both capacity reservation and discount, in which case, you still need to pay attention to modifications as usage drifts.
If you’re already in-the-know, you were already aware that a regional reservation covers any matching instance (type, OS and tenancy) running within a region. The result is that you no longer need to modify Availability Zone to match usage when EC2 capacity isn’t an issue.
Recently, AWS announced one more change to regional reservations that does follow the narrative — they’ve added the ability for regional reservations to apply across sizes within a family. Moving forward, your regional reservation is now size agnostic and can be applied to any instance within a family.
Why Size Flexible RIs Matter
What does this mean in terms of the big picture for Reservations from AWS? On it’s own this is a pretty big step towards flexibility and simplification. If you step back and look at the enhancements AWS has made since they’ve released EC2 Reserved Instances. There’s clearly a trend towards – improved flexibility and greater simplicity.
In 2013, AWS announced the ability to modify reservations. You’ve probably targeted a workload to an instance family – High Performance Computing, Compute Intensive Workloads, Memory Intensive Workloads, High I/O Workloads, etc. – but your footprint may have grown or shrunk. Likewise you may be using different zones for fault tolerance or to manage capacity. Before the ability to make RI modifications, you purchased multiple reservations in different AZs to address these concerns. After RI modifications were possible, changing the AZ or family size was simply an API call away. This process is relatively straightforward on individual instances, but daunting when managing a large number of RIs across instance types or zones. Manually modifying RIs was probably not the best use of your time, which is why many of the largest AWS customers used cloud service management solutions like CloudHealth to automatically manage RIs and RI modifications.
Next was the introduction of regional reservations in late 2016. If you are willing to forgo the capacity guarantee AWS removed the constraint of AZ when managing reservations. Ok, your life just got a little bit easier when it comes to managing RIs. No more reservation modifications to chase your usage in different zones.
How will ‘Size Flexibility’ work?
A regional reservation is assigned a total number of units and a unit burn rate: the number of units consumed by a running instance. Both of these are assigned in proportion to the size of the instance.
This concept already exists today but is not exposed to users as a concern for anything other than modifications. The concept of a ‘Normalization Factor’ is noted in the AWS documentation. AWS is now exposing the direct measure of consumption and it’s become a primary concern.
Here is a greatly simplified example: I buy a t2.small reservation, which is assigned 40 units and a unit burn rate of 1 unit/hour. I run a t2.small instance in the same Region for one hour, consuming one unit and leaving the reservation with 39 remaining units. I then launch a t2.medium (which burns 2 units/hour) for one hour. AWS will automatically apply the t2.small reservation to that t2.medium and consume 2 units from the original reservation. My original t2.small reservation now has 37 units remaining.
This scales up as well as down: in this same example, if I ran a t2.micro in that Region for 1 hour, the instance would benefit from the t2.small reservation but it will only consume .5 units for the hour. This flows all the way down to a nano which consumes .25 units and up to a 32xlarge which consumes 256 units. It’s important to note that not all units are created equal: the units for the t2 family are not equivalent to the units of the r4 family and reservations do not float across families.
What does this mean for AWS Users?
AWS customers who are already using mostly AWS Linux/UNIX shared tenancy regional reservations do not need to take any special action to benefit from these changes. All AWS is doing is removing the consideration of family size from reservation accounting. Any existing or new regional size flexible reservation is now consumed in this manner.
While this change greatly simplifies day to day management of reservations and their modifications, there are two new areas of complexity:
- There are now multiple units of measure — one for AZ-Scoped reservations, one for size flexible regional reservations, and another for non-size flexible regional reservations. These must be considered together when evaluating reservation opportunities.
- Over the course of an hour, an individual instance can now be completely covered by a reservation, partially covered by a reservation, or even covered by multiple reservations. Accounting for one instance hour with fractional charges at different rates, at scale, across an organization is extremely complicated.
The outcome of this is customers who use regional reservations will need to monitor consumption by the unit — tracking multiple reservations applied to every single instance hour for all of their EC2 Compute.
None of this should stop you from adopting regional reservations if you haven’t already. Remember, that if you are concerned about guaranteed capacity, you will need to maintain an inventory of AZ reservations. However, there is a significant benefit to regional reservations and I will not be surprised when AWS moves further on the same trajectory of reservation simplification.
