What an AMI is, its types, how to create a custom AMI from the console and AWS CLI, plus cost, security, and best practices."

tags: aws, ec2, devops, beginners

Every time you click Launch instance in the EC2 console, the first thing AWS asks you to choose is an Amazon Machine Image (AMI). It's easy to pick Amazon Linux or Ubuntu and move on, but the AMI decides what operating system, software, and configuration your server starts with.

In this post I explain what an AMI is, its types, how to create your own custom AMI, and the best practices I follow while learning AWS and DevOps.

What is an AMI?

An AMI is a template that contains the software configuration needed to launch an EC2 instance. Think of it as a ready-made blueprint, or a snapshot of a fully set-up server. From one AMI you can launch as many identical instances as you need.

Analogy: it's like a phone factory image. Every phone that leaves the factory has the same OS and apps. Every EC2 instance launched from one AMI starts with the same OS, packages, and settings.

What does an AMI contain?

• Root volume template: the OS and installed software (for example NGINX, Docker, Jenkins). For EBS-backed AMIs this is stored as an EBS snapshot.
• Launch permissions: who can use it (only you, specific accounts, or public).
• Block device mapping: which volumes are attached at launch, with their size and type.

Where do AMIs come from?

Types of AMIs

Also remember:

• Architecture: x86_64 or arm64 (Graviton). The AMI must match the instance type.
• Region: an AMI exists in one Region only. Copy it to use it elsewhere.

How it works

1. Launch an instance from a base AMI.
2. Customise it: install NGINX, Docker, your app, config files.
3. Create a new AMI from that instance.
4. Launch new instances from your custom AMI, each fully configured in minutes.
5. Optionally copy it to other Regions or share it with other accounts.

Hands-on: create an AMI from the console

1. Open the EC2 console > Instances and select your configured instance.
2. Choose Actions > Image and templates > Create image.
3. Enter an image name (for example nginx-webserver-v1) and a description.
4. Leave No reboot unchecked for a consistent file system.
5. Click Create image.
6. Go to Images > AMIs and wait until the status is available.
7. Select it and click Launch instance from AMI to test.

Hands-on: AWS CLI

Create an AMI from an instance:

aws ec2 create-image \ --instance-id i-0123456789abcdef0 \ --name "nginx-webserver-v1" \ --description "NGINX web server golden image" 

List your own AMIs:

aws ec2 describe-images --owners self 

Copy to another Region:

aws ec2 copy-image \ --source-image-id ami-0123456789abcdef0 \ --source-region us-east-1 \ --region ap-south-1 \ --name "nginx-webserver-v1-copy" 

Share with another AWS account:

aws ec2 modify-image-attribute \ --image-id ami-0123456789abcdef0 \ --launch-permission "Add=[{UserId=111122223333}]" 

Deregister an AMI:

aws ec2 deregister-image --image-id ami-0123456789abcdef0 

Deregistering does not delete the underlying EBS snapshots. Delete them separately to avoid ongoing storage charges.

Real-world use cases

• Golden images: a hardened, patched base image for every team.
• Auto Scaling: launch templates reference an AMI so new instances are ready immediately.
• Fast deployments: bake NGINX, Docker, or Jenkins in instead of installing at every launch.
• Backup and recovery: restore quickly from a known-good image.
• Disaster recovery: copy AMIs to a second Region.
• Consistency: dev, test, and prod from the same image.

AMI vs Snapshot vs Instance

Snapshots store the data, and the AMI turns that data into something you can launch.

Cost

• Owning an AMI has no separate fee. You pay for the EBS snapshots behind it.
• Unused AMIs and snapshots keep costing money, so clean them up.
• Marketplace AMIs may add software charges.
• Copying across Regions creates new snapshots and may add data transfer charges.

Check the current AWS pricing page for exact numbers.

Security best practices

• Never bake secrets (passwords, keys) into an AMI. Use IAM roles, Secrets Manager, or SSM Parameter Store.
• Keep AMIs private unless you intend to share them.
• Encrypt snapshots with AWS KMS.
• Patch regularly by rebuilding your golden image on a schedule.
• Verify third-party AMIs (publisher, owner ID, reviews).
• Clean before capture: remove logs, temp files, shell history, and SSH keys.

Best practices

• Use clear names with version and date, e.g. nginx-web-v1-2026-11-06.
• Add tags (Project, Owner, Environment).
• Automate with EC2 Image Builder, Packer, or AWS Backup.
• Keep images small.
• Retire old images with Data Lifecycle Manager or deprecation.
• Test every new AMI before production.

Common mistakes

• Forgetting that AMIs are Region-specific.
• Deregistering an AMI but leaving its snapshots behind.
• Using No reboot on a busy database server.
• Launching an x86_64 AMI on an arm64 instance type.
• Hard-coding AMI IDs instead of using SSM parameters or launch templates.

Conclusion

An AMI is the foundation of every EC2 instance. Understanding it and building your own custom images lets you launch servers faster, keep environments consistent, scale automatically, and recover quickly. Treat servers as repeatable images instead of hand-built machines, and you move one step closer to real DevOps practice.

I'll keep sharing what I learn on my AWS journey. Feedback is always welcome. Which AWS service should I cover next? Tell me in the comments.

Vishal Patil | AWS & DevOps learner

• LinkedIn: https://www.linkedin.com/in/vishalpatil-devops-aws/
• GitHub: https://github.com/VishalPatil-DevOps-AWS
• dev.to: https://dev.to/vishal_patil_aws
• Credly: https://www.credly.com/badges/a615d775-05e1-4358-ae34-dc4f70a0a485/public_url

vishalcloudjourney #aws #ec2 #devops #amazonmachineimage