Amazon Machine Images (AMIs)

An Amazon Machine Image (AMI) is the template that an EC2 instance (a virtual server you rent in the cloud) is built from when it launches. Think of it as a “master copy” of a disk: it bundles an operating system (OS, the base software like Linux or Windows), any preinstalled software, and the configuration settings the instance starts with. Every time you launch an instance, you must pick exactly one AMI — it decides what the instance “is” the moment it boots. Choosing the right AMI saves you from reinstalling and reconfiguring software by hand on every new server.

What an AMI actually contains

An AMI is more than just an OS disk image. It packages three things together:

A root volume template — a snapshot of the boot disk, including the OS and any software baked in (for example a web server like NGINX, or your own application code).
Launch permissions — who is allowed to use the AMI (just you, specific AWS accounts, or everyone).
Block device mappings — a description of which storage volumes (the virtual hard drives, called EBS volumes) get attached when the instance launches.

When you launch from an AMI, AWS copies the root volume snapshot onto a fresh disk for your new instance. Two instances launched from the same AMI start out identical, then drift apart as you use them.

Where AMIs come from

There are four sources of AMIs, and knowing which to trust matters for both security and reliability.

Source	What it is	When to use it
AWS-provided	Official base images, like Amazon Linux 2023, Ubuntu, or Windows Server.	Almost always your starting point. Patched, supported, and free (you pay only for the instance).
AWS Marketplace	Commercial images from verified vendors (e.g. a hardened database or a firewall appliance).	When you need pre-packaged commercial software. May carry an hourly software fee on top of the instance cost.
Community	Images shared publicly by anyone with an AWS account.	Rarely, and only with caution. Useful for niche or experimental setups.
Your own (custom)	Images you create from an instance you configured.	When you want a repeatable, pre-baked image of your app for fast, identical launches. See Create a custom AMI.

Security gotcha: Community AMIs can contain malware, backdoors, hard-coded SSH keys, or hidden crypto-miners. Anyone can publish one. Prefer official AWS images or trusted Marketplace vendors. If you must use a community AMI, inspect it on an isolated instance first and never run it with production credentials attached.

Finding an AMI ID

Every AMI has a unique ID that looks like ami-0abcdef1234567890. You need this ID to launch an instance from the CLI or in automation. There are two common ways to find it.

Console steps

Sign in to the AWS Management Console and open the EC2 service.
In the left sidebar, choose Images then AMIs.
Use the filter dropdown at the top to switch between Owned by me, Public images, and Private images.
To browse official images instead, start the Launch instance wizard and look at the Application and OS Images (Amazon Machine Image) panel, which lists AWS, Marketplace, and community options with search.
Copy the AMI ID column value for the image you want.

CLI: search official AWS images

The reliable, scriptable way is to query the AWS Systems Manager (SSM) Parameter Store, where AWS publishes the latest AMI IDs by name. This always returns the newest patched image for a Region.

aws ssm get-parameters \
  --names /aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64 \
  --region us-east-1 \
  --query 'Parameters[0].Value' \
  --output text

Output:

ami-0abcdef1234567890

You can also search the EC2 image catalog directly with filters:

aws ec2 describe-images \
  --owners amazon \
  --filters "Name=name,Values=al2023-ami-2023.*-x86_64" "Name=state,Values=available" \
  --query 'reverse(sort_by(Images, &CreationDate))[:1].[ImageId,Name,CreationDate]' \
  --output table \
  --region us-east-1

Output:

-------------------------------------------------------------------------------
|                              DescribeImages                                 |
+-----------------------+-------------------------------+---------------------+
|  ami-0abcdef1234567890 |  al2023-ami-2023.5.x-x86_64  |  2026-05-30T08:14:00.000Z |
+-----------------------+-------------------------------+---------------------+

Using the SSM parameter (the first method) is best for automation because the name never changes even when AWS releases a newer image. Hard-coding a specific ami-... ID locks you to an unpatched image over time.

Gotcha: AMIs are Region-specific

This is the trap that catches almost everyone. An AMI ID is only valid in the AWS Region it lives in. The same Amazon Linux 2023 image has a different ID in us-east-1 than in eu-west-1. If you copy a launch command from a colleague in another Region, it will fail with an error like InvalidAMIID.NotFound.

When to worry about this: any time you deploy the same workload across multiple Regions (for example for disaster recovery or lower latency), or when you reuse Terraform/CloudFormation templates across Regions. The fix is to look up the AMI ID per Region instead of hard-coding one.

In CloudFormation, use an SSM parameter type so the right ID is resolved automatically in each Region:

Parameters:
  LatestAmiId:
    Type: AWS::SSM::Parameter::Value<AWS::EC2::Image::Id>
    Default: /aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64

Resources:
  WebServer:
    Type: AWS::EC2::Instance
    Properties:
      ImageId: !Ref LatestAmiId
      InstanceType: t3.micro

To move your own custom AMI to another Region, copy it explicitly. The copy gets a new ID in the destination Region:

aws ec2 copy-image \
  --source-region us-east-1 \
  --source-image-id ami-0abcdef1234567890 \
  --region eu-west-1 \
  --name "my-app-image-eu"

Output:

{
    "ImageId": "ami-0fedcba9876543210"
}

Cost note: AMIs themselves are free to store as metadata, but each AMI is backed by EBS snapshots, and you pay for that snapshot storage (about $0.05 per GB-month in most Regions). Copying an AMI to another Region creates new snapshots there, so you pay for storage in both Regions plus a one-time cross-Region data transfer charge. Delete (deregister) old custom AMIs and their snapshots when you no longer need them.

Best Practices

Start from an official AWS-provided AMI (such as Amazon Linux 2023) unless you have a specific reason not to — they are patched and supported.
Resolve AMI IDs at launch time via SSM Parameter Store instead of hard-coding a fixed ami-... value, so you always get the latest patched image.
Treat community AMIs as untrusted: prefer AWS or verified Marketplace vendors, and scan any third-party image before production use.
Always select the AMI ID for the Region you are deploying into; never assume an ID works across Regions.
Match the AMI architecture to your instance type — an x86_64 AMI will not boot on an Arm-based Graviton instance and vice versa.
Deregister unused custom AMIs and delete their backing snapshots to avoid quietly accumulating storage charges.

Amazon Machine Images (AMIs)

What an AMI actually contains

Where AMIs come from

Finding an AMI ID

Console steps

CLI: search official AWS images

Gotcha: AMIs are Region-specific

Best Practices

Related Topics