Expire Is Not a Promise
S3 lifecycle rules let you say "expire this object after 30 days," and AWS is careful never to call that deletion. The documentation uses "expiration action," schedules it for "the next applicable time," and reserves "delete" for the thing you do yourself, on purpose, with a request that gets a response. Expiration is something that happens to an object over time. Deletion is something you do to it, right now, and get told about.
That distinction is more honest than it looks. A scheduled background sweep across a distributed store genuinely can't give you the same guarantee as a synchronous delete call. The sweep runs on its own clock, batches its work, retries on its own terms, and reports success or failure to nobody in particular. Calling that "delete" would be claiming a level of certainty the mechanism doesn't have. AWS doesn't claim it. Fair enough.
But naming the gap doesn't close it. It just tells you whose job it is to close it. When a system says "I will expire this, and knowing it's gone is a separate arrangement," it has correctly declined to make a promise it can't keep, and handed you the job of finding out anyway. The honesty is real. It's also a transfer of labor, from the vendor's side of the API to yours.
Think about what "trusting the schedule" actually requires. You set a 30-day expiration, you look away, and at some point you need to know the object is gone, not scheduled to be gone, not probably gone, actually gone. There is an event for that, and it is opt-in: S3 emits s3:LifecycleExpiration:Delete when the sweep removes an object, and will hand it to SNS, SQS, Lambda, or EventBridge if you ask. Nothing in "expire after 30 days" tells you to ask. The lifecycle rule's contract ends at the schedule; the confirmation lives in a different subsystem you configure separately and have to know exists first.
The event also doesn't always say what you'd assume. On a versioned bucket, expiration doesn't remove bytes, it writes a delete marker, and what arrives is s3:LifecycleExpiration:DeleteMarkerCreated. The object is expired. The object is also still sitting there, retrievable by version ID by anyone with permission to ask for it. If your reason for expiring it was that the data shouldn't exist anymore, the notification you just got does not tell you that.
This is a specific and under-discussed cost. It's not that lifecycle expiration is unreliable, it's almost certainly not, at AWS's scale reliability isn't the interesting question. The cost is that the rule's own contract stops at "scheduled," and confirmation is a separate assembly job: wire up the notifications, learn which event type means which thing, fall back to inventory reports and a script that diffs a key list against what you expect to be left. None of that is hard. All of it is work that a "delete and confirm" API would have folded into one response, and none of it happens until you notice the gap and go do it.
The same shape shows up anywhere a system separates "I did the thing" from "the thing is now in the state you wanted." A cron job that kicks off a batch is not the same as the batch completing. A cache TTL is not the same as the cache being empty. A merge queue that says "merged" is not the same as the artifact being built, and a build succeeding is not the same as the artifact being deployed. Each of those systems is being precise, not evasive, by refusing to collapse the two. But precision about what a system can't promise is not the same as delivering what you need. Somebody still has to check.
What bugs me about the S3 case specifically is how easy it is to miss that the job got handed to you. "Expire after 30 days" reads like a delete with a delay bolted on. It isn't. It's a delete-shaped intention with the confirmation step unbundled and sold separately, and the unbundling is documented, which makes it worse to overlook, not better. You can't say nobody told you. They told you, carefully, in language exact enough that skimming it reads like reassurance.
None of this means you should distrust S3 lifecycle rules, or build a verification pipeline for every scheduled action in every system you touch. Most of the time the schedule runs and the object goes away and nobody needs to know beyond that it probably did. The point is narrower: when a vendor is precise about what they're not promising, that precision is a receipt, not a guarantee. Keep it. You'll need it the day someone asks you to prove the object is actually gone, and the answer turns out to be your job, not theirs.