EC2 Cost Options: Understanding Reserved, On-Demand, and Spot Instance Pricing

Copyright ©2015 Cloudreach limitedNot if. When
Cloudreach Voices
Cloudy Issues Explored
Our take on Cloud Technology

Copyright ©2015 Cloudreach limited
Cloudreach Voices: EC2 Making Sense of the Cost Options
Copyright ©2016 Cloudreach Limited

is recognised as a market leader
in delivering cost effective,
scalable compute resource via its
Elastic Compute Cloud (EC2)
service.
AWS
● Options from single core, sub 1GB RAM Instances through to 36 core, 244GB
behemoths
● Intelligent autoscaling capabilities which dynamically manage Instance numbers
to suit load varying load requirements
● There are affordable, appropriately sized options for practically any
workload.
EC2

its main value proposition was the provision of temporary
compute resource for rapid prototyping and development of
workloads.
With EC2 today, businesses can deliver highly available, secure
and compliant production applications and services to internal
and external customers in an economical, OpEx-driven cost
model without the traditional up-front CapEx costs of traditional
on-premises ‘tin’.
In the early days of EC2
enterprises large and small are
harnessing the capabilities of EC2
and associated services.
These days

As well as embracing DevOps and
infrastructure as code methodologies,
the most successful cloud consumers
are developing new cloud-specific skills,
including FinOps: the design and
management of cloud estates to deliver
maximum possible bang for your buck.
And EC2 is a key target for FinOps.
To deliver optimal solutions within AWS takes a different set of skills to
traditional on-premises or hosting services.
BANG!

Understanding the cost options available for the launching
and running of EC2 Instances
Important elements of optimising
EC2 solutions
Let’s briefly run through the available options, and some of the key
use cases for each.
Selecting the most appropriate options for your
architecture

Good if you have very rigorous compliance
requirements (or perhaps auditors who have very
rigorous interpretations of compliance requirements)
Dedicated hosts also provide visibility on physical
cores on the Instances, which can be required by
software vendors whose licensing regimes are not
(yet) well aligned with modern trends towards the
cloud, or even old-school on-premises virtualisation
Dedicated Instances/Dedicated Host Instances
Rating: Most Expensive
Advantages:
Pay hourly
Reserve for the use of one or more
Instances on hardware dedicated
to single customers
Reserve for a whole host dedicated
to the customer on which there are
multiple Instances of the same
family (e.g. general purpose
generation 1, 3 or 4, compute-
optimised or memory-optimised
Instance families).
Cost Analysis
Conclusion
These options have a very specific niche. Since even
rigorous financial regulatory frameworks such as PCI
can be satisfied with non-dedicated Instances,
dedicated Instances and hosts will typically not be
central to the majority of cost optimisation strategies.

All Instance type/platform/region combinations have specific break-
even points based on the percentage of a reservation duration that
the Instance can run.
Below these break-even points, On-Demand Instances will work out
more cost effective than running under a matching Instance
reservation. These vary between types, platforms and regions, but as
a rule of thumb, general purpose Instances running for less than 70%
of a 12 month period will be more cost effective running On-Demand
rather than under a 12 month Instance reservation.
Compared to Spot Instances, and On-Demand Instance may be more
expensive, but unlike a Spot Instance, On-Demand Instances are not
under threat of termination if the number of available matching
Instances drops too low.
On Demand Instances
Rating: Moderate (though has many
benefits)
Advantages:
Default Instance option and Workhorse
of the EC2 world
Pay a fixed hourly cost based on the
Instance type, platform (e.g. Amazon
Linux, Windows, Ubuntu etc.) and region
profile of the Instance for every hour or
partial hour that the Instance is running.
You can shut down and restart a
configured On-Demand Instance when
not in use and you will not pay the hourly
cost for compute whilst the Instance is
running.
(But you will pay the storage costs of
any attached EBS Instances).
Cost
Analysis
Conclusion
If your Instance contains a workload that is not tolerant
of unscheduled termination and needs to run for more
than 6 hours but less than the break-even for the
Instance type, On-Demand is not only the most flexible
but the most cost-effective option.

