Manually resending an AWS EC2 spot instance request after its termination, with data persistance

Question

In Amazon Web Services \ EC2, I have a spot instance request that was run and manually terminated (by me). Now, I would like to run the same instance again - without needing to go through the process of creating a new instance (I mean, the process where I choose the AMI, the instant type, configurations, security group, etc.). When using non-stop instances, this is easy, as I can manually terminate or start the instance as many time as I want (and my saved data is persisted between terminations). But with the spot instance, I don't see how this can be done, since after it was terminated, the spot requests page in the EC2 management console shows that the request is closed and I don't see how to resend the same request again.

I know that I can choose a spot request to be persistent, but I understand that this would automatically resend the request when it is terminated, whereas I would want to continue to have manual control over when the request is sent.

To summarize, I'd want to be able to have the following workflow:

1. Create a spot instance request.
2. Run the spot instance (when the spot price is smaller than my bidding price).
3. Have some data saved in the instance.
4. Terminate the instance (either manually or due to the bid price threshold).
5. Manually, at my chosen time, resend a request to run the same instance, such that when it is opened, I can still see the data from before.
6. Return to 2.

How can this be done?

Answer 1

The short answer is an emphatic yes. Absolutely.

Your instance "workflow" you described is really the instance life-cycle . That life-cycle is the normal life-cycle of any well behaved app server in the cloud, even if you are relying on spot instances for your computing. You control all aspects of the instance lifecycle: launch, provisioning, scaling,and termination.

Using a modified version of this CloudFormation template for a Jenkins server with automatic backup and recovery, I have a number of auto-scaling fleets that do exactly what you describe (NB I use on-demand instances. But the same strategy applies for spot instances. NB2 I say fleet below, but this can a fleet of 1 instance only)

Here is the quick overview (or the long answer):

1. Use CloudFormation (optional, but recommended) to define/launch an autoscaling group and launch configuration to launch your fleet of 1 (or more) instances. Spot instances are directly supported in auto scaling. See Launching Spot Instances in Your Auto Scaling Group

2. Use the auto scaling policy, and your spot bid parameters/duration, to control the time and cost that want to pay for your instances, for the computing power you need. For Jenkins, I autoscale to have 1 healthy instance in any of the AZs in my VPC. Auto-scaling policies are very flexible. For manual termination, suspend ASG Launch process. See Suspending and Resuming Auto Scaling Processes

3. On instance launch, use UserData scripting, to configure your software, install backup and restore scripts, configure your instance, and load any instance data from the last backup. Use a dedicated S3 bucket to backup instance data. In my case, I archive the entire Jenkins work-space and configuration data in a zipped tar file. You would want to backup as frequently as needed for your data set.

4. On any auto relaunch of a new instance, the instance is configured to check S3 data back bucket, and restore the latest one. It immediately comes in to service with all the data from last backup. As noted in step 3, you have manual backup and restore scripts, so you can login to the instance and do these operations as needed.

Using these techniques you can build an instance fleet of on-demand or spot instances, with integrated backup and auto recovery.

Answer 2

The short answer is that you cannot relaunch a spot instance once it is terminated. Terminated means that the instance, data, etc. is destroyed. Your description describes On-Demand instances (except for the price).