What conditions can trigger lifecycle actions?

Lifecycle rules support multiple conditions including age (days since creation or noncurrent), createdBefore (absolute date), numNewerVersions (for versioned objects), isLive (live vs. noncurrent), matchesStorageClass (current class), matchesPrefix and matchesSuffix (object name filters), and daysSinceCustomTime (custom metadata timestamp). Multiple conditions in a single rule use AND logic — all conditions must be true for the action to execute.

What storage class transitions are allowed?

Objects can transition from Standard to Nearline, Coldline, or Archive; from Nearline to Coldline or Archive; and from Coldline to Archive. You cannot transition to a higher-performance class using lifecycle rules — for example, you cannot move an object from Archive back to Standard via lifecycle. To move objects to a higher class, you must rewrite the object using gsutil, the API, or Storage Transfer Service.

How do lifecycle rules interact with object versioning?

When versioning is enabled, lifecycle rules can target live (current) versions using isLive: true and noncurrent (previous) versions using isLive: false. The numNewerVersions condition counts how many newer versions exist, letting you keep only the N most recent versions. A delete action on a live versioned object creates a noncurrent version rather than permanently deleting it. To permanently delete noncurrent versions, create a separate rule targeting isLive: false with an age condition.

GCP Cloud Storage Lifecycle Builder

StorageGCP

Build Cloud Storage lifecycle management rules for storage class transitions and deletion.

Last verified: May 2026

Cloud Storage Lifecycle Rules

Rule 1

Action

Age (days)

Is Live

Newer Versions

Matches Storage Class

StandardNearlineColdlineArchive

Created Before (YYYY-MM-DD)

Generated Lifecycle Configuration JSON

{
  "rule": [
    {
      "action": {
        "type": "Delete"
      },
      "condition": {
        "age": 365
      }
    }
  ]
}

See It in Action

Your team's Cloud Storage bill has crept up to $4,500/month across 80 buckets. Audit reveals 70% of storage is in Standard class, but most data is rarely accessed after 30 days. The builder generates a standard policy: transition to Nearline at 30 days, Coldline at 90 days, Archive at 365 days, plus delete noncurrent versions after 30 days. Apply across all 80 buckets via Terraform. After 3 months, monthly cost drops to $1,800. Annual savings: ~$32K.

What This Tool Does

Google Cloud Storage lifecycle management automatically transitions objects between storage classes or deletes them based on configurable rules. Rules evaluate conditions like object age, creation date, number of newer versions, storage class, and whether the object is live or a noncurrent version. Properly configured lifecycle rules can dramatically reduce storage costs by moving infrequently accessed data to Nearline, Coldline, or Archive classes and cleaning up old versions. This builder helps you define lifecycle rules with correct condition combinations, action types, and storage class transition sequences.

Technical Details

The builder generates Cloud Storage lifecycle configurations as JSON with rule arrays. Each rule has: action (SetStorageClass with target class, or Delete, or AbortIncompleteMultipartUpload), and condition (combinations of age, createdBefore, isLive, numNewerVersions, matchesStorageClass, matchesPrefix, matchesSuffix, daysSinceCustomTime). Output is generated as gsutil lifecycle set commands and Terraform google_storage_bucket.lifecycle_rule blocks.

Common Use Cases

1Building lifecycle rules that transition objects from Standard to Nearline after 30 days and to Coldline after 90 days for a tiered archival strategy
2Creating rules that delete noncurrent object versions older than 7 days in versioned buckets to control storage costs from accumulated versions
3Configuring lifecycle rules that abort incomplete multipart uploads after 7 days to reclaim storage from failed large file uploads
4Generating lifecycle configurations that combine age-based transitions with storage class conditions to avoid redundant transitions

Common Questions

What conditions can trigger lifecycle actions?: Lifecycle rules support multiple conditions including age (days since creation or noncurrent), createdBefore (absolute date), numNewerVersions (for versioned objects), isLive (live vs. noncurrent), matchesStorageClass (current class), matchesPrefix and matchesSuffix (object name filters), and daysSinceCustomTime (custom metadata timestamp). Multiple conditions in a single rule use AND logic — all conditions must be true for the action to execute.
What storage class transitions are allowed?: Objects can transition from Standard to Nearline, Coldline, or Archive; from Nearline to Coldline or Archive; and from Coldline to Archive. You cannot transition to a higher-performance class using lifecycle rules — for example, you cannot move an object from Archive back to Standard via lifecycle. To move objects to a higher class, you must rewrite the object using gsutil, the API, or Storage Transfer Service.
How do lifecycle rules interact with object versioning?: When versioning is enabled, lifecycle rules can target live (current) versions using isLive: true and noncurrent (previous) versions using isLive: false. The numNewerVersions condition counts how many newer versions exist, letting you keep only the N most recent versions. A delete action on a live versioned object creates a noncurrent version rather than permanently deleting it. To permanently delete noncurrent versions, create a separate rule targeting isLive: false with an age condition.

Expert Tips

TIP

Always include a rule to abort incomplete multipart uploads after 7 days. Failed uploads can silently accumulate gigabytes of hidden storage costs. This is a one-line rule that prevents a class of unnoticed billing creep.

TIP

For versioned buckets, set a rule deleting noncurrent versions after a specific number of days OR when there are >N newer versions. Without this, deleted/overwritten objects accumulate noncurrent versions forever — your bucket size grows linearly with churn even when 'live' object count is stable.

TIP

Storage class transitions are one-way (toward colder tiers). If you accidentally tier objects to Archive too aggressively and need them back hot, you must rewrite each object — there's no 'transition back' lifecycle rule. Always use prefix conditions to limit aggressive transitions to specific data sets.

Featured In

Terraform State Management: Remote Backends, Locking, and Recovery

Related Learning Guides

GCS Storage Classes & Lifecycle22 min read

Was this tool helpful?

Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.