OSS Lifecycle, Versioning, and an Unexpected Bill
A media company stores user-uploaded images and short videos in an OSS bucket. The bucket has versioning enabled and a lifecycle rule that transitions objects to Infrequent Access after 30 days and deletes them after 365 days. Monthly storage cost has grown 40% quarter over quarter even though upload volume is flat. The team also reports that deleted objects sometimes reappear, and that a cleanup script deleting old objects did not reduce the bill.
1. Explain why deleting objects did not reduce the bill, and why deleted objects can reappear.
Read the worked answer
With versioning enabled, a delete without specifying a version does not remove data - it creates a delete marker that hides the object. All prior versions remain stored and billable. A cleanup script that issues ordinary deletes therefore hides objects from listing while leaving every version on disk, so the bill does not fall. Objects appearing to "reappear" happen when a delete marker is itself removed, which exposes the previous version again.
To actually reclaim space you must delete specific object versions, not just the current object. The lifecycle rule as described deletes current objects after 365 days but, depending on how it is configured, may not expire noncurrent versions. A correct configuration includes a noncurrent version expiration action so old versions are permanently removed.
2. The lifecycle rule transitions to Infrequent Access after 30 days. Given the access pattern, is this helping? What would you verify?
Read the worked answer
Not necessarily. IA storage has a minimum storage duration (commonly 30 days) and a per-request retrieval cost. If objects are transitioned to IA and then deleted or re-read soon after, you pay early-deletion charges and retrieval fees that can exceed the savings.
Verify:
- Actual access frequency. If a meaningful share of objects are read after 30 days (thumbnails, re-shared media), IA transitions add retrieval cost on every read.
- Object size distribution. Many tiny objects make per-request costs dominate; IA is a poor fit for very small, frequently read objects.
- Minimum duration alignment. Ensure the transition age is comfortably past the point where objects stop being read, so you are not paying early-deletion penalties.
- Whether the 40% growth is storage or request cost. Break the bill down by storage class and request type before changing rules.
A better rule set often keeps hot recent media in Standard, transitions only genuinely cold media to IA or Archive, and adds noncurrent version expiration.
3. Propose a corrected lifecycle and access-control strategy that reduces cost without risking data loss.
Read the worked answer
Recommended changes:
- Add noncurrent version expiration (for example, expire noncurrent versions 30-90 days after they become noncurrent) so versioned data does not accumulate indefinitely.
- Add a cleanup for expired delete markers so hidden objects do not linger.
- Tune transitions to observed access. Keep Standard for the hot window, transition to IA only after the access curve flattens, and use Archive for media unlikely to be read again. Confirm minimum-duration and retrieval-cost tradeoffs first.
- Separate buckets by workload if hot thumbnails and cold archives share a bucket; lifecycle rules apply per prefix, so prefix-based rules can target each class precisely.
- Protect against accidental deletion with RAM policies that deny
DeleteObjectVersionto the cleanup script's role and reserve that permission for a privileged automation role. Enable MFA delete or a retention policy if regulatory. - Monitor bucket size, object count, and version count so growth is visible before the next bill.
This reduces cost by removing hidden versioned data and right-sizing storage classes, while tightening delete permissions to prevent irreversible loss.