How Spot Instances Can Ridiculously Lower Compute Costs

Companies spending copious amounts on elastic cloud compute, fargate, and lambda use savings plans and reserved instances, but many aren’t too familiar with spot instances.

What is a Spot Instance?

A Spot Instance is an instance that uses spare AWS EC2 capacity that is available for ridiculously cheaper prices than the On-Demand price. 

Since Spot Instances allow you to request unused EC2 instances at ridiculously lower prices than normal EC2 costs significantly, sometimes up to 90% off.

But as with most things, there is a catch: you’re given just two minutes as an interruption notice when AWS needs to reclaim that capacity. Therefore, you need your application to be able to run again in under two minutes so there is no downtime. Let’s dive into what Spot Instances are, how they work, and whether they’re right for your workload.

If the above definition wasn’t clear, here’s one more example: Spot Instances let you bid on unused EC2 capacity in AWS’s vast infrastructure. Think of it like snagging a last-minute deal on a flight: the plane’s already scheduled, but there are empty seats AWS wants to fill. Instead of letting that compute power sit idle, AWS offers it at a steep discount.

The spot price fluctuates based on supply and demand in a given region or availability zone, and you can set a maximum bid you’re willing to pay per hour. If your bid exceeds the current Spot price, you get the instance until demand shifts, and AWS gives a two minute warning.

Two-Minute Interruption Notice

Here’s where the trade-off kicks in. Unlike On-Demand or Reserved Instances, Spot Instances aren’t guaranteed to stick around. When AWS needs that capacity back—say, for higher-paying customers, you’ll receive a two-minute interruption notice. This warning, delivered via instance metadata, gives you 120 seconds to wrap things up before the instance is terminated. That could mean saving your progress or shifting workloads. As I’ve heard many times over, and I agree: it is a small window, but with the right setup, it’s manageable.

The interruption notices are made available as a EventBridge event and as items in the instance metadata on the Spot Instance. AWS recommends you check every 5 seconds for any interruption notices.

It’s important to also note that service interruptions are very uncommon. AWS says that it only terminates Spot Instances less than 5% of the time.

When an interruption occurs with an AWS Spot Instance, what happens depends on the interruption behavior you specified when you created the Spot Instance request.The outcome is determined by one of three possible actions:

1. Terminate (default):

What Happens: When a Spot Instance is interrupted with the "Terminate" behavior, AWS terminates the instance completely. The instance is shut down, and all its resources are released. After termination, the instance cannot be restarted unless you request a new Spot Instance. You receive a two-minute warning via instance metadata before the termination occurs.

Implications: This is the default behavior and is best suited for stateless, fault-tolerant workloads (e.g., batch processing or CI/CD pipelines) where losing an instance doesn’t significantly impact the application. However, any data stored on the instance’s ephemeral disks is lost unless backed up elsewhere (e.g., Amazon S3 or EBS snapshots). You’ll need to re-request a Spot Instance or switch to an alternative (like an On-Demand Instance) to resume the workload.

Use Case: Ideal for disposable, short-lived tasks where cost savings outweigh the need for persistence.

2. Stop:

What Happens: With the "Stop" behavior, AWS stops the Spot Instance instead of terminating it, similar to stopping an On-Demand Instance. The instance remains in a stopped state, preserving its root volume (if it’s an EBS-backed instance) and instance store data (if applicable). You can restart the instance later if capacity becomes available again, though there’s no guarantee the same instance will restart as a Spot Instance, it depends on Spot market conditions.

Implications: This option is useful for workloads that can tolerate interruptions but need to resume from where they left off. The EBS volume persists, so data isn’t lost, but you’ll need a mechanism (e.g., a script or AWS Lambda) to detect the stop and restart the instance when feasible. Note that stopped Spot Instances still incur EBS storage costs.

Use Case: Suitable for applications like web servers or data processing jobs that benefit from resuming with saved state.

3. Hibernate:

