Amazon Machine Image (AMI): What It Is and How It Works

Definition

An Amazon Machine Image (AMI) is the master template AWS uses to launch an Amazon EC2 instance. An AMI bundles an operating system, a root filesystem, preinstalled software and libraries, default configuration, and metadata that tells EC2 how to boot the image. Whenever you start an instance — directly, via an Auto Scaling Group, or through Elastic Beanstalk — EC2 copies the AMI's root volume into your account, attaches it to a new VM, and boots the OS. AMIs are regional resources: an AMI in us-east-1 cannot be used to launch an instance in eu-west-1 without first being copied across regions.

How It Works

An AMI is, at its core, a pointer to one or more EBS snapshots (or, in the legacy case, an S3-backed image manifest) plus a block-device mapping and a small set of launch-time attributes:

• Root device type — ebs or instance-store. Nearly all modern AMIs are EBS-backed.
• Architecture — x86_64, arm64 (for Graviton instances), or x86_64_mac for EC2 Mac.
• Virtualization type — only hvm is supported on current-generation instances; paravirtual is retired.
• Boot mode — legacy-bios, uefi, or uefi-preferred. UEFI unlocks Secure Boot and NitroTPM.
• ENA / SR-IOV flags — declare enhanced networking support.
• Block-device mapping — defines the root volume and any additional EBS volumes that should be attached at launch.
• Product codes and license info — marketplace AMIs carry a product code that triggers licensing meters.

When you register a new AMI from a running instance, EC2 takes an EBS snapshot of each attached volume and then records an AMI manifest that points at those snapshots. Launching from that AMI reverses the process: EBS provisions new volumes hydrated from the snapshots, and the Nitro hypervisor boots the instance against them.

Key Features and Limits

• AMI types: EBS-backed (root volume is EBS; supports stop/start, snapshot-based backups, and root-volume resizing) vs instance-store-backed (root is ephemeral; instance cannot be stopped, only terminated). EBS-backed is the default for essentially every modern workload.
• Architectures: x86_64 and arm64. You must match the AMI architecture to the instance family — a Graviton m7g cannot launch an x86_64 AMI.
• Sharing models: AMIs are private by default. You can share an AMI with specific AWS account IDs, with an AWS Organizations OU or the entire organization, or make it public for anyone to launch. Public AMIs are moderated by AWS Marketplace rules and the Public AMI Block setting at the account level.
• Cross-region copy: CopyImage duplicates the AMI and its snapshots into another region, optionally re-encrypting with a different KMS key.
• Encryption: AMI snapshots may be encrypted with AWS managed or customer-managed KMS keys. An unencrypted AMI can be copied into an encrypted one for compliance.
• Deprecation and deregistration: EnableImageDeprecation marks an AMI as deprecated on a date — it stays launchable for the owner but is hidden from Quick Start and non-owners. DeregisterImage removes it entirely. Snapshots survive deregistration and must be cleaned up separately.
• AMI quotas: default 5,000 AMIs per region per account and 10,000 snapshots per region (raise via Service Quotas).
• IMDSv2 default: AMIs can declare IMDSv2-only; AWS increasingly requires it for new AWS-published AMIs.

Common Use Cases

1. Golden images for compliant fleets — bake hardening, CIS benchmarks, and agents (CloudWatch, SSM, EDR) into an AMI so every instance starts compliant.
2. Auto Scaling Group launches — the Launch Template references an AMI ID; immutable deployments replace the AMI ID and roll fleets with Instance Refresh.
3. Disaster recovery — cross-region AMI copies let you rebuild a workload in a DR region in minutes.
4. Blue/green and canary releases — promote a new AMI behind a target group and shift traffic progressively.
5. Marketplace products — ISVs publish AMIs with metered or hourly licensing, delivering preconfigured appliances like firewalls or databases.
6. Reproducible dev/test environments — developers launch identical sandbox instances on demand from a shared AMI.

Pricing Model

AMIs themselves are free to store — you pay only for the EBS snapshots that back them (per-GB-month of snapshot storage, tiered between standard and Archive tier) and any data transfer incurred when copying an AMI to another region or account. Cross-region copies also incur inter-region data-transfer charges for the snapshot bytes. Marketplace AMIs may carry an hourly software fee layered on top of the underlying EC2 instance price.

