Amazon S3
Amazon S3
Object storage accessed via an HTTP API, not a filesystem — though key design, storage-class selection, and permission layering all behave like early, hard-to-reverse architecture decisions despite S3's reputation as the AWS service you do not have to think about. Eight pages, in the order the decisions actually depend on each other — start at one, not wherever looks interesting.
S3 has no real directory structure — "folders" are a console illusion
built from /-delimited key prefixes. That prefix structure is
simultaneously your access-pattern design, your request-throughput
ceiling (see page 5), and your primary lever for parallelizing
reads and writes.
S3 pricing has independent dimensions that don't show up on the same line as "storage" — PUT/COPY/POST/LIST requests are billed roughly 12.5x higher per-request than GET requests, and data transferred out to the internet is billed separately from storage entirely, with the first 100 GB/month free (aggregated across AWS services) and real per-GB rates beyond that.
Storage class selection is roughly a 23x cost range for the same bytes (S3 Standard at ~$0.023/GB down to Glacier Deep Archive at ~$0.00099/GB) — but the cheaper classes trade that discount for real constraints: minimum storage durations, minimum billable object sizes, and retrieval fees that don't exist on Standard.
S3 access control isn't one system — it's up to three overlapping
ones. IAM policies (identity-based, "what can this principal do"),
bucket policies (resource-based, "who can access this bucket"), and
legacy ACLs (object- or bucket-level grants) can all apply to the same
request simultaneously, with Block Public Access acting as a separate
account- or bucket-level override that can silently supersede all
three. AWS has also moved the platform's own default since this
matters most: since April 2023, every newly created bucket gets Block
Public Access enabled and ACLs disabled automatically (the
BucketOwnerEnforced object-ownership setting) — the three-way
overlap described above is now mainly a concern for buckets created
before that change, not a live default for new ones.
S3 supports at least 3,500 write (PUT/COPY/POST/DELETE) and 5,500 read (GET/HEAD) requests per second, per partitioned prefix — with no limit on the number of prefixes a bucket can have. This makes throughput a design choice, not a fixed ceiling, but only if the key scheme (page 1) actually spreads load across prefixes.
Since December 2020, S3 delivers strong read-after-write consistency
for all operations, automatically, at no extra cost and no
performance penalty — a write, overwrite, or delete is immediately
visible to any subsequent read or list operation. This is a genuine,
dated change from S3's original eventual-consistency model. What it
doesn't give you is atomicity across concurrent overlapping writes to
the same key — two simultaneous PUTs still resolve last-writer-wins,
with no built-in compare-and-swap. S3 closed that specific gap with
conditional writes (If-None-Match in 2024, If-Match at re:Invent
2024) rather than by changing the consistency model itself — the two
are separate mechanisms solving separate problems.
S3 Versioning can be enabled and suspended, but never fully disabled once turned on — it's a one-directional switch at the bucket level, and every version of every object is billed at full storage rates for as long as it exists, current or not.
S3 is object storage accessed via an HTTP API — not a filesystem, and
that's still true of the core S3 API itself. But the service boundary
around S3 isn't the clean binary it used to be: Mountpoint for Amazon
S3 (GA 2023) mounts a bucket for high-throughput read/sequential-write
workloads, and Amazon S3 Files (GA April 2026) goes further, exposing
an NFS v4.1/4.2 mount backed by an S3 bucket. If application code
expects open/read/write/close semantics, a mounted path, or
POSIX behavior, the honest framing in 2026 is a three-way decision,
not an S3-vs-EBS/EFS one.