Right, let’s talk about the three flavors of AMIs you’ll encounter in the wild. Think of them like a spectrum of trust, from “I made this myself” to “I found this in a dark digital alley and hope it’s not full of crypto miners.” Spoiler: you should be deeply suspicious of anything in that last category.

An AMI is just a frozen moment of a machine’s soul—its root volume, any attached data volumes, and a bit of metadata that tells EC2 how to boot it. But where that image comes from is the difference between a stable foundation and a house of cards.

The Wild West of Public AMIs

Public AMIs are exactly what they sound like: machine images that anyone, anywhere, with an AWS account can launch. You can find them by filtering the AMI list in the EC2 console for “Public images.” This is where the trouble starts.

Why? Because anyone can create and share a public AMI. That includes well-meaning open-source projects, helpful developers… and also threat actors who have pre-baked malware, keyloggers, or bitcoin miners into a seemingly innocent “Ubuntu 22.04 LTS” image. AWS does not vet these. At all. Using a public AMI from an untrusted source is like accepting a pre-made sandwich from a stranger on the subway. It might be fine. But you’re gonna have a bad time if it’s not.

The one exception is the official ones from Canonical, Amazon, Microsoft, etc. These are your safe bet. Always, always, always verify the owner alias. For example, the official Canonical owner is 099720109477. You should be launching your Ubuntu AMIs from that owner, not some random 12-digit number you’ve never seen before.

Here’s how you find the official Ubuntu 20.04 AMI using the AWS CLI. Notice we’re specifying the owner and filtering by the name pattern.

aws ec2 describe-images \
  --owners 099720109477 \
  --filters \
    "Name=name,Values=ubuntu/images/hvm-ssd/ubuntu-focal-20.04-amd64-server-*" \
    "Name=state,Values=available" \
  --query "sort_by(Images, &CreationDate)[-1].ImageId" \
  --output text

This command spits out the most recent ([-1]) AMI ID for that specific release. This is a million times safer than picking one from the public list manually.

The Curated (but Paid) Aisle: AWS Marketplace AMIs

This is the middle ground. The AWS Marketplace is a vetted digital storefront where third-party vendors can sell you software pre-installed on an AMI. Think of things like CIS Hardened Images, cPanel, or specialized database appliances.

The upside? These vendors are known entities, and AWS does a basic level of due diligence. It’s far more secure than the public AMI free-for-all. The downside? You almost always have to pay for it. The cost of the software gets added directly to your EC2 hourly bill.

Before you launch one, you must subscribe to the product. You can’t just launch it. This usually involves a 1-click acceptance of the vendor’s terms and might require you to configure your billing details. It’s a process, so don’t expect to automate its launch in a hurry during an emergency.

Your Digital Fortress: Private AMIs

This is where you live. A private AMI is one that you own. You created it, you downloaded it from a trusted partner, or you shared it within your own organization. It’s not visible to anyone else unless you explicitly make it public or share it with specific accounts.

This is your gold standard. You built it from a trusted base image (using the CLI method above!), you hardened it, installed your application, and tested it. You know exactly what’s on it because you put it there. This is the image you use for Auto Scaling Groups—consistent, reliable, and secure.

Creating your own is straightforward. You start with a known-good instance (your “golden image”), get it perfectly configured, and then tell AWS to freeze it.

# Create an AMI from a running instance.
# It will reboot the instance, so plan for a quick outage.
aws ec2 create-image \
  --instance-id i-1234567890abcdef0 \
  --name "MyAwesomeApp-Server-v1.2" \
  --description "Base image for ASG, pre-installed with MyAwesomeApp and configured Nginx"

The magic of this process is that it’s atomic. It creates a point-in-time snapshot. Any writes in progress are coordinated to ensure the resulting volume is consistent, which is why it needs the quick reboot.

Sharing AMIs Securely Across Accounts

Maybe you have a dev account and a prod account. You built a perfect image in dev and want to promote it to prod. You don’t recreate it; you share it.

First, you make the AMI shareable with another account. This does not make it public; it just grants that specific account permission to launch it.

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

Now, the user in account 123456789012 can launch it. But here’s the critical, often-missed pitfall: AMIs are region-locked. You shared it in us-east-1. If you need it in eu-west-1, you must copy it there first, then share the copy. This trips up everyone.

aws ec2 copy-image \
  --source-image-id ami-0a1b2c3d4e5f67890 \
  --source-region us-east-1 \
  --region eu-west-1 \
  --name "MyAwesomeApp-Server-v1.2-eu-copy"

The bottom line: Your default should be private AMIs you create from verified sources. Use the Marketplace for validated commercial software. And treat public AMIs like a public restroom—use only the clean, official ones when absolutely necessary, and avoid touching anything suspicious.