What is an AMI - the frozen server explained

An AMI (Amazon Machine Image) is not a server. It is a frozen, reusable template of one — the operating system, the installed software, and every setting, packaged so Amazon EC2 can stamp out identical copies of it whenever you ask. Here is the part almost nobody tells you until it shows up on a bill: when you "delete" an AMI, AWS doesn't actually erase the data behind it. The storage keeps sitting there, keeps costing money, and keeps doing that for as long as you let it.

Jake found out about the frozen-server trap the hard way. Not from a data-loss incident — from a bill.

He runs a small mobile phone repair shop, and about a year and a half ago he'd spun up a test server to try a new appointment-booking tool. He never launched it for real. He deleted the test instance, felt good about being tidy, and moved on. What he didn't do was delete the AMI he'd made from it first — or the snapshot sitting quietly underneath that AMI. Fourteen months later he finally noticed a line item on his AWS invoice he didn't recognize. It wasn't big. But it also wasn't nothing, and it had been there, unnoticed, for over a year.

What Is an AMI, Really?

An Amazon Machine Image is an image that provides the software required to set up and boot an Amazon EC2 instance. Every AMI also contains a block device mapping — a list telling EC2 which storage volumes to attach and where — and you must specify an AMI every single time you launch an instance. There's no "launch a blank server" option in EC2. You always start from a template.

Think of it the way Ethan explained it to Jake one afternoon, using the shop's own phone-flashing process as the analogy.

The instance is the running, breathing machine — the thing you can SSH into, that has a live IP address, that racks up an hourly charge while it's on. The AMI is the pattern used to stamp that machine into existence. Once the instance is running, it develops its own life: files get written, logs accumulate, software gets installed. None of that ever flows backward into the AMI it came from, because the AMI is frozen the moment it's created. If you want those new changes captured too, you have to create a brand-new AMI from the updated instance.

You can use an AMI provided by AWS itself, a public AMI shared by another user, an AMI shared privately with your account, or one you bought through the AWS Marketplace. You can also build your own. All of those live in the same catalog once they're in your account, and all of them work the exact same way at launch time.

AMI vs. Instance vs. Snapshot: Stop Mixing These Up

This is the single most common source of confusion for anyone new to EC2, and it's worth killing off in one table instead of one paragraph at a time.

Here's how they connect. An EBS-backed AMI is built on top of one or more EBS snapshots — usually one for the root volume, plus one for each additional data volume you had attached when you created the image. When you launch an instance from that AMI, EC2 reads the snapshot, creates a brand-new EBS volume from it, and attaches that volume to your new instance as the root device. The instance type you pick determines the CPU, memory, and networking that instance gets — completely independent of which AMI you chose, as long as the AMI is compatible with that instance type.

So an AMI without an instance is just a dormant template, quietly billing you for the snapshot storage underneath it. A snapshot without being wrapped into an AMI is just raw block data — useful for restoring a volume, but not something EC2 can boot directly. And an instance without ever specifying an AMI simply can't exist; EC2 requires one at launch, full stop.

The Five Things That Define Every AMI

When you're choosing an AMI to launch — or trying to figure out why one you found on a forum won't work for your project — it comes down to exactly five characteristics that are baked into the image itself:

1. AWS Region. AMI IDs are unique to the Region they live in. An AMI ID that works in Mumbai (ap-south-1) means nothing in Virginia (us-east-1); it either doesn't exist there or points at a completely different image. You have to copy an AMI to another Region before you can use it there.
2. Operating system. Amazon Linux, Ubuntu, Windows Server, RHEL, SUSE, and so on. This is fixed at build time — you can't swap the OS on a running instance.
3. Processor architecture. 32-bit, 64-bit x86, or 64-bit Arm (Graviton). The instance type you launch it on must match this architecture, or the launch simply fails.
4. Root volume type. Backed by Amazon EBS, or the older instance-store (Amazon S3-backed) style. This decides how the instance boots, what happens to data on stop, and how you're billed. It's important enough to get its own section below.
5. Virtualization type. Hardware virtual machine (HVM) or the legacy paravirtual (PV) type. Every current-generation instance type uses HVM; PV is a holdover for a handful of older instance families like C1, C3, M1, M2, and M3.

