Storage lifecycle

S3's lifecycle configuration is the common implementation: after a number of days, transition the object to a colder class, or expire it. The file does not move across the network for a transition. The store changes how it keeps the bytes, and the next retrieval can be slower or billed differently.

Expiry of the object is not expiry of a link. An expiring link stops the URL. A lifecycle delete removes the object, and every URL to it fails because there is nothing to fetch. A lifecycle transition keeps the object and changes the wait to read it. Teams who set "delete after 7 days" to clean a dropbox will break a download that was supposed to live for 30. Teams who only expire links leave the object billed forever.

A receiving bucket expires objects 14 days after creation and aborts incomplete multipart uploads after 2 days. A 20 GB delivery uploaded on the 1st disappears on the 15th. A client who waits until the 16th gets 404, and the access log shows the GET after the delete. An incomplete upload from a crashed client on the 3rd stops accruing part storage on the 5th because the abort rule ran. Without that second rule, failed uploads outlive the files that succeeded. Replication and versioning interact. Expiring the current version can leave older versions. A residency review that lists only current objects misses those versions in the same region, or replicas in another.

NIST SP 800-88 is the sanitization text for media. A lifecycle delete in an object store is a logical delete. It is what you need so the API stops serving the file. It is not a certificate that every disk sector was wiped. Say which of those you mean when a contract requires destruction.