Object storage is priced to look inexpensive. A few paise per gigabyte per month invites a culture of keeping everything. Several years in, the bucket holds every log file, every image variant, every database export ever taken, and the line item is no longer small.
The providers offer storage classes for exactly this: frequently accessed, infrequently accessed, archive, and deep archive. Each step down is cheaper to store and more expensive or slower to retrieve. The saving is real, but only if the access pattern genuinely matches the class.
This is where lifecycle rules earn their place. A rule that moves objects to an infrequent-access tier after thirty days and to archive after a year automates a decision nobody will make manually. Write the rule when you create the bucket, not when the bill becomes a problem.
Retrieval charges are the trap. Archive tiers charge for reading data back, sometimes substantially, and sometimes with a minimum storage duration that means moving an object too early costs more than leaving it. Data that is read occasionally but unpredictably — customer documents, for instance — often belongs in a middle tier rather than the cheapest one.
Two other costs hide in these buckets. Incomplete multipart uploads accumulate invisibly and are billed as storage; a lifecycle rule should abort them after a few days. And versioning, once enabled, keeps every overwritten copy forever unless a rule expires old versions.
Before optimising, measure. The provider's storage analytics will show which prefixes hold the volume and how often they are read. Optimising the wrong bucket is effort with no return, and the distribution is usually more lopsided than anyone expects.
