Summary

  • An ordinary deletion in a versioning-enabled S3 bucket creates a delete marker rather than permanently erasing payload versions; a normal read can return 404 while retained versions remain chargeable.
  • Removing an expired delete marker is not the operation that expires older payload versions. Noncurrent-version expiry has its own conditions, and protected versions remain outside lifecycle deletion.
  • AWS distinguishes genuinely expired objects awaiting asynchronous removal from retained versions that have merely lost ordinary visibility. Class-specific minimum-duration charges are another separate consideration.

The application and the budget see different endings

An application can stop finding a key without the storage system ceasing to hold the data behind it. AWS’s version-deletion guide makes this distinction explicit for a bucket with versioning enabled: a simple deletion, without a version identifier, introduces a delete marker. It does not permanently remove the payload versions.

The marker becomes the current version. An ordinary read that does not ask for a particular version then receives a 404, and ordinary object listings omit a key whose current version is a marker, according to the delete-marker documentation. Neither observation is a version inventory.

That difference gives two teams plausible but incompatible completion measures. The application owner has removed something from normal use. The storage owner still needs to explain what remains. This is not a finding that AWS concealed a fee or that a customer suffered an unexpected bill. It is the published behaviour of a retention mechanism, and the economics depend on how an organisation chooses to use it.

The marker is small; the retained payload need not be

AWS says normal rates apply to stored and transferred object versions, including noncurrent ones. The chargeable unit does not disappear because its key has dropped out of an ordinary list. A business that counts only visible keys therefore lacks the information needed to infer a reduction in retained payload bytes.

The marker itself is different. It has no payload data and occupies storage corresponding to its UTF-8 key name in S3 Standard. Confusing that modest marker footprint with the storage occupied by older payloads sends a cost review toward the wrong object.

It can be sensible to keep those older versions. They may preserve a recovery option after a mistaken deletion or overwrite. The commercial question is whether that option still has an owner and a purpose, not whether every noncurrent byte is waste. A budget that treats all preserved versions as an accident can be as misleading as one that treats every 404 as completed erasure.

“Expired marker” does not mean “expire everything behind it”

The marker-management guide defines an expired object delete marker as the single remaining marker after all object versions have been deleted. Clearing that residue is not the act that clears the older payloads. The definition describes what is already absent.

Nor is another ordinary deletion necessarily a clean-up operation. If a marker is already current, a deletion without its version identifier adds another marker. Removing the current marker can instead make an earlier version current again, restoring ordinary visibility. These are different state changes, not interchangeable evidence that a storage commitment has ended.

This article does not prescribe any deletion request or perform one. The distinction matters at acceptance: a report titled “deleted objects” needs to say whether it counts hidden keys, removed markers or permanently removed payload versions. The label alone cannot tell finance which storage has gone.

The relevant clock may start later

AWS’s expiration guide separates current-version expiration from noncurrent-version expiration. In an enabled bucket, expiring a current payload can create a marker and make the payload noncurrent. It does not, by that act alone, expire the other noncurrent versions.

The lifecycle-elements guide adds an important condition. When both a noncurrent-age threshold and a number of newer noncurrent versions are configured, both must be exceeded before the specified older version is removed. Time spent noncurrent is not the same as time since original creation. A rule that appears to express “keep for this many days” may also deliberately preserve a number of versions.

The guide describes a separate permanent, unrecoverable action for noncurrent-version expiration. That makes rule acceptance a decision about recovery as well as cost. The correct response to unexplained retention is not to assume that a broad deletion rule should immediately be imposed.

Protection provides another limit. The Object Lock considerations say lifecycle processing can still place markers and transition storage classes, but cannot delete a protected version through an expiration policy. The marker is not itself WORM-protected. Apparent disappearance and preservation can therefore coexist by design, without showing that the protected payload was destroyed or that the protection failed.

Physical delay is not automatically a billing leak

There is a necessary counterpoint to the retained-version argument. AWS says objects that have actually expired may wait for asynchronous physical removal, and that expiration and the storage time associated with such expired objects are not charged. Physical presence during that delay is not enough to allege continued billing.

The exception cannot simply be extended to every payload made noncurrent by a marker. The relevant question is whether that version has met its applicable expiration conditions. The same expiration guide describes conditions, including pending or failed replication states, under which lifecycle does not take the relevant action. A customer-specific conclusion would require the actual version and policy evidence; none was inspected here.

AWS’s pricing page introduces a different consideration: minimum storage durations. Standard-IA and One Zone-IA have 30-day minimums, Glacier Instant Retrieval and Flexible Retrieval 90 days, and Deep Archive 180 days. Early deletion, overwriting or transition can attract a prorated charge for the remaining minimum period. This is not a universal 30-day S3 Standard rule.

The same page makes DELETE and CANCEL requests free. A zero request price is not a promise that retained payload storage or class-specific minimum commitments are free. Nor do these published conditions establish any particular customer’s effective rate or saving.

A smaller visible list is the wrong acceptance object

The Storage Lens metrics glossary separates noncurrent-version bytes from delete-marker bytes. Its current-version object count includes current markers, so even a metric with “current” in its name should not casually be read as a count of accessible files. The free metrics are collected daily rather than providing instantaneous evidence of every state change.

Storage Lens also excludes objects that have expired but have not yet been removed. Its reporting boundary is not a claim to show every physically present byte. A review should use those distinctions to ask better questions, not recast one dashboard as a real-time forensic inventory or an actual invoice.

For the buyer, the durable acceptance object is a reconciliation of version states and their reasons for remaining: useful recovery versions, protected versions, versions not yet eligible, and versions that have genuinely expired. An ordinary 404 belongs to a different column. S3’s flexibility is valuable precisely because disappearance need not be irreversible. That same flexibility makes disappearance an inadequate measure of whether the storage commitment has ended.

Sources