AMI (Amazon Machine Image) comes with the advantages of customization of EC2 instances. It also accelerates launching new instances and reduces external dependencies. By creating AMIs, you can launch identical, fully-provisioned copies of your working image into multiple environments. It could be development or production. However, the process of creation of AMIs should be consistent, where the changes between revisions are identifiable and auditable. How to go about it? By automating AMI creation for customized EC2 instances.
The backdrop: Importance of AMIs
An AMI provides the information required to instantiate an EC2 Instance, which is a virtual server in the cloud. You can also specify an AMI when you launch an instance. And you can launch as many instances from the AMI as you need. You can even customize the instance that you launch, from a public AMI. And you can save that configuration as a custom AMI for your own use.
In general, an AMI includes three key components:
- A template for the root volume, for the instance. It could be for an operating system, an application server, or for the applications
- Launch permissions: Those permissions that help control which AWS accounts can use the AMI – to launch instances
- A block device mapping: The one that specifies the volumes to be attached to the instance when it’s launched
Even though AMI comes with the advantages of customization of EC2 instances, it does not help when you need to make additional customization to your AMIs based on the run-time information. Hence, we recommend that the process of creation of AMIs should be consistent with the revisions. And the best way forward to create AMIs consistently is by automating the whole process using the Botmetric Cloud Automation Jobs.
Automate AMI Creation
Using our Botmetric Cloud Automation Jobs, you can automate the task of creating AMI of your customized EC2 Instances. These jobs can be scheduled either at Interval or Cron basis depending on your requirement.
In the dashboard, you can select a single instance or a group of instances for creating AMIs based on the tags.
The Instances with these tags can only be used to create AMIs. These AMIs can be created using “only Root Volume” and “no Reboot” flags that suggest the way to create AMIs.
- If only RootVolume is selected in the dashboard: The Botmetric will create AMI that contains only root volume. If RootVolume is deselected, it will create AMI for the instance considering all the attached block devices
- If noReboot is selected in the dashboard: The Botmetric will create AMI without restarting the instance. In this case, the Botmetric will first shutdown the instance, create AMI for it, and then start the instance
Additionally, you can also choose the number of AMIs to be retained after creating new AMIs for that instance. It will help in maintaining the latest AMIs available for that instance.
As an AWS expert, we suggest all our customers to look for a hybrid approach. For instance, build static components of your stack into AMIs, and configure dynamic aspects that change regularly (such as application code) at the run time.
Ultimately, you need to build the process of creation of AMIs based on your requirements like frequency of deployments, reduction of external dependencies, requirements to scale quickly, and so forth. To learn how to create AMI for EC2 instances in detail, read our support page here.
This product feature write-up is written by our Software Developer Engineer, Anoop Khandelwal.
Latest posts by Rajeev Kumar (see all)
- AWS Per Second Billing for EC2 and EBS Explained - September 20, 2017
- Five ways to reduce EBS costs from AWS Monthly Bills - September 7, 2017
- 5 steps to good Microsoft Azure Cloud Governance - August 14, 2017