Cut S3 Costs with Storage Classes and Lifecycle Rules

Most large S3 bills are old data in the wrong tier

When a client has a large S3 bill, the cause is usually not the data they are actively using. It is data they stopped using years ago and kept paying full price to store, because it is sitting in S3 Standard when it should be in a cheaper tier or deleted outright.

On one client, the vast majority of their S3 cost came from buckets storing logs. They had many dozens of terabytes of old log files as S3 Standard, spread across multiple buckets, some of it dating back five years. They only needed a few months of retention. They were paying thousands of dollars a month to keep years of logs they would never look at.

Why it had not been fixed

This is easy to describe and not so easy to do in practice. The client’s engineers were not incompetent; they just could not figure out how to configure lifecycle rules to expire old logs and move the rest to a cheaper tier, and it never rose above their other priorities.

Finding it was genuinely fiddly even for me. The buckets and prefixes had inconsistent, random names, so I had to look at the data actually stored in several buckets to work out what each one held before I could safely write a rule against it. That investigation is the real cost of the job, and it is why the work sits undone: it is not a one-line fix you can apply blindly.

Once I understood the layout, a few lifecycle rules on the right buckets and prefixes cut their S3 cost by over 90%, from thousands of dollars a month down to a few hundred spent on the data they actually need.

Storage class matters even on well-run buckets

This is not only about neglected log dumps. Even a fairly well-optimized S3 footprint usually has room to move.

On another client with roughly 800 S3 buckets that were already in decent shape, simply matching each bucket to the right storage class was worth about $50,000 a year. The savings do not require deleting anything or changing how the application reads the data; they come from putting each object on the storage class that fits its access pattern.

What to look at

If you want to sanity-check your own account:

Which buckets hold your largest volumes, and how old is the data in them? Old logs and backups are the usual suspects.
Do those buckets have lifecycle rules at all? Many have none, so nothing ever expires or transitions to a cheaper tier.
For data you keep, is it on a storage class that matches how often you actually read it?

Be careful writing rules against buckets with inconsistent naming: understand what is stored where before you expire or transition anything.

If your S3 bill looks larger than the data you actively use, book a discovery call or reach out on LinkedIn.

-Cristian