To take advantage of these potential savings there
are of course trade-offs.
The Spot Instance market apportions resources that
would otherwise remain unused until required by a
customer for On-Demand or Reserved Instances.
When looking to provision one or more Spot
Instances, a customer places a bid for the maximum
price they are willing to pay for a spot Instance.
Available resources are granted to Customers based
on highest bid first, with earliest bid breaking
deadlocks, until all available resources are
consumed.
Spot Instances
Rating: Moderate
Cost
Analysis
Advantages:
Cost of running Spot Instances can, in some cases, be an order
of magnitude below that of the equivalent On Demand Instance.
The value of the lowest priced bid fulfilled sets
the Spot price, which all customers pay.
However, as resources are required for On-
Demand or Reserved usage, AWS will terminate
Spot Instances so as to provision the resource
for full fee-paying customers. They will start
terminating Instances at the lowest bid first until
all On-Demand and Reserved Instance
requirements are met, with the new lowest
bidder setting the Spot price with their bid.

This has two knock-on effects:
Price paid for a Spot Instance is unpredictable and fluctuates over time (though it will never exceed the Customer’s bid for
the Instances because, at the point this would happen, the Instance would be terminated). Thus, as long as your Spot bid
is lower than the On-Demand asking price, you will never pay more than the On-Demand price to run the Instance.
A Spot Instance can be terminated at any time, without warning. Customers heavily invested in the use of Spot Instances
will often develop, or seek the assistance of partners such as Cloudreach to develop tooling to gather Spot pricing data
from the API, analyse risk and adjust their Spot usage strategy accordingly. Amazon has also recently provided a web tool
to allow customers to get a broad brushstroke picture of the likelihood of an Instance being terminated at a given spot bid
price.
Spot Instances
Analysis
Conclusion
Even the best algorithms cannot predict sudden rushes of demand for an Instance type such as a large customer
spinning up large farms of EMR Instances, and as a result, Spot Instances are best used in a number of specific use
cases:
● Workloads performing time-insensitive, non-urgent tasks;
● Workloads that can tolerate unscheduled termination and store execution data and state off-system; or
● Elastic workloads that have been architected to request and use Spot Instances in preference to On-Demand
Instances where available.

The situation with Spot Instances has recently
gained an additional dimension with the
announcement of Fixed Duration Spot Instances.
When bidding for a Fixed Duration Spot Instance,
you additionally specify the required duration of
the Instance, which can be between one and six
hours. If Instances are available, they will be
provided at a flat rate for the requested duration.
Fixed Duration Spot Instances
The last use case requires a
sizeable dose of DevOps
know-how to implement
successfully, but can be very
cost-effective in large scale-out
deployments.
Cost Analysis
Commentary
These instances are useful for workloads with a known duration activity cycle of less than 6 hours, albeit at a
reduced saving compared to that of a standard Spot Instance. Of course, if you have workloads which fit the
bill and can be architected to make use of Spot Instances, savings of up to 50% on On-Demand prices make
this a cost effective way of delivering short-duration workloads.

No Upfront
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
Instance Reservations
All Upfront
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
Partial Upfront
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

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.
Key Gotchas to Consider

You are committing to pay for an Instance matching the
reservation criteria
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.
Key Gotchas to Consider

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.
To make matters worse...

In other words: 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.
Our team has a saying...
“information
without insight is
at best a blunt
instrument”

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.
Breakeven Points
Not
Reserved
(70-75%)
Reserved
TIME INSTANCE RUNS

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.

Of course there are further cost optimisation opportunities within EC2,
not to mention within Amazon as a whole.
This deck 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.
Conclusion

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 Deck?
Follow our Twitter, LinkedIn and Blog below

EC2 Cost Options: Understanding Reserved, On-Demand, and Spot Instance Pricing

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (19)

Semelhante a EC2 Cost Options: Understanding Reserved, On-Demand, and Spot Instance Pricing

Semelhante a EC2 Cost Options: Understanding Reserved, On-Demand, and Spot Instance Pricing (20)

Último

Último (20)

EC2 Cost Options: Understanding Reserved, On-Demand, and Spot Instance Pricing