This post expands from my FinOps at Tesco Bank talk that I delivered in October 2025 to the FinOps Weekly Summit. It is based on a real-life historic scenario.

Amazon Web Services' S3 offers a variety of storage 'tiers', based upon access requirements. Frequently-accessed data is the most expensive, with deep discounts available if you're willing to accept a delay in retrieval time. Best practice recommends constructing a set of lifecycle transition rules on your S3 buckets, where data are moved into cheaper storage tiers after a certain amount of time has elapsed. This can provide an economical storage mechanism over the full period you require data retention, but as with everything, it's a bit more complicated than that.

Click the S3 bucket to spend some money!

Get in Shape

Let's think about the shape of data in a bucket. You could have:

  • A lot of large objects
  • A lot of small objects
  • A small number of large objects
  • A small number of small objects
  • Any mix of the above!

Understanding the shape of your data is the first step to form an effective cost management strategy. To then identify which lifecycle configurations and storage tiers to implement, you also need to factor in how the data are accessed, as the fundamental trade-off is storage price vs retrieval time.

Is your data archival? That could mean a large amount of large objects, rarely accessed. But it could also be many smaller log objects. Is your data large but in near-constant use, like on a streaming platform? Are you willing (or able) to tolerate a retrieval time potentially in the hours - if a request is non-time-sensitive?

There's no one-size-fits-all approach.

The Cheapest Storage is the Storage You Don't Use

AWS uses a consumption-based pricing model, which means that you're charged based on your usage. In general, the model is "$X per Y" (rate x unit).

So if you don't need to store something - don't store it. In a regulated context, there may be a requirement to store data for a certain number of years. It is possible to add deletion rules to lifecycle configurations to automatically clean things up.

Movement Matters Too

Cost analysis is difficult when the unit differs between two prices - which is exactly what happens in S3. Storage costs are charged per Gigabyte. But lifecycle transitions are charged per 1000 objects. It means that financial analysis becomes a multi-dimensional problem - but once you understand the shape of your data, you have what you need to navigate this.

Think back to the list of data shapes above, this time visualised on a 2x2:

Low Number of objects High Number of objects
Low Size Low Cost Low Storage Cost, High Transition Cost
High Size High Storage Cost, Low Transition Cost High Cost

The low size, high object count is subtle and dangerous - it's where storage is cheap but transition costs dominate.

A Cautionary Tale

Many moons ago, the AWS Team at work set up an S3 bucket to act as a consolidated repository for all CloudTrail logs across the organisation. CloudTrail generates a lot of objects of variable size, but through the magic of .tgz, lots were under 128KB.

We had configured the following lifecycle rules:

  • After 30 days -> Transition to IA
  • After 365 days -> Transition to Glacier
  • After retention period -> Delete

We assumed that cheaper storage tiers automatically meant lower total cost. When we ran the numbers, we realised total storage volume was only a few hundred gigabytes over the full lifecycle, but spread across millions of tiny objects.

All of our savings from lifecycling our objects was completely undone (and then some!) by the object transition costs!

Oh, and another thing. When objects are transitioned to a Glacier Tier, S3 requires another 40KB of storage - 32KB of metadata in Glacier and another 8KB in Standard Tier to reference it. Believe it or not, we had some objects smaller than 40KB, and so in effect we were doubling storage costs, plus paying for transition, chasing a storage saving!

Once we crunched all the numbers, we'd save 70% on our current CloudTrail storage costs, over the data retention period, just by keeping everything in Standard Tier.

This is a very sharp edge of S3 lifecycling, and thankfully for configurations created post-September-2024, there's a default minimum limit of 128KB. Objects smaller than this aren't transitioned to a different tier, regardless of your rules. This doesn't retrospectively apply to configurations created prior, which is why we fell into this situation.

Just Chuck it in the Intelligent Tier?

Certainly, for new data, this is an option. Bear in mind that for historical data, there's a $0.01/1000 object cost to transition to this tier - so you may actually just want to let any existing data remain on its historical lifecycle transition path.

There are some considerations for the Intelligent Tier:

  • Automatic tiering only applies for objects > 128KB. Anything smaller is always charged at the (higher) Frequent Access price.
  • To apply automatic tiering for eligible objects, you're charged an additional monitoring fee per 1000 objects.
  • You aren't charged for any lifecycle transitions that automatic tiering actions on your behalf.
  • You have no ability to configure the automatic tier transition rules - this is managed for you.

Intelligent Tiering is itself a trade-off that's most suitable for unknown access patterns - you pay a fixed monitoring fee and let AWS manage it. If you already understand your access patterns, Intelligent Tiering is usually unnecessary overhead. If you don’t, it can be a sensible insurance policy for new data.

Conclusion: Understand Your Data and Access Patterns

Effective S3 storage cost management requires an active understanding of the data you need to store, and the patterns of access/retrieval. Where this is not known, Intelligent Tiering offers a sensible hedge for many use cases, but isn't suitable to apply to retrospective data. By understanding the shape of your data, retention requirements and how it is accessed, it is possible to devise a lifecycle plan that optimises cost and avoids the shock of an unexpected bill. Price up over the full lifecycle, including storage and transition costs, so that you can account for data at rest and at movement.