Storage tiering that actually saves money
Most scaleups pay hot-tier prices for cold data. A practical approach to lifecycle policies, snapshot hygiene and tiering that survives contact with engineering.
The problem in one line
Most scaleups pay hot-tier prices for data nobody has read in a year.
Storage rarely shows up in a cost review because no single line item looks alarming. It grows quietly: log buckets with no lifecycle rule, snapshots kept "just in case", duplicated datasets from a migration that finished eighteen months ago, and dev environments cloning production volumes every night.
Where the money actually sits
- **Object storage without lifecycle rules.** Logs, exports and analytics dumps written to standard-class storage forever.
- **Orphaned block volumes.** Disks detached when an instance was terminated, still billed monthly.
- **Snapshot sprawl.** Automated snapshots with no retention policy, each one a full-price copy after the first.
- **Cross-environment duplication.** Staging and dev holding near-complete copies of production data.
A tiering policy that survives engineering review
The reason tiering initiatives stall is that they are proposed as a blanket rule. Engineers push back because retrieval latency and retrieval fees are real risks for data that might be needed during an incident.
Start by classifying data by *access pattern*, not by team:
1. **Operational (read weekly or more)** — keep on standard storage. No change.
2. **Reference (read a few times a year)** — infrequent-access tier after 30 days. Retrieval cost is trivial at this frequency.
3. **Compliance-only (read essentially never, but must exist)** — archive tier after 90 days, with a documented restore runbook.
4. **Expendable** — delete on a schedule. Most log data older than the retention requirement falls here.
Write the policy as code in your infrastructure repo, not as a console click. A lifecycle rule that lives in Terraform gets reviewed, versioned and reapplied when someone creates a new bucket from your module.
Snapshot hygiene
Set retention explicitly for every snapshot schedule. A common, defensible default: keep 7 daily, 4 weekly, 3 monthly. Anything beyond that needs an owner and a stated reason. Then run a monthly job that lists snapshots with no matching live volume and flags them for deletion after a grace period.
What to measure
Track storage cost per tier as a percentage of total storage spend, and track it monthly. A healthy scaleup profile is usually 40–60% standard, with the remainder in infrequent-access and archive. If you are at 95% standard, the savings are sitting right there.
Also track *storage cost per active customer*. If storage grows faster than customers, you are accumulating, not serving.
Start here
Pick your three largest buckets and your snapshot schedules. That is normally 80% of the addressable spend. Apply lifecycle rules to those first, verify nothing breaks over two weeks, then roll the same module out everywhere else.
This is the kind of work bluebill does as part of a FinOps engagement — find the concentration, apply the policy as code, and leave the guardrail behind so it does not regrow.