(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

Catchment

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.

Lujan

Ah, I see. Still new to EC2, so not yet familiar with all the states and operations of an instance and how they affect things - in this case, I didn't realize rebooting an instance would reset the local instance storage but not EBS storage (even if Delete on Termination is set to true). – Catchment

This is some critical knowledge I was missing: docs.aws.amazon.com/AWSEC2/latest/UserGuide/… – Catchment

@Catchment that's a good link... wish I had read it. I found out mostly by trial and painful, painful error. – Lujan

@Catchment also, I noticed from your chart reboot will work with non-ebs backed data, so I updated my answer to only be for start/stop – Lujan

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.

Malacology

Also a valid answer, thanks. That's pretty much what I've concluded at this point. – Catchment

yeah, just went into that nightmare forgetting to mark this flag on AMI creation fro ASG and getting a bigger bill from AWS) – Gibe

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.

Petrolatum