Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've been playing with EC2 spot instances, with the ultimate aim of migrating a standard instance hosting a website to a spot instance (yes, I'm well aware this really isn't what spot instances are for, but in this case I'm quite prepared to trade price for availability).

However, I was a little surprised to discover that when the price threshold is crossed, the spot instance is terminated, not stopped, and indeed that it's simply not possible to stop a spot instance, only to terminate it.

So: is there some (recommended) way of getting the instances spawned by spot instance requests to simply associate themselves with a particular EBS volume on creation, so that the full machine state can simply be rolled forward across a series of spot instances ? Or am I fundamentally misunderstanding what spot instances are all about ?

share|improve this question
up vote 5 down vote accepted

Firstly, allow me to clarify a few points. As you pointed out, spot instances are not meant to be run 24/7 - they are intended to provide extra compute capacity for a short time-span at a lower cost. Essentially, they are intended for tasks that can be broken into small pieces - so a terminated instance will not have a significant impact on the overall task.

That said, I have previously run an instance using the spot request model - its usual uptime was about 3 months - and I would typically overbid by about 15x the average market price. While this used to be a reasonably cost effective approach, I found that as more people employed the same technique, the price volatility increased to the point that it was no longer advantageous over a reserved instance.

The average spot price tends to hover around the hourly cost of a medium utilization reserved instance. Doing the math based on the current spot prices vs heavy utilization instances, you get the following:

|             |           1 year            |            3 year            |   Spot   |
| Small       | $0.016/h + $195 = $0.0383/h | $0.013/h +$300 = $0.0244/h   | $0.027/h |
| Medium      | $0.032/h + $390 = $0.0765/h | $0.026/h+$600 = $0.0488/h    | $0.038/h |
| Large       | $0.064/h + $780 = $0.153/h  | $0.052/h + $1200 = $0.0977/h | $0.108/h |
| Extra Large | $0.128/h + $1560 = $0.306/h | $0.104/h + $2400 = $0.195/h  | $0.216/h |

It is evident that in many cases, the 3 year heavy utilization reserved instance works out to less than the current spot price (which is subject to volatility). From my experience, the actual average spot price tends to be at least 50% higher than the baseline market value, since significant spikes are not uncommon.

Now, to actually try and answer your question:

You are correct that spot instances cannot be stopped - in some ways that does agree with the entire premise behind spot instances. Traditionally, an instance will create the EBS volume(s) it is using from snapshots, but it is possible to script the process of attaching an EBS volume. I used to use this script to setup 2 EBS volumes in a RAID0 (I am pretty sure I modified it from some script I found, but I can't find the original at the moment):

#! /bin/sh 
# /etc/init.d/mountec2vol 
# chkconfig: 234 20 50 
# description: Assigns an EC2 EBS Volume to a device and mounts the device 
# To add this as a service run: 
# /sbin/chkconfig --add mountec2vol 

export PS1="[\T] [\W]# "
export JAVA_HOME=/usr/java/jre1.6.0_16
export EC2_HOME=/etc/ec2/apitools
export PATH=$PATH:$EC2_HOME/bin


# start/stop functions for OS 

start() { 
touch /var/lock/subsys/mountec2vol
INSTANCE=`curl 2> /dev/null` 
/bin/echo "Mounting Elastic Block Store Volumes." 
ec2-attach-volume $VOL1 -i $INSTANCE -d $DEV1 
while [ ! -e "$DEV1" ]; do 
/bin/sleep 1 
CTR=`expr $CTR + 1` 
if [ $CTR -eq $MAX_TRIES ] 
/bin/echo "WARNING: Cannot attach volume $VOL1 to $DEV1 -- Giving up after $MAX_TRIES attempts" 
exit 1 
ec2-attach-volume $VOL2 -i $INSTANCE -d $DEV2
while [ ! -e "$DEV2" ]; do 
/bin/sleep 1 
CTR=`expr $CTR + 1` 
if [ $CTR -eq $MAX_TRIES ] 
/bin/echo "WARNING: Cannot attach volume $VOL2 to $DEV2 -- Giving up after $MAX_TRIES attempts" 
exit 1 
depmod -a
modprobe raid0
mdadm --assemble --verbose /dev/md0 /dev/sdh1 /dev/sdh2
if [ ! -d $MOUNT_POINT ]; then 
/bin/mount /dev/md0 $MOUNT_POINT 

stop() { 
/bin/echo "Unmounting Elastic Block Store Volumes." 
rm -f /var/lock/subsys/mountec2vol 
/bin/umount $MOUNT_POINT
mdadm -S /dev/md0
ec2-detach-volume $VOL1
ec2-detach-volume $VOL2

case "$1" in 


sleep 5 
echo "Usage: $0 {start|stop|restart}" 
exit 1 


exit 0 

This was for CentOS, but I imagine it would be easy enough to adapt to most other Linuxes. Change the Java version and remove the RAID attributes (and change the mount point) and you will be good to go. This would then be setup as an init script to run when the instance starts. An alternate way of accomplishing this would be to pass the EBS volume IDs as instance user-data, which would allow for a lot more flexibility.

It should be noted that this, of course, will not work for the root EBS volume - this setup presumes a mostly fixed root volume, with data kept on a separate mount-point. You can always set the EBS root volume from ec2-request-spot-instances using the --block-device-mapping parameter.

share|improve this answer
Thanks, that's fantastic information. The plan to use spot instances originated with someone's experience of them 2-3 years ago (long uptimes at minimal pricing); seems it was too good to last. I hadn't considered reserved instances at all - in fact I'd somehow confused them with "dedicated instances" - but actually the three year pricing is really good (and competitive with the sort of VPS pricing you find on , which was my "Plan B"). – timday Mar 13 '12 at 22:46
@timday: Reserved instances are great, but one word of caution. Once you buy one you are locked in. For instance, AWS introduced Heavy Utilization instances a few months ago - anyone who purchased a reserved instance even a day earlier could not pay the difference and upgrade. Also, there are quite a few reports of new, lower pricing not being applied to existing customers - for instance, they just dropped the prices a week ago - but the new hourly prices might not apply to existing reserved instances - not quite sure if that is true or not, but something to keep in mind. – cyberx86 Mar 13 '12 at 22:54
Final point of mention - with light and medium utilization instances, you are billed the upfront fee whether or not you use it, and the hourly fee for each hour of use. With heavy utilization instances, you are billed the upfront fee AND the hourly fee regardless of whether or not you use the instance (so, even if the instance isn't running, you will be billed the hourly fee with Heavy Utilization instances). – cyberx86 Mar 13 '12 at 22:55
Yes I noticed the pricing difference on the "heavy"; expecting it to be up 24/7 anyway. We're quite comfortable locking ourselves in to something for 3 years if the price is right. – timday Mar 13 '12 at 23:37

What you're looking for can be accomplished through use of their API, I don't think it's possible to use Amazon-supplied automation to do it. You have to write it yourself. It is entirely possible to write a script to create a new spot instance, and associate a specific EBS volume to it.

What you won't be able to do is migrate the full machine-state, you'll still incur outages to spin up new spot instances.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.