Amazon EC2’s new EBS Boot feature not only provides persistent root disks for instances, but also supports root disks larger than the previous limit of 10GB under S3 based AMIs.
Since EBS boot AMIs are implemented by creating a snapshot, the AMI publisher controls the default size of the root disk through the size of the snapshot. There are a number of factors which go into deciding the default root disk size of an EBS boot AMI and some of them conflict.
On the one hand, you want to give users enough free space to run their applications, but on the other hand, you don’t want to increase the cost of running the instance too much. EBS volumes run $0.10 to $0.11 per GB per month depending on the region, or about $10/month for 100GB and $100/month for 1TB.
I suspect the answer to this problem might be for AMI publishers to provide a reasonable low default, perhaps 10GB as per the old standard or 15GB following in the footsteps of Amazon’s first EBS Boot AMIs. This would add $1.00 to $1.50 per month to running the instance which seems negligible for most purposes. Note: There are also IO charges and charges for EBS snapshots, but those are more affected by usage and less by the size of the original volume.
For applications where the EBS boot AMI’s default size is not sufficient, users can increase the root disk size at run time all the way up to 1 TB. Here’s a quick overview of how to do this.
Example
The following demonstrates how to run Amazon’s getting-started-with-ebs-boot AMI increasing the root disk from the default of 15GB up to 100GB.
Before we start, let’s check to see the default size of the root disk in the target AMI and what the device name is:
$ ec2-describe-images ami-b232d0db
IMAGE ami-b232d0db amazon/getting-started-with-ebs-boot amazon available public i386 machine aki-94c527fd ari-96c527ff ebs
BLOCKDEVICEMAPPING /dev/sda1 snap-a08912c9 15
We can see the EBS snapshot id snap-a08912c9 and the fact that it is 15 GB attached to /dev/sda1. If we start an instance of this AMI it will have a 15 GB EBS volume as the root disk and we won’t be able to change it once it’s running.
Now let’s run the EBS boot AMI, but we’ll override the default size, specifying 100 GB for the root disk device (/dev/sda1 as seen above):
ec2-run-instances \
--key KEYPAIR \
--block-device-mapping /dev/sda1=:100 \
ami-b232d0db
If we check the EBS volume mapped to the new instance we’ll see that it is 100GB, but when we ssh to the instance and check the root file system size we’ll notice that it is only showing 15 GB:
$ df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 15G 1.6G 13G 12% /
There’s one step left. We need to resize the file system so that it fills up the entire 100 GB EBS volume. Here’s the magic command for ext3. In my early tests it took 2-3 minutes to run:
$ sudo resize2fs /dev/sda1
resize2fs 1.40.4 (31-Dec-2007)
Filesystem at /dev/sda1 is mounted on /; on-line resizing required
old desc_blocks = 1, new_desc_blocks = 7
Performing an on-line resize of /dev/sda1 to 26214400 (4k) blocks.
The filesystem on /dev/sda1 is now 26214400 blocks long.
Finally, we can check to make sure that we’re running on a bigger file system:
$ df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 99G 1.6G 92G 2% /
Note: The output reflects “99” instead of “100” because of slight differences in how df and EBS calculate “GB” (e.g., 1024 MB vs 1000 MB).
XFS
If it were possible to create an EBS boot AMI with an XFS root file system, then the resizing would be near instantaneous using commands like
sudo apt-get update && sudo apt-get install -y xfsprogs
sudo xfs_growfs /
The Ubuntu kernels built for EC2 by Canonical have XFS support built in, so XFS based EBS boot AMIs might be possible. This would also allow for more consistent EBS snapshots.
Toolset
Make sure you are running the latest version of the ec2-run-instances command. The current version can be determined with the command
ec2-version
To use EBS boot features, the version should be at least 1.3-45772.
Updated 2009-12-11: Switch instructions to default us-east-1 since all regions now support this feature.


Eric,
I am following your instructions to resize the boot volume of an EBS AMI. However, when I run the command:
ec2-run-instances -k laptop2.priv -b /dev/sda1=:100 ami-b232d0db
I get the error
WARNING: Ignoring extra parameter(s): [ ami-b232d0db ]
Invalid argument for option '-b, --block-device-mapping MAPPING': '/dev/sda1' (-h for usage)
I am using API version 1.3-46266 2009-11-30
Erika
Erika: Based on the error message, it looks like you might have typed a space after "/dev/sda1" which does not belong there.
Eric,
There is no space after /dev/sda1 in the statement /dev/sda1=:100.
I am running command line tools version 1.3-46266 2009-11-30
Erika
Erik,
I found the answer to my problem at http://developer.amazonwebservices.com/connect/message.jspa?messageID=157133, in the last post.
This problem occurs when running EC2 commands from a Windows DOS shell. The solution is to put double quotation marks around /dev/sda1=:100, e.g. "/dev/sda1=:100" as described by TiNA
Erika
Erika: Glad you found the solution as I'm not the best person to ask about problems with Windows.
Eric,
I have launched a CentOS EBS instance of 30 GB from a EBS Image of 10GB. How do I extend the root volume to 30GB in CentOS ? resizefs is not present in CentOS package repository.
santhoshsd: I switched from Red Hat products to Ubuntu about five years ago. You might want to ask this question in a CentOS forum, and feel free to post the answer here. Just in case this is the cause: the command is "resize2fs" not "resizefs".
I tried to do what you mention in the article, creating an XFS-formatted root volume, and it works!
It's possible using the recent Canonical Ubuntu AMI and kernel. Here's my article showing how to do this and how it can be used together with your ec2-consistent-snapshot utility.
http://www.shlomoswidler.com/2010/01/creating-consistent-snapshots-of-live.html
Shlomo: Very nice, thanks! I'm a little concerned that if this were placed in a cron job, one might occasionally end up in a deadlock as the ec2-consistent-snapshot command tried to output messages which cron or syslog writes to a disk which is frozen by ec2-consistent-snapshot. I'm considering restructuring the message output so that they are buffered until the file system is unfrozen.