(AWS/EC2/EBS) Why does “Delete on Termination” default to true for root devices?

Question

On Amazon EC2, when you use an EBS volume as the root device for an EC2 instance, the "Delete on Termination" flag defaults to true, meaning the volume will automatically be deleted when you destroy the instance.

What is the point of this?

If the primary benefit of using EBS over local instance storage is storage persistence independent of instance persistence, doesn't this completely defeat the purpose of that?

If you don't mind the root device being destroyed along with the instance, why not just use local instance storage which is cheaper and less effort to create/manage?

Relevant references:

• http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/RootDeviceStorage.html
• http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ComponentsAMIs.html#storage-for-the-root-device
• http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-lifecycle.html#lifecycle-differences

Answer 1

You might want to just start/stop your instance without terminating it and recreating a new one. In this case, you don't want you data on your instance reverted to the initial AMI state. You can do this with an EBS backed volume, you can't with ephemeral storage. I know I frequently cycle instances when testing boot and shutdown scripts and pause them when I don't need to pay for unneeded cycles.

Here's a similar question on serverfault with the diffs between rebooting, start/stop, and terminating: https://serverfault.com/questions/315123/difference-between-rebooting-and-stop-starting-an-amazon-ec2-instance

I think for many it's common after terminating an instance you want the backed storage removed, not just hanging around. If you want to keep state without an instance, you can take a snapshot or create a new AMI from the running instance before termination.

Answer 2

Setting "Delete on Termination" flag to true is the preferred approach for frequently autoscaling instances. It will be a nightmare if we were to manually check and delete the volumes after every scale-down event. In this case, any useful data like application logs should ideally be stored outside of EBS (Like syslog-ng, s3 or logging solutions like Splunk, Loggly, Logstash, etc..)

But for standard instances though (non-autoscaling), setting this flag to false make sense.

Answer 3

Reverting the boot volume to a known good state is one of AWS simplest and most effective recovery mechanisms. Think, "have you tried turning it off and on again"... but with a new computer every time.

I'd be wary of setting DeleteOnTermination=false because you've now opened up a whole world of disk-state related problems that you didn't have to worry about before. Just the most obvious -

• disk full
• bad disk (yeah, I know it's virtual, still..)
• corrupted files
• messed up boot sequence from fiddling, etc

Basically, whatever problem that made the instance want to terminate has a high probability of surviving the reboot (given that you're preserving the root FS), unless it was purely an in-memory issue, in which case, restart the app rather than the instance.

If you pack everything you need into the AMI, there should be minimal work to do on boot. If you're installing a ton of stuff at boot time.... well, there's your problem. Autoscaling relies on a fast spin up time. AMIs should have as much of the boot process baked in as possible.