S3 request pricing: the 18 KB line (2026)

S3 request pricing is the one S3 meter that inverts on small objects. In US East (N. Virginia), S3 Standard charges $0.0004 per 1,000 GET requests and $0.023 per GB-month of storage. Divide one by the other and a single GET per object per month costs more than a month of storage for any object smaller than 18.24 KiB. In S3 Glacier Instant Retrieval the same line sits at 2.56 MiB, and once the per-GB retrieval fee is counted there is no object size at all where one read a month is cheaper than keeping the bytes.

How much does an S3 GET request cost in 2026?

$0.0004 per 1,000 GET requests in S3 Standard, US East (N. Virginia). The rate tables on the Amazon S3 pricing page are rendered by JavaScript, but the prose beside them states the same figures. From the S3 Object Lambda section: "you pay $0.0004 per 1,000 requests for all S3 GET and HEAD requests, or $0.005 per 1,000 requests for all LIST requests." The table below comes from the AWS Price List file for Amazon S3 in us-east-1, version 20260911124507, which agrees with that prose and with the S3 FAQ's replication example.

Read the columns against each other and the shape of the pricing is obvious. Moving from S3 Standard to Glacier Instant Retrieval divides storage by 5.75 and multiplies the GET rate by 25. Express One Zone does the reverse: storage costs 4.78 times S3 Standard, a GET costs a thirteenth. The classes are not cheap or expensive, they are priced for a read frequency, and the request column is where that choice is enforced.

Which S3 operations are billed as PUT requests and which as GET requests?

Two classes, and the split is not the HTTP verb. The S3 usage type reference defines Requests-Tier1 as "The number of PUT, COPY, or POST requests for S3 Standard, RRS, and tags, plus LIST requests for all buckets and objects", and Requests-Tier2 as "The number of GET and all other non-Tier1 requests". Everything that is not a write or a listing, including HEAD, falls into the cheap tier by default.

Deletion is free. The pricing page says "DELETE and CANCEL requests are free", and the DeleteObjects API reference adds that "The request can contain a list of up to 1,000 keys that you want to delete." Note that the S3 performance guidance groups DELETE with the writes: "your application can achieve at least 3,500 PUT/COPY/POST/DELETE or 5,500 GET/HEAD requests per second per partitioned Amazon S3 prefix." That grouping is about partition throughput, not billing. The two taxonomies look alike and are not the same.

Multipart uploads bill per part, and the class rate applied is not the one you asked for. The multipart upload overview states that for a PUT to S3 Glacier Flexible Retrieval, "both CreateMultipartUpload and UploadPart are billed at S3 Standard rates. Only the CompleteMultipartUpload request is billed at the S3 Glacier Flexible Retrieval rate." A 100-part archive upload is therefore 101 S3 Standard Tier1 requests and one Glacier request, not 102 Glacier requests. Parts that never complete keep billing as storage, which is its own line item: see what incomplete S3 multipart uploads cost.

One request source surprises people because nobody wrote the code. The pricing page: "When you use the Amazon S3 console to browse your storage, you incur charges for GET, LIST, and other requests that are made to facilitate browsing."

Why is an S3 LIST request billed at the S3 PUT rate?

Because AWS prices it as a write-class operation regardless of which storage class the objects sit in. The pricing page states the rule plainly: "LIST requests for any storage class are charged at the same rate as S3 Standard PUT, COPY, and POST requests." The usage type reference agrees, folding LIST requests "for all buckets and objects" into the S3 Standard Tier1 meter.

Per request that is 12.5 times a GET. Per object it is the cheapest way to touch S3 there is, because ListObjectsV2 returns a page of keys: "By default, the action returns up to 1,000 key names. The response might contain fewer keys but will never contain more." At $0.005 per 1,000 requests and 1,000 keys per request, a listed key costs $0.000000005, which is one eightieth of a GET on the same object. A full scan of a 50-million-object bucket is 50,000 LIST requests and $0.25.

That last row is the trap. Listing a million keys costs $0.005 with the default page size and $5.00 if something pins max-keys to 1, a thousandfold difference for identical output. Crawlers and inventory jobs are the usual offenders: what a Glue crawler actually costs.

Here two AWS sources disagree, and the gap is 4x. The price list file's own dimension description for Requests-GIR-Tier1 reads "$0.02 per 1,000 PUT, COPY, POST or LIST requests to Glacier Instant Retrieval", which would price that 50-million-object scan at $1.00 rather than $0.25 if the objects were archived. The usage type reference describes the same meter without LIST in it: "The number of PUT, COPY, or POST requests on S3 Glacier Instant Retrieval objects." Two of the three sources say a LIST is always $0.005 per 1,000; the machine-readable price catalogue says otherwise for the archive classes. Budget the higher figure for an archive bucket you scan often, and check the line item rather than the documentation once it appears.

At what object size do S3 request charges exceed S3 storage charges?

Set the two meters equal and solve. A month of storage for one object costs its size in GB times the class storage rate. A month of reads costs the number of GETs times the class request rate. Neither depends on the other, so the crossover is a single division: the object size at which one GET a month equals one month of storage is the per-request rate divided by the per-GB-month rate. AWS publishes both numbers and never puts them side by side.

Below those sizes, the request meter is the larger of the two and adding storage tiering does nothing about it. Read the same relationship the other way and it becomes an access budget. These are the GETs per object per month at which request charges match storage charges, request charges only:

