Amazon S3

Object storage accessed via an HTTP API, not a filesystem. S3 has a reputation as the AWS service you do not have to think about, but key design, storage-class selection, and permission layering all behave like early, hard-to-reverse architecture decisions. Eight pages, in the order the decisions actually depend on each other — start at one, not wherever looks interesting.

Decision drivers for this product

Primary access pattern (sequential scan, random lookup, analytics partition pruning) — the key/prefix scheme has to be designed around it before millions of objects exist, not after.

Whether content is served directly to end users (egress economics) versus accessed only by internal AWS services.

Expected object lifetime against each storage class's minimum storage duration, since a mismatch triggers early-deletion fees that erase the discount.

Whether access is same-account or cross-account, and which of IAM policies, bucket policies, or legacy ACLs actually governs a given bucket.

Whether the bucket has versioning enabled, since that changes what a plain DELETE actually does to the data.

Decision sequence

Core one-way-door

Designing Your Key and Prefix Scheme Before You Have a Million Objects

S3 has no directories. What the console shows as folders is an illusion built from key prefixes — a "folder" is just every object whose key starts with the same /-delimited string.

That prefix structure matters more than it looks. It is your access pattern design, it sets your request-throughput ceiling (page 5), and it is your main lever for parallelizing reads and writes. One naming decision carries all three at once.

Free

Cost & billing mechanics

Understanding Request and Egress Economics Before Your Bill Surprises You

S3 pricing has dimensions that never show up on the "storage" line. Requests are billed by type: PUT/COPY/POST/LIST requests cost roughly 12.5x more per request than GET requests. Data transferred out to the internet is billed separately from storage entirely. The first 100 GB/month of that egress is free, aggregated across AWS services, with real per-GB rates beyond it.

Free

Cost & billing mechanics

Choosing Storage Classes Without Triggering the Minimum-Duration Trap

Storage class selection spans roughly a 23x cost range for the same bytes: S3 Standard at ~$0.023/GB down to Glacier Deep Archive at ~$0.00099/GB.

The cheaper classes trade that discount for real constraints. They carry minimum storage durations, minimum billable object sizes, and retrieval fees that do not exist on Standard.

Free

Security & identity

Choosing an Access Model Before Three Permission Systems Disagree

S3 access control is not one system. Up to three can apply to the same request simultaneously. IAM policies are identity-based: they say what a principal can do. Bucket policies are resource-based: they say who can access a bucket. Legacy ACLs grant permissions at the object or bucket level. On top of all three sits Block Public Access, a separate account- or bucket-level override that can silently supersede them all.

The platform's own default has also moved. Since April 2023, every newly created bucket gets Block Public Access enabled and ACLs disabled automatically, via the BucketOwnerEnforced object-ownership setting. The three-way overlap is now mainly a concern for buckets created before that change, not a live default for new ones.

Scaling & capacity limits

Staying Under the Per-Prefix Request-Rate Ceiling Before Getting Throttled

S3 supports at least 3,500 write requests per second (PUT/COPY/POST/DELETE) and 5,500 read requests per second (GET/HEAD) — per partitioned prefix. A bucket can have any number of prefixes.

That combination makes throughput a design choice rather than a fixed ceiling, but only if the key scheme (page 1) actually spreads load across prefixes.

Failure mode & consistency

Trusting Read-After-Write, and Knowing What "Delete" Actually Does

Since December 2020, S3 delivers strong read-after-write consistency for all operations — automatically, at no extra cost, with 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 does not 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.

Operational lifecycle

Managing Version Retention Before Noncurrent Versions Quietly Multiply Your Bill

S3 Versioning can be enabled and suspended, but never fully disabled once turned on. It is a one-directional switch at the bucket level. And every version of every object — current or not — is billed at full storage rates for as long as it exists.

Wrong-tool / alternatives

Ruling Out S3: When You Actually Need a Filesystem or a Disk

S3 is object storage accessed via an HTTP API, not a filesystem. That is still true of the core S3 API itself.

But the service boundary around S3 is not the clean binary it used to be. Mountpoint for Amazon S3 (GA 2023) mounts a bucket for high-throughput read/sequential-write workloads. Amazon S3 Files (GA April 2026) goes further, exposing an NFS v4.1/4.2 mount backed by an S3 bucket. So if your 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 S3-versus-EBS/EFS.