Case study · FinOps

Cutting a GCP storage bill by 95.9% with lifecycle policies

Cloud storage is the cost that creeps: nobody deletes anything and every byte lands in the most expensive tier. Here is how a handful of lifecycle policies cut a bill by 95.9%, a historical reported reduction, with retention-aware lifecycle policies.

By Vitor Schiavo Updated October 2026 ~5 min read

Solution at a glanceMatch the storage tier to the retention policy.

Active dataKeep recently used objects

Lifecycle rulesMove data to colder tiers

Retention boundaryApply authorized expiry

A simplified lifecycle: the effective policy version and deletion requirements must be validated.

Contribution at a glance

My responsibility: Access/retention review, lifecycle policy configuration and storage-footprint work.
Scope: Historical storage optimization; full financial reconciliation remains incomplete.
Collaboration & boundaries: I worked with the product team on access and retention requirements before changing storage behavior.
Outcome: The historical portfolio reported 95.9% lower storage cost. Absolute savings are withheld until currency, baseline and policy version are reconciled.

Storage is the cost that creeps. Nobody deletes anything, every byte lands in the default (and most expensive) class, and the bill grows quietly until someone looks. This is a write-up of the technique I used to cut one of these bills by 95.9%, with access-aware tiering and retention changes.

My contribution

I reviewed access and retention patterns with the product team, configured lifecycle changes and worked on regional placement and storage footprint reduction.

Results and measurement

The historical portfolio reported 95.9% lower storage cost and a 94.2% smaller footprint. The work records confirm lifecycle and retention changes, but do not establish one consistent currency, billing baseline and policy version for the full estimate. Absolute and cumulative savings are therefore omitted here pending reconciliation.

The problem

The data was not all hot. Most of it was written once and never read again, but it sat in Standard storage priced for frequent access. There was no tiering to cheaper classes and nothing ever aged out, so the footprint and the bill only went one direction.

What I changed

No new infrastructure, no data migration tooling, just lifecycle policies applied to the buckets:

Keep hot data in Standard. Base the hot window on observed access patterns and the applicable retention requirements.
Tier older data automatically. A recorded iteration moved objects to Nearline after 30 days and Archive after 365 days. Earlier policies differed, so these are versioned decisions rather than a universal rule.
Review deletion separately. Agree which records may expire with the product team; archival and deletion have different effects and requirements.
Applied everywhere. The same policies went on both multi-region and single-region buckets.

The important part: this is self-driving. Once the policies are in place, archival and deletion run on their own. Access patterns, retention requirements and billing effects still need periodic review.

95.9%monthly cost cut

Lifecycleautomated tiering

94.2%smaller footprint

Retentionreviewed separately

The result in one line

The historical portfolio reported a 95.9% reduction. Currency, billing period and the exact contribution of tiering versus deletion must be reconciled before publishing an absolute or cumulative savings total. The transferable result is a repeatable lifecycle process tied to actual access and retention requirements.

What I would tell someone starting this

Look at the storage bill before the compute bill. It is usually simpler to fix and the savings compound monthly.
Tier by access pattern, not by guesswork. Validate which data is still read before choosing the transition window.
Add a deletion policy, not just archival. Archival slows the growth; deletion stops it.
Let the platform do the work. Lifecycle policies are set-and-forget, which means the savings do not depend on anyone remembering.

Decisions and next steps

A retrospective view of the approach and its limits. The next improvement is a proposal, not a delivered result.

Alternative and rationale

Keeping everything in Standard is simple; colder tiers and authorized expiry must match real access and retention requirements.

Trade-off

Retrieval charges, minimum retention periods and deletion requirements affect whether a lower storage bill is a better total outcome.

What I would improve next

Next improvement: reconcile the policy version and billing period, then calculate net savings including retrieval and retention charges.