A snapshot is a backup of an EBS volume. An AMI (Amazon Machine Image) is a clone of the entire EC2 instance including licenses. An AMI created from an EC2 instance includes snapshots of the root volume and any other attached EBS volumes.
During the AMI-creation process, Amazon EC2 creates snapshots of your instance's root volume and any other EBS volumes attached to your instance. You're charged for the snapshots until you deregister the AMI and delete the snapshots.
EBS Snapshots are a point-in-time copy of your data, and can be used to enable disaster recovery, migrate data across regions and accounts, and improve backup compliance. You can create and manage your EBS Snapshots through the AWS Management Console, AWS Command Line Interface (CLI), or the AWS SDKs.
By default, when you create an AMI from an instance, snapshots are taken of each EBS volume attached to the instance. AMIs can launch with multiple EBS volumes attached, allowing you to replicate both an instance's configuration and the state of all the EBS volumes that are attached to that instance.
There are two types of AMIs (and corresponding instances):
instance-store (sometimes called S3-based). These are less common and I don't recommend them for beginners. An instance-store AMI is a copy of the root instance-store volume plus some metadata, all saved in an S3 bucket in a special format
EBS boot. This is probably what you are using. An EBS boot AMI is an EBS snapshot of the EBS root volume plus some metadata like the architecture, kernel, AMI name, description, block device mappings, and more.
You can take a snapshot of an EBS boot volume and turn it into an EBS boot AMI by registering it with the appropriate metadata. The trickiest part of this is specifying the correct AKI id (kernel) so that it boots correctly.
The major difference is between the type of service referred to. A snapshot is of an EBS volume where you are able to save state and reboot with the same data at a certain point in time.
An AMI is similar, but its for the EC2 instances themselves. You cannot take a snapshot of a non ebs backed instance, but you can create a AMI (system image) of one.
Generally I use EBS snapshots as backup solutions for a database volume and I use an AMI to save instance configuration
I was confused by that as well. Here's simplest way of understanding it:
EBS Snapshot
very often represents a backup of specific EBS volume, it might be any volume (Root volume, data volume, etc.)
AMI
(Amazon Machine Image) is a backup of Entire EC2 instance. For example, with proper configuration it's possible to create AMI which includes multiple EBS volumes.
Now, it might sound confusing, but they are both stored as a "EBS Snapshots".
Just think of that way:
EBS Snapshot
is a just a data backup.AMI
is a representation of system state at specific time. You can also boot from it.An AMI can be created using a snapshot. For example, using a single "snapshot" you can create multiple AMIs, say one PV and one HVM AMI using the same snapshot.
So, snapshot has the system / OS data. AMI is (snapshot + machine/hardware metadata).
EBS Volume
is the underlying disk behind EC2. Snapshot
is a point in time backup of specific volume
while AMI is is backup of the entire EC2 instance that might have multiple attached volumes, exactly like virtual machines.
With Packer, you can build automated machine images including AMIs for EC2, VMDK/VMX files for VMware, OVF exports for VirtualBox, etc.
EC2 <-- EBS Volume (Boot) + EBS Volume
^
|
Snapshot (only of specific volume)
^
|
AMI (Combined snapshots of all volumes, snapshot must have boot volume)
^
|
Launch a new Instance (same installed softwares and configs, different specs)
Snapshots can be used to backup drives/volumes. It is incremental backup operation which means every time you take a snapshot of a volume, it will add only the new changes added/introduced to the volume since your last backup (not entire backup), that saves backup time, space and ultimately the cost.
Snapshots can be used in:
Backup drives regularly
Change the type of volume, for example you have traffic or reads and writes and need to increase IO operations so you change from gp2
to io1
with higher IOPs
Custom AMIs can be used in:
For disaster recovery in case current running EC2 instance corrupted and couldn't run for no reason.
Standard company's AMIs that have all installed prerequisites softwares that simplifies the process of deployment (e.g. configured to connect to `Splunk, has some monitoring and observability softwares installed, has docker installed, or it's configured to connect Puppet or Chef in startup)
AMIs could be used to deploy your applications in different regions easily.
Upgrade your server to higher or different specs with all installed softwares and their configs
AMIs can be publicly shared across AWS accounts.
Here are few more differences between AMI and EBS Snapshots:
1) An AMI is launchable and contains links to the root device and may contain links to snapshots of the other data volumes.
2) The data image contained in an AMI does not represent a well-defined point-in-time, unless the instance is rebooted, something that is typically not acceptable for production environment. Snapshots can be taken in a consistent manner since their exact point-in-time can be controlled, so before the snapshot starts it can be made sure that everything is "ready for backup".
3) An AMI can be created from existing snapshots of the root device for Linux but not for Windows.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With