One of the underrated and under-utilised cost-saving options in the EC2 Compute class is the Spot Instances. On-Demand instances are the most expensive EC2 instance type on the AWS platform and while they are ideal for most environments you can benefit from more cost-effective options.
Spot instances aren’t a specific type of instance class; they are computing capacity that is not in use and available for a shorter period of time, and therefore cheaper because AWS can claim them at any time. The financial model for AWS is, it is better to sell unused capacity at a low profit for a short period of time, and claim it when purchased at a normal price over absorbing the cost of unused capacity in their data centres.
Ec2 Spot instances can provide you with up to 90% Savings, for example comparing the pricing data available from AWS here, we can see that a spot price for a C5.xlarge (one of the most commonly used instance types for computing workload) is 0.0388$ per hour compared to the on-demand pricing (0.17$ per hour). That’s an astounding 125% saving reduction, you can potentially run multiple spot instances for the price of one on-demand instance.
What’s the catch? Spot instances are provisioned by bid price rather than a fixed price per hour, if the current bid price exceeds the one offered, the instances provisioned get terminated and assigned to another AWS customer or allocated to on-demand requests.
AWS Provides a two-minute warning when an instance is about to be reclaimed, Spot Instance reclaim notice is now available in Cloudwatch events along with the previously available EC2 Metadata service, this change allows you to set reactive or responsive alerts on warnings and take preemptive procedures to either hibernate your instances or work on a graceful shutdown and replacement.
Spot instance workloads:
Since spot instances are subject to termination, any applications or workloads that are running on spot instances need to be fault tolerant and designed to recover from a sudden termination. Therefore any database hosting is out of the question.
By and large, the ideal workload-consuming Spot instances will follow these principles:
Luckily with the rise of Container orchestration and serverless deployments, most containerized workloads are a perfect candidate for spot instances. As per AWS Documentation, Spot instances are ideal for Big Data, CI/CD runners, Instances leveraged with batch processing, and Development and Testing workloads.
Most Development and Testing environments mimic production environments, but by and large, the uptime requirements are more relaxed, and even if an instance were to go down an engineer can run a new spot instance or bring up an on-demand instance for the time being. Since the repercussions of downtime are so low in these types of environments EC2 Spot instances become a perfect choice for dev/staging to leverage 90% savings.
Getting Started with Spot Instances:
So how do you get started with spot instances? You should manoeuvre to the EC2 console to request a spot instance and select spot requests.
AWS has done a lot of innovation with Spot instances, providing value and reusability to clients and architects. The Spot instance title screen will show you a couple of options you can use with your decisions.
Spot blueprints provide infrastructure as code templates in cloud formation and terraform that fit some of the most common uses for spot instances. You can also configure blueprints for further use.
Spot placement score allows you to put in your requirements and provides a scale from 1–10 on how likely AWS will fulfil the spot instance request.
To begin requesting a spot instance, click the Request Spot instance.
Some basic options are which AMI to choose and what role to provide to the spot instance. AWS offers multiple opportunities for handling interruptions to the provisioned spot instance capacity.
You can select how the spot instances that are marked for interruption behave. You select Maintain Target Capacity and choose one of the three options. Terminate, which removes the instance, Stop, which will stop the instance and wait till the capacity Hibernate, which saves the cache and operations of the instance in memory. Hibernate allows a user to have the ability to resume operations when the capacity returns and the instance is turned back on.
There are also two launch options.
Launch only — This launches a new instance when AWS sends the notification for termination. However, since termination is subject to a price change, AWS can interrupt the instance or not; however, in the latter case, you will be charged for both instances. This scenario is ideal if you require High Availability.
Launch before termination — AWS provisions a new instance immediately when the termination notification is sent. After the new instance is brought up, the previous one is terminated regardless of whether AWS would interrupt it or not.
Based on a configuration of 2 instances running on Spot with c5.large and c5.xlarge instance types, the cost of the above design comes to around $0.077, which is an astounding 71% savings.
Running a development environment on-demand for a month for the configuration mentioned above would cost an organisation around $186. Whereas for spot instances, that exact cost would be only $56!
AWS Spot instances are an underrated computing option that has traditionally had a bad reputation based on fault tolerance requirements. However, with the rise of fault-tolerant systems and the need for cheap, repeatable compute requirements for Big Data, Batch processing, and CI/CD processing, Spot instances can provide the right cost savings without the need for any architectural changes. With 70 per cent savings on average, Spot instance can help you cut your AWS cost allowing you the financial freedom to grow in the cloud.
AWS DevOps Consultancy, Boldlink@boldlink