128

I have been poking around Amazon EC2, and am a little confused on some of the terminology. Specifically with regard to AMI, snapshots and volumes, and an EBS

Please correct me if I am wrong, or fill in any serious gaps in my following statements:

  • An AMI (Amazon Machine Image) is a full 'disk' capture of an operating system and configuration. When you launch an instance, you launch it from an AMI

  • An EBS (Elastic Block Storage) is a way to persist the state of any modifications you made once booting from a given AMI. In my mind, this is sort of like a diff on the final state of your instance vs the AMI.

  • A snapshot is ... well, I'm not sure. I can only assume it is a snapshot of a specific instance, but it is not clear to me how this differs from the state stored in an EBS. How is a snapshot different from creating an EBS AMI from an existing instance?

  • A volume is ... it would seem mounted disk space into which an AMI/EBS pair is loaded? I'm not sure on this one either. I can see (from the AWS Console) that you can create a volume from a snapshot, and that you can attach/detach volumes, but it isn't clear to me why or when you would do that.

Matt
  • 3,171
  • 9
  • 28
  • 33

4 Answers4

156

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.

Seldom 'Where's Monica' Needy
  • 109
  • 5
Caleb
  • 11,583
  • 4
  • 35
  • 49
  • 1
    Thanks for the great info, I think it is coming together for me. A follow up question: what is the difference between doing a snapshot of an EBS AMI compared to right clicking and selecting 'Create Image (EBS AMI) from the EC2 web console? Based on your description above, it would seem like they are identical except for how you use them. You can create a volume from a snapshot, and then attach that volume to an AMI. Where as the EBS AMI image just... I don't know, eliminates that step of attaching it to a volume? – Matt May 11 '11 at 19:00
  • Actually I think the console tool for snapshoting an AMI does the same thing as the web console. Where your description errors is the bit about attachments. If you snapshot an instance, yes a snapshot gets created of the root volume, but more than that the snapshot becomes an AMI. A regular snapshot you make into a volume and attach to an instance. A snapshot of an instance you make into a instance (you don't attach the volume to an instance, it IS the instance). Does that make sense? – Caleb May 11 '11 at 19:05
  • Whenever I said console I've meant to say web-console. I haven't played with command line api's or anything yet. I guess what I'm confused about is, you create an EBS AMI from an instance, and you create a snapshot from a volume, but it seems that the volume *is* the EBS AMI. And then, to create a new instance, you can either 1) launch one from a created AMI, or 2) Copy the snapshot to a volume and launch an AMI attached to that volume, but in the end, the result is the same. Is that correct? – Matt May 11 '11 at 19:11
  • You were ok until the "it seems like" part, then it stops matching the reality. Particularly the last part (your 2) is nonsense. You don't attach AMI's to volumes. EBS backed AMI's *are* specially tagged volumes that are bootable. Volumes are attached to instances, not the other way around. – Caleb May 11 '11 at 19:19
  • Sorry to keep pestering - when you say "Volumes are attached to instances, not the other way around.", how can an instance be an instance without a volume? And, when you launch an EBS AMI, isn't it's volume based on the contents of the EBS, or can the contents of the volume be different (e.g. from a snapshot) – Matt May 11 '11 at 19:27
  • You're over thinking there. There is a sense in which you have a point, but it's not the way you need to think about the pieces in order to use them most effectively. You can have an instance without a volume in the case of ephemeral instances, or an instance that IS a volume in the case of EBS backed. In the later case even the instance still comes first (special set of properties that make up an AMI), but during the launch/boot process it's special ebs volume get's attached to the instances and mounted as /. – Caleb May 11 '11 at 19:35
  • Okay, thank you so much. One last question. When/why would one do a snapshot instead of a created EBS AMI image? – Matt May 11 '11 at 19:41
  • 2
    When you are snapshotting something other than the root disk. I have lots of disks that store data sets that are not part of any given computer. If you are snapshoting the system disk / root drive, then use the EBS AMI creation tools. But sometimes you have other volumes with other sets of data that may or may not even be attached to a given system. Those you can snapshot on your own time. An automatic snapshot will get made if they happen to be attached to an instance you snapshot, but you may also want to make your own sometimes ... say to duplicate a disk and attatch it to another instance. – Caleb May 11 '11 at 19:45
  • Ahh, okay, that use case helps make things clear. Thank you so much for your time and patience Caleb. – Matt May 11 '11 at 19:59
  • if I have an AMI, that an instance was created from it. Does the AMI include the data on that instance? I mean, if the instance contains tomcat WAR files, the the AMI that that instance was created from, includes as well? – Dejel Jun 23 '15 at 12:54
  • @Odelya ① There isn't enough information in your camment to answer that question but ② if you have a question you should post it as a question. See [ask]. Be sure to include details about what kind of instance (EBS backed?) and where in the instance you stored data. – Caleb Jun 23 '15 at 13:35
  • 1
    This answer is generally good, but one point is incorrect in last para - AWS never stops the instance when taking a snapshot of the root EBS volume. The docs [recommend you shut down](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ebs-creating-snapshot.html) (search for 'should stop') but AWS doesn't do this for you. Also, snapshotting a root volume doesn't create an AMI - it doesn't, it creates a snapshot. From that, you can create an AMI, which has pros and cons - you might have boot fsck issues (snapshot made from a running server) but you don't have to shut down first. – RichVel Oct 05 '18 at 06:19
9

I think let's make it simple. Create an AMI template from an existing instance (say instance#1. Note, when you create an AMI template, you will have a volume snapshot as well, look into your snapshot section. When you want to create new instance, choose the newly created AMI template, it will then pick the snapshot at the time the AMI template created. Simple.

Now, if you have been creating snapshots from the volume of instance#1, it is ok. Create new instance from the AMI template, then detach the volume that was automatically created for it, then attach volume created from snapshots from the volume of instance#1.

Bart De Vos
  • 17,761
  • 6
  • 62
  • 81
Goldwynn T
  • 91
  • 1
  • 1
2

To summarize things:

  • EBS = the AWS service itself

  • EBS Volume = think of it like a hard drive you can attach to an EC2 instance

  • Snapshot = a point in time copy of your volume

  • AMI = a copy of a full instance

  • EC2 = the service that RUNS the VM compute
TH22
  • 121
  • 4
0

Further to above explanations, here is an example to clarify all these.

Let's say your "EC2 Instance I1" has two EBS volumes attached to it - EBS Volume V1a and EBS Volume V1b.

Now, if you create an AMI image from EC2 Instance I1, you will get -

a. An AMI image of EC2 Instance I1, let's call it AMI1

b. A snapshot of EBS Volume V1a, let's call it S1

c. A snapshot of EBS Volume V1b, let's call it S2

Then, if you launch a new instance from AMI1 image, you will get -

a. A new EC2 instance, let’s call it I2

b. A new EBS Volume generated from Snapshot S1, let’s call it V2a

c. A new EBS Volume generated from Snapshot S2, let’s call it V2b

To sum it up -

  1. An AMI image creates snapshot(s) of the volume(s) that are attached to the original instance (from which the AMI is created)

  2. A new instance launched from an AMI image creates volume(s) from the snapshots attached to that AMI.

I explained it in detail in http://zilhaz.com/ebs-ami-aws-ec2/

zilhaz
  • 1
  • 2