S3 Pricing Explained: The Four Costs That Actually Bill You

Everybody knows the S3 storage rate. Roughly $0.023 per GB per month, tiering down slightly past 50 TB. It is printed on every pricing page and quoted in every thread.

It is also, for most teams, the smallest of the four things S3 bills you for. The bill that shocks you is rarely a storage bill.

Meter one: storage, per GB-month

This is the one people budget for. S3 Standard bills about $0.023 per GB for the first 50 TB each month, about $0.022 for the next 450 TB, and about $0.021 beyond 500 TB. Storage is prorated hourly, so a file that exists for a day costs a thirtieth of a month.

A terabyte of Standard storage is therefore about $23 per month. If your bill is $400, storage is not why.

Meter two: requests

Every API call has a price. PUT, COPY, POST, and LIST cost roughly $0.005 per 1,000 requests. GET, SELECT, and friends cost roughly $0.0004 per 1,000.

Those numbers look like nothing, and they are nothing right up until your code lists a bucket inside a loop. A nightly job that calls LIST once per object across 2 million objects is a $10 job that should have cost a cent. Multipart uploads bill each part separately, so chunking a file into 10,000 tiny parts costs 10,000 PUTs.

Requests are the meter that punishes bad code rather than heavy usage. They are also the easiest to fix once you can see them.

Meter three: data transfer out - the one that actually hurts

Data into S3 is free. Data out is not. The first 100 GB per month is free, and after that egress runs around $0.09 per GB, tapering at very high volume.

Consider what that means concretely. Storing 500 GB of product images costs about $11.50 per month. Serving those images to users 20,000 times a month, at 500 GB of transfer, costs about $36. The storage was never the problem.

If your bucket is a public file server, your bill is an egress bill wearing a storage bill's clothes. Put a CDN in front of it before you touch anything else.

A CDN converts repeat reads into cache hits that never reach the bucket. That reduces the egress meter and the request meter simultaneously, and it is almost always the single highest-leverage change available.

Meter four: retrieval, and the lifecycle trap

Cheaper storage classes are not simply cheaper. They trade money now for money later, and the trade is only good if your access pattern cooperates.

Three traps live in that table, and all three are common:

• Minimum durations are billed whether or not the object survives. Move an object to Glacier Deep Archive and delete it a week later and you still pay for 180 days of storage.

• Retrieval is per GB, and it is not cheap. Reading an archive back can cost more than a year of storing it in Standard would have.

• Intelligent-Tiering charges per object, not per GB, to monitor. For millions of small objects, that monitoring fee can exceed the savings it produces.

The rule of thumb: archive classes pay off for data you are legally obliged to keep and practically never read. For anything a user might request, Standard usually wins once retrieval is priced in.

Putting it together

Here is a realistic media-heavy bucket, priced across all four meters:

Storage
  800 GB, S3 Standard
  800 x $0.023                                  $18.40
​
Requests
  1.2 M GET  x $0.0004 / 1,000                   $0.48
  90 K  PUT  x $0.005  / 1,000                   $0.45
                                                -------
                                                 $0.93
​
Data transfer out
  1,100 GB served, first 100 GB free
  1,000 x $0.09                                 $90.00
​
Retrieval
  none (all objects in Standard)                 $0.00
                                                -------
TOTAL                                          $109.33
​
Egress is 82% of the bill. Storage is 17%.

The instinct is to reach for a cheaper storage class. That would save perhaps $10 and slow every read. Putting a CDN in front would save most of the $90.

Cutting an S3 bill, in order of leverage

1. Cache aggressively at the edge. Repeat reads should never reach the bucket. This attacks the largest meter first.

2. Audit request patterns. Look for LIST inside loops, unbounded pagination, and multipart uploads with tiny parts.

3. Right-size multipart chunks. Larger parts mean fewer requests. Anything under 8 MB per part is usually wasteful.

4. Only then consider storage classes. And only for data with a genuinely cold access pattern that you have measured, not assumed.

5. Reconsider egress-billed storage entirely. If your workload is read-heavy and public, per-GB egress is structurally hostile to you.

The S3-compatible escape hatch

That last point is worth sitting with. Egress pricing is not a technical necessity; it is a commercial choice. AWS charges per GB out because it can, and because doing so makes leaving expensive. Several providers implement the same S3 API and decline to make that choice.

This matters more than it sounds, because the S3 API is effectively a standard. Your application talks to it through an SDK that accepts an endpoint URL. Pointing that SDK at a different S3-compatible endpoint is usually a configuration change rather than a rewrite: same bucket semantics, same presigned URLs, same multipart upload flow.

The practical consequence is that egress-heavy workloads have an exit that costs very little to take. If 82 percent of your bill is data leaving a bucket, and the bucket's API is portable, then the pricing model is the only thing keeping you there.

Swyftstack's object storage is S3-compatible and included in the plan rather than metered per GB out. The Launch plan at $19 per month covers 200 GB of object storage and 500 GB of egress; Growth at $99 covers a terabyte of storage and two terabytes of egress. When your bill is 82 percent egress, changing the pricing model beats optimising within it. Disclosure: that is our product, and it is the wrong choice if you need S3's deep integration with the rest of AWS.

Because none of this means S3 is a bad service. It is the most durable, most integrated, most thoroughly documented object store in existence, its consistency guarantees are excellent, and for workloads that are write-heavy and read-light it is genuinely cheap. If your data mostly sits still - backups, logs, archives that nobody streams to a browser - the egress meter never fires and S3's storage rate is hard to beat.

The failure mode is not choosing S3. It is choosing S3 for a workload whose defining characteristic is serving bytes to the public, then optimising the storage class while the egress meter runs. Price all four meters against your actual access pattern before you decide, rather than the one printed on the marketing page.

Prices quoted here were checked in July 2026. Vendors change them; treat the structure as the durable part and re-check the current numbers before you budget.