A deployment script that launches EC2 instances hardcodes an AMI ID. It works in us-east-1 and fails in eu-west-1 with InvalidAMIID.NotFound. Why, and what is an AMI actually made of?
answer
- the ID is regional, not global
- same image, different ami- id per region
- a manifest over EBS snapshots
- CopyImage mints a brand-new ID
- resolve it, do not hardcode it
basics
~20 sAMI IDs are scoped to a single AWS region, so an ID registered in us-east-1 does not exist in eu-west-1. Copy the image with CopyImage, which mints a new ID, or look the ID up per region instead of hardcoding it.
solid answer
~50 sAn AMI is not a portable file — it is a registration record inside one region. It holds a block device mapping pointing at EBS snapshots in that region, plus launch metadata: architecture, root device name, boot mode, ENA/NVMe support and any billing product codes. Because the snapshots it references are regional objects, the `ami-` ID is meaningful only in the region where it was registered, which is exactly why the second region answers `InvalidAMIID.NotFound`. The fix is one of two things. Either run `CopyImage` into the target region, which copies the snapshots and registers a **new** AMI with a **different** ID, or stop hardcoding IDs: resolve them at deploy time from a public SSM Parameter Store parameter for Amazon-published images, or from `DescribeImages` filtered by owner and name pattern for your own. Even AWS's own Amazon Linux AMI has a different ID in every region.
code
bash · 10 linesaws ec2 copy-image \
--source-region us-east-1 \
--source-image-id ami-0123456789abcdef0 \
--region eu-west-1 \
--name app-base-2025-06
aws ssm get-parameter \
--region eu-west-1 \
--name /aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64 \
--query Parameter.Value --output textgo deeper
Know that an AMI ID belongs to one region and that the same operating system image has a different ID in each one. Say plainly that you look the ID up for the region you are deploying to.
Be ready to explain that an AMI is a manifest of EBS snapshots plus launch metadata, that CopyImage produces a new ID, and how you resolve IDs at deploy time from SSM parameters or DescribeImages filters.
Show you have operated this: deregistered AMIs breaking Auto Scaling replacements, orphaned snapshots still billing, encrypted copies needing a destination-region KMS key, and a bake pipeline that publishes a per-region ID map.
Own the policy question — whether images resolve to latest automatically or pin per release, how long old AMIs stay registered, who may deregister, and how image identity is tracked so an incident can be traced back to a specific build.
## What an AMI actually is An Amazon Machine Image is not a file you download and move around. It is a **registration record** held by EC2 in one region. That record contains: - a **block device mapping** naming the root device (`/dev/xvda` on most Linux AMIs) and pointing at one or more **EBS snapshots**, plus volume size, type and the `DeleteOnTermination` default for each device; - **launch metadata**: architecture (`x86_64` or `arm64`), virtualization type, boot mode (legacy BIOS or UEFI), ENA and NVMe support flags; - ownership and permissions: the owner account, and the launch permissions that decide who else may use it; - optionally **billing product codes**, for Marketplace or licensed images. At launch time EC2 creates brand-new EBS volumes from those snapshots and attaches them to the instance. Nothing is "copied out of" the AMI in the sense of a disk image being transferred. ## Why the ID is regional Regions are deliberately independent failure domains. EBS snapshots live in a region; the manifest that references them is registered in the same region. So `ami-0123456789abcdef0` is a key into one region's catalogue and simply has no meaning in another — hence the `InvalidAMIID.NotFound` error, which is EC2 saying "no such row here", not "you lack permission". This is true for public images too. Amazon Linux, Ubuntu and Windows base AMIs all carry a different ID in every region, which is why an AMI ID copied out of a tutorial or another team's config so often fails. ## Getting an image into a second region `CopyImage` (`aws ec2 copy-image --source-region ... --source-image-id ...`) copies the underlying snapshots and registers a new AMI in the destination. Points that matter: - the result has a **new ID**; nothing about the original ID survives the trip; - the copy is asynchronous — the new image sits in `pending` while snapshot data moves, and only then becomes `available`; - encryption is re-done in the destination. KMS keys are also regional, so an encrypted copy needs `--encrypted` and a key that exists in the target region; - images carrying billing product codes (many Marketplace images) cannot be copied out. ## Stop hardcoding the ID The durable fix is resolution at deploy time: - **Amazon-published images** are advertised through public SSM Parameter Store parameters — for example the Amazon Linux 2023 parameters under `/aws/service/ami-amazon-linux-latest/`. Reading the parameter in the region you are deploying to always yields that region's current ID. - **Your own images** can be found with `DescribeImages` filtered by `owner-id` and a `name` pattern such as `app-base-*`, then sorted by `CreationDate` to take the newest. - If you must pin, pin a **per-region map** of IDs produced by your bake process, not one ID reused everywhere. Resolving "latest" automatically has a cost of its own: instances launched a week apart can differ. Many teams resolve the ID once per release, record it, and pin that value for the release's lifetime — reproducible, and still region-aware. ## Retiring an AMI Two separate mechanisms, often confused: - **Deprecation** (`EnableImageDeprecation` with a `deprecate-at` date) marks an AMI as old. After that date it stops appearing in default `DescribeImages` results for other accounts, but it still launches. It is a nudge, not a block. - **Deregistration** (`DeregisterImage`) removes the registration outright. Running instances are untouched, but every future launch fails. Deregistering does **not** delete the backing snapshots — they keep billing until you delete them yourself. The classic 3 a.m. incident is a deregistered AMI: everything looks healthy until an Auto Scaling group tries to replace an instance and cannot launch a single one. Guard against it by keeping old AMIs registered until nothing references them, and by using deregistration protection on images you cannot afford to lose. ## What to say in an interview Lead with the region scoping, then show you know an AMI is a manifest over snapshots rather than a blob — that is the detail that explains *why* the ID cannot travel, and it sets up the encryption and copy behaviour that follows.
- What changes when the AMI you are copying to another region is encrypted?KMS keys are regional too, so the copy cannot reuse the source key. `CopyImage` re-encrypts in the destination: you pass `--encrypted` and a `--kms-key-id` that exists there, and the caller needs permission on both the source and destination keys. Skipping the key argument falls back to the destination's default EBS encryption key, which may not be the one your policies expect.
- An AMI that instances were launched from gets deregistered. What actually breaks?Already-running instances keep running — they use volumes, not the AMI. What breaks is every future launch: manual runs, and crucially Auto Scaling replacements, which start failing silently until capacity drops. Deregistration also leaves the backing snapshots in place and still billing, so it is neither a clean delete nor a safe cleanup step.
- How do you steer teams off an old AMI without breaking them overnight?Use image deprecation: set a `deprecate-at` date so the AMI drops out of default `DescribeImages` listings for consumers while remaining fully launchable. New lookups naturally find the newer image, existing pipelines keep working, and you deregister only once telemetry shows nothing launches from it any more.
saying these in an interview costs you the question
- Saying AMI IDs are global and work in any region
- Believing a copied AMI keeps the same ami- ID
- Describing an AMI as a downloadable disk image file
- Thinking deregistering an AMI terminates instances launched from it
- Assuming deregistering an AMI also deletes its snapshots and stops the cost