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:
- Use within AWS Autoscaling Groups only, this will allow instance termination to be handled by the autoscaling service without your intervention.
- Use more than one instance type per AWS Autoscaling Group with similar resources (vCPU/vRam), Spot instances availability is different per region and you don’t want to find yourself with zero instances on your workload.
- Design the applications to be stateless, with no data logs etc since they can be replaced at any time, instead, these will be running on on-demand workloads.
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.