What Is an AMI and How Do I Create One from My EC2 Instance

You've spent hours configuring an EC2 instance — installing packages, tuning system settings, deploying application code — and now you need a repeatable way to launch identical instances without doing it all over again. An Amazon Machine Image (AMI) is the mechanism AWS provides to capture that exact state and use it as a launch template for future instances.

TL;DR: AMI Creation at a Glance

StepActionKey Consideration
1Prepare the instanceStop or quiesce the instance for a consistent snapshot
2Create the AMIConsole or CLI: create-image
3Wait for availabilityAMI state transitions: pending → available
4Launch from AMIUse AMI ID in run-instances or Launch Template
5Manage lifecycleDeregister AMI + delete associated snapshots when done

How AMI Creation Works

When you call CreateImage, AWS instructs the hypervisor to take EBS snapshots of every volume attached to the instance. The AMI itself is a metadata object — it stores the snapshot IDs, block device mappings, architecture, virtualization type, and boot mode. The snapshots are the actual data. This means AMI storage cost is driven by EBS snapshot pricing, not a separate AMI fee. If you stop the instance before creating the AMI, the filesystem is in a clean state; if you create the AMI while the instance is running, AWS uses the --no-reboot flag behavior — the instance keeps running but the snapshot may capture in-flight writes, which is acceptable for many workloads but not for databases without application-level quiescing.

graph LR A["EC2 Instance
configured state"] -->|CreateImage API| B["EBS Snapshot
per attached volume"] B --> C["AMI Registration
ami-xxxxxxxx"] C -->|RunInstances| D["New EBS Volumes
from snapshots"] D --> E["New EC2 Instance
identical configuration"] style A fill:#f0f4ff,stroke:#4a6cf7 style C fill:#e6f4ea,stroke:#34a853 style E fill:#e6f4ea,stroke:#34a853
  1. CreateImage call — triggers snapshot creation for each attached EBS volume.
  2. EBS Snapshots — incremental, stored in S3-backed infrastructure; the AMI references these by snapshot ID.
  3. AMI Registration — AWS registers the AMI with a unique ami-xxxxxxxx ID in your account and region.
  4. Launch — RunInstances uses the AMI's block device mappings to create new EBS volumes from the snapshots and attach them to the new instance.

Step 1: Prepare Your EC2 Instance for AMI Creation

Before capturing the image, eliminate sources of inconsistency. For stateless web servers, creating the AMI while the instance is running is usually fine. For databases or anything writing to disk continuously, stop the instance first — this is the single most reliable way to guarantee a clean filesystem state.

If stopping is not an option, flush application buffers and sync the filesystem before proceeding. The --no-reboot parameter in create-image keeps the instance running during snapshot creation; omitting it allows AWS to reboot the instance to ensure data integrity before snapshotting.

# Stop the instance for a consistent AMI (recommended for stateful workloads)
aws ec2 stop-instances \
  --instance-ids i-0abcdef1234567890 \
  --region us-east-1

# Wait until the instance is fully stopped
aws ec2 wait instance-stopped \
  --instance-ids i-0abcdef1234567890 \
  --region us-east-1

Step 2: Create the AMI from Your EC2 Instance

With the instance stopped (or quiesced), issue the create-image command. AWS will snapshot all attached EBS volumes and register the AMI atomically. The command returns an AMI ID immediately, but the AMI is not usable until its state transitions to available.

aws ec2 create-image \
  --instance-id i-0abcdef1234567890 \
  --name "my-app-server-v1" \
  --description "Production app server - configured 2025" \
  --no-reboot \
  --region us-east-1

The response includes the ImageId — save it. Every subsequent action references this ID.

Think of the AMI as a blueprint and the EBS snapshots as the raw materials. The blueprint tells AWS what to build; the snapshots provide the actual data to build from. Deleting the blueprint (deregistering the AMI) doesn't destroy the materials — you must clean up snapshots separately.

Step 3: Monitor AMI State Until Available

The AMI creation process is asynchronous. Snapshot creation time scales with the amount of data on the volumes — a freshly provisioned instance with minimal data completes in minutes; a heavily populated volume takes longer. Poll the state rather than assuming a fixed wait time.

# Wait for the AMI to reach 'available' state
aws ec2 wait image-available \
  --image-ids ami-0123456789abcdef0 \
  --region us-east-1

# Or describe the AMI state manually
aws ec2 describe-images \
  --image-ids ami-0123456789abcdef0 \
  --query 'Images[0].State' \
  --region us-east-1

Valid state transitions are pending → available. If something goes wrong during snapshot creation, the AMI transitions to failed. Check the StateReason field in describe-images output for the failure message.

stateDiagram-v2 [*] --> pending : CreateImage called pending --> available : All snapshots completed pending --> failed : Snapshot error available --> deregistered : DeregisterImage called failed --> [*] deregistered --> [*]
  1. pending — Snapshots are being created; AMI is not yet usable.
  2. available — All snapshots completed; AMI can be used to launch instances.
  3. failed — Snapshot creation encountered an error; check StateReason.
  4. deregistered — AMI has been explicitly deregistered; no longer launchable.

Step 4: Launch a New Instance from Your AMI

Once the AMI is available, use it exactly as you would an AWS-provided AMI. The instance launched from your custom AMI will have the same OS, packages, configuration, and data that existed on the source instance at snapshot time.

aws ec2 run-instances \
  --image-id ami-0123456789abcdef0 \
  --instance-type t3.micro \
  --key-name my-key-pair \
  --security-group-ids sg-0abcdef1234567890 \
  --subnet-id subnet-0abcdef1234567890 \
  --count 1 \
  --region us-east-1

For repeatable infrastructure, embed the AMI ID in a Launch Template rather than passing it directly to run-instances. Launch Templates support versioning, which makes AMI rotation auditable.

IAM Permissions Required for AMI Creation

The principal creating the AMI needs permissions to describe instances, create images, and manage the resulting snapshots. Read and Describe actions on EC2 typically require "Resource": "*" — verify against the Service Authorization Reference before narrowing scope.

🔽 Click to expand — IAM policy for AMI creation 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "CreateAMI",
      "Effect": "Allow",
      "Action": [
        "ec2:CreateImage",
        "ec2:DescribeInstances",
        "ec2:DescribeImages",
        "ec2:DescribeSnapshots"
      ],
      "Resource": "*"
    },
    {
      "Sid": "TagResources",
      "Effect": "Allow",
      "Action": [
        "ec2:CreateTags"
      ],
      "Resource": [
        "arn:aws:ec2:us-east-1::image/*",
        "arn:aws:ec2:us-east-1:*:snapshot/*"
      ]
    },
    {
      "Sid": "SnapshotCleanup",
      "Effect": "Allow",
      "Action": [
        "ec2:DeregisterImage",
        "ec2:DeleteSnapshot"
      ],
      "Resource": [
        "arn:aws:ec2:us-east-1::image/*",
        "arn:aws:ec2:us-east-1:*:snapshot/*"
      ]
    }
  ]
}

