What Is an AMI in AWS? Amazon Machine Images Explained for EC2

AMIs in plain English

You configure one server exactly the way you want: install the OS, apply patches, install your application and monitoring agents. Then you take a snapshot of that entire disk and register it as an AMI. From that point on, you can launch as many identical instances as you need without repeating any of those setup steps.

Concretely: an AMI stores a snapshot of the root EBS volume (the disk the OS runs from), plus metadata about the instance. That metadata includes architecture (x86_64 or arm64), virtualisation type, additional volume mappings, and who is allowed to use the image. When you launch an instance, AWS creates a fresh EBS volume from that snapshot and boots the instance from it. The original snapshot is never modified. Every instance gets its own copy.

Why AMIs matter

Without AMIs, every new EC2 instance would start as a blank OS installation. You would need to install your application, configure dependencies, and set up monitoring manually. That process is slow, error-prone, and does not scale.

AMIs solve this by letting you bake configuration into a reusable image. Launch a hundred instances from the same AMI and they all start identically. This is the foundation of reliable, repeatable deployments in AWS.

AMIs also unlock Auto Scaling Groups. When traffic spikes and AWS adds capacity automatically, it launches new instances from the configured AMI. If that AMI already has your application installed, new instances are healthy and serving traffic in under a minute. If they need to run a long installation script at boot, they join the fleet slowly and can fail mid-installation.

How AMIs work

Understanding the relationship between AMIs, EBS snapshots, and EC2 instances makes the whole system easier to reason about.

1. You create an AMI from a configured EC2 instance. AWS takes a snapshot of the root EBS volume (and any additional volumes in the block device mapping) and registers the result as an AMI with its own ID such as ami-0abc12345def67890.
2. You reference the AMI in a launch request, a Launch Template, or an Auto Scaling Group configuration.
3. At launch time, AWS creates a fresh EBS volume from the AMI’s root snapshot, attaches it as the root device, and boots the instance. The underlying snapshot is never modified. Every new instance gets its own copy.
4. The instance runs independently from the AMI. You can deregister the AMI without affecting running instances, and you can release a new AMI version without touching existing instances.

A few important properties:

• Region-specific: An AMI lives in one region. To use it elsewhere, you must copy it. Copied AMIs get a different ID in the destination region. AMI IDs are never portable across regions.
• Architecture-specific: An AMI built for x86_64 cannot run on Graviton (arm64) instances, and vice versa.
• Block device mapping: An AMI can define multiple volumes, including a root volume and additional data volumes, all created automatically at launch.
• Launch permissions: AMIs are private by default. You can share them with specific AWS accounts or make them public.

What an AMI contains

An AMI is made up of several components:

• A root volume snapshot: A point-in-time EBS snapshot of the OS volume. This is the primary component. It is what gets stamped into a new EBS volume each time you launch an instance.
• Launch permissions: Controls who can use the AMI. Options are public (anyone), private (your account only), or shared with specific AWS account IDs.
• Block device mapping: Specifies what volumes to attach at launch, including the root volume and any additional EBS or instance store volumes, with their sizes and termination behaviour.
• Architecture and virtualisation type: Whether the image is x86_64 or arm64, and whether it uses HVM (hardware virtual machine) virtualisation. Nearly all modern AMIs use HVM.

AMI vs EBS snapshot

AMIs and EBS snapshots are closely related but serve different purposes. An AMI references snapshots. It does not replace them.

If you deregister an AMI, the underlying snapshots are not deleted automatically. You are still billed for snapshot storage until you delete them explicitly. See the cleanup steps in the deregistering section below.

EBS-backed vs instance store AMIs

The root volume type affects how the instance behaves when stopped or terminated.

EBS-backed AMIs (the standard)

The root volume is an EBS volume created fresh from the AMI snapshot at launch time. This means:

• The instance can be stopped and started. The root volume persists.
• You can take snapshots of the root volume at any time.
• Boot time is typically 30–90 seconds.
• The root volume can survive instance termination if DeleteOnTermination is disabled.

EBS-backed AMIs are the right choice for almost every workload.

Instance store AMIs (legacy)

The root volume lives on physical storage directly attached to the host. The instance cannot be stopped; it can only be rebooted or terminated. All data is lost on termination. Instance store root volumes are a legacy feature. Unless you have a specific reason to use them, and you almost certainly do not, use EBS-backed AMIs exclusively.

Public, private, and golden AMIs

AMIs have launch permissions that control who can use them. Teams often create a third category called the golden AMI for internal use.

Public AMIs

AWS and its partners publish thousands of public AMIs: official OS images from Amazon, Canonical (Ubuntu), Red Hat, and SUSE, as well as commercial images from the AWS Marketplace. Any AWS account can launch from a public AMI.

Private AMIs

AMIs you create are private by default. Only your AWS account can use them. You can share a private AMI with specific AWS account IDs, or make it fully public. Sharing by account ID is common in large organisations where a platform team maintains a hardened base image that product teams build on top of.

Golden AMIs

