Configure lifecycle and versioning policies

This is the rare capability where the security finding and the cost lever are the same thing. S3 charges by the gigabyte-month, with rates varying by more than 23 times across storage classes, and ECR charges a flat rate per gigabyte-month for stored images. Without lifecycle rules, every byte stays in the most expensive tier forever, and three categories of waste accumulate silently: cold data still paying Standard rates, noncurrent versions piling up in versioned buckets, and orphaned multipart-upload fragments and stale CI images that nobody will ever read again.

The cost is sneaky because the visible part of a bucket, the current objects, can look stable while the invisible part, the retained old versions, balloons. On a high-churn bucket the noncurrent-version cost can exceed the live data, and a single neglected CI repository has reached terabyte scale at real money per month, composed entirely of build artifacts nobody referenced after the build completed.

From a finance standpoint this is one of the cleanest returns in cloud cost management: a one-time configuration decision per resource, with no recurring cost to act on and almost no downside, because the data being aged out is old copies nobody uses. The decision to make is the retention window, with the data owners, not whether to clean up at all. The right metric is the trend, the share of spend in stale tiers and noncurrent versions, which should fall after a policy and stay low.

Priya brings the cluster of S3.13, S3.10 and ECR.3 findings to her finance partner because, unusually, the security report and the storage bill are pointing at the same thing. The instinct is to ask what the fix costs, and the answer is the opposite of most cloud work: this is the rare capability where remediation has no recurring cost and actually reduces the bill. The data being aged out is old copies and stale images nobody reads, so there is no trade-off to negotiate beyond choosing a retention window. The finance partner treats it as among the cleanest returns in cloud cost management, a one-time configuration decision per resource that buys down a silently compounding line.

What Priya's partner needs to size is the hidden footprint, because the bill lies about it. The CI artifacts bucket shows 1,842 current objects in the console but 51,367 noncurrent versions billing underneath, roughly 8 TB of dead copies the console hides. The same shape recurs across versioned buckets and busy ECR repositories, where a single neglected registry has reached terabyte scale on build artifacts nobody referenced after the build completed. She prioritises by storage size and by churn rather than by finding count, since high-churn buckets accumulate fastest even when their live data is small, agrees the retention windows with the data owners, and tracks the share of spend in stale tiers and noncurrent versions as the metric that should fall and stay low.

The defining feature of this category, for budgeting, is that it grows by itself. Most cost lines move when the business does; retained-version and stale-image storage grows with how often files are rewritten and how often builds run, which has nothing to do with business value. So you can see a storage line climbing steadily while the team honestly reports that nothing new is happening, and both can be true. That makes it a recurring source of unexplained variance, exactly the kind of line that erodes trust in the forecast.

The fix is unusually clean from a finance perspective: a one-time policy decision with essentially no ongoing cost and no downside, because the data being deleted is old copies nobody uses. There is no trade-off to negotiate beyond choosing the retention window. Compared with most cost-optimisation work, which involves engineering effort, risk and judgement, this is closer to free money once the policy is set.

The right metric is the share of storage spend in stale tiers and noncurrent versions, available from S3 Storage Lens and Cost Explorer's storage-class breakdown. Before remediation it can be the majority of a resource's cost; after a policy it should settle to a small, stable fraction. A rising share is a leading indicator that new buckets or repositories are being created without the standard applied, the same governance gap that produces other slow-burn waste.

Container images and stored objects grow forever at full price unless a cleanup rule is attached. Most organisations have dozens of buckets and repositories, each quietly accumulating months or years of data nobody touches. The bill is silent, continuous, and invisible until someone looks. Security Hub flags the absence of a rule as S3.13, S3.10 and ECR.3, a rare two-for-one where the compliance finding is also the cost leak.

The fix is a lifecycle policy: a short configuration that tiers, expires or prunes data after a defined age. It is a one-time setup per resource and then self-maintaining. The leadership question is not the dollar amount in any one quarter; it is whether the organisation has a default retention standard applied at creation, so this never silently accumulates in the first place.

This is a hygiene and policy decision more than a technical one, and it clears a cluster of compliance findings as a bonus. The right outcome is a retention decision made once, deliberately, rather than discovered years later in a cost review.

A storage line that had climbed quietly for two years finally drew leadership attention when a cost review found a bucket billing 9 TB while the console showed 800 GB. The executive team stopped treating the S3 and ECR findings as a security backlog item and saw the shape for what it is: storage that compounds on autopilot, invisible in the obvious dashboards, and trivially preventable with a default rule. The dozens of buckets and repositories each accumulating data nobody touches were not a security curiosity, they were one question the company had never decided, namely whether storage has a retention standard applied at creation.

Leadership set the end state rather than the implementation: a default lifecycle policy applied automatically when a bucket or repository is created, so retention is a decision made once and then self-maintaining, rather than discovered years later in a cost review. Because the controls are Security Hub findings, the decision cleared a cluster of compliance items as a bonus and, for ECR, reduced stale attack surface at the same time. The question the team settled was not how much are we wasting on old copies, it was whether the organisation has a default retention standard so this never silently accumulates again.

This category is worth a moment of leadership attention because of its shape: it compounds quietly, it is invisible in the obvious dashboards, and it is trivially preventable with a default policy. A small, stable noncurrent-version and stale-image share means the organisation has a working retention standard applied by default; a growing one means resources are being created ad hoc with no cleanup rule, the same absence of defaults that produces other accumulating costs.

Because these map to Security Hub controls, fixing them improves the security posture dashboard at the same time it cuts cost, and the ECR case also reduces stale attack surface. The leadership question is not how much we are wasting on old copies; it is whether we have a default retention standard for storage and registries, applied automatically at creation. If the answer is yes, this never becomes a line item worth discussing again.