Amazon EC2 – Making Sense of the Cost Options (Part 2)

Peter Cridland 1st February 2016

The concluding part of our exploration of EC2. Read Part 1 here.


Instance Reservations

Instance reservations are on the face of things fairly straightforward. There are three options:

  • No Upfront, where for no upfront cost you commit to pay for an Instance matching the reservation criteria (of type, platform and Availability Zone) for 12 or 36 months in return for a discount on hourly costs, typically in the region of 25% for a general purpose Instance for a 12 month reservation;
  • All Upfront, where you pay an upfront cost which allows you to run an Instance matching the reservation criteria without incurring an hourly compute cost for the matching Instance for the reservation period, which will typically provide an overall saving in the region of 30% for a general purpose Instance for a 12 month reservation; and
  • Partial Upfront, which is a halfway house, where you pay a smaller upfront cost in exchange for a moderate discount on hourly cost for an Instance matching the reservation criteria, which will typically provide an overall saving between that of a No Upfront or All Upfront reservation.

Looking at reservations in more depth, there are a couple of key gotchas which need to be considered.

The first consideration is that an Instance reservation is not tied to a specific Instance. Instead, it will apply to and confer the benefits on any On-Demand Instance which meets the reservation criteria (of type, platform and Availability Zone). This means that for larger or elastic estates it is possible to model reservations against overall numbers of Instances rather than specific Instances. Reservation modelling is offered by services such as CloudHealth (and of course also by Cloudreach Governance Services) to enable customers to make informed decisions on reservations of their estate. Services such as these have significant benefits over AWS Trusted Advisor, which will identify potential reservation targets for you, but only at a very high level without the long-term sensitivity to Instance run-times, which can risk over-reservation.

Another consideration is that for all reservation options, you are committing to pay for an Instance matching the reservation criteria (of type, platform and Availability Zone) for the duration of the reservation. If you shut down or resize an Instance which is currently making use of a matching reservation, and there is no matching Instance to take advantage of the reservation, you will continue to pay the Reserved Instance hourly price even though no matching Instance is running. In the case of an All Upfront reservation, whilst you are not paying an hourly cost, you are failing to take advantage of the upfront payment you have made, which has the same effect on your TCO.

To make matters worse, in the case of resizing, you will pay the On-Demand cost of the resized Instance in addition to the Reserved Instance cost for the now unused reservation. As a result of this, when considering reservations, it is important to consider the capacity plan for workloads running in your estate, and modify any reservation plans accordingly. When Cloudreach Governance Services engages with a customer, we will typically work with the customer to understand capacity plans so as to provide optimal reservation recommendations, and to work with the reservation movement and resizing capabilities of EC2 to provide ongoing optimisation of reservations.

My team have a saying, ‘information without insight is at best a blunt instrument’, and the understanding of a customer’s capacity is what separates a suboptimal reservation plan straight out of a visualisation tool from an optimal reservation plan which takes these into account.

It is the commitment to pay for a matching Instance for the duration of the reservation which results in the effective breakeven points for Instance reservations. As a rule of thumb, for a 12 month Instance reservation for a general purpose Instance, the break-even point for percentage of time a matching Instance must run over the duration of the reservation for reservations to become cost effective is in the region of 70-75%, although this can vary greatly depending on Instance size and operating system. Understanding of these break-even points is critical to an optimal reservation strategy.

If your Instance contains a workload that is not tolerant of unscheduled termination and needs to run for more than the break-even for the Instance type, Instance reservations are the most cost-effective option, but beware of capacity planning! It is cheaper, for example, to run an reserved Instance one size too large for 12 months than to run a reserved Instance for 6 months and resize it due to increased demand on the workload.

 

Conclusion

Of course there are further cost optimisation opportunities within EC2, not to mention within Amazon as a whole. The article has given a brief overview of the various cost options for compute resource within EC2, along with related use cases, but of course there are various permutations and combinations of these options that can be deployed, and there are also strategies for optimising storage and networking costs associated with AWS compute capacity. This is even before considering optimisation of additional AWS Services.

The beauty of the AWS cost model is that, by considered architectural design and ongoing optimisation of costs, there is a cost effective solution for virtually any workload from large enterprise workloads through agile, scalable digital estates.

If you are interested in learning more about Financial Optimisation or how Cloudreach can assist your business in implementing a solid governance framework for its cloud estate, please drop us a line on commercial-uk@cloudreach.com.

Liked this post? Check out our Slide Deck on this topic!