A hypothetical bucket makes the scale concrete. Five million objects of 32 KiB is 152.59 GB, or $3.51 a month of S3 Standard storage. Writing them once costs $25.00 in PUT requests, seven months of their own storage. Reading each one twice a month costs $4.00, which already exceeds the storage bill. The S3 Standard-IA and Glacier Instant Retrieval columns are worse for objects this small than the table suggests, because both bill a 128 KB minimum per object: that rounding, the 30-day and 90-day minimum durations and the 40 KB Glacier metadata overhead are covered in when a cheap S3 storage class costs more.

A different comparison governs replication, where a PUT is weighed against inter-Region data transfer and the line falls near 262 KB: S3 replication pricing has that arithmetic. Storage recurs every month and a request does not, so this crossover turns on access frequency and not on object size alone.

Does one GET a month cost more than a month of Glacier Instant Retrieval storage?

Yes, at every object size, and it is the retrieval fee rather than the request that does it. The price list prices the S3 Glacier Instant Retrieval retrieval meter at "$0.03 per GB - flat fee for all bytes retrieved in Glacier Instant Retrieval", against $0.004 per GB-month of storage. One full read of an object therefore costs 7.5 months of keeping it. S3 Standard-IA is milder at "$0.01 per GB - flat fee for all bytes retrieved in Standard-Infrequent Access" against $0.0125 of storage, or 0.8 months per read, which still means anything read more than about 1.25 times a month costs more to read than to keep.

AWS positions Glacier Instant Retrieval on the pricing page as being "For long-lived archive data accessed once a quarter with instant retrieval in milliseconds". Take that cadence literally. One retrieval every three months amortises to $0.01 per GB-month, which is 2.5 times the $0.004 of storage it sits beside, before a single request charge. The class is still the cheaper home for those bytes overall, at $0.014 per GB-month all in against $0.023 in S3 Standard, but only by 1.64x rather than the 5.75x the storage column advertises. On five million 256 KiB objects, one GET each per month is $50.00 of requests plus $36.62 of retrieval against $4.88 of storage: 17.7 times the storage bill.

How much do S3 lifecycle transition requests cost per storage class?

A transition is a billable request priced by destination, tracked separately from your own writes. The usage type reference defines Requests-Tier4 as "The number of lifecycle transitions to S3 Glacier Instant Retrieval, S3 Intelligent-Tiering, S3 Standard-IA, or S3 One Zone-IA storage", with Glacier Flexible Retrieval and Deep Archive transitions landing in Requests-Tier3 instead.

The charge is per object and ignores size, so it has a payback period. Five million 200 KiB objects moved from S3 Standard to S3 Standard-IA cost $50.00 in transition requests and save $10.01 a month in storage: just under five months before the rule is ahead, and that assumes nothing reads the objects afterwards at the higher Standard-IA GET rate. AWS blocks the worst version of this by default, and the lifecycle transition considerations say why: "We don't recommend transitioning objects less than 128 KB because you are charged a transition request for each object. This means, for smaller objects, the transition costs can outweigh the storage savings."

Which S3 requests does AWS not charge for?

Four categories, and one of them is documented in a place nobody looks. Deletes and cancels are free. Bulk restores from S3 Glacier Flexible Retrieval are priced at zero in the price list file. Server errors are not billed at all, and a specific list of client errors is exempt. The billing for Amazon S3 error responses page states the rule: "In general, S3 bucket owners are billed for requests with HTTP 200 OK successful responses and HTTP 4XX client error responses. Bucket owners aren't billed for HTTP 5XX server error responses, such as HTTP 503 Slow Down errors."

So throttling is free, which matters when a workload is ramping into a new request rate and collecting 503s. Anonymous probing is free too, by a separate rule on the same page: "For AccessDenied (HTTP 403 Forbidden), S3 doesn't charge the bucket owner when the request is initiated outside of the bucket owner's individual AWS account or the bucket owner's AWS organization."

Read that page for what it omits, though. It enumerates exempt error codes under 301, 307, 400, 403, 404, 405, 409, 411, 412 and 416, and the 404 list contains NoSuchUpload, NoSuchWebsiteConfiguration and five siblings. It does not contain NoSuchKey or NoSuchBucket. An application that probes for an object before writing it, or a cache that treats a miss as a normal path, is paying the full Tier2 rate for every miss. On a 40%-miss workload doing a billion lookups a month, that is $160 of GET charges buying nothing but the word no.

How do you find S3 request charges on an AWS bill?

By usage type, not by service. Requests never appear as their own line: they appear as Requests-Tier1, Requests-Tier2, Requests-SIA-Tier1, Requests-GIR-Tier2 and the rest of the codes in the usage type reference, all under Amazon S3 alongside TimedStorage-ByteHrs. The reference notes that "For the US East (N. Virginia) Region, the region prefix is omitted from usage type codes", so a us-east-1 bucket shows the bare code and every other Region carries a prefix. Grouping by usage type is the one view that separates the request meter from the storage meter, which Cost Explorer and the CUR both support and neither does by default.

Two things change who pays. With a Requester Pays bucket, "The requester pays for the data transfer and the request, and the bucket owner pays for the data storage", with an asymmetry worth knowing for archives: on a restore, "the requester only pays for the cost of the request. The bucket owner pays the retrieval charges." And measuring requests costs money of its own. S3 CloudWatch request metrics are opt-in and "billed at the standard CloudWatch rate", while storage metrics "are provided to all customers at no additional cost."

The ceiling is worth holding in mind before optimising anything. At the documented 3,500 writes per second per prefix, sustained for a 30-day month, S3 Standard Tier1 requests alone are $45,360. At 5,500 reads per second the Tier2 charge is $5,702. Query engines hit this from the other direction, by turning one analytical scan into millions of GETs against small files: controlling Athena query cost covers the file-size side of the same problem. The general answer to a request-heavy S3 bill is fewer, larger objects, and the crossover table above is how to work out where larger stops paying.