         | Did this page help you? Yes No Tell us about it... |
Basics of Amazon EBS-Backed AMIs and Instances
Topics
Before the 2009-10-31 API, every AMI had its root device stored in Amazon S3. Instances that are launched from these AMIs have instance stores available on them with a separate root partition. When an instance is launched, an image of the root device stored in Amazon S3 is copied to the root partition. This image is used to boot the instance. We refer to these AMIs as Amazon EC2 instance store-backed, or AMIs with the root device in Amazon S3. Starting with the 2009-10-31 API, we have a new type of AMI that stores its root device as an Amazon EBS volume. We refer to these AMIs as Amazon EBS-backed. When an instance of this type of AMI launches, we create an Amazon EBS volume from the associated snapshot, and that volume becomes the root device.
Summary of Differences
This section describes the general differences between Amazon EBS-backed AMIs and Amazon EC2 instance store-backed AMIs.
Size Limit
Amazon EC2 instance store-backed AMIs are limited to 10 GiB storage for the root device, whereas Amazon EBS-backed AMIs are limited to 1 TiB. Many Windows AMIs come close to the 10 GiB limit, so you'll find that Windows AMIs are often backed by an Amazon EBS volume.
![[Note]](http://docs.amazonwebservices.com/docs-common/images/note.png) | Note |
|---|---|
All Windows Server 2008 and Windows Server 2008 R2 AMIs are backed by an Amazon EBS volume by default because of their larger size. |
Stopped State
You can stop an Amazon EBS-backed instance, but not an Amazon EC2 instance store-backed instance. Stopping causes the instance to stop running (its status goes from running to stopping to stopped). A stopped instance persists in Amazon EBS, which allows it to be restarted. Stopping is different from terminating; you can't restart a terminated instance. Because Amazon EC2 instance store-backed AMIs can't be stopped, they're either running or terminated. For more information about what happens and what you can do while an instance is stopped, see Stop/Start.
Default Data Storage and Persistence
Instances that use instance store for the root device automatically have instance stores available on them (for the root partition and other data you want to add). Any data on those stores is deleted if the instance fails or terminates (except for data on the root device). However, after you launch an instance, you can provide it with persistent non-root data by attaching one or more Amazon EBS volumes.
Instances that use Amazon EBS for the root device automatically have an Amazon EBS volume attached. The volume appears in your list of volumes like any other. The instances don't expose ephemeral storage by default. However, you can add ephemeral storage by using a block device mapping. You can also add additional Amazon EBS volumes for non-root data (for more information, see Block Device Mapping). For information about what happens to the ephemeral storage and volumes when you stop an instance, see Stop/Start.
Boot Times
Amazon EBS-backed AMIs launch faster than Amazon EC2 instance store-backed AMIs. When you launch an Amazon EC2 instance store-backed AMI, all the parts have to be retrieved from Amazon S3 before the instance is available. With an Amazon EBS-backed AMI, only the parts required to boot the instance need to be retrieved from the snapshot before the instance is available. However, the performance of an instance that uses an Amazon EBS volume for its root device is slower for a short time while the remaining parts are retrieved from the snapshot and loaded into the volume. When you stop and restart the instance, it launches quickly, because the state is stored in an Amazon EBS volume.
AMI Creation
To create Linux/UNIX AMIs backed by instance store, you must create an image of your instance on the instance itself, and there aren't any APIs available to help you. To create a Windows AMI backed by instance store, there's an API call that creates an image, but you still have to call another API to register the AMI.
AMI creation is much easier for AMIs backed by Amazon EBS. There's a single API action called
CreateImage that works for both Linux/UNIX and Windows. The single call
bundles your Amazon EBS-backed AMI and registers it. There's also a button in the AWS Management
Console that lets you create an image from a running instance. For more information, see Creating Amazon EBS-Backed AMIs.
How You're Charged
With AMIs backed by instance store, you're charged for AMI storage and instance usage. With AMIs backed by Amazon EBS, you're charged for volume storage and usage in addition to the AMI and instance usage charges.
With Amazon EC2 instance store-backed AMIs, each time you customize an AMI and create a new one, all of the parts are stored in Amazon S3 for each AMI. So, the storage footprint for each customized AMI is the full size of the AMI. For Amazon EBS-backed AMIs, each time you customize an AMI and create a new one, only the changes are stored. So the storage footprint for subsequent AMIs you customize after the first is much smaller, resulting in lower AMI storage charges.
When an Amazon EBS-backed instance is stopped, you're not charged for instance usage; however, you're still charged for volume storage. We charge a full instance hour for every transition from a stopped state to a running state, even if you transition the instance multiple times within a single hour. For example, let's say the hourly instance charge for your instance is $0.10. If you were to run that instance for one hour without stopping it, you would be charged $0.10. If you stopped and restarted that instance twice during that hour, you would be charged $0.30 for that hour of usage (the initial $0.10, plus 2 x $0.10 for each restart).
The Root Device Volume
When you launch an instance of an Amazon EBS-backed AMI, the instance has an Amazon EBS volume attached to it for the root device. The volume is created from a snapshot associated at the time of AMI creation. If someone shares an Amazon EBS-backed AMI with you, you can still launch the AMI even if they haven't shared the corresponding snapshot with you. You own the resulting instance and volume. The new volume is like any other Amazon EBS volume. You can only access it when it's attached to a running instance. Any changes you make to the volume are saved (as with any other volume). You should regularly create a snapshot of the volume for backup purposes. For more information, see Root Device Storage.
Stop/Start
When you stop an instance, the following things happen:
The instance performs a normal shutdown and stops running (the status switches to stopping and then to stopped)
The Amazon EBS volumes remain attached, but any ephemeral storage does not persist
The instance retains its instance ID
The instance will probably not retain its public and private IP addresses (exception: instances launched in Amazon VPC; they keep the same IP address when stopped and restarted)
Any elastic IP address that was mapped to the instance is unmapped
| Note |
|---|---|
You can't launch an instance directly into the stopped state. You can only stop an instance after its status is running. |
Let's address a few details for the items in the preceding list.
When the instance is stopped, you're not charged for any instance hours, only the volume storage. Each time you transition an instance from stopped to started, we charge a full instance hour, even if transitions happen multiple times within a single hour.
The root device volume and any others that you added either at the time of launch (through block device mapping) or after launch (by attaching volumes) remain attached while the instance is stopped. Any ephemeral storage does not persist. While the instance is stopped, you can't change which devices are mapped to the instance.
When you stop an instance, it will probably lose its public and private IP addresses and get new ones when you restart the instance. Exception: instances you launch with Amazon VPC retain the same private IP address when stopped and then started; it's therefore possible to have an Amazon VPC subnet with no running instances (they're all stopped), and also no remaining IP addresses available.
When you restart a Windows instance, by default, the Ec2ConfigService changes the instance hostname to match the new IP address and initiates a reboot. For more information about this service, see Appendix C: Windows Configuration Service.
If you were using an elastic IP address with the instance, the address is automatically unmapped when the instance stops. While the instance is stopped, you're charged for the address being unmapped (unless you remap it to another instance). When you restart the instance, you need to manually remap the elastic IP address to the instance; it doesn't happen automatically. For more information about the charges for elastic IP addresses, go to the Amazon EC2 product page.
Each Amazon EBS-backed instance has an attribute called InstanceInitiatedShutdownBehavior
that controls whether the instance stops or terminates when you initiate a shutdown from within the
instance itself. The default is stop. You can modify the attribute while the instance is running or
stopped.
You can modify several other instance attributes only while the instance is stopped:
Kernel
RAM disk
Instance type
User data
While the instance is stopped, you can't change anything about the instance's block device mapping
except the DeleteOnTermination flag for an attached volume (you can also change the flag
while the instance is running). For more information about modifying instance attributes while the
instance is stopped, see Modifying Attributes of a Stopped
Instance.
| Note |
|---|---|
Although you can use the AWS Management Console to stop and start instances, you can't use it to modify any instance attributes. That functionality is available only through the command line tools or API. |
While the instance is stopped, you can treat the root volume like any other volume, and modify it (e.g., repair file system problems or update software). You just detach the volume from the stopped instance, attach it to a running instance, make your changes, detach it from the running instance, and then reattach it to the stopped instance. Make sure you reattach it to the correct storage device (whichever device name is specified as the root device in the instance's block device mapping).
Instance Termination
When an instance terminates, any instance store associated with that instance is deleted.
By default, any volumes that were created when the instance launched (the root device and any others
specified in the block device mapping) are automatically deleted when the instance terminates (in other
words, their DeleteOnTermination flags are set to true by default). However,
any volumes that you attached after the instance was running are not (their
DeleteOnTermination flags are set to false by default). If you detach and
then reattach a volume that was created at instance launch, it's treated like a new volume that you
attached after the launch, and its DeleteOnTermination flag is set to
false.
You can see the value for the DeleteOnTermination flag for each of the attached volumes
by looking at the instance's block device mapping (for more information, see Viewing Block Device Mappings). You currently can't change the
flag's value once the instance is launched; however, you can launch the instance with your desired value
for the flag. In the launch request, you just specify a block device mapping with the value. For an
example of how to change the flag at launch time, see Changing the Root Volume to Persist.
What happens to the volume when you terminate the instance it's attached to? Assuming the volume's
DeleteOnTermination flag is false, the volume persists in its current
state. You could take a snapshot of it, and you could attach it to any other instance you have.
| Note |
|---|---|
When you launch an instance of a particular AMI and then terminate the instance, any remaining volumes are not automatically related to any future instances of that AMI. In other words, a new instance that you launch of that same AMI doesn't attempt to attach to the remaining volume. However, you can manually attach the remaining volume to the new instance if you want. |
For more information on persisting the data after instance termination, see Data Persistence after Instance Termination.
Starting with the 2009-10-31 API version, you can prevent an instance from being terminated. This
feature is available for both Amazon EC2 instance store-backed and Amazon EBS-backed instances. Each instance has a
DisableApiTermination attribute that defaults to false (i.e., the instance
can be terminated). You can modify this instance attribute while the instance is running or stopped (in
the case of Amazon EBS-backed instances).
Shared AMIs Backed by Amazon EBS
You can share Amazon EBS-backed AMIs like you share Amazon EC2 instance store-backed AMIs. You don't need to share the snapshot that the AMI references. Even though people you share the AMI with get a root volume created from the snapshot when they launch an instance, they can't separately create a volume from that snapshot.
Limits on Number of Instances and Volumes
Your AWS account has a limit on the number of running instances you can have. There's also a limit on
the overall number of instances you can have with any status except
Terminated. This overall instance limit is 2x the running instance limit. You can
request to increase your running instance limit by completing the Amazon EC2 Instance Limit Request
Form.
Your account is also limited to 5000 Amazon EBS volumes, or 20 TiB in total volume storage, whichever you reach first. The maximum volume size is 1 TiB. You can request to increase your volume limit by completing the Amazon EBS Volume Limit Request Form.
