An AMI, as you note, is a machine image. It's a total snapshot of a system stored as an image that can be launched as an instance. We'll get back to AMIs in a second.
Lets look at EBS. Your other two items are sub-items of this. EBS is a virtual block device. You can think of it as a hard drive, although it's really a bunch of software magic to link into another kind of storage device but make it look like a hard drive to an instance.
EBS is just the name for the whole service. Inside of EBS you have what are called volumes. These are the "unit" amazon is selling you. You create a volume and they allocate you X number of gigabytes and you use it like a hard drive that you can plug into any of your running computers (instances). Volumes can either be created blank or from a snapshot copy of previous volume, which brings us to the next topic.
Snapshots are ... well ... snapshots of volumes: an exact capture of what a volume looked like at a particular moment in time, including all its data. You could have a volume, attach it to your instance, fill it up with stuff, then snapshot it, but keep using it. The volume contents would keep changing as you used it as a file system but the snapshot would be frozen in time. You could create a new volume using this snapshot as a base. The new volume would look exactly like your first disk did when you took the snapshot. You could start using the new volume in place of the old one to roll-back your data, or maybe attach the same data set to a second machine. You can keep taking snapshots of volumes at any point in time. It's like a freeze-frame instance backup that can then easy be made into a new live disk (volume) whenever you need it.
So volumes can be based on new blank space or on a snapshot. Got that? Volumes can be attached and detached from any instances, but only connected to one instance at a time, just like the physical disk that they are a virtual abstraction of.
Now back to AMIs. These are tricky because there are two types. One creates an ephemeral instances where the root files system looks like a drive to the computer but actually sits in memory somewhere and vaporizes the minute it stops being used. The other kind is called an EBS backed instance. This means that when your instances loads up, it loads its root file system onto a new EBS volume, basically layering the EC2 virtual machine technology on top of their EBS technology. A regular EBS volume is something that sits next to EC2 and can be attached, but an EBS backed instance also IS a volume itself.
A regular AMI is just a big chunk of data that gets loaded up as a machine. An EBS backed AMI will get loaded up onto an EBS volume, so you can shut it down and it will start back up from where you left off just like a real disk would.
Now put it all together. If an instance is EBS backed, you can also snapshot it. Basically this does exactly what a regular snapshot would ... a freeze frame of the root disk of your computer at a moment in time. In practice, it does two things different. One is it shuts down your instance so that you get a copy of the disk as it would look to an OFF computer, not an ON one. This makes it easier to boot up :) So when you snapshot an instance, it shuts it down, takes the disk picture, then starts up again. Secondly, it saves that images as an AMI instead of as a regular disk snapshot. Basically it's a bootable snapshot of a volume.
One thing to remember is that not all data needs to be permanent. Instance store provides a cost effective solution for dealing with temporary data.
Let me provide a few examples.
The most obvious is swap space. If you want to allocate a few GB of swap space, a file on an instance store device is perfect - no cost to the I/O operations, and the data does not even need to persist between reboots.
More practically though, consider that AWS caters to a wide variety of computing tasks - not just to web infrastructure. So, for instance, instance storage is perfect for certain build processes that generate large quantities of intermediate files but a small final product. The need for this kind of storage is not uncommon in scientific applications and even some map-reduce applications.
Temporary files (i.e. /tmp), some caches, and even certain types of logs may also not need to be permanently stored and are well suited to the instance-store model.
Especially given the larger instances which have multiple instance-store volumes attached, you can set them up in RAID0 to improve performance - get large quantities of storage for no additional cost, and do not have to pay for I/O operations.
Consider, for a moment that an m1.xlarge (if purchased as a 3 yr reserved instance) will cost $116.8+$94.44=$211.24/mo - and it includes 1690GB of storage. To provision that same amount of EBS storage would cost $169/mo - plus the I/O costs (which can be substantial). Especially is someone has a cluster with many servers, the cost savings can merit implementing copy all data to a permanent store, but use the instance-store as the primary storage of the server.
The above said, however, in most common cases, EBS is the better way to go - especially with the ease of backups (EBS-snapshots) - which will even work for RAID arrays (and are differential and compressed).
Best Answer
While all instances, other than the t1.micro, do have an allocation of 'instance storage' (i.e. ephemeral storage), that storage is not necessarily attached by default. In most cases, instances with an EBS root volume will have zero or one attached ephemeral volumes.
The ephemeral disks, available to an instance are labelled
ephemeral[0-3]
. You can NOT attach these to an instance once it has been launched. (On the other hand, you can add EBS volumes to an instance while it is running).Since ephemeral disks, together with EBS volumes, are block devices, AWS calls the mapping of these disks to an instance's devices 'block device mappings', and these can be specified either using the
-b
or--block-device-mapping
parameters (which you can use more than once).In order to change the ephemeral disks attached to the instance, you need to either:
launch the instance explicitly specifying the ephemeral disk mappings OR
register a new AMI, explicitly specifying the ephemeral disk mappings (and an EBS root):
Note, on windows instance, you will specify the device as /dev/xvdX, whereas on Linux instances you will specify it as /dev/sdX (although, modern Linux kernels will still show this device as /dev/xvdX, with a symlink to /dev/sdX). Additionally, Windows instances will format the instance store volumes to NTFS (although, by default, the volumes come formatted as ext3).
AWS details the available instance storage and allocations in their documentation.