Why do we need a simpler way to launch a new EC2 instance, does AWS not already tell us how simple this process is and how quick and easy it is to set up? This is all true, however, as more organizations migrate to the cloud AWS continually, strive to meet their customer’s demands and develop with them new ways to meet their organisation requirements or giving the customer the right tools for the right job. So let’s compare, What’s involved in creating an AMI and how does it work, compared to creating EBS snapshots?
What is an AMI?
An Amazon Machine Image (AMI) is an encrypted machine image of a specific computer running an operating system that is configured in a specific way and that can also contain a set of applications and services for accomplishing a specific purpose. An AMI contains all the information necessary to start up and run the software in the image. Amazon Elastic Compute Cloud (Amazon EC2) and AWS infrastructure make up the computing environment for running an AMI.
You specify an AMI when you launch an EC2 instance, you can launch as many instances from the AMI as you want and as many different AMIs as you need. An AMI includes a template for the root volume for the instance (for example, an operating system, an application server, and applications), launch permissions that control which AWS accounts can use the AMI to launch instances and a block device mapping that specifies the volumes to attach to the instance when it’s launched.
What happens when you launch an instance?
When you launch an instance, the root device volume contains the image used to boot the instance. When Amazon EC2 was launched, all AMIs were backed by Amazon EC2 instance store, which means the root device for an instance launched from the AMI is an instance store volume created from a template stored in Amazon S3. However, when Amazon EBS was launched, they introduced AMIs that are backed by Amazon EBS. This means that the root device for an instance launched from the AMI is an Amazon EBS volume created from an Amazon EBS snapshot. You can choose between AMIs backed by Amazon EC2 instance store and AMIs backed by Amazon EBS.
How do they compare?
Amazon Instance Store-Backed
|Boot time||Usually less than 1 minute||Usually less than 5 minutes|
|Size limit||16 TiB||10 GiB|
|Root device volume||Amazon EBS volume||Instance store volume|
|Data persistence||By default, the root volume is deleted when the instance terminates.* Data on any other Amazon EBS volumes persists after instance termination by default. Data on any instance store volumes persists only during the life of the instance.||Data on any instance store volumes persists only during the life of the instance. Data on any Amazon EBS volumes persists after instance termination by default.|
|Upgrading||The instance type, kernel, RAM disk, and user data can be changed while the instance is stopped.||Instance attributes are fixed for the life of an instance.|
|Charges||You’re charged for instance usage, Amazon EBS volume usage, and storing your AMI as an Amazon EBS snapshot.||You’re charged for instance usage and storing your AMI in Amazon S3.|
|AMI creation/bundling||Uses a single command/call||Requires installation and use of AMI tools|
|Stopped state||Can be placed in stopped state where instance is not running, but the root volume is persisted in Amazon EBS||Cannot be in stopped state; instances are running or terminated|
Creating EBS snapshots
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.
An Amazon Machine Image (AMI), a virtual computing environments, known as instances (EC2), is a preconfigured templates for your instances, known as Amazon Machine Images (AMIs), that package the bits you need for your server (including the operating system and additional software)and this is an instance image (AMI) in the AWS Marketplace, where users install the software themselves. After you create and register an AMI, you can use it to launch new instances. The registration of the instance links it to the volumes. As AMIs hold data that is needed to launch a new EC2 instance, they are preferred for keeping “Golden Images” that can support the same baseline instance. With EBS snapshots been a backup of an EBS volume from a specific point in time, the two main reasons why an EBS Snapshots are better backups solution than AMIs, are scalability and consistency.
AMIs do not scale well for large volumes, EBS volumes were created for this reason. With an AMI the exact point in time the creation begins is not in our control. AMIs can be created with or without a reboot of the instance. This makes it inconsistent, not good for a production environment, these high-frequency outputs have to be available around the clock with little or no downtime consistency is not guaranteed. The indeterminable point in time the AMI was taken could cause a problem when the instance is restored. Because backups of critical application require consistent snapshots, EBS is recommended.
However, the process of an EC2 instance restore, from a snapshot differs, depending on which operating system is used. A Linux EC2 instances, EBS snapshot can be achieved easily with the automated system in the CPM. With Windows AWS does not allow AMIs to be created from a snapshot of the root device(Volume), it can be achieved manually.
So, this is why AWS recommends that you use AMIs backed by Amazon EBS volumes because they launch faster and use persistent storage.
Druva CloudRanger provides the world’s easiest to use backup and recovery solution for Amazon Web Services. We make it easy to manage your backups & servers running on AWS cloud. Using CloudRanger, you can easily manage backups and retention of your RDS, EC2 and Redshift resources with snapshots and AMIs.
With an easy to use interface, managing your routine AWS tasks is simple and effective. CloudRanger saves your team time and hassle, making the day-to-day management of your AWS resources easier and more automated. CloudRanger can also help you save on your EC2 costs by starting/stopping non-production instances automatically when you need them.
Try CloudRanger for Free
A centralized approach helps cloud-focused IT teams effectively manage their data, mitigate loss, while maintaining compliance and optimizing costs. Check out our whitepaper on 8 tips to simplify backup and recovery for native AWS workloads, that Cloud Administrators, or Cloud Solution Architects should take into consideration when they set up a data protection strategy for applications running in AWS