A golden AMI is a private AMI your team builds and maintains as an approved starting point. It typically includes the OS, security patches, monitoring agents, and organisation-wide configuration — except application-specific code. Product teams launch instances from the golden AMI, layer their application on top, and optionally create a more specific AMI for their service.

When to use a custom AMI

Custom AMIs add real value in specific situations:

• Auto Scaling fleets with complex software. If your application takes more than a minute to install and start, pre-bake it into an AMI. New instances join the fleet faster and cannot fail due to installation errors at boot time.
• Consistent environments across dev, staging, and prod. Use the same AMI across all environments to eliminate environment-specific bugs. What you test is exactly what you deploy.
• Multi-region deployments. Copy a single golden AMI to each region you operate in. Every region gets the same verified image rather than a separately built instance.
• Disaster recovery. Pre-copy AMIs to your recovery region so you can launch instances immediately during an outage without rebuilding anything from scratch.
• Image versioning and rollback. When you deploy a new version, build a new AMI and update your Launch Template. Rolling back to the previous version is just a matter of pointing the Launch Template at the old AMI ID.
• Distributing a hardened base image. Platform teams can share a patched, security-configured AMI across all accounts in an AWS Organisation, ensuring every new instance starts from an approved baseline.

When not to create a custom AMI

A custom AMI is not always the right tool:

• Simple, short configuration. If your EC2 user data script takes less than 60 seconds, a custom AMI adds pipeline complexity without meaningful benefit. A plain vendor AMI plus a lightweight bootstrap script is often simpler to maintain.
• Containerised workloads. If you are running containers on ECS or EKS, your application lives in a container image, not an AMI. The EC2 node only needs to run the container runtime. AWS provides managed node AMIs for this.
• Serverless workloads. Lambda, Fargate, and similar services abstract away the instance entirely. There is no AMI to manage.
• Very frequent releases. If you ship multiple times per day and your image build pipeline cannot keep up, reconsider. A hybrid model using a pre-baked base AMI for the OS and runtime layer plus user data for the application layer can be a better fit than rebuilding the entire image on every deploy.

Creating your own AMI

Start with a running or stopped EC2 instance configured the way you want. Launch an instance from a base vendor AMI, install and validate your software, then run:

# Create an AMI from a running instance
aws ec2 create-image \
  --instance-id i-0abc12345def67890 \
  --name "myapp-v1.0-2026-04-01" \
  --description "Application server with Node.js 20 and app v1.0" \
  --no-reboot

The —no-reboot flag skips rebooting the instance before snapshotting. Without it, AWS reboots the instance first to ensure filesystem consistency. For most Linux workloads under light load, —no-reboot is fine. For production golden AMI builds, omit the flag and let AWS reboot. A consistent snapshot is worth the extra few minutes.

Wait for the AMI to reach the available state before using it:

aws ec2 wait image-available --image-ids ami-0abc12345def67890

List all your owned AMIs to confirm creation:

aws ec2 describe-images \
  --owners self \
  --query "Images[*].[ImageId,Name,State,CreationDate]" \
  --output table

AMI creation snapshots the root EBS volume and any additional volumes in the block device mapping. While snapshots are in progress, the AMI state shows as pending. Once all snapshots complete, it moves to available. Larger volumes take longer. A few minutes is typical.

For automated golden AMI builds, HashiCorp Packer is a popular choice. You define the build in a configuration file. Packer launches an instance, runs your provisioning steps, and creates the AMI automatically. This slots naturally into a CI/CD pipeline alongside the Launch Templates that reference the resulting AMI.

Golden AMI vs user data scripts

Both golden AMIs and EC2 user data scripts configure EC2 instances, but they operate at different points in the lifecycle and suit different needs.

Copying, sharing, and deregistering AMIs

Copying to another region

To use an AMI in a different region for multi-region deployments or disaster recovery, copy it explicitly:

aws ec2 copy-image \
  --source-region us-east-1 \
  --source-image-id ami-0abc12345def67890 \
  --region eu-west-1 \
  --name "myapp-v1.0-eu-copy"

The copy process duplicates the underlying snapshots into the destination region. You will be billed for snapshot storage in both regions until you clean up old copies.

Sharing with another AWS account

To share a private AMI with a specific account without making it public:

aws ec2 modify-image-attribute \
  --image-id ami-0abc12345def67890 \
  --launch-permission "Add=[{UserId=123456789012}]"

Deregistering and cleaning up

When you no longer need an AMI, clean it up in three steps. Retrieve the snapshot IDs first. After deregistering, that association is gone.

# Step 1: Get the snapshot IDs from the AMI's block device mapping
SNAPSHOT_IDS=$(aws ec2 describe-images \
  --image-ids ami-0abc12345def67890 \
  --query "Images[0].BlockDeviceMappings[*].Ebs.SnapshotId" \
  --output text)

# Step 2: Deregister the AMI
aws ec2 deregister-image --image-id ami-0abc12345def67890

# Step 3: Delete the associated snapshots
for SNAPSHOT_ID in $SNAPSHOT_IDS; do
  aws ec2 delete-snapshot --snapshot-id "$SNAPSHOT_ID"
done