A product stores 400 million thumbnails averaging 20 KB each in an infrequent-access object storage class to save money. The storage line on the bill is roughly six times what the team calculated. What is the most likely cause?

The mechanism

Infrequent-access storage classes are priced for objects that are large and rarely read, and the published terms say so explicitly: S3 Standard-Infrequent Access and One Zone-IA have a minimum billable object size of 128 KB, as does Glacier Instant Retrieval. A smaller object is stored faithfully and billed as though it were 128 KB.

The arithmetic follows directly. 400 million objects at a real 20 KB each is 8 TB of data and 51.2 TB of billed storage - a factor of 6.4, which is the number on the bill. The cheaper per-gigabyte rate was more than cancelled by the floor.

Archive classes add a second overhead on the same axis: AWS charges for 40 KB of extra metadata per object archived to Glacier Flexible Retrieval or Deep Archive. For 20 KB thumbnails that overhead alone is twice the payload.

What to do instead

• Pack. Group thumbnails into container objects of a few megabytes with an index that records the offset and length of each one, then fetch with a ranged read. The range request is a normal operation, so reads stay per-thumbnail while billing becomes per-container. A hundred 20 KB images in one 2 MB object removes the floor entirely.
• Keep small, hot objects in the standard class. The IA discount is on storage, and the standard class has no size floor, no 30-day minimum duration and no retrieval fee. Below roughly 128 KB, infrequent access is almost never cheaper.
• Check the minimum duration too. Standard-IA charges a minimum of 30 days, Glacier Instant and Flexible Retrieval 90 days, Deep Archive 180 days. Lifecycle rules that move an object down a tier and delete it a week later pay the remainder of the minimum.

Why the other options fail

• "Replication to a second region." Cross-region replication does double stored bytes and appears as its own line on the bill, under a different region. A 6.4x factor on one region's storage line cannot come from a 2x mechanism.
• "Versioning is retaining an old copy of every object." Real and common: a bucket with versioning and no expiry rule quietly keeps every overwrite. It would show as roughly 2x for one overwrite each, and thumbnails are usually written once.
• "Counted before compression." Billing counts stored bytes, which are the bytes you uploaded. Nothing compresses them for you, and JPEG thumbnails are already compressed.

When this is the wrong answer

If the objects were 2 MB video segments rather than 20 KB thumbnails, the floor is irrelevant and the IA class is the right call. The floor only bites below 128 KB, and the packing fix only pays when the access pattern tolerates fetching a container - if each thumbnail is read independently and randomly at high rate, a ranged read adds latency and the per-request charges may dominate anyway. For a few million small objects the whole exercise is worth a few pounds a month and is not worth the index you would have to maintain.