Intro to AMIs
Amazon Machine Images (AMIs) are the templates by which EC2 virtual servers, or instances, are started from. They define all of the info required to launch a fully functioning operating system. AWS provides a set of baseline AMIs for popular operating systems such as several different versions of Windows and Linux variants. As AMIs are a template, you can create as many running servers from them as you want.
An AMI can be customized to include the following elements:
- Base OS including packages and customizations
- Packaged or custom applications
- A block storage device mapping (if you want more than just an OS volume)
- Permissions that control who can access the AMI (private, public, or shared)
The AMI Lifecycle
There's a specific process to follow to use AMIs. When first getting started, you will launch an already created AMI. This could be one of the vanilla AMIs provided by AWS, a free AMI from the community, or a paid AMI from the marketplace. No matter which one you start, the general lifecycle is the same.
Diagram Review
- The first part of the lifecycle is the creation of the AMI. AWS will perform this step for the baseline AMIs. You can perform this step if you want to customize an AMI
- Part of creating the AMI is defining the root volume type. There are two types of root volumes; instance-backed or EBS
- After creating an AMI you need to register it for use. This process is automated when using the AWS Console
- Once registered, you can start launching instances from the AMI, or copy it to create another AMI
Creating an AMI
AWS has provided all of the tools to create custom AMIs. For most customers, creating custom AMIs will become a key part of the sytems and apps they deploy to EC2. AMIs become a key way to speed up the deployment of new systems. They also become a way to backup OS and app combos. AMIs are also a requirement when using other AWS services such as Autoscaling.
It's important to know how to create AMIs. There are different processes to follow depending on what OS and storage type is being used. To help you decide which storage type to use, it's important to understand the difference between EBS and Instance Backed AMIs. Please read the Amazon EC2 Root Device Volume article for more information about this.
Once you understand the different root volume types, you can select one of the following processes to create your AMI:
Creating an Amazon EBS-Backed Linux AMI
Creating an Instance Store-Backed Linux AMI
Creating an Amazon EBS-Backed Windows AMI
Creating an Instance Store-Backed Windows AMI
Key Considerations
If you're designing how an application runs on AWS, how you use AMIs will need additional consideration. Should you always use the baseline AMIs provided by AWS, or customize your own? If you do customize your own, should you include all software and packages, or just some? Here we will review these questions to help you figure out the right solution.
Include in AMI or Bootstrap If you have a server that needs to run a custom application, should you include it in the AMI, or install it after the server starts? The answer will depend on a number of factors. A good way to judge this is to consider how fast the server needs to come online. If you need the server to come online as fast as possible, then you'll want to include as much of the custom software in the AMI.
Automate or Manual AMI Creation You can create AMIs via a manual or automated process. The manual process is the simplest and would be sufficient if the AMI doesn't change much. However, if the AMI changes frequently, perhaps with every software release, then you'll want to look at ways of automating the process. This can be especially useful if you want to tie the AMI creation process into a test and build pipeline.
You can use the AWS CLI tools to automate the process. Or, consider third party tools like Packer.
Community and Marketplace AMIs
There are a large number of free and paid AMIs that are availble to consider. When it comes to these AMIs you need to be cautious. AWS does not vet them. Be sure you know the source of the AMI and that you trust that source before basing your applications on them.