Object Storage Classes and Lifecycle Rules to Cut Storage Costs

The short answer

Object storage providers offer several storage classes. The cheaper the class per gigabyte, the more you pay to read data back, and the longer you are billed for an object even if you delete it early.

Lifecycle rules move objects between classes and delete them automatically based on age, prefix or version. Used well, they cut the storage bill without manual work. Used carelessly, they create retrieval and early-deletion charges that exceed the savings.

The three tiers

• Hot: highest storage price, no retrieval fee, no minimum duration. For data read often.
• Infrequent access: lower storage price, a per-GB retrieval fee and a minimum storage duration. For backups and old files that are still read sometimes.
• Archive: lowest storage price, the highest retrieval cost and longest minimums. In Azure Archive and S3 Glacier Flexible Retrieval or Deep Archive, objects must be restored (rehydrated) before reading, which can take hours.

There are also auto-tiering options: S3 Intelligent-Tiering and GCS Autoclass move objects based on actual access. They suit data with unpredictable access patterns.

Retrieval fees and minimum durations

Minimum storage duration: if you delete, overwrite or move an object earlier, you still pay for the full minimum. Typical values at the time of writing:

Check current values on your provider's pricing page.

Other cost factors:

• Retrieval fee per GB read from non-hot classes.
• Request prices are often higher for colder classes, and each lifecycle transition is itself a request.
• Small objects: some classes bill a minimum object size or add per-object metadata overhead. Millions of tiny files may cost more after a transition, not less.

Rule of thumb: move data to a colder class only if you are confident it will stay there longer than the minimum and will rarely be read.

How to design lifecycle rules

1. Group data by prefix or tag: logs/, backups/, uploads/. One rule per data type, not one rule for the whole bucket.
2. Know the access pattern: how long is the data actively read? When is it needed only for audits?
3. Set transitions in order from hot to cold, respecting minimum durations.
4. Set expiration when data has no value after a certain age.
5. Handle versioning: expire noncurrent versions, or deleted objects will keep costing money.
6. Abort incomplete multipart uploads: failed large uploads leave invisible parts that are billed as storage.

Example S3 lifecycle configuration:

{
  "Rules": [
    {
      "ID": "logs-tiering",
      "Status": "Enabled",
      "Filter": { "Prefix": "logs/" },
      "Transitions": [
        { "Days": 30, "StorageClass": "STANDARD_IA" },
        { "Days": 120, "StorageClass": "GLACIER" }
      ],
      "Expiration": { "Days": 730 }
    },
    {
      "ID": "versions-and-uploads-cleanup",
      "Status": "Enabled",
      "Filter": {},
      "NoncurrentVersionExpiration": { "NoncurrentDays": 30, "NewerNoncurrentVersions": 3 },
      "AbortIncompleteMultipartUpload": { "DaysAfterInitiation": 7 }
    }
  ]
}

Here logs move to Standard-IA after 30 days, to Glacier Flexible Retrieval after 120 days and are deleted after two years. The second rule deletes old versions 30 days after they stop being current, while always keeping the three most recent ones, and clears multipart leftovers after a week.

Google Cloud Storage and Azure use the same ideas with different syntax: SetStorageClass, Delete and AbortIncompleteMultipartUpload actions with age or version conditions in GCS, and tierToCool, tierToArchive and delete actions in Azure lifecycle management policies. See the official S3 lifecycle documentation for every field.

Common mistakes

• Moving everything to archive and then restoring it for every analytics job.
• Short-lived data in cold classes: temporary files deleted after a week still pay for 30 or 90 days.
• Versioning without cleanup: the bucket grows forever with hidden old versions and delete markers.
• Forgetting multipart uploads: storage grows while the object list looks the same.
• Applying rules to the whole bucket when only one prefix needs them.
• No test: enable new rules on a test prefix and watch the cost report before a full rollout.