Step 5: Manage AMI Lifecycle — Deregister and Clean Up Snapshots

Here's where engineers consistently leave money on the table. Deregistering an AMI removes the launch capability but does not delete the underlying EBS snapshots. Those snapshots continue to accrue storage costs until explicitly deleted. The correct cleanup sequence is: deregister the AMI first, then delete each associated snapshot.

# Step 1: Find the snapshot IDs associated with the AMI before deregistering
aws ec2 describe-images \
  --image-ids ami-0123456789abcdef0 \
  --query 'Images[0].BlockDeviceMappings[*].Ebs.SnapshotId' \
  --region us-east-1

# Step 2: Deregister the AMI
aws ec2 deregister-image \
  --image-id ami-0123456789abcdef0 \
  --region us-east-1

# Step 3: Delete each snapshot returned in Step 1
aws ec2 delete-snapshot \
  --snapshot-id snap-0abcdef1234567890 \
  --region us-east-1

Always retrieve snapshot IDs before deregistering — once the AMI is deregistered, the association between the AMI and its snapshots is no longer queryable through describe-images.

Experience Signal: The Snapshot Orphan Problem

A common pattern: a team automates AMI creation for nightly builds, deregisters old AMIs after 30 days via a Lambda function, and then wonders why their EBS snapshot costs keep climbing month over month. The Lambda correctly calls deregister-image — but never calls delete-snapshot. The snapshots are orphaned: no AMI references them, but they exist and bill indefinitely.

The misdiagnosis is assuming that deregistering the AMI cleans up everything. The actual cause is that AMI deregistration and snapshot deletion are two independent API calls with no automatic cascade. The fix is to always query BlockDeviceMappings[*].Ebs.SnapshotId before deregistering and include snapshot deletion in the same automation run.

Insight: an AMI is a pointer, not a container — deleting the pointer leaves the data behind.

Sharing AMIs Across Accounts and Regions

By default, an AMI is private to the AWS account and region where it was created. To use it in another account, modify the AMI's launch permissions. To use it in another region, copy the AMI — this creates new snapshots in the target region.

