Attach existing EBS as root device in spot instance request

Question

Is it possible to include an existing, unattached, available EBS volume as the root device in a spot instance request? I'd like to create a setup where the system is up and running when the spot price is met, and after a termination and the spot price comes back into range I can re-request and start an instance right where I left off.

thanks!

Ichthyoid

Not sure if you were able to get the answer for this, if not let us know. As far as I know you should be able to do it if the EBS is on the same zone as of the instance. – Practicable

@RakeshS - I'm not aware of such an option, see my respective answer for details; so please let us know, if you have a solution or workaround to address Mark's request. – Provincial

Answer 1

While Overriding the AMI's Block Device Mapping as such is possible, the root device is the exception, unfortunately:

Any instance you launch automatically includes any storage devices in the AMI's block device mapping. You can override that mapping by specifying a block device mapping with the changes that you want at launch time. In your overrides, you can modify the mapping for any of the storage devices except the root device volume. [emphasis mine]

This is also reflected in the respective wizards within the AWS Management Console, which only allow to adjust the root volume size, but not the snapshot it is based upon, see the image within Changing the Root Device Volume to Persist.

Provincial

Has the situation changed since then? We still cannot reassign root device for existing AMI? – Topazolite

Answer 2

You can boot with the default spot volume, then pivot_root init to a separate EBS volume.

The EC2 Spotter tool can manage this for you. A snippet from EC2 Spotter's documentation:

The launch script employs user-data to create a boot-time script that attaches the specified EBS volume to /dev/xvdf and then proceeds to do a pivot_root and chroot in order to use it as the main system disk in place of /dev/xvda. When the instance is first created or restarted following an interruption, the /sbin/init on the AMI-based EBS volume (/dev/xvda1) is replaced with a small shell script which performs the magic pivot_root and chroot and then chain-loads the /sbin/init from the specified persistent EBS volume (/dev/xvdf1). An extra reboot is performed when the instance first comes up, to ensure a clean slate. The end-result is a full Linux system running on the persistent volume dev/xvdf mounted as /. The ephemeral disk remains mounted under /old-root and can be unmounted if needed.

Also see this StackOverflow answer: AWS EC2: How to remount previous EBS volume using pivot_root?

Myocardiograph