When using AWS Spot Instances, you have the option to choose between two types of request behaviors:
- One-Time Spot Instance Requests
- Persistent Spot Instance Requests
These two types of requests determine how AWS manages your Spot Instance lifecycle and how they handle interruptions. Let’s look at the differences:
1. One-Time Spot Instance Requests:
Description:
- A One-Time Spot Instance Request is a single, one-off request for a Spot Instance. AWS will fulfill the request for as long as there is available capacity at your bid price.
- Once the Spot Instance is terminated (either by AWS due to capacity needs or by the user), the instance is no longer requested and won’t automatically be replaced.
Key Features:
- Single Request: It’s a one-time request for the Spot Instance.
- Lifecycle: The instance runs until it is either interrupted by AWS (due to price increase or capacity demand) or manually stopped/terminated by the user.
- No Automatic Replacement: When AWS interrupts or terminates the instance, it does not automatically launch a new instance.
Use Cases:
- Short-term workloads: If you need Spot Instances for a short, one-off task or burst of computing power that does not need to be maintained over time.
- Non-critical jobs: For tasks where you can tolerate interruptions without needing an automatic restart (e.g., batch jobs or data processing).
2. Persistent Spot Instance Requests:
Description:
- A Persistent Spot Instance Request automatically attempts to replace the Spot Instance if it’s interrupted or terminated by AWS (due to capacity loss or price increases).
- The request persists until you cancel it, meaning if the instance is terminated, AWS will automatically launch a new one, continuing the request for as long as you need.
Key Features:
- Automatic Replacement: If your Spot Instance is interrupted or terminated, AWS will automatically try to launch a new instance to fulfill your request.
- Lifecycle: The request will continue until you manually cancel it or terminate it. Even after interruptions, AWS will keep attempting to fulfill your Spot request.
- Use with Auto Scaling Groups: Persistent Spot Instances are ideal if you need to maintain a stable number of instances over time and you want to handle interruptions without losing the capacity.
Use Cases:
- Longer-term workloads: When you need a Spot Instance to run indefinitely and want AWS to automatically replace any terminated instances.
- High-availability or fault-tolerant applications: When the job needs to continue without manual intervention, even if AWS terminates the instance.
- Auto Scaling: Integrating with Auto Scaling Groups to replace instances automatically, allowing Spot Instances to be used for larger, dynamic workloads.
Comparison: One-Time vs. Persistent Spot Instance Requests
| Feature | One-Time Spot Instance Request | Persistent Spot Instance Request |
|---|---|---|
| Request Type | One-off request | Continuous request (persistent) |
| Automatic Replacement | No | Yes (AWS attempts to replace instances) |
| Ideal Use Case | Short-term, non-critical tasks | Long-term, fault-tolerant workloads |
| Lifecycle | Ends when instance is interrupted or terminated | Continues until manually canceled |
| Cost Control | Limited to a one-time instance | Continuous cost based on usage |
How to Choose Between One-Time and Persistent Requests:
- One-Time: Choose this if you want to run a Spot Instance for a short, specific task and are okay with the instance potentially being terminated without automatic replacement.
- Example: A data processing job that runs for a few hours or a one-off batch process.
- Persistent: Choose this if you need reliable, ongoing capacity for your workload, and you want to automatically replace Spot Instances if they are interrupted by AWS.
- Example: A web server farm or a large data processing job that needs to continue running with minimal interruption.
Spot Instance Interruptions:
Regardless of the request type, Spot Instances can be interrupted by AWS when there is a lack of capacity or if your bid price falls below the market price. If you are using Persistent Spot Instance Requests, AWS will automatically try to replace the instance. However, if you’re using a One-Time Spot Request, the instance will be terminated and won’t be restarted.
AWS will notify you of the interruption via a 2-minute warning before the instance is terminated, which is useful for managing graceful shutdowns or migrations.
If your Spot Instance is interrupted but not terminated, the behavior will depend on the type of Spot Instance request you’ve made, specifically whether you chose a persistent or one-time request. Let’s break it down:
1. Spot Instance Interruption vs. Termination:
- Interruption means that AWS preempts your Spot Instance to reclaim capacity for other customers or due to price increases, but your instance isn’t immediately terminated. Instead, AWS sends a 2-minute warning and may stop or hibernate the instance, depending on your configuration.
- Termination means AWS completely shuts down the instance, either because you’ve requested it, the capacity is no longer available, or the instance is no longer needed.
2. Impact of Interruption (Not Termination):
When you choose a Persistent Spot Instance Request, and the instance is interrupted but not terminated, the instance will not immediately be replaced unless it’s actually terminated. Here’s the behavior:
Persistent Spot Instance Request:
- Interruption: If the Spot Instance is interrupted (e.g., due to capacity or price increase) but not terminated, the instance will either:
- Stop (if you’ve set the instance to hibernate or stop on interruption).
- Transition to stopped state (if you’ve configured the instance for hibernate), allowing it to be resumed.
- Automatic Replacement: If you have a persistent request, AWS will automatically attempt to launch a new instance to replace the interrupted instance when it is terminated (if the instance was stopped or hibernated, it doesn’t count as terminated, so no new instance is launched until it’s fully terminated).
- Instance Still Running: If AWS interrupts the instance but it’s still running, you’ll continue to be billed for the running instance as long as it’s active.
One-Time Spot Instance Request:
- If you have a one-time request and the Spot Instance is interrupted, the request is automatically canceled once the interruption occurs.
- Since the instance wasn’t terminated, you might still be able to restart the instance if the capacity becomes available again, but a new request needs to be made if you want to launch another Spot Instance.
Key Points on Interruption Without Termination:
- Persistent Spot Requests will not automatically launch a new instance unless the instance is terminated. Interruption doesn’t trigger a new instance launch.
- If your Spot Instance is interrupted and stopped or hibernated, AWS will not replace it automatically unless you’ve configured Auto Scaling Groups to handle it. It simply remains in the stopped or hibernated state.
- Termination is the key trigger for persistent Spot request replacements. So, interruption without termination means AWS will not replace your instance immediately.
What Happens When AWS Interrupts But Does Not Terminate?
- Instance Status:
- Stopped or Hibernate: If your instance is set to stop or hibernate, it will stay in the stopped state until manually resumed or restarted.
- Running: If it’s not affected by the interruption (e.g., low interruption priority), it will continue running without immediate action.
- Spot Request:
- If the instance is not terminated, the persistent request will still be open.
- No new instance is launched unless the instance is terminated. AWS will only attempt to replace a Spot instance if it’s fully terminated.
Example Scenario:
- You’ve made a Persistent Spot Instance Request for an m5.large instance in us-west-2a.
- AWS interrupts your Spot instance because it needs the capacity for other uses, but the instance is not terminated—it gets stopped or hibernated (depending on your configuration).
- Impact: Since the instance is stopped, AWS does not automatically replace the instance. The Spot Request remains open, but the system does not launch a new instance until the existing one is fully terminated.
How to Handle Spot Instance Interruptions:
If you need better control over interruptions and automatic recovery, here are a few strategies:
- Use Auto Scaling Groups:
- Auto Scaling can help automatically launch replacement instances when Spot instances are interrupted or terminated.
- You can set up Auto Scaling to mix On-Demand and Spot Instances in the same group for more reliability.
- Set Up a Fault-Tolerant Architecture:
- Use multiple Availability Zones (AZs) to distribute your workload across several zones. This helps in case Spot Instances are interrupted in one AZ.
- Use Amazon EC2 Instance Fleets to diversify your instance types and Spot Instances.
- Configure Instance Stop/Start:
- For critical workloads, consider setting the instance to hibernate instead of stop. This allows the instance to resume from the exact state it was in when the interruption happened.
Summary of Key Points:
- Persistent Spot Request will not automatically launch a replacement if your instance is interrupted but not terminated.
- If your Spot instance is stopped or hibernated, AWS will not launch another instance automatically until the original instance is terminated.
- One-Time Spot Requests are canceled once the instance is interrupted, but you can request another instance after the interruption.
- Consider using Auto Scaling Groups or instance fleets for automatic recovery when using Spot Instances.
