Skip to content
By using AWS re:Post, you agree to the AWS re:Post Terms of Use
AWS re:Postre:Post
About re:Post

Do persistent spot instances retain their EBS volumes and instance IDs unlike those tested with an FIS experiment?

0

Hi,

I am testing Spot instances right now. I need a persistent Spot instance that retains its EBS volumes and instance id along with an elastic-IP assigned to it (this one is optional). From reading the documentation, this seems incredibly do-able, however using the FIS experiments for interruptions in testing, none of these properties are being executed. I have set up multiple spot requests using the following general guidelines:

  • Stop on interruption
  • Persistent
  • Don't delete EBS on termination
  • Assigning proper IAM and key-pairs for permissions
  • Setting a minimum vCPU and RAM requirement without needing a specific instance type

Whenever I initiate an interruption for a running Spot instance through the AWS management console using the "Initiate Interruption" button on the Spot Requests page, I will get a successful interruption and the instance that was interrupted says that it's stopped and remains in my instance list, but a completely new instance is spun up in its place without the EBS from before.

According to this documentation [1] [2], this doesn't seem to be the expected behavior, but asking AmazonQ (which I am taking with a grain of salt) says that sometimes this just happens and you can't do anything about it.

Is this issue local to the FIS experiment or is this expected behavior in the production environment? Thanks!!!

Topics
Management & GovernanceComputeStorage
Tags
Amazon EC2AWS Management ConsoleAmazon Elastic Block StoreAWS Fault Injection ServiceAmazon EC2 Spot Instances
Language
English
asked a year ago210 views
2 Answers
0

The behavior you're experiencing with the Fault Injection Simulator (FIS) experiment does not accurately reflect the expected behavior of persistent Spot Instances in a production environment. In a real-world scenario, persistent Spot Instances should indeed retain their EBS volumes and instance IDs when stopped due to an interruption, unlike what you're observing in your FIS tests.

Persistent Spot Instances are designed to allow you to stop and start them similar to On-Demand instances. When a persistent Spot Instance is stopped due to an interruption:

  1. The instance should retain its instance ID.
  2. The attached EBS volumes should remain associated with the instance.
  3. The instance should remain in your instance list in a stopped state.

When capacity becomes available again and the Spot price is below your maximum price, the same instance should be started, maintaining its instance ID and attached EBS volumes.

The behavior you're seeing where a new instance is spun up without the previous EBS volume is not the expected behavior for persistent Spot Instances in a production environment. This discrepancy suggests that the FIS experiment may not be accurately simulating the real-world behavior of Spot Instance interruptions.

It's important to note that while you can modify some instance attributes while a Spot Instance is stopped, you cannot change the instance type. Also, while a Spot Instance is stopped, you are not charged for usage, but you are still charged for the storage of any attached EBS volumes.

Given the unexpected behavior you're experiencing with FIS, it would be advisable to test your setup in a real Spot environment (being mindful of potential costs) or to contact AWS support for clarification on why the FIS experiment is not accurately reflecting the expected behavior of persistent Spot Instances. This will help ensure that your production deployment behaves as expected when dealing with actual Spot Instance interruptions.
Sources
Manage your Spot Instances - Amazon Elastic Compute Cloud
Spot Instances - Amazon Elastic Compute Cloud

answered a year ago
EXPERT
reviewed a year ago
-1

Interruption behavior: The behavior that you choose determines what happens when a Spot Instance is interrupted.

  • For persistent requests, valid values are Stop and Hibernate. When an instance is stopped, charges for EBS volume storage apply.

Note Spot Instances now use the same hibernation functionality as On-Demand Instances. To enable hibernation, you can either choose Hibernate here, or you can choose Enable from the Stop - Hibernate behavior field, which appears lower down in the launch instance wizard. For the hibernation prerequisites, see Prerequisites for Amazon EC2 instance hibernation.

  • For one-time requests, only Terminate is valid.

If you do not specify a value, the default is Terminate, which is not valid for a persistent Spot Instance request. If you keep the default and try to launch a persistent Spot Instance request, you'll get an error.

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-requests.html

EXPERT
answered a year ago
  • steve-do
    a year ago

    I am already aware of the above, this doesn't answer my question. What I'm still after is why my persistent "stop" interruptions from the FIS are being spun up as new instances without the EBS volume attached from before. Is this expected or not when using the experiment built into the fleet request page?

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Relevant content