A team I worked with moved twenty million small log files into a cheaper archive tier, watched the storage line fall by about seventy percent, and celebrated. Six weeks later somebody needed to reprocess a quarter of that archive. The retrieval charge plus the early deletion penalty came to more than eighteen months of the savings they had booked.

Nothing went wrong technically. Every charge was documented, published and predictable. The team had optimised the one number on the invoice they could see, the price per gigabyte per month, and had not priced the three charges sitting behind it: the minimum billable object size, the minimum storage duration, and the cost of getting the bytes back out. Storage is the part of the cloud bill where the sticker price is the least interesting number on the page.

Where storage money actually goes

Object storage is billed on at least four independent meters and most cost reviews only look at the first one. There is the storage meter itself, charged per gigabyte for the time the object sits there. There is the request meter, charged per thousand operations, and it is priced differently for writes and reads and differently again per storage class. There is the retrieval meter, a per gigabyte charge that applies when you read data back out of an infrequent access or archive class. And there is data transfer, charged when bytes leave a billing boundary.

Those meters are not independent of each other in practice, because moving data to a cheaper class turns down the first meter while turning up the other three. A storage class is best understood as a bet about access. You are being offered a lower rent in exchange for a higher fee every time you open the door, plus a promise about how long you will stay. Colder classes are not cheaper. They are cheaper for data you genuinely will not touch.

This is why storage optimisation behaves so differently from the compute work in the last three parts. Rightsizing and commitments are decisions you make once and largely reverse at will. Storage tiering is a decision that binds you for thirty, ninety, one hundred and eighty or even three hundred and sixty five days depending on the class, and reversing it early costs money rather than saving it. Get it wrong and you cannot simply undo it next Tuesday.

Minimum durations and minimum billable object sizes

Two rules do most of the damage. A minimum storage duration means that once an object enters a class, you are billed as though it stayed there for a set period even if you delete it on day two. A minimum billable object size means that objects below a threshold are billed as though they were that size. Both are published, both are unglamorous, and neither appears anywhere in the headline price per gigabyte that gets quoted in planning meetings.

Here is how the three major clouds set them. Names differ, structure does not.

Verified against the Amazon S3 pricing page, Microsoft Learn access tier documentation and Google Cloud Storage documentation in July 2026. Google Cloud Archive keeps millisecond access despite the year long minimum, which makes it structurally different from AWS Deep Archive and Azure Archive.

Read the last two columns together and a useful distinction appears. Google Cloud Archive charges you for a full year but hands the data back in milliseconds. Azure Archive and AWS Deep Archive charge for six months but make you wait hours. If your requirement is cheap retention with occasional urgent reads, those are not interchangeable products even though the marketing pages describe them in similar language.

Why tiering sometimes costs more than it saves

The minimum billable object size is the trap that catches the most people, because it punishes exactly the workload that looks most attractive to archive: enormous numbers of tiny files. Logs, thumbnails, per user JSON documents, sensor readings, individual event records. High object count, low total volume, obviously cold. Move them to a cheaper class and the bill can rise.

Take twenty million objects averaging forty kilobytes each, which is about 781 GB of real data. AWS bills S3 Standard-IA and S3 Glacier Instant Retrieval at a minimum of 128 KB per object, and adds 40 KB of metadata per object in Glacier Flexible Retrieval and Deep Archive, of which 8 KB is charged at S3 Standard rates. Work through what you are billed for rather than what you stored.

Arithmetic from the AWS published minimums applied to twenty million objects of forty kilobytes each. The per gigabyte rates themselves are not included because they vary by region and change over time.

Standard-IA is roughly half the per gigabyte rate of Standard in most regions, but here you are billed for 3.1 times the volume. That is not a saving, it is a fifty percent increase. The class that is supposed to be for cold data has made cold data more expensive, and it will keep doing so for at least thirty days because of the minimum duration.

There is a second charge that almost nobody models. AWS states plainly that there are per request ingest charges when using PUT, COPY or lifecycle rules to move data into any S3 storage class, and advises considering the ingest or transition cost before moving objects anywhere. Twenty million objects is twenty million lifecycle transition requests, billed per thousand, as a one off charge in the month you run the policy. On a large archive that single number has been known to exceed the first year of savings. Price it in the calculator before you write the rule, not after the invoice arrives.

flowchart TD
  A{Is the average object under 128 KB} -->|Yes| B[Aggregate or compact first, do not tier]
  A -->|No| C{Will anything read it in the next 30 days}
  C -->|Yes, regularly| D[Leave it in the standard class]
  C -->|Rarely or never| E{Is retention longer than the minimum duration}
  E -->|No, data expires sooner| F[Leave it and set an expiry rule instead]
  E -->|Yes| G{Do reads need to be immediate}
  G -->|Yes, milliseconds| H[Instant retrieval class or Google Cloud Archive]
  G -->|Hours are acceptable| I[Deep archive class]
  H --> J[Model the transition request cost before enabling]
  I --> J

