Many teams treat an AMI as something you create once and forget. The problem shows up months later: dozens of untagged images, EBS snapshots nobody knows whether they can delete, and a bill that grows without explanation. Managing the lifecycle of an AMI means treating it as a software artefact with a birth, versions, maturity, deprecation and retirement.
Good image governance cuts costs, improves security —nobody accidentally launches an unpatched image from a year ago— and makes compliance audits easier.
Phase 1 — Versioning with meaning
Versioning is the backbone. Without it, “the latest good AMI” is a hallway conversation, not a fact. We recommend a readable, consistent scheme.
- Versioned name: for instance
imaxe-ubuntu22-nginx-2026.07.1, with product, base and calendar version. - Mandatory tags:
Version,GitCommit,BuildDate,Owner,Environment,CISLevel,Status. - Immutable: one version, one artefact. Never modify a published AMI; create a new version.
- Central registry: use AWS Systems Manager Parameter Store to hold the ID of “the current production AMI” so your Launch Templates read it by reference.
Phase 2 — End-to-end encryption
An AMI’s data lives in EBS snapshots. If they are not encrypted, any poorly governed copy is a potential leak. Encryption should be the norm, not the exception.
- Encryption by default: enable EBS encryption by default at account and region level.
- Customer-managed keys (CMK): use your own KMS key instead of the AWS default one to control permissions and rotation.
- A copy is a re-encryption: when copying an AMI to another region or account, take the chance to re-encrypt it with the destination key.
- Share with KMS grants: if you distribute the AMI to other accounts, grant key access with minimal policies.
Phase 3 — Deprecation: warn before deleting
AWS lets you mark an AMI as deprecated with a date. From that moment it stops appearing by default in searches, but it still works for anyone referencing it explicitly. It is the civilised middle ground between “current” and “deleted”: you warn, you give room to migrate and you avoid breaking deployments.
Phase 4 — Automated cleanup (and the hidden cost of snapshots)
Here is where the money is. When you delete an AMI, its associated EBS snapshots are not removed automatically. That is the number-one cause of storage bills that grow mysteriously. A retirement policy must deregister the AMI and then delete its orphaned snapshots.
- Retention policy: keep N recent versions (for example the last three) and retire the rest.
- Automate with the cloud: Amazon Data Lifecycle Manager (DLM) can manage image creation and deletion by policy.
- Hunt orphaned snapshots: periodically audit snapshots with no associated AMI and delete them.
- Never delete blindly: check that no active instance or Launch Template depends on the AMI before retiring it.
Lifecycle summary table
| Phase | Key action | Tool or service |
|---|---|---|
| Creation | Reproducible build and tagging | Packer / EC2 Image Builder |
| Encryption | Snapshots encrypted with a CMK | AWS KMS + EBS default encryption |
| Distribution | Multi-region or multi-account copy and re-encryption | AMI copy / AWS RAM |
| In force | Registry of the current ID | SSM Parameter Store |
| Deprecation | Mark deprecated with a date | ec2 enable-image-deprecation |
| Retirement | Deregister and delete snapshots | DLM / scheduled scripts |
The six phases of AMI governance and how to automate them.
Metrics you should watch
- Average age of the AMIs in use: the lower, the better patched.
- Number of orphaned snapshots and their monthly cost.
- Percentage of encrypted AMIs, with a target of 100 %.
- Time from a critical CVE to the new published image, the patch MTTR.
Frequently asked questions
Why is my EBS bill rising if I already deleted the AMIs?
Because deregistering an AMI does not delete its snapshots. You must remove them explicitly. Audit orphaned snapshots regularly; they are usually the biggest hidden cost.
Is it safe to share an encrypted AMI with another account?
Yes, as long as you grant access to the KMS key with a specific grant and minimal permissions. Without that access, the destination account cannot launch the image.
How many versions of an AMI should I keep?
It depends on your rollback and compliance needs, but keeping between two and four recent versions is usually a good balance between rollback safety and cost.
At imaxe.cloud we design our images with versioning and encryption from the start, so their lifecycle is predictable and auditable.
