S3 Storage Class Analysis

TL;DR: Storage Class Analysis is the free data-collection step everyone skips before writing lifecycle rules. Enable it on a bucket (or prefix), wait 30+ days, and it produces a CSV saying exactly which objects have gone cold and when access dropped off. It moves nothing itself — it's the evidence; lifecycle policies are the action. Typical outcome on a mature bucket: discovering 60–80% of "production" data is cold.

The numbers

• Cost: free (you pay only pennies for the CSV report storage)
• Typical first-pass example from the source workflow: 10 TB SaaS uploads bucket at $230/month → analysis shows 8 TB untouched for 60+ days → one lifecycle rule later, **$80/month** (a $150/month permanent cut for an afternoon's work)
• Enterprise post-migration example: 48 of 50 TB never accessed since a datacenter-exit migration → moved to Glacier Flexible → ~$900/month saved

Do this

1. Enable it on your biggest mixed-access bucket (console: bucket → Metrics → Storage Class Analysis, or CLI):

   aws s3api put-bucket-analytics-configuration \
     --bucket YOUR-BUCKET --id access-watch \
     --analytics-configuration file://watch.json
   

   Point the export at a reports bucket; optionally filter by prefix.

2. Put a calendar reminder 35 days out. The tool's #1 failure mode isn't technical — it's reports nobody opens. The analysis doesn't save money; acting on it does.

3. Write the rule the report justifies — e.g., "objects untouched after 60 days → Standard-IA at 60, Glacier at 180." You now have data to defend the change to whoever owns the bucket.

4. Start with one bucket, not fifty. A 50-bucket analysis dump produces CSV mountains nobody reads. Learn the loop on one high-value bucket, then expand (automate configs via IaC if you have many).

Gotchas

• It observes; it never moves data. That's deliberate — you sanity-check recommendations against workload knowledge before anything changes tier.
• Backup jobs poison the data. A nightly process that reads every object makes everything look hot. Exclude those access patterns mentally (or the principals from the analysis scope) when reading the report.
• Tiny objects break Glacier math. The report flags cold objects by access alone; it doesn't know your objects are 10 KB each and will be billed at 128 KB minimums in Glacier classes. Check size distribution before transitioning small-object buckets.
• Recommendations are conservative — AWS only certifies clearly-infrequent objects; manual digging often finds more cold data than the report commits to.
• 30+ days before results. Patience is the price of accuracy.

Skip this if

• The bucket is tiny or its data is uniformly hot (live CDN assets) — nothing to learn.
• Lifecycle rules are already tuned and recently reviewed.
• Access patterns are so chaotic that no static rule will ever fit — skip straight to S3 Intelligent-Tiering and let it manage placement per object. For estate-wide visibility rather than per-bucket evidence, that's S3 Storage Lens.