Deregister unused AMIs and their snapshots

An AMI is free to register, but every AMI is backed by one or more EBS snapshots that bill at roughly $0.05 per GB-month, continuously, whether or not anyone ever launches the image again. Because the charge surfaces as generic EBS snapshot storage rather than as a named AMI cost, it rarely gets flagged in standard cost reviews — it's the line that everyone rounds down and nobody cleans up.

The dollar arithmetic is straightforward to model. A 100 GB AMI with a single snapshot costs about $5/month; a 500 GB multi-volume golden image costs $25–30/month. Individually those are rounding errors. The finance problem is scale and duration: an account that has been building AMIs for four or five years, running CI pipelines that bake a new image on every deployment, can easily accumulate three hundred or more unused images and silently carry six thousand or more dollars a month in storage charges for artifacts nobody references.

The FinOps framing here is straightforward. This is pure waste — there is no upside to retaining an AMI that hasn't been launched in over 180 days and isn't tagged for intentional retention. The remediation is a cleanup plus a policy that prevents the accumulation from restarting. The finance contribution is to insist the organization has a documented AMI retention rule (how long, which exceptions, who approves them) so the storage line becomes predictable and manageable rather than a slow, invisible accumulator.

Carlos is the finance partner sitting in on the quarterly cloud review. The platform team flags a wastage report with 312 unused AMIs across one region — 11.4 TB of snapshot storage that's been billing for years. His first question isn't 'delete them all' — it's 'what's the cost, and are any of these load-bearing?'

He pulls the dollar model quickly: 11.4 TB at $0.05/GB-month is roughly $570 a month, $6,800 a year, landing in an 'unallocated EBS' line nobody has ever actioned. That's the easy part. The harder question is whether any of these images are intentionally retained — DR golden images, compliance snapshots, anything tagged Keep. The team confirms four AMIs carry Keep=DR tags for the quarterly compliance archive; the other 308 are CI artifacts nobody has referenced in over 18 months.

Carlos's framing for the review: the 308 candidates are unambiguous waste, and deleting them is a budget line item, not a risk decision. The four DR images stay, and they document why — the audit trail matters more than the storage cost. For the future, he asks for a retention policy: build pipelines should tag artifacts with an expiry, and anything older than 90 days without a Keep tag should be auto-deleted. That turns a one-time cleanup into a managed cost.

The direct cost impact is easy to quantify but easy to miss because it hides on a generic storage line. EBS snapshot storage at $0.05/GB-month doesn't look alarming at the level of any single AMI — a 200 GB image is $10/month. The finance problem is the long tail: an account running active CI pipelines for four years may have hundreds of images it has never cleaned up, and the aggregate can reach five or six figures annually. That money is being spent on data the organization has no business reason to retain.

This is one of the cleanest cases in cloud cost optimization — it is unambiguously waste. Unlike compute rightsizing (where you trade off performance) or Multi-AZ databases (where you trade off resilience), unused AMIs provide zero ongoing value. The cost is real, the benefit of keeping them is zero, and the risk of deleting them — once you have verified they are genuinely unused and not referenced by any live system — is also close to zero.

The finance contribution is two things: first, ensure that a cleanup generates a forecast and a measured saving, not just an engineering task that disappears into a sprint. Model the monthly saving before and after; track it on the bill for 60 days to confirm it materialized. Second, require that any intentional exception — a DR image, a compliance snapshot — is a recorded, budgeted line, not an undocumented survivor. If the organization carries twenty retained AMIs at a total of $300/month, that should be an approved, named line on the cloud budget, not anonymous background noise.

Every time an engineering team builds a new machine image — for a software release, a CI pipeline run, a server configuration change — AWS stores the artifact as paid cloud storage. The image itself is free; the underlying storage blocks are not. An organization that has been building images for several years without a cleanup policy is routinely paying tens of thousands of dollars a year to store images that nobody has used in years and that nobody can name the purpose of.

This is not a resilience trade-off or a cost-versus-risk decision — it's unmanaged accumulation. The fix is a retention policy: keep what the business needs (disaster-recovery images, compliance-required snapshots), clean up everything else on a rolling window, and make sure new build pipelines tag and expire their artifacts automatically. The leadership question is simply whether that policy exists and is enforced, or whether the account is silently billing for years of forgotten build history.

At one company, the VP of Engineering was surprised to learn the organization was spending nearly $80,000 a year on EBS storage for machine images — mostly CI build artifacts that had accumulated over four years with no cleanup process. The cost had been invisible, sitting in a generic storage line that nobody owned.

After a one-time cleanup and a retention policy requiring that all new AMIs carry an expiry tag, the line dropped to under $5,000 a year — the cost of the images the company had deliberately decided to keep. The change took a few weeks of engineering time and a policy decision that took about an hour.

The leadership question this surfaces is simple: does the organization have a documented image retention policy, or is it accumulating storage charges for artifacts nobody chose to keep? The healthy state is a clean policy — keep DR and compliance images, expire everything else on a rolling window — with the cost of exceptions recorded and justified.

The most direct impact is a silent, growing cloud bill. Without a retention policy, every machine image ever built sits in storage indefinitely, accumulating charges that no one owns and no budget line names. Organizations that have been running AWS for four or five years without cleanup routinely discover tens to hundreds of thousands of dollars of annual spend on images nobody can identify. It is among the cleanest forms of cloud waste — no trade-off, just accumulation.

The secondary impact is security posture. Old images almost always predate critical security patches. An image built three years ago is three years behind on OS updates. If that image is still launchable — and without cleanup it is — anyone with EC2 launch permissions can spin up an unpatched server from it. Deregistering the image removes that risk; a retention policy prevents it from coming back.

The governance impact is audit readiness. Retaining everything without a policy fails most audit frameworks. The auditor's question is simple: 'show me your image retention standard.' "We keep everything" is not a standard — it is the absence of one. The right answer is a documented policy with named retention windows, tag-based exceptions, and evidence the policy is being enforced. Getting there is a one-time effort that closes a compliance gap and removes an ongoing cost simultaneously.