AMIs: Machine Images and Their Lifecycle

An Amazon Machine Image (AMI) is the template EC2 uses to build an instance. It holds the operating system and any software you baked in, plus the settings for the instance's disks. Every EC2 launch needs an AMI, so AMIs decide how fast new servers start and how alike they are. This note covers what is inside an AMI, its lifecycle, the two root-device types, and how teams use custom images.

Template vs instance#

An AMI and an instance relate the way a class and an object do. The AMI is the read-only blueprint; each instance is a running copy built from it.

• One AMI, many instances. Every instance you launch from the same AMI starts with the same OS, packages and config. This is what makes scaling out and replacing failed servers predictable.
• The instance owns its disk. At launch, EC2 creates a new root volume for the instance from the AMI. Changes you make on the instance do not flow back into the AMI.
• You cannot attach an AMI to a running instance. To change an instance's base image, launch a new instance from a new AMI.
• Deleting the source instance does not affect the AMI. The AMI has its own copy of the data.

Before you build your own, know where ready-made ones come from. You can get AMIs from AWS (for example Amazon Linux or Ubuntu), from AWS Marketplace, from other accounts that share them, or build your own.

What an AMI contains#

Now look inside the blueprint. An AMI has three parts.

Block device mapping#

The third part is the one you'll touch most often. The block device mapping describes every disk the instance gets at launch.

• Root volume: the boot disk, for example /dev/xvda. For an EBS-backed AMI it is created from the AMI's root snapshot.
• Extra data volumes: optional. They can come from snapshots in the AMI or be added when you launch.
• Delete on termination: decides whether a volume is deleted with the instance. The root volume is deleted by default; volumes you attach after launch are kept by default.

You can override parts of the mapping at launch, for example to make the root volume bigger. Volume types and performance belong to EBS and are covered in the storage notes.

The AMI lifecycle#

Knowing what an AMI holds, you can follow one from build to cleanup. It moves through six stages.

1. Create. Build an image from a configured instance, or import one from a VM image.
2. Register. EC2 records the AMI's metadata (architecture, root device, block device mapping) and gives it an ID such as ami-0abc1234def567890. Creating from an instance registers it in the same step.
3. Launch. Start any number of instances from the AMI.
4. Copy. Copy the AMI to another Region or account. AMIs are regional, so a copy is how you launch the same image elsewhere.
5. Deregister. Retire the AMI so nobody can launch new instances from it. Running instances keep running.
6. Delete snapshots. Deregistering does not delete the backing EBS snapshots. Delete them yourself, or you keep paying for them.

How creation works#

Step 1 of the lifecycle hides most of the detail. When you create an AMI from an EBS-backed instance, no helper instance is involved. EC2 works on the instance's own volumes:

1. By default, EC2 shuts down and reboots the instance so the file system is consistent on disk.
2. EC2 takes an EBS snapshot of each attached EBS volume.
3. EC2 registers the AMI with a block device mapping that points to those snapshots.

The snapshots are stored durably by AWS, not in an S3 bucket you can see. You can pass a no-reboot option to avoid the restart, but EC2 then cannot guarantee a consistent file system. Use it only if you stop writes yourself. You can also create an AMI from a stopped instance, which is consistent by default.

Instance store volumes are never part of an AMI built this way. Their data is not captured.

The commands below map to the lifecycle stages: create, copy to another Region, deregister, then delete the leftover snapshot.

# Create, copy and retire an AMI with the AWS CLI.
aws ec2 create-image --instance-id i-0123456789abcdef0 \
  --name "web-2026-10-18" --description "nginx + app v42"

aws ec2 copy-image --source-region us-east-1 \
  --source-image-id ami-0abc1234def567890 \
  --region us-west-2 --name "web-2026-10-18"

aws ec2 deregister-image --image-id ami-0abc1234def567890
aws ec2 delete-snapshot --snapshot-id snap-0fedcba9876543210

Copying across Regions#

A copy creates a new AMI with a new ID in the target Region, backed by new snapshots there. You can encrypt the snapshots during the copy. Launch permissions do not come along, so share the copy again if other accounts need it.

Updating an image#

Since nothing in the lifecycle edits an image in place, updates follow their own loop. An AMI is immutable: you can edit its description, launch permissions and tags, but not the disk contents. To update the software:

1. Launch an instance from the current AMI.
2. Patch it or deploy the new version.
3. Create a new AMI with a versioned name, for example web-2026-10-18.
4. Point your launch template at the new AMI and roll the fleet.
5. Deregister old versions and delete their snapshots when nothing uses them.

EBS-backed vs instance-store-backed AMIs#

Everything so far assumed an EBS-backed AMI. That's the root device type, and it decides where the root disk lives and what survives a stop. Almost all modern AMIs are EBS-backed; instance-store-backed AMIs are a legacy option.

With an EBS-backed instance, you can stop the instance, change its type and start it again with the same disk. EBS volumes live in one Availability Zone and can move between instances in that zone.

Golden images and other custom AMIs#

With the mechanics covered, here's how teams put AMIs to work. A custom AMI with your software pre-installed is often called a golden image. Teams build them in a pipeline with tools such as EC2 Image Builder or HashiCorp Packer.

Bake vs bootstrap#

Every golden image raises one design question: what goes in the image and what gets installed later. You can put software into the image (bake) or install it at boot with a user data script (bootstrap).

• Bake gives fast, repeatable boots, but every change needs a new image.
• Bootstrap keeps one generic image, but boots are slower and depend on package mirrors being up.

Most teams bake the slow, stable parts (OS patches, runtimes, agents) and bootstrap the small, changing parts (config, secrets fetched at runtime). See Instance Metadata and User Data for the bootstrap side.

Pitfalls#

Most AMI problems come from cost, leaks and Region scope.

• Orphaned snapshots keep costing money after you deregister an AMI.
• Secrets baked into an image spread to every instance and every account you share it with. Fetch secrets at runtime.
• Public AMIs expose everything on the disk. Check launch permissions before sharing.
• Region mismatch: an AMI ID only works in its own Region. Copy the AMI first.
• No-reboot images can capture a half-written file system.

Key takeaways#

• An AMI is the read-only template; an instance gets its own root volume built from it.
• An AMI has three parts: root volume template, launch permissions and block device mapping.
• EBS-backed AMIs are backed by EBS snapshots. Creating one reboots the source instance by default and uses no temporary instance.
• AMIs are regional and immutable; copy them across Regions and version them for updates.
• Deregistering stops new launches only. Delete the snapshots yourself.
• Golden images give consistent, fast-booting fleets; bake the stable parts and bootstrap the rest.