When to Use Custom AMI vs. Standard AMI
Earlier this week, I had a meeting with a client in regards to custom Amazon Machine Images (AMIs) vs. standard AMIs. They indicated that an article they had read about this topic told them never to use custom AMI. I hope to provide some insight as to when a custom AMI would be appropriate.
First, we need to understand the difference between a standard AMI and a custom AMI. It’s important to note that no matter what method you choose, it will not automatically get patched for you. You’re still responsible for the patch levels and any maintenance. If you’re not familiar, update yourself with the AWS Shared Responsibility model before reading onward.
What is a Standard Amazon Machine Image (AMI)?
A standard AMI is provided to you by the vendor (Amazon for Amazon Linux, Canonical for Ubuntu, CentOS for CentOS, Microsoft for Windows, and so forth).
What is a Custom AMI?
A custom Amazon Machine Image is one that you create and manage yourself.
Using Standard AMI
Standard AMIs are useful if you have a small codebase and are not too worried about patch levels. Standard AMIs give you the ability to forget about maintaining an updated AMI yourself with the latest patches. You can rebuild your environment with the new AMI that was released that quarter with the most recent security patches and you’re off to the races. The only thing you’re responsible for is having your environment rebuild with the newest AMIs. One suggestion, when rebuilding your environment, start with only a small percentage of the environment to avoid bringing your application offline or create a new cluster and point your DNS to the new load balancer.
Benefits of using a standard AMI
- Don’t worry about applying patches to your AMIs, as the most recent AMIs will contain the latest patches
- Don’t worry about updating the AMIs with your application code when it changes. Your process for deployment should include fetching the latest code from your repository.
- Shorter time to automate this process than automating a custom AMI
- Easier to update new instances going forward with user data (bootstrapping)
Cons of using a standard AMI
- Longer boot to application-ready. Your instance has to fetch all of your third-party tools, your application, deploy them, and configure them before the instance can be utilized to serve content.
- Patches likely aren’t vetted by you or your team. Therefore you can’t accurately fend off compliance problems or check those boxes.
Using AWS Elastic Beanstalk Custom AMIs
Custom AMIs are useful if you have a rather large codebase and are worried about the patches that get applied for either code reliability or compliance. Custom AMIs require more work, but you know exactly what happens to the AMI and what patches get applied.
What is AWS Elastic Beanstalk?
AWS Elastic Beanstalk is a service for deploying and scaling web applications and services on common web platforms. To use it, you create an application, upload it, and then provide information about it. Elastic Beanstalk launches an environment automatically and creates/configures the resources needed.
Benefits of using a custom AMI
- You understand what patch levels are being used – this can help with both code reliability and help solve compliance problems
- You can pre-stage your codebase on your servers if your code doesn’t change often
- You can pre-stage other applications such as NewRelic, Splunk, or other customer monitoring agents on the systems and not have to worry about configuration later
- Decreased time from boot to application-ready. Your code is already on the instance and doesn’t have to be fetched, so when the new instance boots up, it should be ready to serve application requests.
- Easily copy your AMI from one region to another for backups
Cons of using a custom AMI
- Creating and maintaining your own AMI deployment process
- If the creation process for the AMI isn’t automated, time has to be dedicated to an individual to update the AMI for each application
- When new code is released, the AMI must be updated to reflect the new code
- The creating and maintaining process development can be costly and timely to establish at first
If you decide to go the custom AMI route, there are many ways you can automate the process. One method we like to use at CorpInfo is Jenkins and Packer. Jenkins allows us to create custom AMIs with Packer at scheduled intervals, or ad-hoc. With proper Jenkins configuration, plugins and scripts, you can have Jenkins and Packer working in tandem with each other to create a newly updated AMI. You would use Jenkins to assume a role via STS, start up Packer, and start deploying the new EC2 instance that will later become your new AMI. Within Packer, you would designate how to fetch your code base from your code repository and to update the OS packages.
Want to learn more about automation?
Read our CI/CD on AWS whitepaper to learn how DevOps teams leverage automation to quickly build, test, and deploy apps.
Need Help with DevOps?
We are an AWS Premier Consulting Partner. We specialize in guiding our customers with DevOps challenges on their journey into the cloud. Our goal is to increase automation and decrease the 20th century approach to technology thinking. We strive to give you continual measurements for achievement, on demand demonstrations, and milestones for approvals and rejections. We want to help your teams’ talent break through by automating your workloads, because we know that downtime and repetition cost organizations money. Contact us to learn more and speak with one of our DevOps consultants.