# Share AMI with another AWS account
aws ec2 modify-image-attribute \
  --image-id ami-0123456789abcdef0 \
  --launch-permission "Add=[{UserId=111122223333}]" \
  --region us-east-1

# Copy AMI to another region
aws ec2 copy-image \
  --source-image-id ami-0123456789abcdef0 \
  --source-region us-east-1 \
  --name "my-app-server-v1-copy" \
  --region eu-west-1

When sharing an AMI, the receiving account also needs access to the underlying snapshots if they intend to copy the AMI or launch it in a way that requires snapshot access. Modify snapshot permissions separately using modify-snapshot-attribute if needed.

Wrap-Up: AMI Creation and What Is an AMI — Next Steps

Creating an AMI from a configured EC2 instance is a three-part operation: snapshot the volumes, register the AMI metadata, and manage the lifecycle of both artifacts independently. The most operationally significant detail is that AMI deregistration does not cascade to snapshot deletion — build that into any automation from day one.

For production environments, consider integrating AMI creation into your CI/CD pipeline using EC2 Image Builder, which provides a managed pipeline for building, testing, and distributing AMIs with full lifecycle management. See the EC2 Image Builder documentation and the AMI user guide for authoritative reference.

Glossary

TermDefinition
AMI (Amazon Machine Image)A metadata object containing the configuration — OS, block device mappings, snapshot references — required to launch an EC2 instance.
EBS SnapshotA point-in-time backup of an EBS volume stored in AWS-managed infrastructure. AMIs reference snapshots for their root and data volumes.
Block Device MappingThe configuration within an AMI that defines which volumes to attach to a launched instance and how (device name, size, snapshot ID).
DeregisterThe act of removing an AMI's launch capability. Does not delete associated EBS snapshots.
Launch TemplateAn EC2 resource that stores instance configuration including AMI ID, instance type, and network settings for repeatable launches.

Related Posts

Comments

Post a Comment

Popular posts from this blog

EC2 No Internet Access in Custom VPC: Fix Internet Gateway and Route Table

EC2 no internet access in a custom VPC is one of the most common launch-day failures — the instance is running, but outbound connectivity is completely silent. TL;DR: EC2 No Internet Access — Fix Checklist Step What to Do Why It Matters Complexity 1 Create and attach an Internet Gateway to the VPC Without an IGW, the VPC has no path to the public internet Low 2 Add a default route (0.0.0.0/0) pointing to the IGW in the subnet's route table The IGW exists but traffic has no route to reach it Low 3 Assign a public IP or Elastic IP to the instance Private IPs are not routable on the public internet Low 4 Verify Security Group allows outbound traffic A restrictive outbound rule silently drops all egress Low 5 Verify Network ...
Read more

EC2 SSH Connection Timeout: Which Security Group Rules to Check

An EC2 SSH connection timeout is one of the most common blockers when launching a new instance — the fix is almost always a missing or misconfigured inbound rule in your Security Group. TL;DR — Diagnostic Steps at a Glance Step What to Check Common Fix 1 Security Group inbound rules Add SSH (TCP 22) from your IP 2 Subnet route table Ensure 0.0.0.0/0 routes to an Internet Gateway 3 Network ACL rules Allow inbound TCP 22 and ephemeral return ports 4 Instance public IP / Elastic IP Confirm a public IP is assigned 5 Key pair and SSH username Use correct private key and AMI-specific username Why SSH Times Out Instead of Refusing A connection refused error means the TCP handshake reached the host but nothing is listening. A connection timed out error means packets never arrived — or replies never returned. On EC2, that silence is almost always a network-layer block, not an OS-level problem. The Se...
Read more

Difference Between IAM User and IAM Role: Which One Should Your EC2 Use?

Understanding the difference between IAM User and IAM Role is critical — choosing wrong means either hardcoded credentials in your app or a silent security exposure you won't catch until an audit. TL;DR: IAM User vs IAM Role at a Glance Dimension IAM User IAM Role Identity type Permanent, named human or service identity Assumable identity with temporary credentials Credential type Long-lived access keys or password Short-lived STS tokens (auto-rotated) Attached to EC2? No native attachment — keys must be embedded Yes — via Instance Profile, injected automatically Rotation required? Manual — your responsibility Automatic — AWS STS handles it Recommended for EC2 → S3? No Yes — always Cross-account access Requires separate user per account Native — assume role across accounts Audit trail Tied to user identity Tied to role + session name in CloudTrail What IAM User and IAM Role Actual...
Read more