Creating a Custom AMI

An AMI (Amazon Machine Image — the template AWS uses to boot an EC2 instance) does not have to be one of the stock images Amazon gives you. You can take an instance you have already configured — with your app installed, packages updated, and settings tuned — and freeze it into your own custom AMI. Every future instance launched from that image starts up already provisioned, in seconds, exactly like the one you captured. This is the foundation of the “golden image” pattern, and it is one of the biggest speed and consistency wins in EC2.

What a custom AMI actually is

When you create an AMI from an instance, AWS takes a snapshot (a point-in-time backup) of each EBS volume (Elastic Block Store — the virtual disks attached to your instance) and records the instance’s configuration: architecture, virtualization type, and which volumes map to which device. The result is a reusable template stored in your account in one Region.

Launching from that AMI restores those snapshots into fresh volumes on a brand-new instance. So whatever was on disk at capture time — your code, your config, and unfortunately also any leftover secrets — comes back to life.

The golden image pattern: when to use it

A “golden image” is a single, blessed AMI that already contains everything an instance needs to run. Instead of booting a plain OS and installing software on every launch (slow, and prone to drift when a package version changes), you bake it once and launch many identical copies.

Approach	Boot time	Consistency	Best for
Plain AMI + user-data script	Slow (installs at boot)	Can drift over time	Rarely-changing, simple setups
Golden image (custom AMI)	Fast (pre-baked)	Identical every launch	Auto Scaling, fleets, fast scale-out
Hybrid (baked base + small user-data)	Medium	Strong	Config that changes per environment

When to use it: Auto Scaling groups that must add instances in seconds, blue/green deployments, or any fleet where every node must be byte-for-byte identical.

When NOT to: A single long-lived server you rarely rebuild, or rapidly changing code better delivered by a deploy pipeline than by re-baking an image.

Creating an AMI from an instance

Stop the instance first when you can. AWS lets you create an image from a running instance, but it briefly reboots it (unless you skip the reboot) to flush the filesystem to disk. A clean, stopped instance gives the most consistent snapshot.

Console steps

1. Open the EC2 console and go to Instances.
2. Select the instance you want to capture (for example i-0a1b2c3d4e5f).
3. Choose Actions -> Image and templates -> Create image.
4. Give it an Image name like web-app-golden-2026-06 and a description.
5. Leave No reboot unchecked for a consistent disk (or check it to avoid downtime, accepting a slightly less clean snapshot).
6. Review the Instance volumes mappings, then choose Create image.
7. Watch progress under AMIs in the left nav. Status moves from pending to available.

AWS CLI

aws ec2 create-image \
  --instance-id i-0a1b2c3d4e5f \
  --name "web-app-golden-2026-06" \
  --description "Nginx + app baked 2026-06-15" \
  --tag-specifications 'ResourceType=image,Tags=[{Key=Name,Value=web-app-golden}]'

Output:

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

The call returns immediately, but the image is not usable until the underlying snapshots finish. Wait for it:

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

Then launch identical instances from it:

aws ec2 run-instances \
  --image-id ami-0abcdef1234567890 \
  --instance-type t3.micro \
  --key-name my-key \
  --security-group-ids sg-0a1b2c3d \
  --subnet-id subnet-0a1b2c3d \
  --count 3

Security gotcha: clean the instance before you bake

This is the mistake that bites teams hardest. Because an AMI snapshots the whole disk, it captures everything on it — including things you never meant to ship.

Never bake credentials, secrets, logs, or SSH host keys into an AMI. Anyone who can launch your image (or who you share it with) inherits those secrets, and every instance born from it shares the same identity. Treat the image as if it could become public.

Before creating the image, clean the instance:

# Remove SSH host keys so each new instance regenerates unique ones
sudo rm -f /etc/ssh/ssh_host_*

# Wipe shell history and temp files
sudo rm -f /root/.bash_history /home/*/.bash_history
sudo rm -rf /tmp/* /var/tmp/*

# Truncate logs that may contain request data or IPs
sudo find /var/log -type f -exec truncate -s 0 {} \;

# Remove any cloud-init state so it reruns cleanly on next boot
sudo cloud-init clean --logs

Use IAM roles (identity permissions attached to the instance) for AWS access instead of long-lived keys on disk — that way nothing sensitive needs to live in the image at all.

Repeatable builds: EC2 Image Builder vs Packer

Hand-baking from a console click works once, but it is not repeatable or auditable. For production golden images, automate the build:

Tool	What it is	When to use
EC2 Image Builder	AWS-native pipeline service	You want a managed, no-server pipeline with built-in security hardening and AMI distribution across Regions/accounts
HashiCorp Packer	Open-source, multi-cloud image builder	You build for multiple clouds, want config in version control, or already use HashiCorp tooling

A Packer template defines a base AMI, the provisioning steps (your cleanup script included), and outputs a new AMI ID. EC2 Image Builder does the same through a managed pipeline you define with components and can schedule to rebuild on a cadence so your base OS stays patched.

Cost note: Creating an AMI is free, but you pay for the EBS snapshots it stores — roughly $0.05 per GB-month in most Regions. A 30 GB image costs about $1.50/month. Old, unused AMIs and their orphaned snapshots quietly add up, so deregister stale images and delete their snapshots regularly.

Best practices

• Stop or quiesce the instance before imaging for a clean, consistent snapshot.
• Always run a cleanup pass (host keys, history, logs, cloud-init state) before baking.
• Use IAM roles, not on-disk keys, so no credentials ever land in the image.
• Version and date your AMI names (web-app-golden-2026-06) and tag them so you can find and prune them later.
• Automate builds with EC2 Image Builder or Packer instead of clicking the console.
• Deregister old AMIs and delete their backing snapshots to control storage cost.
• Pair golden images with launch templates so Auto Scaling always uses the right AMI.

Related Topics

• Understanding AMIs
• Launch an EC2 instance with the CLI
• EBS snapshots
• Launch templates
• EC2 tags