Cost

Tame excessive S3 object versioning

Versioning is on, lifecycle rules aren't — buckets quietly accumulate every overwrite and delete-marker forever. Find them and trim the tail.

14 min·10 sections·AWS

Last reviewed 27 May 2026

Excessive versioning: the basics

What does it mean for an S3 bucket to carry excessive versions?

S3 versioning is a per-bucket switch that, once enabled, preserves every prior state of every object. A PutObject to a key that already exists doesn't overwrite — it adds a new version. A DeleteObject doesn't delete — it inserts a delete-marker and tucks the previous version away as noncurrent. The default ListObjectsV2 call only shows current versions, so the bucket looks the same size it has always been while the storage bill quietly climbs.

A bucket is flagged as having excessive versioning when versioning is enabled and there are no lifecycle rules expiring noncurrent versions. The signal is structural, not metric — the wastage check doesn't need to know how much noncurrent storage you carry to know you're guaranteed to accumulate it forever. Three years of daily build artefacts, log rotations, or terraform-state overwrites compound into thousands of noncurrent copies for a single key.

The pattern that gets flagged in practice is the unintentional kind: versioning was enabled at bucket creation as a "safety net" or by a compliance template, the team writes to the bucket like it's a regular store, and nobody adds a NoncurrentVersionExpiration rule. Months later S3 Storage Lens shows that 80% of the bucket's bytes are noncurrent. Each of those bytes bills at the full Standard rate — roughly $0.023/GB-month — until lifecycle catches up.

In this lesson you'll learn how versioning and writes actually interact under the hood, why the default ls view hides the cost, and how to size the noncurrent tail using list-object-versions and Storage Lens. You'll see the two-rule lifecycle pattern that fixes the leak permanently, and how Intelligent-Tiering can drop noncurrent bytes to Archive Access automatically when retention is non-negotiable.

Fun fact

The terraform-state iceberg

A team running Terraform against a versioned tfstate bucket discovered they were paying for 47 GB of storage on a bucket that showed 9 MB in the console. Every terraform apply had been writing a fresh state file for two years — roughly 8,000 noncurrent versions of terraform.tfstate, each a few MB, none ever expired. The fix was a 30-day NoncurrentVersionExpiration rule that immediately reclaimed 99.98% of the bytes on the next lifecycle sweep. The bill drop was rounding-error money for them, but the same pattern at petabyte scale is how organisations end up paying six figures a year for storage nobody can name.

Excessive versioning in action

Nina runs platform engineering at an analytics company. A FinOps review flags a bucket called acme-data-warehouse-staging as carrying excessive versions — versioning on, no lifecycle, $4,200/month in S3 Standard.

She runs a quick s3 ls --summarize and the bucket reports 320 GB of current objects. At $0.023/GB-month that should be roughly $7.40 — three orders of magnitude below the bill. The discrepancy can only be one thing: noncurrent versions.

She drops to list-object-versions and the picture clears up. Current versions: 320 GB. Noncurrent versions: 178,000 entries totalling 174 TB. The bucket is a parquet staging area; every nightly ETL writes the same key paths, and every prior run is still there, two years deep.

First, confirm versioning is on and check whether any lifecycle rule expires noncurrent objects.

$ aws s3api get-bucket-versioning --bucket acme-data-warehouse-staging && aws s3api get-bucket-lifecycle-configuration --bucket acme-data-warehouse-staging

{

"Status": "Enabled",

"MFADelete": "Disabled"

}

An error occurred (NoSuchLifecycleConfiguration) when calling the GetBucketLifecycleConfiguration operation: The lifecycle configuration does not exist

# Versioning on, lifecycle absent — noncurrent versions accumulate forever.

The exact signature the wastage check looks for: versioning enabled, no lifecycle rule.

Now size the noncurrent tail. list-object-versions returns every version and delete-marker — count and sum the ones where IsLatest is false.

$ aws s3api list-object-versions --bucket acme-data-warehouse-staging --output json --query 'Versions[?IsLatest==`false`].Size' | jq 'add / 1024 / 1024 / 1024'

# (paginated, ~178k entries — running in the background)

178142.7

# 178 TB of noncurrent versions. At S3 Standard $0.023/GB-month that's ~$4,200/month.

