Skip to main content
Live. This area is documented as current, user-reliable behavior.

​
Goal

Match S2 data-protection controls to the recovery and retention requirements of each object prefix.

​
Prerequisites

  • An existing S2 bucket
  • Permission to update bucket settings and policies

​
Workflow

1
Enable versioning before workloads begin overwriting important keys.
2
Set a bucket default retention period or create narrower prefix retention rules.
3
Create lifecycle rules for deletion, old-version expiry, or storage-class tiering.
4
List versions for a key and test restoration with a non-production object.
5
Review active rules before deleting a bucket or changing application key conventions.

​
Object versioning

When versioning is enabled, S2 records object history and delete markers. The management API can list versions for a specific key and restore a selected version as the current object. Version records preserve the object checksum, content headers, metadata, tags, storage class, retention state, and encryption metadata associated with that write.

​
Lifecycle rules

  • delete removes matching current objects after the configured age.
  • expire_versions removes matching historical versions after the configured age.
  • tier changes matching objects from the hot storage class to the cold storage class.
  • Rules can target a key prefix and use supported ages of 7, 30, or 90 days.
  • Disable or delete obsolete rules instead of leaving policies attached to prefixes the application no longer owns.

​
Retention rules

A retention rule protects matching objects for a configured number of days. Prefixes let one bucket hold data with different retention requirements, such as invoices/, audit/, and temporary/. S2 rejects deletion of an object while its effective retention period or legal hold protects it. Validate the required retention policy before storing regulated or contractual records.

​
Bucket defaults

  • Bucket settings support default retention values of 0, 7, 30, or 90 days.
  • The tier-after setting uses the same supported day values and applies to new policy evaluation.
  • Changing a bucket default does not rewrite the encryption metadata or content of existing object versions.

​
Expected result

Overwrites remain recoverable when versioning is enabled, protected objects resist premature deletion, and aging policies run against intentional prefixes.

​
Common failures

  • Enabling versioning after an overwrite and expecting an older unversioned body to exist.
  • Using a broad lifecycle prefix that also matches current production objects.
  • Treating a retention rule as a backup. Retention prevents deletion; recovery copies and application-level restore testing remain separate concerns.
  • Changing key prefixes without updating the lifecycle and retention rules that target them.

Access keys, encryption, isolation, and quotas

Operate S2 credentials, encryption, visibility, tenant isolation, request limits, and customer-plan quotas safely.

S3 operations and presigned access

Use the supported S3 operations, conditional requests, object metadata, tags, multipart uploads, and presigned URLs.

Capacity, monitoring, and recovery

Monitor bucket usage, handle temporary service responses, protect critical objects, and validate application recovery.