TL
The short answer

S3 charges in two dimensions that buyers routinely conflate: storage, billed per GB per month by class, and requests, billed per thousand operations. GET, PUT, COPY, POST, LIST, and the lifecycle transitions that move data between classes are each priced, and colder classes carry higher request and retrieval costs to offset their lower storage rate. The practical consequence is that a bucket of many small, frequently read objects can spend as much on requests as on storage, and a lifecycle rule that transitions everything to a colder class can raise the bill rather than lower it. The fix is to manage the request profile alongside the storage class, not instead of it.

Here is how request pricing works, where the forgotten charges hide, and how to cut them without hurting the workload.

How does S3 request pricing actually work?

Every operation against S3 is a billable request. Writes such as PUT, COPY, and POST are priced per thousand, reads such as GET and SELECT are priced per thousand at a lower rate, and LIST operations are priced like writes because they are expensive to serve. The rates differ by storage class: the warm general purpose class has the cheapest requests, while the infrequent access and archive classes charge more per request and add retrieval fees on top. Because the rate is per operation and not per byte, the cost is driven by how many objects you touch, not how large they are. A job that reads ten million tiny objects pays far more in requests than a job that reads ten thousand large ones holding the same data.

Which request costs do buyers forget?

ChargeWhat triggers itWhere it bites
PUT, COPY, POSTEvery object written or copiedPipelines writing millions of small files
GET, SELECTEvery object read or queriedHot data lakes and content served object by object
LISTEnumerating bucket contentsRecursive crawls and jobs that list before reading
Lifecycle transitionEach object moved to another classBulk transitions of many small objects
RetrievalReading from infrequent access or archive classesColder data that turns out to be read often

The two most overlooked are lifecycle transitions and retrieval. Both are easy to ignore because they do not appear when you reason about storage as a price per GB, yet both are billed per object and both scale with object count. A bucket with a hundred million small objects can incur a meaningful one time transition cost just to move classes, before any storage saving accrues. All figures here are indicative; verify against current AWS S3 pricing for your region.

Why can a colder storage class raise the bill?

The infrequent access and archive classes trade a lower per GB storage rate for higher per request and retrieval costs, and they carry minimum object size and minimum storage duration assumptions. On large objects that are genuinely cold, that trade is a clear win. On small objects, the minimum billable size means a tiny file is charged as though it were larger, eroding the storage saving. On objects that are still read regularly, the higher GET and retrieval rates can overwhelm the storage saving entirely. So the colder class pays off precisely when objects are large and rarely accessed, and works against you when they are small or active. Matching the rule to that reality is the whole discipline.

A worked example

Worked example

A media company set a blanket lifecycle rule transitioning every object older than thirty days to an infrequent access class to cut storage cost. The bucket held roughly two hundred million thumbnail and metadata objects, most under the minimum billable size, and a recommendation engine still read them constantly. The transition itself generated a large one time request bill, the minimum object size wiped out most of the per GB saving on the small files, and the higher GET rate on the still active reads pushed the monthly request line up. Reworking the rule to transition only objects above a size threshold that were genuinely cold, and combining small metadata into batched objects, cut total S3 cost by about a quarter while leaving the hot path on the warm class. Figures are verified against billing data and anonymised.

Frequently asked questions

Does S3 charge for requests as well as storage?
Yes. Storage is billed per GB per month and requests are billed per thousand operations, with GET, PUT, COPY, POST, LIST, and lifecycle transitions each priced. On buckets with many small objects or heavy listing, request charges can rival or exceed the storage line.
Why did moving data to a colder S3 class raise my bill?
Colder classes lower the per GB rate but raise per request and retrieval costs and bill the transition per object. Moving millions of small or still active objects can cost more in transition and retrieval than it saves on storage. Class changes pay off on large, rarely read objects.
How do you cut S3 request costs?
Reduce operations: batch small objects, cache and avoid repeated LIST calls, use S3 Inventory rather than recursive listing, and set lifecycle rules that match real access. Right sizing the class is half the job; the request profile is the other half.

Get the whole S3 bill under control

We help teams model the full S3 picture, storage and requests together, so lifecycle rules and class choices lower the bill instead of moving cost from one line to another, as an independent advisory that takes zero provider commissions and answers only to you. Our guarantee: we reduce your cloud spend or we reimburse our service fee, on a Fixed Fee or a no risk Gainshare basis. Download the cloud cost optimization playbook, read the deeper AWS cost optimization guide, and pair this with S3 storage classes and lifecycle policies. For monthly buyer side analysis, subscribe to The Cloud Spend Navigator.

Independent · buyer-side

Put a defensible number on your cloud spend.

No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.

Buyer-side intelligence, monthly.

The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.