One flat, sorted list of keys. Folders are just text.
A bucket lives in one region. Keys run up to 1,024 bytes; objects up to 50 TB, replaced whole, never edited.
Is S3 eventually consistent?
Bad: Yes, reads can lag writes
Out of date since 1 December 2020.
Good: Strong, per key
Reads after a successful PUT or DELETE see it. But last writer wins; no multi-key transactions.
A 2 GB video should never touch your servers.
The API writes a pending row and returns a presigned URL. The phone PUTs the bytes straight to S3.
A 10 GB phone video. One PUT stops at 5 GB, and connections drop.
The trick
Multipart: 640 parts of 16 MiB, each presigned. A drop costs one part; Complete makes it appear whole.
3,500/s
writes per partitioned prefix, at least
Reads get 5,500. Date-first keys aim a day’s 9,000 PUT/s at one range: 503 Slow Down. A hash prefix spreads it, four × 2,250.
A sale month: serving images costs six times storing them.
1 billion views of 200 KB is 200 TB out, ≈ $13,800. Put a CDN in front: S3-to-CloudFront transfer is free.
When to pick it, when not
- Pick: large files, written once, kept or read often
- Not: updating in place or appending often
- Not: small values needing millisecond reads
- Not: data you query by attributes
Say it like this
Big, write-once bytes go to S3: presigned and multipart uploads, a CDN for reads, metadata in a database. Strong per key; ≥ 3,500 writes/s per prefix. Not for in-place updates or queries.