Amazon EC2 for Windows The Basics – Part V

What is Elastic Block Storage (EBS)? When the Amazon web site describes EBS there is a lot of references about mounting and raw block storage -- Linux terms. However, with the new boot from EBS for Windows this is a confusing. So from a Windows perspective I am going to try to explain EBS and touch on why boot from EBS is the only way to go for Windows.

Windows doesn't really have a concept of mounting hard drives, and the operating system likes all physical drives to be in place before it boots. Which means that when Amazon EC2 boots your Windows instance it needs to know what storage (drives) are attached.  Keep this in mind as you read on.

In Microsoft Virtual server we think about this as a .vhd drive. All the virtual hard drives are attached when the Virtual instance is started.

Back to Amazon EC2, there are two types of storage (drives) available. ESB drives and Amazon Machine Images (AMI). Amazon Machine Images are stored on the Amazon S3 cloud, and moved to the Amazon EC2 servers when the EC2 instance is booted. Previous to December 3rd 2009, you could only boot off an AMI. Here are the steps for creating a Amazon EC2 instance that booted off an AMI:

1) Choose a operating system pre-installed on a AMI from the list.
2) Boot your Amazon EC2 instance and wait for the System log to tell you that Windows is ready.
3) Log in via RDC and do some stuff.
4) Shutdown your Amazon EC2 instance
5) Save that AMI that was running on Amazon EC2 datacenter to Amazon S3, which is a slow process.
6) Register the AMI instance with Amazon EC2, so that EC2 knows where in S3 to fetch the image from. 
6) Terminate the instance running on Amazon EC2, which removes the storage from the EC2 data center.

When you wanted to restart that AMI:

1) Choose your AMI image to boot from the registered AMI list. 
2) Your image is copied from Amazon S3 to The EC2 data center, this tends to be very slow -- up to 20 minutes.

3) The image is booted and now you can log in.
4) Once you are done using EC2 instance, you have to repeat the steps to save it off to the Amazon S3 cloud.

 

AMI instances where impractical for two reasons: they where slow to transfer between the EC2 datacenter and Amazon S3, which meant saving them and retrieve them was a tremendous act of patience.  The second reason is that they where limited to 10 gigabytes.  Which is enough to run a web server, however using it for almost anything else was impractical. 

 

Before December 3rd, 2009, Amazon solution to the problems was the allocation of EBS for a secondary drive from the main drive booting AMI image.  EBS is permanent storage of from 1 gigabyte to 1 terabyte in the Amazon EC2 datacenter.  This second drive (think d: drive) didn’t need to be copied from Amazon S3 so it was available instantly when the operating system booted and it could be much bigger then the 10 Gigabyte limit of the AMI boot image.  However, this didn’t work for Windows operating system.  Most of the strain on the 10 gigabyte main  (c:) drive was from Windows updates and program installation, which typically require that they be installed on the c: drive (under Program Files).  Secondly, as pointed out above windows needs to know the permanent drives before it boots, and there are no device drivers for EBS drives.  Which left Windows operators doing some pretty convoluted stuff to figure out how to get a little more storage from EBS drives.  All in all it wasn’t worth the effort.

 

“On December 3rd Amazon announced that you could boot from Elastic Block Storage (EBS)”

 

What this meant is that Amazon provided a few pre-installed images of the Windows operating system (and Linux) that where on EBS.  Booting from these worked like this:

 

1) Choose a operating system pre-installed on a EBS from the list.
2) Boot your Amazon EC2 instance and wait for the System log to tell you that Windows is ready.
3) Log in via RDC and do some stuff.
4) Shutdown your Amazon EC2 instance  -- do not terminate.

That is it.  Your personal EBS (a copy of the pre-installed EBS) stayed in the EC2 data center.  When shutdown the instance is not charge the CPU fee, just the storage fee.  An when you start it the next time it starts much faster since it doesn’t need to be copied from S3. 

 

However, the pre-installed EBS image you choose has a fixed hard disk size.  I am running the medium instance of the Windows 2003 basic, it was installed on a 30 Gigabyte EBS, which is plenty for what I am doing.  Basically, Amazon had to make a choice about the EBS size before they installed the operating system.  Coming from the Virtual Server 2005 world I find myself a little spoiled.  In Virtual Server you could have dynamically expanding drives that increased their storage (up to 256 Gigabytes) as you used the storage (wrote more to the disk).  In the EBS world you have a fixed pre-allocated size of the hard disk.

 

Booting from EBS makes running the Windows operating system practical on Amazon EC2.  It is my recommendation that you always choose a EBS image to boot from.

 

{6230289B-5BEE-409e-932A-2F01FA407A92}