Amazon Web Service’s NEW Reserved Instance Feature

At the start of this month Amazon released a new feature to their reserved instances called Instance Size Flexibility. You can read more about it here. This is quite a handy little update to how they handle reserved instances on a regional setting.

When they first came out, reserved instances were great for the huge savings but a real pita to manage in large environments spanning multiple regions or accounts. In order to take advantage of it you had to make sure you reserved the proper region and instance type for ALL of your individual instances. With few servers of only 1 or 2 types, not a big deal but scale out to hundreds of servers in multiple regions, zones and accounts and you had a recipe for a major accounting and administrative nightmare unless you looked into automation. That all changed in the last quarter of 2016 when Amazon released updates to how RI’s worked.

The first major change that came about was they changed ‘capacity reservations’, which is what they call the reservation of an instance by zone and instance type, and regionalized it. So now you can purchase reservations in a region, such as North Virginia, and have it apply to ALL instances in any availability zone in that region. More can be read about this here. They called this ‘regional benefit’ and it easily allows you to provision reserved instances for all instances in a region without worrying about what zone they are in. If you wish to assign the reservation to a specific instance, you can modify it to become a ‘capacity reservation’, then it will be tied to that zone. There is no difference in cost between capacity reservations and regional reservations.

The other change that they made in September 2016 was the introduction of convertible reservations. While not a topic of this post, these are handy if you want to commit to a 3 year term but want to have the flexibility to change your instances as you are not locked to instance type or operating system. These would be good for changing workloads and environments. If you want more details read the AWS blog post, or leave a comment.

The latest enhancement to AWS reserved instances further enhances this regional benefit by also making your reserved instances somewhat ‘convertible’ as well. As stated in the Amazon blog post, “All Regional Linux/UNIX RIs with shared tenancy now apply to all sizes of instances within an instance family and AWS region, even if you are using them across multiple accounts via Consolidated Billing”. **NOTE: not available for Windows or RHEL/SUSE yet**

So what exactly does this mean? Well it means if you have regionally reserved capacity, and want to change your servers around, you can STILL take advantage of your reserved instance pricing. This is possible through the introduction of ‘normalized units’, or normalization factor that provides for this. The only catch is your instance must remain within the same instance family (c3 remains c3, m4 remains m4, etc). So a small instance has a normalization factor/unit (nu) of 1, medium is 2, large is 4, doubling like the prices do, go figure.

Let’s do an example to see how this works.
We have the following 6 instances all default tenancy and all regional reservations:

2x m4.large 1 in us-east-1a, 1 in us-east-1b
2x m4.xlarge both in us-east-1a
1x c3.2xlarge in us-east-1c
1x c3.medium in us-east-1b

We have the following reservations:
3x m4.xlarge in us-east-1
1x c3.xlarge in us-east-1
1x c3.large in us-east-1

How does this all work out, let’s calculate the normalization factor.
2x m4.large = 8nu
2x m4.xlarge = 16nu
1x c3.2xlarge = 16nu
1x c3.medium = 2nu

This gives a normalization factor of 24nu for m4 instance family and 18nu for the c3.
We purchased 3 m4.xlarge for 24nu total, so 1 m4.xlarge reservation is split across the the 2 m4.large instances.
3x m4.xlarge = 24nu matching the 24nu requirement for our m4 instances.

When it comes to our c3 instances there is a mismatch. We have 18nu required in reservations but we only have 12nu of reservations available.

Available c3 reservation capacity:
1x c3.xlarge = 8nu
1x c3.large = 4nu

Required c3 reservation capacity:
1x c3.2xlarge = 16nu
1x c3.medium = 2nu

In a situation like this, AWS will charge us a prorated charge on the unreserved capacity of 6 c3 normalized units, thus you will pay 75% of the on demand rate for a c3.xlarge instance to make up for those 6 unreserved normalized units. If you want to reserve everything 100% you will have to purchase 3x c3.medium or 1x c3.medium and 1x c3.large to make up the difference or any combination of recalibration to make up the 6 units such as downgrading the 2xlarge to xlarge and upgrading the medium to large to match your reservation.

Zonal/capacity reservations add a bit of a wrinkle as they are applied BEFORE regional reservation. Thus if the 3x m4.xlarge were zone reservations in us-east-1a, they would only apply to those instances in us-east-1a and the m4.large in us-east-1b would be considered on demand. Then you would be left with 4nu available to you in us-east-1a as they are unused.