# Current objects: 320 GB. Noncurrent multiplier: ~556×.

Noncurrent versions outweigh current data by more than 500×. The bill is the bill.

Excessive versioning under the hooddeep dive

S3 versioning has three states per bucket: Unversioned (the default), Enabled, and Suspended. Once a bucket has ever been Enabled, you can't go back to Unversioned — only Suspended, which stops new versions from being created but leaves every existing one in place. The cost path is one-way: the only way to actually reduce a bucket's footprint is to delete noncurrent versions and delete-markers explicitly, either by hand or via lifecycle.

Each write generates a new version with a unique VersionId. The previous version isn't deleted, moved, or tagged — it stays at the same key, same storage class, billed at the full per-GB rate of that class. DeleteObject on a versioned bucket inserts a zero-byte delete-marker (which itself is a version) and demotes the previously-current version to noncurrent. DeleteObject followed by PutObject on the same key therefore leaves three version records: the delete-marker, the old noncurrent version, and the new current version. Multipart uploads that fail or are abandoned add yet another category: incomplete multipart upload parts, billed by part size, invisible in the version list, and only cleanable via AbortIncompleteMultipartUpload.

Lifecycle is the only at-scale tool to clean this up. NoncurrentVersionExpiration deletes versions that have been noncurrent for N days. NoncurrentVersionTransition moves them to a cheaper class first (e.g. Glacier Instant Retrieval at $0.004/GB-month, an 83% drop from Standard). AbortIncompleteMultipartUpload cleans up stranded parts. Lifecycle runs asynchronously once a day — expect a 24-48 hour lag between applying the rule and seeing the bill drop, and S3 doesn't charge for the lifecycle delete actions themselves.

# Inspect noncurrent storage at scale via S3 Storage Lens (free metrics dashboard).
aws s3control get-storage-lens-configuration \
  --account-id 123456789012 \
  --config-id default-account-dashboard

# The metric you want is NonCurrentVersionStorageBytes — broken down by bucket and prefix.
# Storage Lens samples daily; treat it as the authoritative source for noncurrent footprint.

What is the impact of unbounded versioning?

The direct cost is linear and merciless. Every overwrite of a 50 MB parquet file in a daily ETL adds 50 MB of noncurrent storage. After a year of daily runs you're paying for ~18 GB of revision history per key. Multiply by every key the job touches and the bucket's footprint outruns the visible data by 1-2 orders of magnitude. At Standard rates a multi-TB noncurrent tail is the difference between a $50/month bucket and a $5,000/month bucket — and the team responsible for the bucket genuinely doesn't see it in the console.

The second-order impact is investigative cost. When someone finally notices, the first reaction is usually "can we just delete the old versions?" — which is correct, but you can't s3 rm your way out of millions of versions in any reasonable time. You either write a lifecycle rule and wait 24-48 hours, or you script a bulk-delete via delete-objects with VersionId set, hammer the bucket for hours, and pay the per-request charge ($0.0005 per 1,000 deletes) for the privilege. A bucket with 10M noncurrent versions costs $5 just to clean up.

There's also a security and compliance angle. Versioning is often kept on for genuine reasons — ransomware resilience, audit trails, immutability for SOX or HIPAA. The wastage check isn't telling you to turn it off; it's telling you that without lifecycle, you can't distinguish "versions we need" from "versions we forgot." When an auditor asks how long a particular document has been retained, an unbounded version list is harder to attest against than a deliberate 90-day retention policy.

Finally, suspended versioning is a trap. Teams often hit Suspended thinking they've stopped the bleeding — but every existing noncurrent version still bills exactly the same, and writes after suspension still create a version-id of null that behaves oddly with subsequent re-enables. The fix is lifecycle, not the versioning switch.

How do you tame versioning safely?

Excessive versioning is one of the cleanest leaks to fix in S3 — a single lifecycle policy stops it permanently. The four-step loop below scales from a single bucket to a fleet of thousands.

1. Inventory the noncurrent tail

