Snapshots == EBS backed instance, persistence, and S3 storage?

I want to clear up some confusion and clarify understanding on EC2 instances being EBS backed.

If you start an AMI from a community image, configure your server as you want it configured, then use the "create image" option from the EC2 dashboard to create a snapshot, that snapshot (image) can be used to create more servers with your configuration and is considered EBS-backed, yes?

If you create a snapshot and later terminate your AMI EC2 instance, that machine goes away, but the snapshot persists and can be used to recreate your instance, whereas if you don't create an image you lose everything upon termination?

And if you created your server, created an image/snapshot, then terminated your running instance and created a new EC2 instance from your snapshot, then do your changes persist upon termination (new data gets saved to the snapshot) or does it revert to your snapshot's saved state unless you create a new snapshot?

Creating the image/snapshot (these are the same thing with their terminology, yes?) means the resulting disk image is stored on S3, it just doesn't show up under S3 buckets, correct? So the data will be saved across multiple sites for redundancy invisibly?

I think I know the answer to these, but I'd like to verify it.

If you start an EBS-root community AMI - an EBS volume(s) is created under your account from the snapshot(s) associated with that AMI - after that you have no real connection to the original AMI any longer - you will be modifying the local EBS volume that you now own.

By default, most AMIs are set to delete the root volume on termination - even if the root volume is an EBS volume. You can change this by modifying the instance attributes. If you make such a change, termination of the instance will not delete the EBS volume - so you can attach it to another instance you start at a later time point, or snapshot the volume after the instance is terminated.

You must use a snapshot to create an EBS backed AMI - since you define the root volume by referencing your snapshot. You can also create S3 backed instances that have attached EBS volumes by pointing the block-device-mapping at an EBS snapshot. (So, an image is only EBS-backed if you use a snapshot for the root volume).

Snapshots persist independently of the volumes they are associated with or the instances those volumes may have been associated with.

Typically EBS volumes are not deleted by default when an instance terminates (the exception being the root volume, as mentioned above). So, if you create an EBS volume and attach it to an instance, make changes to it, and terminate that instance, the EBS volume will persist, despite the instance being terminated (even in the absence of a snapshot).

Snapshots are point in time backups. The EBS volume is a block device - Amazon creates a map of these blocks in its snapshots, and tracks which blocks have changed. So, EBS snapshots are differential - only changed blocks are stored; point in time - you can deleted any previous snapshot without affecting any other one - and any snapshot can be restored at any time; and compressed - only the amount of data present is stored - empty blocks are ignored.

Changes made to an EBS volume do not affect any pre-existing snapshots - they will only be added to a snapshot if you explicitly take a new snapshot. So, when you restore your snapshot, the resulting EBS volume will be an identical block copy of the EBS volume from which the snapshot originated (this means that deleted files can be undeleted from a restored snapshot using the usual methods - it is not a file copy, and is file system agnostic). Just to reiterate, nothing added after a snapshot is taken will be available when a snapshot is restored.

As per [Amazon's page on EBS][1], snapshots are stored in S3 and benefit from S3's redundancy. They do not show up in your buckets - or on your S3 usage reports. Usually the only way to determine how much snapshot space you are using is to look under your EC2 usage report, under the EBS category - where it lists snapshot data stored.

A few other interesting points about snapshots: a) they load lazily - you can access an EBS volume created from a snapshot, before all the data has loaded, and the necessary data will be fetched from S3 on request - handy if you have large volumes. b) you can create larger (but not smaller) EBS volumes from a snapshot (although, you will need to resize the file system after doing so). c) It is possible to create RAID setups of EBS volumes, and snapshot these, since snapshots work at a block level.

• An EBS backed instance is any instance that has an EBS volume as it's root device. This encompasses almost all new instances.
• Snapshots are persistent until they are deleted. They aren't tied directly to either instances or volumes, though you can view which volume a snapshot was created from.
• You are able to create volume from a snapshot, then mount that volume either as the root of an instance, or attach it to the instance and mount it from inside the instance wherever you like. You can't mount a snapshot directly.
  • Following from this, if you make a new instance based on a snapshot (or an AMI created from the snapshot), you are using the volume. The snapshot itself is totally untouched. You can create another new volume from the snapshot, and it will be exactly the same as when the snapshot was originally taken.
• Snapshots are definitely saved to S3. I believe the EBS volumes themselves are too.

If I missed any of your questions, or something is still unclear, please comment.