Reading a data transfer charge

Data transfer confuses people because the mental model is wrong. Bytes are not priced by how far they go. They are priced by which billing boundary they cross, and the boundaries are availability zone, region, and the public internet. Inbound traffic from the internet is generally free or very cheap. Outbound is where the meter runs.

Some published AWS rates make the shape of this clear. Transfer out from Amazon S3 in Europe Ireland to the internet is 0.09 USD per GB at the first tier. Inter region transfer out from US West Oregon to US East North Virginia is 0.02 USD per GB. Between US East North Virginia and US East Ohio it is 0.01 USD per GB. And the first 100 GB per month of transfer out to the internet is free, aggregated across all AWS services and all regions rather than per region, with a further 1 TB per month free from Amazon CloudFront.

Rates taken from published AWS pricing examples in July 2026 and used to illustrate the ratio between paths. Transfer out to the internet is tiered by volume, so the 50 TB figure is an upper bound before volume tiering applies. Check your own region and current rates before budgeting.

The ratio is the lesson. Serving bytes to the internet costs roughly nine times what moving them between two American regions costs, and the same fifty terabytes swings from five hundred dollars to nearly five thousand depending only on where it lands. That is why the highest value data transfer work is almost never negotiating a rate. It is noticing that a service in one region is talking constantly to a database in another, or that a bucket is being replicated across a continent for a disaster recovery requirement nobody has tested since it was written.

The switching waiver and what it does not cover

Egress fees were for years the standard argument that cloud storage is a one way door. That changed in 2024. Following the direction set by the European Data Act, AWS waived data transfer out to the internet charges for customers moving off the platform, and made it available worldwide rather than only in the European Union. The process is not automatic: you contact AWS Support, they review at the account level, and approved customers receive credits for the data being migrated. AWS updated the terms in September 2025 to give eligible customers ninety days to complete the move, with a requirement to notify support if more time is needed.

Two practical points follow. First, if you are building a business case that includes exit costs, the egress component of that case is now much smaller than the internet folklore suggests, and you should say so rather than quoting a scary number from 2021. Second, the waiver covers transfer out to the internet for the purpose of leaving. It does not touch the far larger and more mundane cost of the data transfer you generate every single day inside your own architecture, which is where essentially all of your actual transfer spend lives.

I would not build a migration strategy on the waiver. I would use it to remove exit cost as a blocker in architectural conversations, then go back to the recurring internal transfer that appears on every invoice regardless of who your provider is.

flowchart LR
  U[User on the internet] -->|Free or cheap inbound| L[Load balancer]
  L --> A[App in region one]
  A -->|Billed egress to internet| U
  A -->|Billed inter region| D[(Database in region two)]
  A -->|Usually free in region| S[(Object storage same region)]
  S -->|Billed inter region| R[(Replica bucket region two)]
  A -->|Check your cloud rules| Z[Service in another zone]

Start with an object size histogram, not a lifecycle policy

Here is the recommendation for this part. Before you write a single lifecycle rule, produce two artefacts. The first is an object size histogram for your largest buckets, showing what fraction of objects fall under 128 KB and what fraction of total bytes those objects represent. The second is a map of your data transfer by path, split into same region, inter region and internet. Both are a day of work with the inventory and cost reports you already have from Part 7.

Those two artefacts will tell you which of three situations you are in. If most objects are tiny, your work is compaction in the write path and tiering will make things worse. If objects are large and genuinely cold, tier them and expect real savings with very little risk. If the storage line is modest but the transfer line is not, ignore storage classes entirely and go and find the service that is chatting across a region boundary, because that single fix will be worth more than every lifecycle policy you could write. Most teams assume they are in the second situation and are actually in the first or third.

Part 15 moves on to Kubernetes and container cost management, where storage and transfer both reappear in a harder form because a cluster hides which workload generated them. The reporting foundation for all of this was built in Part 7, the allocation that makes any of it attributable came from Part 5, and every part so far is indexed on the Cloud FinOps guide.

One thing to do this week: run a listing on your single largest bucket and calculate the average object size. If it is under 128 KB, you have just saved yourself a lifecycle project that would have increased the bill.

References

• Amazon S3 pricing, including minimum storage durations and minimum billable object sizes
• Access tiers for blob data, Microsoft Learn
• Blob rehydration from the archive tier, Microsoft Learn
• Cloud Storage pricing and minimum storage durations, Google Cloud
• Free data transfer out to internet when moving out of AWS, AWS News Blog
• AWS free tier data transfer expansion, 100 GB from regions per month, AWS News Blog

Minimum durations, minimum billable object sizes, rehydration windows and transfer rates were verified against AWS, Microsoft and Google documentation in July 2026 and change over time. Volume figures in the tables are arithmetic from the published minimums rather than quotes from a live price list.

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts