Storage-Class and CDN Policy for 800 TB of Video Assets
A media subsidiary stores 800 TB of video assets (about 1.2 million objects) in an OBS bucket in the Standard class in the Singapore region, fronted by CDN with an 85% cache hit ratio. Monthly delivery is 300 TB to end users. Analytics over the past year show a clear pattern: 8% of objects are requested daily, 12% are requested one to three times a month, and 80% have not been requested at all in the past 30 days - though a contractual legal-hold clause requires that a named subset of those cold objects be retrievable within 24 hours on demand. Storage cost dominates the bill. A proposal has been circulated to move all 80% cold objects to Archive to cut the storage line item by roughly 70%, and to leave CDN unchanged because the hit ratio is already 'good'.
1. Evaluate the Archive proposal. Explain what it would and would not save, and which hidden costs determine whether it is a win.
Read the worked answer
What it saves: the storage rate per GB-month. Archive sits well below Standard, so the headline saving on 80% of 800 TB (640 TB) is real but smaller than the 70% figure implies, because the remaining 160 TB stays on Standard and the saving applies only to the cold portion.
What it costs, and what the proposal ignores:
- Minimum billable duration. Archive objects carry a minimum storage duration (commonly 90 days) and IA a shorter one (about 30 days). Objects deleted or transitioned earlier are billed for the full minimum. With 1.2 million objects and an active ingest pipeline, early-deletion charges can consume a large share of the saving.
- Restore time and restore cost. Archive is not readable until restored, and restore takes minutes to hours plus per-GB retrieval fees. If any part of the 80% is re-accessed - a rights re-licensing, a compilation edit, an audit - you pay restore plus retrieval and lose the latency advantage.
- The legal-hold subset is the killer. A 24-hour retrieval obligation is compatible with Archive only if the restore SLA comfortably beats 24 hours and the restore path is tested, not assumed. Blanket-transitioning that subset without testing is a compliance breach waiting to happen.
- Lifecycle churn. Transitioning 640 TB generates request costs and, if the analytics misclassifies, later re-transitioning costs again.
The proposal optimises the wrong variable in isolation: storage rate rather than total cost of ownership including retrieval, request and compliance risk.
2. Design the object-class and lifecycle policy. Justify each rule with reference to the access pattern, and state what you would verify before enabling it.
Read the worked answer
Class mapping.
- 8% daily-accessed: Standard, served through CDN. No transition rule; these are the delivery working set.
- 12% monthly-accessed: transition to Infrequent Access after 30 days, which matches the minimum duration and the access cadence, so retrieval fees stay rare.
- The bulk cold 80%: transition to Archive after 90 days, not 30 - a 90-day dwell time both respects the minimum duration and avoids archiving content that is still inside its post-publication window.
- The legal-hold subset: keep on Standard or IA and implement retention through bucket policy or WORM retention instead of Archive, unless a restore drill proves retrieval inside 24 hours. Cost is not the deciding factor when a contractual retrieval obligation exists.
- Deep Archive, if available in the region, only for the fraction with multi-year retention and no retrieval expectation.
Supporting rules. Enable last-access-time tracking on the bucket so the classification is measured rather than inferred from age; expire incomplete multipart uploads (a classic hidden cost at 1.2 million objects); expire non-current object versions; and tag objects that must be excluded from lifecycle so exceptions are data-driven, not a spreadsheet.
Verify before enabling: simulate the rule on a sampled prefix and read the projected transition and retrieval charges; confirm the region's minimum-duration and restore-time documentation; confirm the legal-hold subset is excluded by tag; confirm the restore path and time with an actual restore test; and confirm that transitioning an object does not break the CDN origin path for anything still being requested.
3. The CDN hit ratio stays at 85%. Quantify what that means and describe how you would reduce origin traffic.
Read the worked answer
What 85% means: of 300 TB delivered per month, 15% - about 45 TB - is fetched from OBS to the CDN. That is origin egress, plus request costs, plus latency for the 15% of users who miss. At 800 TB of assets, a 5-point improvement to 90% removes roughly 15 TB per month of origin traffic and directly reduces both CDN-to-origin cost and tail latency.
How to get there, in order of effort-to-impact:
- Raise TTLs for immutable content. Video segments that never change should carry long cache TTLs; only manifests and auth-bearing URLs need short ones. A short TTL applied uniformly is the most common cause of a stuck hit ratio.
- Normalise the cache key. Strip query parameters that do not change the response (tracking, timestamps) so equivalent requests map to one cached object. Multi-tenant tracking parameters can silently double unique URLs.
- Pre-warm hot assets before a release or campaign rather than letting the first thousands of users miss.
- Check range-request behaviour for large video files; frequent partial-content misses fragment the cache and lower the measured ratio without an obvious cause.
- Verify objects remain readable after lifecycle transitions - an archived object that the CDN tries to fetch will fail rather than miss, which shows up as errors, not as a hit-ratio drop.
Instrument origin request count per content category, not just the aggregate ratio; the aggregate hides which category is responsible.