Miss any one of these and the launch wizard will either grey out your instance type choices or throw an error explaining the mismatch. If you've ever wondered why a perfectly good-looking AMI wasn't selectable for the instance type you wanted, this list is almost always the reason — usually the architecture or the Region.

EBS-Backed vs. Instance-Store AMIs

Every AMI falls into one of two camps for its root volume: backed by Amazon EBS (Elastic Block Store — persistent network storage that survives independently of the instance) or backed by Amazon S3, which uses old-style instance store volumes for the root device. If you're building anything new in 2026, you'll almost always land on EBS-backed, and there's a good reason for that beyond convenience.

Notice the row about data persistence — this trips people up constantly. On an EBS-backed instance, the root volume is deleted by default when you terminate the instance (that's the "delete on termination" flag, and it defaults to true), but any additional EBS volumes you attached separately keep their data unless you tell EC2 otherwise. On an instance-store AMI, everything on that root volume vanishes the instant the instance stops existing, because instance store is physically tied to that one specific host computer. There's no "stopped" state to fall back into.

How to Find an AMI to Launch

Before you can launch anything, you need to find an AMI that fits your Region, OS, architecture, and root volume needs. There are three practical routes.

Route 1: The launch wizard's Quick Start tab

Open the EC2 console, choose Launch instance, and under Application and OS Images (Amazon Machine Image), pick Quick Start. This shows the operating systems most people reach for, with a curated set of commonly used AMIs for each one. If nothing there fits, Browse more AMIs opens the full catalog.

Route 2: The AMIs page in the console

In the navigation pane, choose AMIs, then filter — Public images, Owned by me, Private images, or Disabled images. You can search by Owner alias (set it to amazon to see only AWS-published images) and by Platform to narrow to Linux or Windows. Before you commit to one, check whether it's EBS-backed or instance-store, since that changes how the instance behaves later.

Route 3: The AWS CLI, for scripting and automation

The describe-images command (the CLI is the command-line tool AWS provides so you can control your account by typing commands instead of clicking through the console) returns AMIs that are public, owned by you, or shared with you:

If you're using the AWS Tools for PowerShell instead, the equivalent cmdlet is Get-EC2Image, with an -Owner or -Filter parameter doing the same job.

One more thing worth knowing: public AMIs published by Amazon or by a verified AWS partner are marked "Verified provider" in the console, and in CLI output they show an ImageOwnerAlias of amazon, aws-backup-vault, or aws-marketplace. Other users can't fake that alias onto their own AMIs — it's how you tell a genuinely AWS-blessed image from a random community upload with the same friendly name.

How to Create Your Own Custom AMI

This is the part Jake actually cared about. His shop's booking system runs on one EC2 instance, and he wanted a second location to run the exact same setup without spending another Saturday reinstalling everything by hand — which is what he'd done the first time, before he knew AMIs existed.

To actually do step three from an existing instance, here's the console path:

1. Open the EC2 console, go to Instances, select the instance you want to capture, then choose Actions, Image and templates, Create image.
2. Give it an Image name (up to 127 characters) and an optional Image description (up to 255 characters).
3. Decide on Reboot instance. Leave it checked (the default) unless you're confident the file system is already in a consistent state — some file systems like XFS can freeze and unfreeze cleanly, letting you skip the reboot. Clear the checkbox and AWS explicitly can't guarantee the file system integrity of the resulting image.
4. Review Instance volumes — you can resize the root volume, decide whether it should delete on termination for instances launched from the new AMI, and add extra EBS or instance-store volumes.
5. Add tags if you want the AMI and its snapshots labeled — either the same tags on both, or different tags on each.
6. Choose Create image, then watch its status in the AMIs list. It starts as pending and moves to available once EC2 has finished snapshotting every volume — usually a few minutes, though large volumes can occasionally take up to 24 hours.

The equivalent single command, if you'd rather script it, is create-image:

Ethan's take on the reboot question is blunt: "If it's a production database, take the reboot hit at 3 a.m. and get a clean image. If it's a stateless web server that reads config off S3 anyway, --no-reboot is fine — but don't pretend to yourself you tested that it's safe when you didn't." That's not a testing claim about this article, either — it's the honest logic AWS's own warning is pointing at: a skipped reboot means AWS itself won't vouch for the file system's consistency, and neither can anyone writing about it secondhand.

You can also build an AMI from an existing snapshot instead of a live instance, using Create image from snapshot on the Snapshots page, or the register-image CLI command. That path matters mainly for Windows, Red Hat, SUSE, and SQL Server images, where the correct licensing metadata has to carry over from the snapshot — check the Platform details field on the resulting AMI, and if it's empty or wrong, discard the AMI and go back to building it from a running instance instead.

Windows AMIs need Sysprep, not just a reboot

Everything above works the same for Windows instances, but Windows has one more layer: the Microsoft System Preparation tool, better known as Sysprep. Sysprep generalizes the operating system — it strips out instance-specific details like the security identifier (SID), the computer name, event logs, and certain drivers — so the resulting AMI can be safely duplicated onto new instances without every clone behaving as if it's the exact same machine as every other clone.

You run Sysprep through whichever EC2 launch agent your Windows AMI uses. EC2Launch v2 is the current recommendation, and it covers Windows Server 2012 through 2025; older Server 2016 and 2019 builds can still run it through the earlier EC2Launch v1 agent or the legacy EC2Config service if you haven't migrated. Whichever agent you're on, the warning is identical across all of them: never use Sysprep to create an instance backup. Because Sysprep deliberately strips system-specific information, running it against a machine you actually intend to restore later can have unintended consequences for that backup.

Ethan's guidance here is short: "If you're capturing a golden image you'll clone across a fleet, generalize it with Sysprep first. If you're just trying to save tonight's exact state of one server in case something goes wrong, don't touch Sysprep — take a plain AMI instead." AWS's own recommendation for anyone building and maintaining Windows images repeatedly, rather than as a one-off, is to reach for EC2 Image Builder instead of running Sysprep by hand every time — covered in full further down.

The AMI Lifecycle: Copy, Deprecate, Disable, Deregister

An AMI isn't a one-and-done object. AWS gives you four distinct actions for managing one over time, and they do genuinely different things — mixing them up is where most of the confusion (and most of the wasted spend) comes from.

Copy

An AMI only launches instances in the Region it lives in. If you need the same configuration in a second Region, you copy it there — a distinct AMI ID is created in the destination Region, fully independent of the source from that point on.

Deprecate

Marking an AMI as superseded or out of date. You set an immediate or future deprecation date, and once it hits, the AMI is hidden from AMI listings — but anyone (or any service) that already knows the AMI ID can still use it. It's a "please stop finding this by browsing" flag, not a hard lock.

Disable

A temporary, reversible block. A disabled AMI can't be used to launch new instances, but re-enabling it restores full use immediately. Disabling has zero effect on instances that were already launched from that AMI before you disabled it — they keep running untouched.

Deregister

This is the "delete" action, and it's also where the counterintuitive reveal from the top of this post lives. Deregistering an AMI permanently prevents it from being used to launch new instances. It's protected against accidental use by an optional deregistration protection setting you can turn on. If you accidentally deregister an EBS-backed AMI anyway, the Recycle Bin can restore it — but only within whatever retention period you configured, and only if the AMI matched a retention rule in the first place. Miss that window, and it's gone for good.

Deregistering also has zero effect on instances already launched from that AMI — they keep running exactly as before, and you keep paying for their compute and storage as usual. The only thing that changes is that nobody can launch a fresh instance from that particular AMI ID again.

For anything beyond occasional manual cleanup, Amazon Data Lifecycle Manager can automate the creation, retention, copying, deprecation, and deregistration of EBS-backed AMIs and their backing snapshots on a schedule — worth knowing about the moment you find yourself deregistering the same category of "old nightly build" AMI by hand more than once a week.

Tracing Where an AMI Came From: Ancestry and Watermarks

Once an AMI has been copied across a couple of Regions, and someone's built a new AMI from that copy, and someone else did it again six months later, the honest question becomes: where did this thing actually come from? Two relatively recent EC2 features answer that directly.

AMI ancestry: automatic lineage tracking

AMI ancestry, introduced in November 2025, lets you trace the complete lineage of any AMI — from its immediate parent, back through every preceding generation, to the root AMI. Before this feature existed, tracking that lineage meant manual tagging conventions and hoping nobody forgot to apply them, especially once an AMI had been copied across Regions a few times.

The root AMI at the end of the chain is one of: a public AMI from a verified provider (owned by amazon or aws-marketplace), an AMI with no recorded ancestor (for example, one built directly from snapshots with register-image rather than from an instance), an AMI whose source came from a different partition entirely, or simply the 50th entry in the list — ancestry chains are capped at 50 AMIs deep. Ancestry keeps working even if an intermediate AMI in the chain gets deregistered later; the record of where the current AMI came from survives independently.

You can pull the full chain with the get-image-ancestry CLI command, or view it from the AMI Ancestry tab on the AMI's details page in the console. There's no charge to use it, in any AWS Region, including AWS GovCloud (US) and the AWS China Regions.

AMI watermarks: proving what an AMI actually is

AMI watermarks, a newer governance feature, let the owner of a private (non-public) AMI attach a structured identifier — up to five per AMI — that automatically propagates to every derivative image created from it through CreateImage or CopyImage. Unlike a tag, a watermark can't be stripped off by copying the AMI or building a new one from it; it persists regardless of how many generations removed the derivative is, and it stays visible even after you share the AMI with another account.

Each watermark carries its own metadata — the account ID that created it, the Region and AMI ID it was originally attached to, and the creation timestamp — combined into a key in the format account-id:watermark-name. Only the AMI's owner can attach or detach a watermark, and watermarks can't be added to public AMIs at all. The practical use case is governance at scale: combine watermarks with Allowed AMIs (a feature that restricts which AMIs can be used to launch instances in your account) and Declarative Policies, and you can enforce, organization-wide, that instances only ever launch from AMIs carrying an approved watermark — not just an approved-looking name.

What an AMI Actually Costs

The AMI object itself has no separate line-item price. What you're actually paying for is the storage underneath it, and understanding that separation is the whole trick to not getting surprised by your bill.

For an EBS-backed AMI, EC2 creates a snapshot of the root volume — and any other attached EBS volumes — during the AMI-creation process, and you are charged for those snapshots for as long as they exist, whether or not the AMI is ever used to launch a single instance. Standard-tier EBS snapshot storage runs around $0.05 per GB-month in US regions. A 20 GB root-volume snapshot sitting untouched for a year, in other words, costs roughly a dollar a year — small on its own, but Jake's shop had accumulated several of these across a year and a half of experimentation, and small numbers add up when nobody is looking.

For an S3-backed AMI (the legacy kind), you're charged for instance usage plus storing your AMI bundle in Amazon S3 instead — a different pricing model, but the same principle: the AMI persists as storage, and storage costs money until you remove it.

A few cost specifics worth knowing before you launch anything at scale:

• Copying an AMI to another Region is free by default, with standard storage and data-transfer rates applying to the new snapshot it creates. If you request a time-based copy — guaranteeing the copy finishes inside a set window from 15 minutes up to 48 hours — that specifically incurs additional charges.
• If you archive a rarely-used snapshot to the EBS Snapshots Archive tier instead of deleting it, the archive rate is about $0.0125 per GB-month, roughly a quarter of the standard rate — but there's a 90-day minimum retention, and restoring it back to standard tier costs $0.03 per GB on top of the standard $0.05 per GB-month once it's restored.
• EC2 Image Builder itself has no service fee to use — but every AMI it produces still goes through the same billing rules above for the underlying EBS snapshots, plus whatever EC2 instance time it uses to build and test the image.

For Windows, Red Hat, SUSE, and SQL Server AMIs, there's a second cost layer worth knowing about: platform licensing. Check the AMI's Platform details field before launching or purchasing a Reserved Instance, and confirm it matches what you expect — this is also how AWS knows what licensing rate to bill you at.

Sharing an AMI With Others

Launch permissions control who can use your AMI, and only the AMI's owner can set them. There are three categories: public (every AWS account can launch from it), explicit (you name specific accounts, organizations, or organizational units), and implicit (you, the owner, always have permission on your own AMI). AWS and the wider EC2 community publish a huge range of public AMIs this way, and if you want to charge for yours, that's what the AWS Marketplace is for — you register as a seller and list your AMI as a paid product.

A word of caution that applies whether you're sharing your own AMI or using someone else's: AWS explicitly does not vouch for the integrity or security of AMIs shared by other EC2 users. Treat a shared AMI the way you'd treat any third-party code before running it in your own environment — the same due diligence you'd apply to a random script someone emailed you. The one shortcut worth trusting is the Verified provider badge, which only appears on AMIs owned by Amazon or by a registered AWS Marketplace partner; other users have no way to fake that label onto their own images.

When you copy a shared AMI, note that launch permissions and any Amazon S3 bucket permissions from the source AMI do not carry over to your new copy automatically — you have to reapply them yourself once the copy finishes. Tags work similarly: only user-defined tags you attached yourself get copied, never system tags prefixed aws:, and never tags another account attached.

Copying an AMI to Local Zones, Outposts, and Other Accounts

Region-to-Region copying covers most people's needs, but EC2 also runs in places that aren't standard Regions, and the copy rules shift depending on where the source AMI actually lives.

If your source AMI is in a Region, you can copy it within that Region, to another Region, to an AWS Outpost associated with that Region, or to a Local Zone in that Region. A Local Zone is an AWS infrastructure deployment placed closer to a specific metro area than the parent Region it belongs to, for workloads sensitive to network latency. If your source AMI already lives in a Local Zone, you can copy it within that Local Zone, to its parent Region, or to certain other Local Zones that share the same parent Region. The one hard stop: an AMI stored on an Outpost can't be copied anywhere at all — it stays exactly where it is.

Cross-partition copying — moving an AMI from the standard commercial partition into a separate partition like AWS GovCloud (US) — doesn't use the regular copy-image workflow at all. It goes through a dedicated store-and-restore process instead, since the two partitions don't share the infrastructure the normal copy path relies on.

Cross-account copying is simpler in concept but has its own gotcha worth remembering: you can copy an AMI that another AWS account shared with you, creating your own independent copy in your account. But AWS does not carry over the source AMI's launch permissions or any Amazon S3 bucket permissions to your new copy — you have to reapply whatever sharing settings you want on the copy yourself, from scratch, once the copy finishes.

AMI Encryption

Snapshots inside an AMI can be encrypted using Amazon EBS encryption — either your account's default AWS KMS key (Key Management Service — the AWS system that creates and controls the cryptographic keys used to encrypt your data) or a customer-managed key you specify yourself. Whichever key is used, you need permission to use it, every time.

The default behavior when you launch an instance, without specifying any encryption parameters, is to carry forward whatever encryption state the source snapshot already had: an unencrypted snapshot restores to an unencrypted volume (unless your account has "encryption by default" turned on, in which case everything gets encrypted regardless), and an encrypted snapshot you own restores to a volume encrypted with that same key. If the AMI was shared with you rather than owned by you, an encrypted source snapshot instead restores using your own account's default KMS key — not the original owner's key, since you generally won't have access to that.

You're not stuck with whatever encryption state the AMI already has, though. Supplying the Encrypted parameter at launch (or during a copy) lets you convert an unencrypted volume to encrypted on the fly, and adding a specific KmsKeyId alongside it lets you re-encrypt to a different key entirely — useful when you're copying an AMI between AWS accounts and want the new copy locked to a key only your account controls.

Automating AMI Builds With EC2 Image Builder

Manually clicking through Create image every time a security patch drops is fine for one server. It falls apart the moment you're maintaining a fleet. EC2 Image Builder is AWS's answer: a fully managed service that automates the creation, testing, and distribution of AMIs on a schedule you define.

You build an image pipeline around an image recipe, which names a base image (an existing AMI to start from) and a set of components — build components that customize the instance before capture, and test components that verify the result afterward. Image Builder launches a temporary instance, applies the build components, validates the result, stops the instance, creates the AMI, then launches a fresh instance from that new AMI to run test components against it before distributing the image anywhere. If any configured test fails, Image Builder doesn't distribute the image — which is a meaningfully different guarantee than a manually built AMI gets, since nobody manually re-validates a hand-clicked image the same way.

Supported base operating systems currently include Amazon Linux 2 and 2023, several versions of CentOS and CentOS Stream, RHEL 7 through 10, SUSE 12/15/16, Ubuntu 18.04 through 24.04 LTS, several macOS versions, and Windows Server 2012 R2 through 2025 — a considerably wider net than most teams actually need, but useful if your fleet is mixed.

There's no separate charge to use Image Builder itself. What you do pay for is everything it touches along the way: the temporary EC2 instances it launches during build and test, log storage in Amazon S3, image validation through Amazon Inspector if you enable it, and — same as any other AMI — ongoing EBS snapshot storage for whatever AMIs it produces. If you're also distributing container images through the same pipeline, standard Amazon ECR storage and data-transfer charges apply on that side too.

Common Mistakes People Make With AMIs

Between the AWS documentation and the questions readers actually send in, the same handful of mistakes show up again and again. Worth naming them plainly instead of letting you find each one the expensive way.

Assuming an AMI ID travels between Regions

It doesn't. Copy the AMI to each Region you need, and treat each copy as its own independent object from that point forward — updates to one don't propagate to the others.

Forgetting to delete snapshots after deregistering

Covered above, but it bears repeating because it's the single most common source of the "why am I still being billed for something I deleted" support question. The AMI and its snapshot are two separate objects billed separately.

Skipping the reboot without checking the file system first

Clearing Reboot instance can produce a faster AMI creation, but AWS is explicit that file system integrity is not guaranteed when you do that. If you don't know whether your file system can safely freeze and unfreeze without a reboot, the safe default is to leave the reboot on.

Trying to copy an AMI off an Outpost

It can't be done. An AMI stored on an AWS Outpost is intentionally stuck there — not copyable to a Region, another Outpost, or anywhere else. If you need that configuration available elsewhere, rebuild the AMI from an instance running in a Region instead.

Trusting an unverified public AMI for anything production-facing

A friendly-sounding AMI name is not a security review. If it doesn't carry the Verified provider badge, treat it like any unreviewed third-party code before you put customer data anywhere near it.

Building a Windows or licensed AMI from a snapshot and never checking Platform details

If that field comes back empty, or doesn't match the OS code you expected, the AMI creation silently failed to carry the correct billing and licensing metadata. Discard it and rebuild from the running instance instead.

Frequently Asked Questions

What does AMI actually stand for, and what does it mean in plain English?

It stands for Amazon Machine Image. In plain terms, it's a frozen, reusable template — the operating system plus whatever software and settings you've baked in — that Amazon EC2 uses as the starting point every time it boots a new virtual server.

Is an AMI the same thing as an EC2 instance?

No. The AMI is the template; the instance is the live, running server launched from it. Changes made on a running instance never write back into the AMI it came from — you'd have to capture a new AMI to include them.

What's the real difference between an AMI and an EBS snapshot?

A snapshot is raw, point-in-time data from a single storage volume — it isn't bootable by itself. An EBS-backed AMI is built on top of one or more snapshots, plus launch permissions and a block device mapping, which together make it something EC2 can actually use to launch an instance.

Can I use the same AMI ID in every AWS Region?

No. AMI IDs are unique to the Region they were created in. To use the same configuration elsewhere, you copy the AMI to each target Region, which produces a new, independent AMI ID there.

How much does it cost to just keep an AMI sitting around?

The AMI itself has no separate charge, but the EBS snapshot storage backing an EBS-backed AMI runs around $0.05 per GB-month in US regions, billed for as long as the snapshot exists, whether or not you ever launch anything from it.

If I deregister an AMI, does that delete the snapshot behind it too?

Not automatically. You have to explicitly select "Delete associated snapshots" during deregistration, or pass the equivalent flag on the CLI. Even then, if that snapshot is also backing a different AMI you own, it won't be deleted, and you'll keep paying storage costs for it.

What happens to instances that are already running if I deregister the AMI they were launched from?

Nothing happens to them. Deregistering only prevents that AMI from being used to launch new instances going forward — existing instances keep running exactly as before, and you continue paying for their compute and storage as usual.

What's the difference between an EBS-backed AMI and an instance-store (S3-backed) AMI?

An EBS-backed AMI's root volume lives on persistent, network-attached EBS storage, so the instance can be stopped and restarted without losing data, and its instance type can be changed later. An instance-store AMI's root volume is physically tied to one host machine, has no stopped state, and is considered end of life, supported only on a short list of older instance types.

Do I have to reboot my server to create an AMI from it?

By default, yes — Reboot instance is checked, and EC2 reboots the instance to snapshot its volumes while data is at rest. You can clear that checkbox to skip the reboot, but AWS explicitly states it can't guarantee file system integrity for the resulting image if you do.

Is it safe to launch an instance from a public or community AMI?

Use it at your own risk. AWS does not vouch for the integrity or security of AMIs shared by other EC2 users, so treat one the way you'd treat any unreviewed third-party code. AMIs marked Verified provider, owned by Amazon or a verified AWS partner, carry more assurance than an unmarked community upload.

Can I share a custom AMI with another AWS account, or sell it?

Yes to both. You can grant explicit launch permissions to specific accounts, organizations, or organizational units, make it public to every AWS account, or register as a seller on the AWS Marketplace to charge for it.

Is copying an AMI to another Region free?

Yes, if you don't request a guaranteed completion window — standard storage and data-transfer rates apply for the new snapshot the copy creates. If you enable a time-based copy with a set completion window, that specifically incurs an additional charge.

How many AMIs am I allowed to have in one Region?

The default quota is 50,000 AMIs per Region, counting available, pending, and disabled AMIs plus anything in the Recycle Bin. Public AMIs are capped separately at 5 per Region by default. Both quotas can be raised through a Service Quotas increase request if you need more.

Can an AMI be encrypted, and does that change how it launches?

Yes — the EBS snapshots inside an AMI can be encrypted with either your account's default KMS key or a customer-managed key you choose. By default, launching from it preserves whatever encryption state the source snapshot had, but you can override that at launch time to encrypt an unencrypted volume, or re-encrypt to a different key entirely.

What does a "pending" AMI status mean, and how long should I wait?

Pending means EC2 is still creating the underlying snapshots and hasn't finished registering the AMI. It usually resolves to Available within a few minutes, though large volumes can occasionally take up to 24 hours. Creating snapshots ahead of time can speed this up since only incremental changes need to be captured during the actual AMI creation.

How do I stop manually rebuilding AMIs every time there's a security patch?

Automate it with EC2 Image Builder, which builds, tests, and distributes updated AMIs on a schedule you define, or use Amazon Data Lifecycle Manager to automate the retention, copying, deprecation, and deregistration of the AMIs and snapshots you already have.

Revision note. Written September 2026. This will need a fresh look whenever AWS changes AMI quotas, snapshot pricing, or Recycle Bin retention behavior. If you're staring at a surprise line item on your AWS bill right now, you're not the first person this has happened to, and it's fixable in a few minutes. See you on next post