S3 Data Deletion: Versions, Replicas and Retention
Short answer
Deleting an object from a versioning-enabled Amazon S3 bucket can hide its current name while leaving earlier data versions available. A complete deletion decision must identify the approved versions, retention constraints, replica destinations and independent backups. Verify each location separately. An empty ordinary object listing is insufficient evidence that every retained copy is gone.
Keep two claims separate: removal through the customer's cloud interface and sanitization of the provider's underlying physical media. S3 API responses can support the first within a defined scope. They do not give an operator direct evidence that particular disks or flash cells have been overwritten.
Who this is for
This guide is for authorized storage administrators and data-removal reviewers working with general purpose Amazon S3 buckets whose versioning status is Enabled. The command examples use AWS CLI v2 syntax checked against the command reference on November 3, 2026. Record your installed version and verify its help before adopting the examples.
Versioning-suspended buckets, directory buckets, S3 on Outposts and other vendors' S3-compatible implementations need separate procedures. A familiar API name does not establish identical deletion semantics. This article concerns a reviewed object or dataset, not indiscriminate bucket emptying.
Verification note: The checks below define evidence to collect and conditions for acceptance. No AWS account was inspected, no customer object was deleted and no cloud deletion experiment was performed for this article. All bucket, account, key and version placeholders are illustrative.
When to use this
Use this workflow when retiring a dataset, responding to an approved deletion request or reconciling a successful application delete with copies that remain in storage. It is especially useful when object versioning, cross-account replication, lifecycle expiration or retention controls are involved.
When not to use this
Stop when ownership, scope or the retention decision is unresolved. Do not remove a legal hold, bypass governance retention, shorten a policy or delete an encryption key to force a clean-looking result. Those are separate decisions with different effects. If your role cannot inspect the relevant locations, record that evidence gap rather than claiming they are empty.
What a delete marker actually establishes
An object key names a series of versions when versioning is enabled. A simple delete without a version ID normally creates a delete marker. The previous data version becomes noncurrent; its bytes are not removed by that marker. A request for the current object can consequently appear to find nothing even though version-specific retrieval remains possible for an authorized principal.
Removing the marker can expose the previous version again. Deleting a specific data version also requires care: if an older version remains, changing the current version can change what an application sees. Plan the desired visibility state and the removal of data versions together. Do not use delete-marker cleanup as a synonym for erasing data.
For deletion review, identify a stored version by its bucket, exact key and version ID. A key alone is not a complete manifest entry. Include versions with a null version ID if they exist; enabling versioning does not justify discarding older entries from the review.
Workflow
1. Establish the account, bucket and approved boundary
Confirm the credential context before collecting evidence:
aws --version
aws sts get-caller-identity --output json
Use the approved CLI profile and the bucket's Region. Keep identity output internally. The caller's account and the bucket owner's account can differ in a cross-account workflow; record both rather than assuming equality.
Before using the next examples, replace these fictional values with the reviewed scope. The account value is the expected bucket owner:
BUCKET='amzn-s3-demo-bucket'
ACCOUNT_ID='111122223333'
PREFIX='approved-delete-scope/'
aws s3api get-bucket-versioning \
--bucket "$BUCKET" --expected-bucket-owner "$ACCOUNT_ID" \
--output json
aws s3api get-bucket-replication \
--bucket "$BUCKET" --expected-bucket-owner "$ACCOUNT_ID" \
--output json
aws s3api get-object-lock-configuration \
--bucket "$BUCKET" --expected-bucket-owner "$ACCOUNT_ID" \
--output json
These commands inspect configuration. Confirm Enabled before continuing with this versioning-specific procedure. Classify errors individually: insufficient permission, an unexpected owner and an absent configuration are not interchangeable. The Object Lock configuration query returns an error when the feature is not enabled; an arbitrary failed query does not establish that retention is absent.
Record the configuration observation time. If a replication configuration was just changed, reconcile the effective state before treating a subsequent read as a definitive history of where copies went. Today's rules alone do not enumerate every destination used in the past.
2. Build a version manifest, including pagination
List versions rather than relying on a normal current-object list:
aws s3api list-object-versions \
--bucket "$BUCKET" --expected-bucket-owner "$ACCOUNT_ID" \
--prefix "$PREFIX" --output json
The operation is paginated; the CLI normally follows pagination. Do not add --no-paginate or an unhandled --max-items limit and then call the output complete. If a wrapper, SDK or job runner imposes limits, preserve and consume its continuation state. Treat parse errors and failed pages as incomplete evidence.
Review both Versions and DeleteMarkers. A prefix selects a namespace range, not an exact key. For a single-object request, filter the collected records by exact key equality before approving any action. Object names can contain characters that make a line-oriented shell pipeline unsafe; do not turn unreviewed listing text into deletion commands.
Arrange an approved pause or reconciliation boundary for writers, import jobs and restore processes that can recreate the data. A series of listing requests is not a transaction that freezes the dataset. Save a manifest generation time and record how writes during the review are handled.
3. Resolve retention on each relevant version
A bucket default is not a substitute for the settings of an existing version. For a version in the reviewed manifest, inspect its retention and legal hold separately. Replace the key and version placeholders before running these read-only examples:
KEY='approved-delete-scope/example.bin'
VERSION_ID='VERSION_ID_FROM_REVIEWED_MANIFEST'
aws s3api get-object-retention \
--bucket "$BUCKET" --expected-bucket-owner "$ACCOUNT_ID" \
--key "$KEY" --version-id "$VERSION_ID" --output json
aws s3api get-object-legal-hold \
--bucket "$BUCKET" --expected-bucket-owner "$ACCOUNT_ID" \
--key "$KEY" --version-id "$VERSION_ID" --output json
Object Lock protection applies to object versions. Compliance retention prevents deletion during its protected period, including by the root user. Governance retention has a distinct privileged override mechanism; this workflow does not use it. A legal hold is separate from a retention period and does not disappear merely because a retain-until date passes.
If a protected version must remain, record its exact identity and the applicable disposition decision as retained or deferred. Do not convert that state into completed deletion because the ordinary object name is hidden. Errors reading these settings remain exceptions until an authorized operator resolves them.
4. Treat replicas and backups as separate locations
Source deletion is not a global cascade. Permanently deleting a specific version in a source bucket does not replicate that version deletion to a destination bucket. Delete-marker replication is another mechanism with its own configuration and restrictions; propagating a marker still does not remove the destination's earlier data versions.
Identify destination buckets and their owners, then obtain a destination-side version and retention review. Include historical destinations and separately created copies in the scope record. Do not assume the same version identifier or the same permissions can be used everywhere; reconcile the actual destination records.
Independent backups, exported archives and restored datasets are additional records to resolve. An S3 version listing does not enumerate an organization's backup catalogue. Name the team responsible for each location and obtain its result or retention exception. If a backup must remain under an approved policy, state that boundary explicitly rather than describing the whole dataset as fully removed.
5. Execute the approved version-specific action
Only after the manifest, permissions, writer boundary and retention review are approved should an operator perform deletion. This example is irreversible for the specified data version. It is not a loop or a recommendation to delete whichever version happens to be current:
aws s3api delete-object \
--bucket "$BUCKET" --expected-bucket-owner "$ACCOUNT_ID" \
--key "$KEY" --version-id "$VERSION_ID"
Match all four values to the approved record immediately before submission. An MFA Delete configuration or other access condition may require a different authorized procedure. Stop on a rejection; do not add override options to make the request succeed. Preserve the individual action outcome and map it back to the version, including when a job partially succeeds.
A successful response is one item of evidence for the requested operation. It is not proof that the original manifest was complete or that replicas and backups were included. Reconcile what remains after the action.
Lifecycle rules are policy, not a completion receipt
In an Enabled bucket, expiration of a current data version creates a delete marker and makes that data version noncurrent. Removing noncurrent data versions requires the relevant noncurrent-version expiration action. Lifecycle processing is asynchronous, so an eligibility date or a saved rule is not a completed-deletion timestamp.
Retention and replication state can also prevent lifecycle removal. For example, the documented handling excludes current and noncurrent versions with Pending or Failed replication status from expiration action. Read the actual remaining records and exceptions; do not invent a fixed waiting period that guarantees an empty result.
Verification checklist
Use an explicit result for each location: completed within scope, retained by an approved decision, action failed or evidence unavailable. These are recommended workflow labels, not AWS response codes.
- Re-run a complete version listing for the approved scope and reconcile it against the manifest.
- Confirm both the bucket owner and exact key before interpreting a missing record.
- Resolve remaining data versions separately from delete markers.
- Keep failed requests, denied reads and pagination gaps visible.
- Obtain destination and independent-backup results, not just the source result.
- Check for recreations after the agreed writer boundary.
- Record the observation time, responsible reviewer and any retained-copy exception.
A failed retrieval alone is ambiguous: an access failure is not evidence of absent data. Likewise, do not describe successful customer-interface checks as direct physical-media verification. NIST SP 800-88 Rev. 2 provides a sanitization-program framework; citing it does not upgrade an object API response into a certificate for the provider's hardware.
Resale and evidence checklist
Retiring a local workstation or server does not settle the disposition of cloud copies it created. Link the local media record to the approved cloud deletion scope, account owner, remaining-copy decisions and review outcome. Keep local wipe acceptance distinct from cloud dataset disposition.
What not to publish
Keep account identifiers, bucket names, keys, version IDs, IAM identities, customer records and request evidence in the approved internal system. Public examples should use synthetic values and must not contain credentials or recovered object contents.
Common mistakes
The most consequential mistakes are checking only current objects, deleting markers before reviewing data versions, assuming a source deletion removes replicas, and treating every failed retention query as an unlocked object. A lifecycle rule, a revoked permission or an empty application screen is also insufficient evidence of complete data removal.
CliDeck workflow fit
A deletion runbook should keep scope discovery, version approval, irreversible actions and final review as distinct stages. Store each exception beside the affected copy so another operator can continue the same job. This is workflow guidance; it does not claim that forthcoming CliDeck wiping software manages S3, removes cloud backups or certifies provider media sanitization.
FAQ
Does a 404 for the current object prove its old versions were deleted?
No. A delete marker can hide the current name while data versions remain. Inspect the complete version history under the appropriate identity and permissions.
Can replication settings prove every destination is clean?
No. Configuration describes rules, not a complete deletion result. Reconcile actual destination versions and include historical or independent copies in the review.
Is deleting a cloud object equivalent to overwriting a drive?
No. They operate at different layers. Report the customer-interface action and its scope, while relying on appropriate provider assurance for physical-media handling.