AMI
Amazon Machine Image. A pre-built template containing the OS, installed software, and configuration used to launch EC2 instances. Custom AMIs with your app pre-installed reduce boot time from minutes to seconds.
An AMI (Amazon Machine Image) is the template every EC2 instance starts from. It contains the operating system, pre-installed software, configuration, and attached EBS snapshot references. When you launch an EC2, AWS copies the AMI onto a fresh EBS volume and boots from it.
Three Types of AMI
AWS-provided: Amazon Linux 2023, Ubuntu 22.04, Windows Server — maintained by AWS Default usernames: Amazon Linux → ec2-user, Ubuntu → ubuntu, Windows → AdministratorMarketplace: Vendor-built with software pre-installed — WordPress, LAMP stack, firewalls Some are free, some have additional licensing feesCustom: You build from a running instance — your app already installed and configured The most valuable type for production Auto Scaling GroupsAMI and EBS Snapshots
Creating a custom AMI involves two things you must understand:
You click "Create Image" on a running EC2 instance ↓AWS snapshots every attached EBS volume automatically ↓AMI stores references to those snapshots (not the data itself) ↓Launch from AMI → AWS creates fresh EBS volumes from those snapshotsNew EC2 has identical disk state to the source instanceWhy Custom AMIs Matter for Auto Scaling
This is the highest-impact optimisation for any Auto Scaling Group:
Base Amazon Linux + User Data script: Boot → apt install → npm install → build app → start server Time before instance can serve traffic: 8-10 minutes ASG cooldown must be at least 8-10 minutes → slow, over-provisions during spikes Custom AMI with app pre-installed: Boot → app already there → start server Time before instance can serve traffic: 60-90 seconds ASG cooldown can be 90 seconds → reacts fast, scales preciselyCross-Region Copy
AMIs are region-specific. To use an AMI in another region:
EC2 → AMIs → select AMI → Actions → Copy AMI → select target regionAWS copies all underlying EBS snapshots to the target regionNew AMI ID is assigned in the target regionSharing AMIs
AMIs can be made public (shared with all AWS accounts)AMIs can be shared with specific AWS accounts by account IDEncrypted AMIs can only be shared if you also share the KMS keySecurityDeleting an AMI does NOT automatically delete its underlying EBS snapshots. Snapshots remain and continue billing you. Always check for and delete orphaned snapshots after deregistering an AMI.
TipWhen building a custom AMI, install and configure everything, run the app once to verify it works, then create the image. Test the AMI by launching a new instance from it before using it in your Auto Scaling Group Launch Template.
Frequently Asked Questions
Why bake a custom AMI instead of just running a startup script on a stock image?
A stock Amazon Linux or Ubuntu AMI plus a bootstrap script (installing packages, pulling your app, configuring services) can take minutes to become ready, during which the instance is unhealthy and unable to serve traffic. A custom AMI has all of that already baked in at the disk-image level, so an instance launched from it can pass health checks in seconds — critical for Auto Scaling Groups reacting to a traffic spike.
What's the tradeoff of baking custom AMIs versus using user-data scripts?
You gain fast, consistent boots but lose flexibility — every AMI update means rebuilding and re-testing the image, then rolling it out via a new launch template version, which is slower than editing a script. Common pattern: bake AMIs with tools like Packer as part of your CI pipeline so image builds are automated and versioned, rather than hand-crafting AMIs and losing track of what's actually inside one.