EC2 Image Builder, the managed pipeline that automates AMI creation, is free to use — you pay only for the EC2 build instances, EBS volumes, and S3/Inspector resources consumed during a build.

Pros and Cons

Pros

• Identical, repeatable launches — every instance boots from the same bit-for-bit root volume.
• Fast startup vs configuration-at-boot — a fully baked AMI can be launch-ready in under a minute.
• Deep integration with Auto Scaling, Image Builder, Inspector, and Marketplace.
• Cross-account and cross-region sharing supports enterprise governance and DR.

Cons

• AMIs are immutable — any change requires baking and rolling a new image.
• Regional scope adds operational overhead for multi-region architectures.
• Lingering snapshots after deregistration silently accrue cost.
• Keeping AMIs patched across an estate requires a pipeline (Image Builder or custom Packer jobs).

Comparison with Alternatives

| | AMI | Container Image | Configuration at Boot (user data / Ansible) | | --- | --- | --- | --- | | Unit | Full OS + disk | App + minimal OS layers | Base AMI + runtime config | | Startup | Seconds | Seconds | Minutes (package installs at boot) | | Portability | AWS-only | Any container runtime | Any VM | | Patching | Rebake AMI | Rebuild image | Run config management | | Best for | EC2 fleets, golden images, DR | ECS/EKS/Fargate/App Runner | Flexible but slower fleets |

Container images (ECR) serve the same "baked artifact" role in ECS/EKS/Fargate that AMIs do for EC2. Inside EKS, you can still pin a worker-node AMI (Amazon EKS optimized AMI, Bottlerocket) to control the host OS.

Exam Relevance

• Solutions Architect Associate (SAA-C03) — know that AMIs are regional, must be copied for cross-region launches, and that the AMI architecture must match the instance family (x86 vs arm64).
• Developer Associate (DVA-C02) — how User Data works in concert with an AMI, and how to bake vs bootstrap.
• SysOps Administrator (SOA-C02) — EC2 Image Builder pipelines, AMI deprecation, snapshot lifecycle with AWS Backup and DLM.
• DevOps Professional (DOP-C02) — immutable-infrastructure patterns, golden-AMI pipelines, AMI sharing across accounts in an Organization, cross-account KMS encryption of AMI snapshots.

Common exam trap: deregistering an AMI does not delete the underlying EBS snapshots — those linger and keep billing you until explicitly deleted, unless you set up AWS Backup or Data Lifecycle Manager retention.

Frequently Asked Questions

Q: What is the difference between an EBS-backed AMI and an instance-store-backed AMI?

A: An EBS-backed AMI stores the root volume as an EBS snapshot, so instances launched from it can be stopped, started, and have their root volume resized or snapshotted. An instance-store-backed AMI keeps the root volume on ephemeral local disk, so instances can only be terminated — they cannot be stopped, and all root-volume data is lost on shutdown or hardware failure. Essentially every modern AMI is EBS-backed; instance-store-backed AMIs persist for legacy and specialized workloads only.

Q: Can I use the same AMI in another AWS region?

A: Not directly. AMIs are regional resources. You use CopyImage (console or CLI) to copy the AMI and its underlying snapshots into the target region, optionally re-encrypting with a KMS key in that region. The copy gets a new AMI ID; you must update Launch Templates, Auto Scaling Groups, and CloudFormation stacks in the target region to reference it.

Q: How do I keep my AMIs patched without manual rebuilds?

A: Use EC2 Image Builder, which gives you a managed pipeline that pulls a base image, applies AWS-managed or custom build components (package updates, agents, hardening), tests the result, and publishes a new AMI on a schedule. Combine it with AWS Systems Manager Parameter Store or EventBridge to automatically roll Auto Scaling Groups via Instance Refresh when a fresh AMI is published.

---

This article reflects AWS features and pricing as of 2026. AWS services evolve rapidly — always verify against the official Amazon EC2 AMI documentation before making production decisions.