S3-backed EC2 instances are good for one-shot servers, which don’t need to persist state
from one run to another. If you need to persist that state, however, an EBS-backed instance
is a better choice.
Create an EBS-backed instance
The procedure for creating an EBS-backed instance is pretty much the same as for
creating an S3-backed instance. There are
a couple extra parameters you can pass when launching that make sense
for EBS-backed instances.
About the parameters and their values:
Replace ec2-keypair with the name of the keypair you generated in the initial setup,
The value for --block-device-mapping is of the form “device=snapshot:size:delete-on-termination”.
In this case, we’re saying that /dev/sda1 will be attached to a new EBS volume, 16 GB in size,
which will not be deleted when the instance is terminated.
The value for --instance-initiated-shutdown-behavior can be either stop or terminate,
and describes what happens to the instance if it shuts itself down (e.g. with
shutdown -h now).
--disable-api-termination locks the instance, keeping it from being deleted until you
explicitly allow it.
Make sure that the instance is running.
Log in and look around
Log in as ec2-user.
Let’s have a look at the EBS volume that’s being used for root.
That’s not right – 8,256,952 1K blocks adds up to roughly 8 GB, and nowhere near the 16 GB
we specified when launching the instance.
If you don’t specify a snapshot to start with when you specify a block device mapping, EC2
apparently initializes the EBS volume from some internal snapshot which is 8 GB in size.
Fortunately, it’s easy to resize the filesystem to use all of the space on the volume that
Test the persistence
Now, it would be good to prove to ourselves that the filesystem survives the instance being shutdown
and restarted. Copy some text to a file in the ec2-user’s home directory. 1
Shut down the instance from within itself (which we can safely do, because we specified that
the instance should stop rather than terminate, when we launched it).
Restart the instance. Wait a minute for it to come up, then check to make sure that it’s running.
Note that the public IP address changed from the previous run.
Log in, and go looking for the file that was stashed in ec2-user’s home directory.
EBS volumes are just volumes
Let’s say that some process in an EBS-backed instance went haywire, corrupting the disk
enough that starting the instance causes it to lock up, and you can’t even log into it
to clean it up or even figure out what’s gone wrong. If this were a physical computer
with a physical hard drive 3 we could pull the drive and put it into another
computer, or boot off of a different volume like a CD.
The comparable thing in the EC2 realm is to attach the volume to a running instance.
It appears in the instance as a disk device, which then can be mounted wherever you want
in the filesystem.
An important note
Just as EC2 instances rack up charges as long as they’re running, so do EBS volumes as long
as they exist. If you started an EBS-backed instance with a --block-device-mapping parameter
containing false for “delete on termination”, the EBS volume will be retained even after
the EC2 instance has been terminated and garbage collected. If you don’t want to keep incurring
charges for it, don’t forget to delete it as well.
Believe it or not, single quotes instead of double quotes in that echo
make a difference. ↩
The EC2 command-line tools come in two forms: a longer, verbose form and a shorter form.
ec2din is the shorter form of ec2-describe-instances. ↩
Well, yeah, there’s obviously a physical computer with a physical hard drive