Architecture Note: IBM Cloud Object Storage Lifecycle Rules with Versioned Buckets

Problem: Versioned Buckets Make Lifecycle Behavior Less Obvious

IBM Cloud Object Storage (ICOS) lifecycle rules move objects between storage tiers based on age. When bucket versioning is enabled, each object can have a current version and one or more noncurrent versions. A lifecycle rule applies to each version independently. Deleting the current version does not remove older versions, and transitioning the current version to Infrequent Access does not automatically transition noncurrent versions. The result is often a bucket where active-looking data sits in a costly tier while older versions accumulate separate charges.

Useful takeaway: scope lifecycle rules by object prefix, define separate transitions for current and noncurrent versions, and avoid deleting or reading objects before the Infrequent Access minimum storage period unless you are prepared for retrieval charges.

Requirements and Assumptions

• IBM Cloud Object Storage bucket with versioning enabled.
• Lifecycle configuration applied through the IBM Cloud console, IBM Cloud CLI with the COS plugin, or the S3-compatible API.
• Infrequent Access has a 30-day minimum storage duration; objects deleted or accessed before that period may incur charges.
• Lifecycle rule changes are not instantaneous and can take up to 24 hours to propagate across the bucket.

Smallest Suitable Design

Use one versioned bucket with two prefix-scoped rules. The example below keeps recent application uploads in Standard, moves log data to Infrequent Access after 30 days, and removes noncurrent log versions after 90 days.

{
  "Rules": [
    {
      "ID": "move-logs-to-infrequent-access",
      "Status": "Enabled",
      "Filter": { "Prefix": "logs/" },
      "Transitions": [
        { "Days": 30, "StorageClass": "STANDARD_IA" }
      ],
      "NoncurrentVersionTransitions": [
        { "NoncurrentDays": 30, "StorageClass": "STANDARD_IA" }
      ],
      "NoncurrentVersionExpiration": { "NoncurrentDays": 90 }
    },
    {
      "ID": "retain-uploads-in-standard",
      "Status": "Enabled",
      "Filter": { "Prefix": "uploads/" },
      "Transitions": []
    }
  ]
}

This is the smallest design because it uses a single bucket, avoids Archive for active workloads, and leaves a prefix untouched when immediate access is required.

Trust and Data Boundaries

Lifecycle rules are bucket-level controls. They do not copy or move data between buckets or accounts. A service ID with `Reader` permission on a bucket can list objects but cannot change the lifecycle configuration; `Writer` or `Manager` is required to apply or remove rules. Cross-account access to an object does not exempt that object from the bucket's lifecycle policy.

Operational Checks

1. Apply the configuration from a workstation or CI runner with the IBM Cloud CLI and COS plugin installed. Required permission: `Writer` or `Manager` on the target bucket.
2. Confirm the configuration with a lifecycle get operation. Expected check: the returned JSON shows the rules and statuses you submitted.
3. Select a test object under `logs/`, wait more than 30 days, and inspect its storage class through object metadata or the console. Do not read the object during verification, because an early Infrequent Access access can trigger a retrieval charge.
4. Review the IBM Cloud billing dashboard by storage class to confirm that log data is shifting from Standard to Infrequent Access.

Example command context

# Run from: local workstation or CI runner
# Required permission: Writer or Manager on 
# Placeholders: , 
# Risk: an incorrect Prefix transitions production data to a paid tier with retrieval charges
ibmcloud cos bucket-lifecycle --bucket  --lifecycle-configuration file://lifecycle.json
# Expected check: subsequent get command returns the same rule set
ibmcloud cos bucket-lifecycle-get --bucket 

Exact CLI subcommand names depend on the installed plugin version; consult the plugin help before running against a production bucket.

Failure Modes

Failure mode	Cause	Effect
Early Infrequent Access read	Object accessed before 30-day minimum storage period	Retrieval charge; potential latency
Noncurrent version retained in Standard	Lifecycle rule transitions only current version	Unexpected Standard-tier charges for old versions
Delayed cost savings	Rule propagation takes up to 24 hours	Objects remain in Standard after the rule is applied
Archive retrieval delay	Object transitioned to Archive tier	Retrieval can take hours; unsuitable for real-time access

Conditions That Change the Design

• If the application must read older object versions in real time, do not transition noncurrent versions to Archive; keep them in Standard or Infrequent Access only.
• If regulatory immutability is required, pair lifecycle rules with Object Lock or use Object Lock instead of lifecycle expiration.
• If the bucket is replicated across regions, remember that lifecycle rules are evaluated per region and cross-region version timestamp drift can affect which version appears current.

Verification

After applying the rule, upload a test object to `logs/test-object`, wait at least 30 days, and request its metadata without downloading the body. The storage class should show Infrequent Access. Then check the billing report for the bucket's storage-class line items. If the object remains in Standard after 48 hours, review the rule status and prefix filter before assuming the tier transition failed.

Limitation: this guidance covers age-based transitions. It does not address tag-based transitions or legal-hold interactions, which require separate review.