Turn on S3 Storage Lens (free tier covers 28 days of organisation-level metrics) and sort buckets by NonCurrentVersionStorageBytes descending. The top 5-10 buckets almost always carry 90%+ of the waste. For each one, run aws s3api list-object-versions --bucket <name> --query 'Versions[?IsLatest==\false`].Size' | jq 'add'` to confirm the magnitude before you change anything.

2. Apply the two-rule lifecycle pattern

Every versioned bucket should have at least two lifecycle rules: NoncurrentVersionExpiration set to 30-90 days (start at 90 for safety; shorten once you've watched a few cycles), and AbortIncompleteMultipartUpload set to 7 days. Together these cover the two ways S3 silently accumulates orphan bytes. If retention is non-negotiable for compliance, add a NoncurrentVersionTransition to Glacier Instant Retrieval or Intelligent-Tiering Archive Access at 30 days — you keep the version, you stop paying Standard rates for it.

3. Verify with Storage Lens, not the console

The console shows current object size, not bucket footprint. After applying lifecycle, wait 48 hours and check Storage Lens — NonCurrentVersionStorageBytes should fall sharply, and the Cost & Usage Report will show the StorageObjectSize line item drop on the next billing cycle. If the number doesn't move, the most common cause is a rule scoped to a prefix that doesn't match the keys you thought it did. Always test with aws s3api get-bucket-lifecycle-configuration and re-read the filter.

4. Prevent recurrence with AWS Config or SCP

AWS Config managed rule s3-version-lifecycle-policy-check flags any versioned bucket without a NoncurrentVersionExpiration rule — wire it into your remediation pipeline (or a Slack channel) so a new bucket created without lifecycle is flagged within minutes, not months. For multi-account orgs an SCP can deny s3:PutBucketVersioning unless paired with s3:PutBucketLifecycleConfiguration in the same template — bluntly forcing every new versioned bucket to ship with a retention policy.

# The standard two-rule lifecycle for a versioned bucket.
cat > lifecycle.json <<'EOF'
{
  "Rules": [
    {
      "ID": "expire-noncurrent-versions",
      "Status": "Enabled",
      "Filter": {},
      "NoncurrentVersionExpiration": { "NoncurrentDays": 90 }
    },
    {
      "ID": "abort-incomplete-multipart",
      "Status": "Enabled",
      "Filter": {},
      "AbortIncompleteMultipartUpload": { "DaysAfterInitiation": 7 }
    }
  ]
}
EOF

aws s3api put-bucket-lifecycle-configuration \
  --bucket acme-data-warehouse-staging \
  --lifecycle-configuration file://lifecycle.json

# Lifecycle is async — give it 24-48 hours, then verify via Storage Lens.

Quick quiz

Question 1 of 5

A versioned bucket shows 50 GB in the console but $1,200/month on the bill. What's the right first move?

Keep learning

Dig deeper into S3 versioning, lifecycle, and the visibility tooling around them.

You've completed Tame excessive S3 object versioning. You now know why the default object list hides the cost, how to size the noncurrent tail with list-object-versions and Storage Lens, and the two-rule lifecycle pattern that stops the leak permanently. The next time a versioned bucket shows up on a FinOps report, you'll have the four-step loop — inventory, lifecycle, verify, prevent — ready to apply.

Back to the library

Excessive S3 versioning: what it costs and how to model it

Unbounded version accumulation is a predictable, fixable storage overage — with clean unit economics

S3 versioning keeps a permanent copy of every previous state of every object in a bucket. Without a lifecycle rule to expire old versions, every write permanently increases the bucket's storage footprint at the full Standard rate ($0.023/GB-month). The console only shows current objects, so the bill can be 10x, 100x, or even 500x what the visible data implies — a common source of unexplained S3 overages in FinOps reviews.

The unit economics are straightforward: if a 50 MB file is overwritten daily, after one year you're carrying ~18 GB of noncurrent versions for that single key, costing roughly $0.41/month in noncurrent storage alone. Scale that across every key an ETL job touches and noncurrent storage often eclipses current storage by one to two orders of magnitude. The flagged signal — versioning on, no NoncurrentVersionExpiration rule — is the exact condition that guarantees unbounded accumulation.

This is a tiering and retention policy question, not a binary on/off decision. Some buckets need versioning for compliance or ransomware resilience; the fix is a lifecycle rule that caps retention (e.g. keep noncurrent versions for 90 days, then expire). Others have versioning on by accident and need it governed. Either way, the cost is fully preventable once a retention policy is in place, and the dollar savings from adding a single lifecycle rule can be immediate and substantial.

This lesson is for the finance partner who wants to understand why an S3 bucket's bill can dwarf what the console shows, and what it takes to fix it. You'll get the unit economics of noncurrent version accumulation — the per-GB math, the multiplier effect of high-churn buckets, and how to read Storage Lens to size the exposure. The focus is on the retention policy decision: which buckets need a compliance-grade version history, which ones have versioning on by accident, and how to set a NoncurrentVersionExpiration rule that caps the cost without removing the safety net.

Fun fact

The terraform-state iceberg

How a finance partner frames the noncurrent storage conversation

Marcus is a FinOps analyst who notices acme-data-warehouse-staging appearing near the top of the month's S3 cost variance report — up $900 from last month with no new workloads launched. The console shows 320 GB; at $0.023/GB-month that should be under $8. The actual charge is $4,200.

He pulls the Storage Lens dashboard and the culprit is immediate: NonCurrentVersionStorageBytes for that bucket is 174 TB — 556 times the visible footprint. Each nightly ETL run has been permanently appending to the version chain for two years. There's no NoncurrentVersionExpiration rule, so every byte has billed at Standard rates from the day it was written.

Marcus brings the number to the team with a simple frame: 174 TB of noncurrent storage at $0.023/GB-month is $4,002/month. A 90-day NoncurrentVersionExpiration rule would retain 90 daily runs of history — more than enough for any realistic rollback need — and eliminate roughly 99% of the noncurrent footprint within 48 hours of the rule being applied. That's ~$3,960/month in recoverable savings from a single lifecycle rule on a single bucket, at no risk to the data the team actually uses.

Quantifying the impact on the cloud bill

The financial impact of unbounded versioning is a compounding storage cost that grows in direct proportion to write frequency and data size, with no natural ceiling. A 100 MB object overwritten daily accumulates 36 GB of noncurrent storage in a year. At $0.023/GB-month that's $0.83/month per key per year — trivial for one key, significant at scale. A bucket with 10,000 active keys and daily writes can accumulate $8,000/month in noncurrent charges within 12 months, all invisible in the console's current-objects view.

The cost is especially easy to miss in the monthly bill because it appears as a single S3 StorageObjectSize line item with no breakdown by current versus noncurrent. Finance teams frequently attribute it to data growth when it's actually version accumulation. The correct diagnostic is S3 Storage Lens's NonCurrentVersionStorageBytes metric, which separates current from noncurrent footprint by bucket and prefix — the only view that lets you size the exposure and model the savings from a lifecycle rule.

From a chargeback perspective, noncurrent storage is almost always a shared-platform or DevOps cost center line that rarely gets allocated back to the team running the workload. That's part of why it persists: the team paying the bill isn't the team generating the writes. Tagging versioned buckets to their owning teams and surfacing noncurrent storage in the internal chargeback report is the forcing function that turns this into a team-level action item rather than a platform-level shrug.

Remediation has a clean ROI calculation. A 90-day NoncurrentVersionExpiration rule applied today means 90 days from now the noncurrent footprint is capped at 90 days of writes — after which it's a flat line. The savings are the difference between current noncurrent storage and the equilibrium footprint after lifecycle runs. For a bucket that's been accumulating for two years, that recapture is often 90%+ of the noncurrent charge, realised within 48-72 hours.

What finance can do to close the noncurrent versioning gap

Finance doesn't write lifecycle rules, but it owns the framing and the cadence that turn a recurring overage into a managed line item. Four levers applied at the regular cost review.

1. Use Storage Lens to size and rank the exposure

Before the cost review, pull NonCurrentVersionStorageBytes from S3 Storage Lens sorted by bucket descending. The top 10 buckets typically hold 90%+ of the noncurrent footprint. Convert bytes to dollars at $0.023/GB-month (or the actual blended storage rate from Cost Explorer) and present the list as a ranked savings opportunity. This reframes the conversation from 'we have a versioning problem' to 'here are the ten buckets, here is the dollar amount recoverable from each, and here is the cost of a 90-day lifecycle rule on each one.'

2. Allocate noncurrent storage to workload owners in chargeback

If noncurrent storage rolls up to a shared platform cost center, the teams generating the writes have no incentive to add lifecycle rules. Tag versioned buckets to their owning team (via Owner or CostCenter tags), include NonCurrentVersionStorageBytes in the internal chargeback report, and watch how quickly teams add lifecycle rules when the cost lands in their budget. This is the accountability mechanism that makes the fix self-sustaining.

3. Require a retention policy for all new versioned buckets

Work with the platform team to make lifecycle policy a gate on any new bucket creation request — just as you'd require a cost-center tag. A simple questionnaire: does this bucket need versioning? If yes, what is the minimum retention window for compliance or rollback purposes? That answer becomes the NoncurrentVersionExpiration rule. The one-time effort of adding this gate prevents the next two years of silent accumulation.

4. Model the savings before and after lifecycle runs

When a lifecycle rule is applied, model the expected equilibrium footprint: (writes per day) × (retention window in days) × (average object size). Compare that to the current noncurrent footprint. The delta is the recoverable savings, realised within 48-72 hours. Tracking actual versus modelled savings in the following month's report closes the loop and builds credibility for future remediation investments.

Quick quiz

Question 1 of 5

A FinOps review flags a versioned S3 bucket whose Storage Lens shows 85 TB of noncurrent storage but only 200 GB of current objects. The bucket has no lifecycle rule. Engineering wants to turn versioning off entirely. As the finance partner, what's the right recommendation?

Keep learning

Dig deeper into S3 versioning, lifecycle, and the visibility tooling around them.

You've finished the finance partner's view of excessive S3 versioning. You know how to size the noncurrent footprint using Storage Lens, how to model the savings from a NoncurrentVersionExpiration rule before it's applied, and the four levers — Storage Lens ranking, chargeback allocation, new-bucket gates, and closed-loop savings tracking — that turn a recurring overage into a managed line item. Next time this shows up in the cost report, you'll have the questions and the frame to move it from 'S3 went up again' to 'here's the retention policy, here's the savings, here's who owns it.'

Back to the library

Excessive S3 versioning: the headline

Storage bills that grow silently because retention policy was never set

S3 versioning is a useful safety feature — but without a corresponding retention policy, it accumulates every historical copy of every file forever, at full storage rates. The console hides this: teams see the current data footprint while the bill reflects the entire revision history. This is one of the most common sources of surprise S3 costs across cloud organisations.

The finding doesn't mean versioning should be turned off. It means the organisation hasn't decided how long old versions should be kept. A deliberate retention policy — 30, 60, or 90 days of history, codified in a lifecycle rule — gives you the safety net versioning was intended to provide without open-ended cost accumulation. The leadership question is whether data retention is being managed by policy or by default. Right now, for the flagged buckets, the answer is by default.

A concise read for the executive who wants to understand the governance gap this finding exposes. You'll get the plain-English explanation of why versioning without lifecycle is an unlimited-spend commitment, what a deliberate retention policy looks like, and how to tell whether the organisation is managing storage retention by policy or by default. No CLI or configuration detail — just the framing for asking the right question at the next cloud cost review.

Fun fact

The terraform-state iceberg

What unbounded versioning looks like from the top

At one company the VP of Engineering, Claire, received a quarterly S3 cost report showing a 340% year-over-year increase in storage costs despite no significant growth in active data. The team had been attributing it to business growth. A FinOps review found the real cause: twelve buckets with versioning enabled and no lifecycle rules, accumulating every historical copy of every file since the buckets were created.

The team had enabled versioning in good faith — it was a compliance template requirement for one workload that got copy-pasted across the fleet. Nobody had paired it with a retention policy. The result was three years of write history billed at full Standard rates, invisible in the console, showing up only in the bill.

Claire's takeaway wasn't to disable versioning — the safety net had genuine value for some of those buckets. It was that the organisation had an unwritten retention policy ('keep everything forever') that nobody had deliberately chosen. The fix was a one-hour policy decision — 90 days of noncurrent history for operational buckets, 1 year for compliance-designated ones — applied as lifecycle rules across the fleet. S3 cost dropped by 60% the following month.

Why this is a governance issue, not just an engineering one

Unbounded S3 versioning is a governance gap: the organisation is making an implicit decision to retain every historical copy of every object forever, but nobody made that decision explicitly. The result is storage costs that compound quietly in the background while the teams responsible have no visibility into them and no mechanism to manage them.

The executive-level impact shows up in three places. First, the cloud bill grows at a rate that doesn't track business activity — a reliable indicator that cost attribution and accountability are not working. Second, retention posture is inconsistent: some buckets carry years of version history while others carry days, based on nothing more than when lifecycle was set up. That inconsistency is a compliance and audit risk as much as a cost one. Third, the teams generating the most writes are often the ones least aware of the cost, because noncurrent storage charges accumulate in platform accounts and don't flow back to the workload owners.

The fix requires two things that are organisational rather than technical: a retention policy (how long is old data kept, by tier or classification), and an accountability mechanism (who sees the noncurrent storage cost for the buckets their workloads write to). Once those exist, lifecycle rules are just the implementation. Without them, lifecycle rules get added reactively when someone notices the bill, and the same pattern re-emerges six months later on a new bucket.

The leadership move on excessive versioning

The executive handle is a retention policy and an accountability model — not a mandate to add lifecycle rules to every bucket. Two decisions that make the fix self-sustaining.

1. Establish a retention policy by data tier

Set a simple standard: operational data (ETL outputs, build artefacts, logs) retains noncurrent versions for 30-90 days; compliance-designated data retains for whatever the regulatory requirement is; everything else follows the operational default. This one-page policy gives engineering a clear rule to implement in lifecycle configuration and gives finance a benchmark to measure against. Without it, every bucket is a negotiation.

2. Make noncurrent storage visible in team budgets

If S3 cost is a shared-platform line that nobody owns, noncurrent accumulation is everybody's problem and nobody's priority. Surfacing noncurrent storage cost by workload owner in the chargeback report — even as an FYI line before it's a hard charge — creates the visibility that drives action. Teams that see their own noncurrent footprint add lifecycle rules; teams that don't, don't.

3. Ask for the retention coverage number, not the finding count

The one-line question at the cloud governance review: 'what percentage of versioned buckets have a lifecycle policy, and what percentage of noncurrent storage bytes are covered by one?' A 95%+ coverage rate, trending up, means retention is governed by policy. A flat or declining rate means the gate on new bucket creation isn't working and needs a harder control.

Quick quiz

Question 1 of 5

Your cloud governance report shows 40% of versioned S3 buckets across the organisation have no lifecycle policy, accounting for $180,000/year in estimated noncurrent storage costs. The platform team proposes a project to manually audit and fix each bucket over six months. What's the right leadership response?

Keep learning

Dig deeper into S3 versioning, lifecycle, and the visibility tooling around them.

That's the lesson. Two takeaways: versioning without a retention policy is an unlimited-spend commitment that nobody made deliberately, and the fix requires an organisational decision (what's the retention standard by data tier?) before it requires any technical work. The leadership question is whether noncurrent storage costs are visible to the teams generating them and governed by a policy. If not, the same pattern will keep recurring on every new bucket.

Back to the library

Part of the learning path Cut your storage bill

Tame excessive S3 object versioning

Excessive versioning: the basics

The terraform-state iceberg

Excessive versioning in action

Excessive versioning under the hooddeep dive

What is the impact of unbounded versioning?

How do you tame versioning safely?

1. Inventory the noncurrent tail

2. Apply the two-rule lifecycle pattern

3. Verify with Storage Lens, not the console

4. Prevent recurrence with AWS Config or SCP

Quick quiz

Keep learning

Excessive S3 versioning: what it costs and how to model it

The terraform-state iceberg

How a finance partner frames the noncurrent storage conversation

Quantifying the impact on the cloud bill

What finance can do to close the noncurrent versioning gap

1. Use Storage Lens to size and rank the exposure

2. Allocate noncurrent storage to workload owners in chargeback

3. Require a retention policy for all new versioned buckets

4. Model the savings before and after lifecycle runs

Quick quiz

Keep learning

Excessive S3 versioning: the headline

The terraform-state iceberg

What unbounded versioning looks like from the top

Why this is a governance issue, not just an engineering one

The leadership move on excessive versioning

1. Establish a retention policy by data tier

2. Make noncurrent storage visible in team budgets

3. Ask for the retention coverage number, not the finding count

Quick quiz

Keep learning

Related cost lessons