What Happens: When set to "Hibernate," AWS hibernates the Spot Instance upon interruption. Hibernation saves the instance’s in-memory state (RAM) to the root EBS volume and stops the instance. When restarted (if capacity allows), the instance resumes from its exact pre-interruption state, including running processes and memory contents. Like the "Stop" option, you get a two-minute warning to prepare.

Implications: This is the most seamless option for stateful applications, as it preserves both disk and memory state, minimizing downtime. However, hibernation is only supported for specific instance types and operating systems (e.g., Amazon Linux 2, Ubuntu with certain configurations) and requires an EBS-backed instance with hibernation enabled at launch. Restarting depends on Spot capacity availability.

Use Case: Best for long-running, state-dependent workloads like machine learning training or database nodes where preserving memory state is critical.

If your Spot request is persistent or part of an Auto Scaling group, AWS will try to launch a replacement instance when capacity becomes available again. This makes termination ideal for stateless, fault-tolerant workloads like batch processing, but it’s less suitable for tasks requiring continuity.

How Auto Scaling Works with Spot and On-Demand Instances

When you create an Auto Scaling group, you define…

• A launch template or launch configuration (specifying AMI, instance type, user data, etc.)

• A desired capacity (the number of instances you want running)

• Policies for instance types and purchasing options (Spot, On-Demand, or a mix)

With Spot Instances, if one gets interrupted (e.g., terminated due to capacity or price changes), the Auto Scaling group notices the reduction in capacity and attempts to launch a replacement instance to meet the desired capacity. By configuring a mixed instances policy, you can ensure that an On-Demand Instance is launched if Spot capacity isn’t available.

Here's how you can set up an Auto Scaling Group to Launch an On-Demand Instance:

1. Create a Launch Template

   1. Go to the EC2 console, select "Launch Templates," and click "Create launch template."

   2. Specify your AMI (e.g., Amazon Linux 2), instance types (e.g., t3.medium), key pair, security groups, and any user data scripts to configure your application.

   3. Enable Spot Instance support by leaving the purchasing option flexible (you’ll specify this in the Auto Scaling group).

2. Create an Auto Scaling Group

   1. In the EC2 console, navigate to "Auto Scaling Groups" and click "Create Auto Scaling group."

   2. Choose your launch template and proceed.

3. Configure Instance Types and Purchasing Options

   1. Select "Adhere to launch template" or override it to specify multiple instance types (e.g., t3.medium, t2.medium) for flexibility.

   2. Under "Instance type requirements," enable the "Mixed instances policy."

   3. Set the On-Demand base capacity (e.g., 1 instance) to ensure a minimum number of On-Demand Instances are always running.

   4. Allocate a percentage of the remaining capacity to Spot Instances (e.g., 50% On-Demand, 50% Spot). If Spot Instances are interrupted and unavailable, the group will fall back to On-Demand Instances to meet the desired capacity.

4. Set Desired, Minimum, and Maximum Capacity

   1. Desired capacity: The number of instances you want (e.g., 2).

   2. Minimum capacity: The fewest instances allowed (e.g., 1).

   3. Maximum capacity: The most instances allowed (e.g., 5).

   4. If a Spot Instance is terminated, the group adjusts by launching an On-Demand Instance if Spot capacity is insufficient.

5. Configure Scaling Policies (Optional)

   1. Add a scaling policy (e.g., target tracking based on CPU utilization) to dynamically adjust capacity. This ensures your application scales with demand, using On-Demand Instances as needed when Spot Instances aren’t viable.

6. Review and Launch

   1. Specify your VPC, subnets, and any load balancers, then create the group. The Auto Scaling group will launch instances according to your settings, starting with the On-Demand base capacity and filling the rest with Spot Instances if available.

Auto Scaling automates the process, making it ideal for production workloads. It eliminates manual intervention, ensures availability, and optimizes costs by favoring Spot Instances when possible while falling back to On-Demand Instances seamlessly. For example, if you’re running a web app and a Spot Instance terminates, Auto Scaling can replace it with an On-Demand Instance in minutes, keeping your service online.

Yaddle out.