7 Best Practices for Managing EC2 AMIs with EC2 Image Builder Across Multiple AWS Accounts
Seven technology leaders explain how they centralize AMI builds, manage versioning and patching, and control stale images across multi-account AWS environments.
As AWS environments expand across accounts and teams, EC2 AMI management can become difficult to control. Test images, emergency-patch builds, and one-off AMIs accumulate quickly, often with inconsistent naming, unclear ownership, and no reliable indication of which versions are approved for production. Without a defined lifecycle for building, testing, distributing, patching, and retiring AMIs, teams can lose confidence in which images are current and safe to launch.
Governance becomes increasingly important as that environment grows. Clear ownership, consistent versioning, controlled promotion, and defined cleanup rules help prevent image sprawl while giving teams a reliable way to identify and deploy approved AMIs.
7 EC2 AMI Management Best Practices at a Glance
Treat AMIs as immutable, reproducible artifacts
What it solves: Prevents undocumented manual changes and makes images reproducible
Tag every AMI for ownership and traceability
What it solves: Establishes governance, traceability, and accountability
Centralize builds in an image factory
What it solves: Prevents account-by-account drift and inconsistent baselines
Build a controlled promotion and rollback process
What it solves: Keeps untested images out of production while preserving recovery options
Define lifecycle and retention rules
What it solves: Prevents stale-image sprawl without deleting images that are still needed
Preserve useful metadata before deleting old AMIs
What it solves: Retains engineering history without keeping every image indefinitely
Assign a retirement date when the AMI is created
What it solves: Makes cleanup part of the release process instead of a future project
How AWS EC2 Image Builder Fits into a Multi-Account AMI Strategy
EC2 Image Builder provides the AWS-native foundation for many of these practices. Teams can use image recipes and reusable components to standardize builds, automate testing, and distribute approved AMIs across AWS accounts, AWS Organizations, organizational units (OUs), and Regions. Image Builder lifecycle policies can also automate the deprecation, disabling, and deletion of outdated images.
But the service itself doesn’t make the organizational decisions for you.
Teams still need to determine where images should be built, who owns the approved baseline, what must happen before an image reaches production, how application teams consume approved AMIs, how encryption and permissions work across accounts, and when an image is actually safe to retire.
Those are the governance decisions that turn EC2 Image Builder from an image-building tool into a sustainable AMI management process.
See an Automated AMI Pipeline in Practice
AWS and Stratus10 published a technical walkthrough showing how EC2 Image Builder can be integrated into an automated release workflow for custom AMIs. The architecture automates image creation, validation, testing, and distribution, reducing work that previously took hours or days to a process completed in minutes.
We asked seven cloud and engineering leaders how they approach AMI versioning, patching, distribution, and stale-image cleanup. Their implementations vary, but the pattern is remarkably consistent: centralize image creation, treat every AMI as a versioned release artifact, automate testing and distribution, and define its retirement conditions when it is created.
Editor’s note: Responses have been lightly edited for clarity and length.
1. Treat Images As Immutable, Reproducible Artifacts
The principle I hold to is that an image is a build artefact, not a pet. If an AMI is produced by hand, nobody can tell you six months later what is inside it, and that is where the risk sits.
Practically, that means baking images from a pipeline off a versioned definition in source control, so a rebuild is reproducible rather than a memory test. Tag at build time with the source commit, the base image and the build date, because that metadata is what makes the later questions answerable: What is running? How old is it? What needs rebuilding?
Across accounts, build once centrally and share the image outward rather than rebuilding per account, which is where drift creeps in. On patching, the cadence matters less than it being fixed and automatic, and images treated as immutable so you roll forward instead of patching in place.
Cleanup works when it is a rule rather than a project: age images out automatically and deregister the snapshots with them.
James Rowell, Chief Technology Officer, Capture Expense
Key takeaway: Rowell’s “rule rather than a project” framing is a useful starting point for the entire AMI lifecycle. Once an image can be reproduced from source-controlled definitions, the team no longer has to preserve a particular AMI simply because nobody is confident they could recreate it.
2. Tag Every AMI for Ownership and Traceability
I treat AMIs as release artifacts with ownership, changelog, and expiry date. Every image starts from a small set of approved base images, then goes through a repeatable build pipeline that installs OS patches, hardening settings, monitoring agents, runtime dependencies, and CIS or company baseline checks.
Versioning needs to be boring. I use a name and tag pattern that humans can read and automation can sort: service or platform name, OS family, patch date, build number, and source commit or pipeline run ID. The AMI also gets tags for owner, environment, base AMI ID, compliance profile, creation date, deprecation date, and replacement AMI ID once it's superseded.
Those tags matter more than the AMI name because cleanup, reporting, and launch policies can act on them.
For patching, I prefer a fixed monthly image release for normal OS updates and an emergency release path for critical CVEs. Before promotion, the image should boot in a test account, pass smoke tests, validate SSM connectivity, confirm logs and metrics are flowing, and run a vulnerability scan. Only then should the pipeline promote it.
Cross-account distribution should be centralized. Build in one image factory account, then share or copy the AMI into workload accounts and regions according to account type. Regulated or isolated accounts usually need copied AMIs because they own the encrypted snapshots and can keep operating if sharing permissions change. Use KMS keys deliberately here; most AMI distribution failures come from snapshot encryption permissions, not EC2 itself.
Cleanup is part of the release. I keep a small rollback window, then deregister stale AMIs and delete their snapshots after checking launch templates, Auto Scaling groups, ECS capacity, EKS node groups, and any disaster recovery references.
An AMI that can still be launched by old automation isn't stale yet. If you can't identify who owns an AMI, what replaced it, and when it expires from tags alone, your AMI process is already too manual.
Evgeny Leonov, Chief Technology Officer, Ronas IT
Key takeaway: Leonov’s approach highlights an important distinction: AMI lifecycle management begins when the image is created, not when someone eventually decides the account contains too many images.
Ownership, replacement, expiration, patch level, and source information should already exist by the time the AMI reaches production.
3. Central Builds in an Image Factory
Managing EC2 machine images in a complicated multi-account environment involves using a centralized image factory pattern instead of relying on manual snapshots. Our organization develops an independent Shared Services or Security account where every golden image begins its life cycle and creates a clear audit trail. This also prevents the usage of unapproved base images in various workload accounts.
To keep up with patching requirements, we use human free automated pipelines to retrieve vendor base images, attach organizational security hardening scripts, and deploy necessary agents.
We follow strict semantic naming approach and use immutable tagging for versions. Every build will have a unique version and recorded time of being built. Once the image is ready, we run a distribution part of the pipeline that delivers the AMI to the necessary unit in the organization.
To make the AMI easily reachable, we update the SSM Parameter Store in every consumer account using Infra as Code so that the application teams will have an option to define constants such as prod-web-server-latest instead of hardcoding AMI references.
Patching follows both a regular monthly cadence and an immediate out-of-band process for critical vulnerabilities. For cleanup, we remove images that haven't been used for more than 90 days after a dedicated worker verifies they are not still tied to instances or templates.
Sudhanshu Dubey, Delivery Manager, Enterprise Solutions Architect, Errna
Key takeaway: EC2 Image Builder supports centralized distribution of output AMIs to other AWS accounts, Organizations, OUs, and Regions. That makes a central image-factory architecture possible without requiring each workload account to independently rebuild the same baseline.
The SSM Parameter Store pattern Dubey describes adds another useful abstraction: application teams can consume an approved logical image reference instead of embedding a specific AMI ID throughout their infrastructure code.
4. Build a Controlled Promotion and Rollback Process
I would use a centralized image pipeline with immutable versioning, automated security scanning and a controlled promotion path from build to testing and approved production accounts.
Every AMI should include a build date, source revision, operating-system patch level, owner and planned expiration date. Patching should create a new version rather than modifying an existing approved image.
The previous stable image should remain available for rollback until the new version has passed application and operational tests. Stale-image cleanup should check launch templates, active instances and recovery dependencies rather than relying only on age.
My systems rule is that every production artifact needs an owner, a current approved version and a retirement condition. Old images become risky when nobody knows why they remain, while aggressive cleanup becomes risky when rollback needs were never documented.
Cem Oner, Founder / Finance & Public Data Publisher, Hesap Cebimde
Key takeaway: “Newest” and “approved” should not mean the same thing.
A newly built AMI may be technically current while still failing application tests, security validation, or operational requirements. A promotion process lets teams separate creation from approval—and preserve a known-good image long enough to recover if the new version causes problems.
5. Define Lifecycle and Retention Rules
The overlooked challenge in multi-account AWS environments is image sprawl. Teams often create multiple AMIs for testing, emergency fixes, and temporary deployments, then leave them behind. Over time, this increases storage costs, complicates audits, and makes it difficult to identify which images are safe for production use.
The process I recommend is: (1) use a standardized naming convention that includes application, operating system, patch level, and release date, (2) establish a regular patching cycle with automated image builds and security validation, and (3) define retention rules that remove unused AMIs after a specific period while preserving approved baseline versions.
For example, keeping the latest production image plus a limited rollback history provides recovery options without maintaining unnecessary copies across accounts.
Omer Malik, CEO, ORM Systems
Key takeaway: EC2 Image Builder lifecycle policies can automate the deprecation, disabling, and deletion of outdated images and their associated resources. But AWS explicitly notes that Image Builder does not evaluate downstream dependencies such as launch templates or Auto Scaling groups before removing an image.
That makes Malik’s distinction important: lifecycle automation still needs a retention policy that accounts for production dependencies and rollback requirements.
6. Preserve Useful Metadata Before Deleting Old AMIs
I started to pay attention to the number of times an AMI was viewed instead of being used to launch an instance. Some AMIs that are never used again in production were being checked by engineers for tag information, build information, or just version of installed packages when they were debugging an issue. It was a clear indicator that the AMI had become documentation in the eyes of the engineers. Removing it too early would have destroyed the documentation, and keeping every old AMI would have lead to a situation similar to the attic of a house.
It also changed the way I approached cleanup in the AWS accounts. I no longer treated every old AMI the same, and instead made a distinction between those that were reference documentation and those that could still be used to create an environment. If an AMI had not been used in a long time, but still provided valuable information about past versions of the environment, I would preserve some of its metadata and build manifest, and then delete the AMI itself. This way the accounts are kept clean, but engineering history is preserved.
Yukt Mitash, Founder, WriteBros.ai
Key takeaway: Mitash brings up an easy lifecycle consideration to overlook.
Deleting an obsolete AMI does not have to mean deleting every record of what went into it. If build definitions, manifests, tags, package versions, source revisions, and logs are stored elsewhere, teams can preserve the forensic and debugging value of an old image without retaining the actual AMI and snapshots indefinitely.
7. Assign a Retirement Date When the AMI Is Created
An AMI should have a retirement date from the start. To do this, we use a central image factory to make images. Each image gets a unique version number, build date, and other details. We test the images for security and other issues before moving them to production.
Rebuild images regularly, such as monthly, and also when there are critical security problems. When you deploy, use approved images, not just the newest one.
Old images need a cleanup policy as well. Keep the current one, the previous good one, and a limited number of older ones for rollback, then get rid of the rest.
This is not just about reducing the cost of storing old images. An outdated AMI can still be launched, including one with a known security vulnerability. Having a retirement plan helps keep those images from remaining available indefinitely.
Erin Zadoorian, Co-Founder, Exhalewell
Key takeaway: This is why AMI cleanup should be treated as a security control as well as a storage-management task.
AWS lists reducing the risk of launching outdated images as one of the benefits of automated Image Builder lifecycle management. Lifecycle policies can automatically retire images and associated resources across accounts and Regions rather than leaving old versions available indefinitely.
The Bottom Line on Managing EC2 AMIs Across AWS Accounts
Across all seven responses, the same operating model keeps appearing:
- Build centrally.
- Version everything.
- Test before promotion.
- Distribute approved images outward.
- Patch on a predictable cadence.
- Keep a defined rollback window.
- Retire images intentionally.
The details vary though. One leader uses SSM Parameter Store to abstract AMI IDs. Another emphasizes KMS permissions during cross-account distribution. Another preserves build metadata after deleting the image itself.
But they all reject the same underlying model: AMIs as manually created snapshots that accumulate indefinitely.
Instead, they treat AMIs as governed release artifacts moving through a repeatable lifecycle.
EC2 Image Builder gives AWS teams many of the native building blocks for that approach. The harder part is connecting those capabilities to an account structure, security model, deployment process, ownership model, and retirement policy that teams can actually operate.
If your organization is still creating AMIs manually or managing them independently in each account, that is usually the signal to establish the governed pipeline before image sprawl—or a security incident—forces the issue. The seven contributors consistently emphasized centralized builds, strong tagging, predictable patching, testing, and dependency-aware cleanup.
Need Help Implementing EC2 Image Builder Across Multiple AWS Accounts?
The practices above are straightforward in principle. Implementing them across real AWS account structures, deployment pipelines, encryption requirements, application teams, and security controls is where the complexity begins.
Stratus10 designs and implements EC2 Image Builder automation for organizations that need a governed way to build, test, distribute, and retire AMIs across AWS environments.
Our work can include centralized image-factory architecture, hardened baseline AMIs, application-specific builds, CI/CD integration, cross-account and multi-Region distribution, testing and validation, and image lifecycle management.
