Configuring Cloud Storage Lifecycle Management

Overview and What You Will Learn

In this lab, you will build a Lifecycle policy with multiple rules - one transitioning objects to a colder class by age, another deleting objects entirely after a longer retention period - and verify the policy's conditions actually match the objects intended.

Why This Matters in Production

A team manually reclassifies old log files to a colder storage tier once a quarter, whenever someone remembers to do it - meaning for weeks at a time, aging data sits in a more expensive tier than it needs to, and the "manual quarterly cleanup" task is exactly the kind of recurring chore that eventually stops happening reliably once the person who used to do it moves to a different team.

Core Principles

A Lifecycle rule pairs a condition (like object age, or a specific storage class) with an action (like transitioning to a colder class, or deleting the object outright) - once configured, Cloud Storage evaluates every object against these rules automatically and continuously, with no manual intervention required.

A bucket can have multiple Lifecycle rules simultaneously, each evaluated independently against every object - this lets a single bucket age data through several storage classes over time before eventually being deleted, all through one configured policy.

Detailed Step-by-Step Practical Lab

1. Create a project and a bucket:

2. Upload a few test objects:

3. Build a multi-rule Lifecycle policy - transition to Nearline after 30 days, Coldline after 90 days, and delete entirely after 7 years:

4. Apply the policy to the bucket:

5. Confirm the policy was applied correctly:

6. Add a condition targeting only objects under a specific prefix, so different folders within the same bucket can age differently:

Note

matchesPrefix scopes a rule to only objects whose key starts with the given prefix, similar in concept to how an AWS S3 Lifecycle rule can be scoped to a specific folder path. Without this, a single bucket-wide rule applies identically to every object regardless of which logical "folder" it sits in.

7. Clean up:

Production Best Practices & Common Pitfalls

Common Mistake

Writing a Lifecycle rule with an age condition that conflicts with actual business retention requirements - like a rule deleting data after 90 days when a compliance requirement mandates keeping it for 7 years. Always confirm the actual required retention period before writing a delete rule, since a wrongly-configured delete action is not reversible once it executes.

Tip

Test a new Lifecycle rule's conditions against a small, non-critical bucket first, and review which objects it would actually match before applying it broadly. A subtly wrong age or prefix condition can silently affect far more (or fewer) objects than intended.

• Lifecycle actions apply to existing objects immediately upon policy creation, not just to objects uploaded afterward - an object already 100 days old when a 90-day transition rule is added will be transitioned on the next evaluation cycle, not exempted just because it predates the rule.
• Combine Lifecycle rules with Object Versioning carefully. If versioning is enabled, Lifecycle conditions can also target non-current (older) versions specifically, letting you keep only the current version at Standard cost while aging out old versions faster.

Quick Reference & Troubleshooting Commands