Amazon EC2 – Making Sense of the Cost Options (Part 1)
AWS is recognised as a market leader in delivering cost effective, scalable compute resource via its Elastic Compute Cloud (EC2) service. With options from single core, sub 1GB RAM Instances through to 36 core, 244GB behemoths, and intelligent autoscaling capabilities to dynamically manage Instance numbers to suit load varying load requirements, there are affordable, appropriately sized options for practically any workload.
We are now a long way past the early days of EC2 where its main value proposition was the provision of temporary compute resource for rapid prototyping and development of workloads. These days enterprises large and small are harnessing the capabilities of EC2 and associated services to 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’.
To deliver optimal solutions within AWS takes a different set of skills to traditional on-premises or hosting services. 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.
An important element of delivering cost-optimal solutions within EC2 is understanding the cost options available for the launching and running of EC2 Instances, and selecting the most appropriate options for your architecture. Let’s briefly run through the available options, and some of the key use cases for each.
Dedicated Instances and Dedicated Host Instances
Starting with the more expensive end of the scale, AWS provides a number of capabilities. You can pay hourly, you can reserve for the use of one or more Instances on hardware dedicated to single customers, or you can 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).
These offerings provide options for customers who have very rigorous compliance requirements (or perhaps auditors who have very rigorous interpretations of compliance requirements). Additionally, dedicated hosts can 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.
As such, these options have a very specific niche. However, considering that even rigorous financial regulatory frameworks such as PCI can be satisfied with non-dedicated Instances under the Amazon shared responsibility security model, dedicated Instances and hosts will typically not be central to the majority of cost optimisation strategies.
On-Demand Instances are the default option when launching an Instance and are the workhorse of the EC2 world. When launching an Instance On-Demand, you 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. This means that 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. Note however that you will continue to pay the storage costs of any attached Elastic Block Storage (EBS) Instances.
Whilst running Instances On-Demand may at first glance be the most expensive of the standard Instance options, it does have a number of benefits over the alternatives for specific use cases.
Due to the nature of Instance reservations, 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.
As a result of the above, 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.
Spot Instances are an interesting option for certain use cases, as the cost of running Spot Instances can, in some cases, be an order of magnitude below that of the equivalent On Demand Instance.
To take advantage of these potential savings there are of course trade-offs. The Spot Instance market is designed to apportion 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. 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. The first of which is that the price paid for a Spot Instance is unpredictable and fluctuates over time, although it will never exceed the Customer’s bid for the Instances because, at the point this would happen, the Instance would be terminated. Of course, this means that 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.
The second, and potentially more troublesome effect is that 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.
However, 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 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.
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. This makes them 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.
Part 2, Reservations of Instances, click here.