Handcrafted AMIsThis is the most straightforward option and may be a good starting point. Start a generic AMI, install your code, and configure it. Once it is working, create an AMI from the working instance, and use that AMI as your base image for the instances in your auto scale group. This is a reasonable option if you deploy new application code relatively infrequently.
AMI bakeryIf your code deployments happen too frequently for that to be practical, or better yet, you have a continuous delivery philosophy, you can still take the same approach of using customized AMIs, but you can create the AMIs using automation. There are a number of tools available that can help you automate AMI creation, including Ansible (https://www.ansible.com), Aminator (https://github.com/aminator), Chef (https://www.chef.io), and AWS Opsworks (https://aws.amazon.com/opsworks). All of these offer offer methods for creating AMIs in a continuous integration environment.
BootstrappingBuilding AMIs has some advantages, including potentially being up and running faster during an auto scaling event; however, there are downsides as well. Managing a large inventory of AMIs can become challenging since it can be difficult to keep track what is in each one. The alternative to custom AMIs is to bootstrap a basic AMI with the desired code at provisioning time. Some tools and options for bootstrapping are as follows:
SaltSalt (http://saltstack.com) began its life as an approach for fast remote execution of multiple commands, but it developed into a great configuration management tool that can be used to deploy the same code to many different servers at the same time. Note, too, that Salt now offers other capabilities such as Salt-cloud that orchestrates the provisioning and management of EC2 instances.
ChefChef (https://www.chef.io) has the same kinds of capabilities and has a longer track record. It uses scripts known as cookbooks written in Ruby to specify configurations. It also offers automated testing and continuous integration/continuous delivery tools, including a workflow pipeline. The tools promote the infrastructure-as-code approach, which ensures reproducibility.
AnsibleAnsible (https://www.ansible.com) also does the same kinds of things using a slightly different approach. Ansible has an agent-less design, so there is no drain on system resources, and the configuration and usage can be simpler.
Packer is an open-source automation tool for creating repeatable machine images, e.g. AMIs, from source code. It can use Chef, Puppet, Ansible, Salt, or shell scripts to customize the AMI with your software. Since it’s a command line tool, you can use Packer in a CI/CD pipeline to automatically create custom AMIs for each successful build of your application.