EC2 Spot instances: How to start tasks, how to stop them? - amazon-web-services

I have a long batch job that I'd like to run on AWS EC2 Spot Instances, to save money. However, I can't find the answer to two seemingly critical questions:
When a new instance is created, I need to upload the code onto it, configure it, and run the code. How does that get done for Spot Instances, which are created automatically and unattatendly?
When an instance is stopped, I would prefer having some type of notification, so that the state could be saved. (This is not critical, as the batch job will run fine if terminated suddenly - but a clean shutdown is preferred).
What is the standard way to deploy spot instances? Is there a way to do manual setup, turn it into a spot instance, and then let it hibernate until the spot price is available?

As to #1, if you create an AMI (amazon machine image), you can have everything you want pre-installed on a 'hibernating' image that you can use as a basis for the spot image you start:
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances-getting-started.html
For #2, you can be notified when a spot instance terminates using SNS:
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-autoscaling-notifications.html
http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/ASGettingNotifications.html
BTW: You can be notified the the instance was terminated, but only after it terminates. You can't get notified that an instance is about to be shutdown and gracefully save the state - you need to engineer your solution to be OK with unexpected shutdowns.
No matter how high you bid, there is always a risk that your Spot
Instance will be interrupted. We strongly recommend against bidding
above the On-Demand price or using Spot for applications that cannot
tolerate interruptions.
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-protect-interruptions.html

You can use the user data settings to download from a specific repository a script and run it at the first instance startup.
As E.J. Brennan said: you can use SNS

Related

Preventing an auto-terminated spot instances from restarting

Imagine I have a persistent spot request of size 1. If I manually stop this instance, it will not restart until I start it again.
However, if the instance is interrupted by AWS because of a lack of spot capacity, it will restart automatically when capacity is available (as I understand it).
How can I put an instance in the stopped-because-interrupted state into a state where it will not restart automatically if capacity becomes available.
According to AWS documentation only EC2 can start interrupted spot instances so I think that the only option would be monitoring events/alerts which notify when instances restart and then stop them again with automation. Never tried this si this is only an educated guess/opinion.

How to use existing On-Demand instance in spot fleet?

I'm trying to reduce my expenses and want to start using AWS's spot pricing service. I'm completely new to it, but as I understand I can have instances running for certain amounts of time based on the price that will eventually stop running based on certain conditions. That's fine, I'm also aware you can have spot fleets, and in these fleets you can have an On-Demand instance for when the spot instance is interrupted.
I currently have a an On-Demand instance that hosts an ElasticBeanStalk application (it's an API), is there a way to use this instance inside the spot fleet so that when there's an available spot-instance it's servicing my EBS application then when the spot-instance is interrupted it just goes back to using my current On-Demand instance until another spot-instance is available?
Sadly, spot fleets don't work like this. If your spot instance gets terminated, no on-demand replacement is going to be created for you automatically. If it worked like this, everyone would be using spot instances in my view.
The on-demand portion of your spot fleet is separate from spot portion. This way your application will always run at minimum capacity (without spot). When spot is available, your spot instances will run along side your on-demand. This way you will have more computational power for cheap, which is very beneficial for any heavy processing application (e.g. batch image processing).
Details of how spot fleet and spot instances work are in How Spot Fleet works and How Spot Instances work docs.
Nevertheless, if you would like to have such replacement provisioned you would have to develop a custom solution for that.
There's a third-party solution called Spot.io that not only replaces the spot instance for an on-demand instance in a scenario like the one you describe but it has an algorithm that anticipates the interruption event and stands up an On-demand instance and has it ready before the interruption occurs.

how to test stop start of AWS Spot Instances

I am creating AWS spot instances on demand and wanted to keep interruption behavior as STOP, so that AWS can restart my VM as soon as price/demand meets.
But the problem is AWS GUI doesn't have any option to STOP running spot instances.
It just have option to terminate instances or cancel spot requests.
I am developing some application which will resume itself on reboot.
I wanted to test the application by simulating AWS stop and restart behaviour.
Thx in advance
~Ashish
As of now you cannot Stop a Spot Instance.
To simulate your application behavior, bid for minimum and wait for AWS to interrupt the instance.
Make sure that your spot instance is Stop Interruption ready.
Reference:
Spot Instance Interruptions
You do not have an option to restart a SPOT instance. SPOT instance is not the right candidate for this kind of application.

Auto Delete Stack on Instance Termination

I am currently working with EC2 instances and have made a Java CLI tool to quickly launch/kill instances for our developers. One of the options is to set a lease time, so that the instance terminates after a certain amount of hours. For spot instances this works great, terminates the instance, the request, and deletes all volumes associated with that instance.
However, for on demand instances, the lease time only affects instance termination and does not delete the stack that it was on.
Is there some way to automate this through AWS? I don't want to write a script to manually check or even monitor, it would be great if this could be automated through AWS itself. I have looked and have not found anything. Any advice is appreciated!

Ec2 1/2 checks passed

Since today i can't access my instance, i tried stop and restart several times but the status is always : "1/2 checks passed"
I tried to create a snapshot, detach and reattach new volume but the result is the same.
I also tried to create another instance and attach the volume and it's not starting either.
Any help ?
The status checks automatically performed on Amazon EC2 instances are:
System Status Checks: These check the underlying systems used by the Amazon EC2 instance
Instance Status Checks: These check the configuration of the specific instance
See documentation: Status Checks for Your Instances
Often, an instance is available and ready to be used before these checks are complete -- this is especially the case for Linux instances because they boot very quickly.
If you receive a 1/2 checks passed message, either wait a little longer or Stop and Start the instance. Performing a Stop/Start will launch the instance on a different host, which will probably fix whatever problem was being experienced.
If the 1/2 checks passed message continues to appear after a Stop/Start, it is probably a misconfiguration of the AMI. I have seen this when the wrong virtualization type was selected for an AMI that was created from a Snapshot.
You might be able to get a hint about the problem by using the Get System Log command in the Actions menu, which shows the log while the instance is booting.
Worst case, launch a new instance from a known-good AMI, attach the non-booting volume as an additional disk and copy files to the new disk. You will still have access to your files even if it will not boot.
You can check the description of the checks here, and understand which one is not working...