DEV Community

Cover image for Exploring the Options for Billing and Capacity Reservations
Brian Tarbox for AWS Heroes

Posted on

Exploring the Options for Billing and Capacity Reservations

Although many projects have embraced serverless for the compute portion of their applications there are still many systems that are based on EC2 instances. These EC2 instances can often be large cost drivers and so there is a whole industry around ways to reduce that spend. In this article we will explore the relationship between Reserved Instances, Capacity Reservations and Savings Plan.

For the purposes of this article, we are assuming that the compute workload is not compatible with Spot Instances or Spot Fleets. Those two approaches are generally the most cost effective but require that the application can handle interruptions. Many applications can do so but many others cannot.

When dealing with cost optimizations and capacity issues we also tend to look at the larger instance sizes. These instance types are the most expensive and can often be in short supply. If you’ve ever gotten the “Insufficient Capacity” error you know what I mean.

So, while you certainly can use on-demand style instances, perhaps within an AutoScalingGroup that can sometimes not be the most cost effective or resilient strategy.

There are really two variables to be considered here: cost and availability.

Reserved Instances
The cost factor can be address with various forms of Reserved Instances as well as via various Saving Plans. Interestingly enough, if you go to the Reserved Instance page you now see a message saying that AWS recommends Savings Plans vs. RIs.

When you purchase a Reserved Instance you are paying for a certain amount of EC2 usage … which is distinct from actually running any EC2s. This is easier to explain by example.

Suppose you run three m5.2xlarge instances 8 hours each day. Normally you would be paying for 8 hours * 7 days * 3 instances. If you had single m5.2xlarge Reserved Instance then whenever you were running such instances the first instance’s cost would be covered by the RI. So, you would be paying for two instances via on-demand and one instance via the RI. Basically, an RI is an agreement to use/purchase a certain amount of instance usage.

RIs payments can be made via upfront payments and/or via hourly rates. The lowest cost is achieved by agreeing to a three year term with all of the cost paid upfront. At the other end of the pricing spectrum, you could purchase a one term term with zero upfront cost but a higher hourly rate.

Keep in mind that this is all just about cost, not about any actual availability of an instance. You might create an RI for a g5.32xlarge but find that there was “Insufficient Capacity” to actually create such an instance when needed.

Capacity Reservations – aka On Demand Capacity Reservations – aka ODCR
Capacity Reservations are an agreement with AWS that the specified instance(s) will be available when needed. If you create a CA for 2 g4dn.16xlarge instances then those instances are taken out of the free pool and will be marked as “in use”. Since no one else can use them you have to pay for 24x7 usage even if you are not actually running the instances all the time. While the idea of paying for something that you’re not using is at a certain level counter to the least cost principal of AWS it does guarantee that when you do need the instance it will be available for you.

Another very important thing to know about ODCRs is that you can cancel them at any time. This is in sharp contrast with Reserved Instances which are locked to a one or three year term.

Scheduled Instances
Scheduled Instances allow you to purchase capacity by the hour on a certain schedule. A use case for this might be a weekly batch job that had large requirements but only once a week perhaps at a certain time and day.

Standard vs Convertible Reserved Instances
In a standard RI you can change the Availability Zone and instance size but you cannot change the instance type. So, you could go from a g5.xlarge to g5.2xlarge but not to a g4dn.xlarge. These reservations can also be bought and sold in the Reserved Instance Marketplace.

Convertible Reservations on the other hand let you change the instance type but they cannot be exchanged in the Marketplace. The flexibility to change instance type comes at a slight increase in cost (or decrease in savings).

Regional vs Zonal Reserved Instances
A regional RI is independent of the Availability Zone. So, any matching instance that is run in the given region will benefit from the reserved cost. These are strictly cost based reservations as there is no capacity guarantee. Regional RIs also allow for instance size substitution. If you reserve say two 2x versions of an instance type the discount will be applied if you run a 2x version but also if you run a 4x version. Note that this flexibility only applies to Amazon Linux instances and does not apply if you are running Window’s instances.

Zonal Reservations on the other hand require the specification of a particular Availability Zone and the discount only applies to that specific instance type and size in that AZ. On the other hand, and this is critical, Zonal Reservations do guarantee capacity.

ODCR vs Zonal RI
So, the bottom line is: what is the difference between an ODCR and a Zonal Reserved Instance?
Let’s walk through an example of using each approach to assure the availably of a g5.16xlarge.

If we created a one year Standard, Windows, Zonal RI with All upfront payment for a g5.16xlarge instance the cost would be $46,887 for the year, for an effective hourly rate of $5.352.

If we created a Capacity Reservation for a Windows g6.16xlarge the cost would be $42,801 for the year or an hourly rate of $4.886.

Savings Plans apply to either approach so the actual billed cost would be lower. In this example ODCR is the better approach. All of this is to illustrate that finding the best pricing model for your EC2 needs is still a complex process, but hopefully we’ve shown you how to approach solving the equation.

Top comments (0)