What Is Amazon S3 and How Does It Work

S3 runs on two primitives. Buckets and objects.

A bucket is a globally unique namespace. Not unique to your account. Unique across all of AWS. One flat namespace, globally enforced.

An object is your data plus metadata. System metadata like content type and creation date, your storage class, optional key-value pairs you attach yourself. The object's identity inside a bucket is its key. A key looks like logs/2024/app.log. It is not a path. It is a string.

This is where people get tripped up. The S3 console shows you what looks like folders. You click into logs/, then 2024/, and find your file. Looks like a directory tree. It isn't. The console is just rendering prefix-delimited strings as if they were folders. The / has no structural meaning underneath it. S3 genuinely does not know what a folder is — you could say it's completely direc-tory of that concept.

That's not an oversight. Flat namespaces distribute more evenly across storage nodes, and hierarchy creates coordination overhead and hot spots. The engineers who built S3 made a deliberate call.

A few other things worth knowing about the model as of 2025:

• Object size: up to 50 TB per object, a 10x increase from the previous 5 TB cap announced at re:Invent 2024. Single-operation uploads cap at 5 GB. Above that, you use the multipart upload API.
• Durability: 99.999999999%, eleven nines. Objects are stored redundantly across a minimum of three Availability Zones per region.
• Access: HTTP REST API, AWS SDK, or the console. No mounting. No file descriptors. No seeking. You retrieve whole objects, or byte ranges, over the network.

S3 was never trying to be a file system. If you walk in expecting one, you're going to be confused for a while.

The storage class tier system and what drives the tradeoffs

S3 isn't one product. It's a spectrum of products sharing the same API, each with a different durability, latency, and cost profile — like a buffet where every dish looks the same but the price tags are very different.

S3 Standard is your general-purpose workhorse. Multi-AZ redundancy, roughly 100 to 200 milliseconds of latency for small object access. The default for a reason.

S3 Intelligent-Tiering auto-moves objects across up to five tiers based on actual access patterns. No retrieval fees. Thirty-day minimum storage duration. If you genuinely don't know how often your data will be accessed, this is the low-friction answer. It manages lifecycle so you don't have to write manual rules.

S3 Glacier Flexible Retrieval is where data goes when you need it eventually, not now. Costs around $0.0036 per GB. Retrieval times run from one to five minutes on the fast end, up to five to twelve hours for bulk. Cost-optimized archival. No live access.

S3 Express One Zone is the interesting one. Single-digit millisecond response times, up to ten times faster than S3 Standard. It co-locates storage and compute within a single Availability Zone using what AWS calls "directory buckets," and it supports up to two million requests per second per bucket. In April 2025, AWS cut its prices significantly: storage down 31%, PUT requests down 55%, GET requests down 85%.

When AWS drops prices that sharply on a tier, they're telling you where they want workloads to land. In this case: ML training and real-time pipelines.

The core tradeoff across all of this is straightforward. Standard's multi-AZ durability adds latency because of the coordination overhead between zones. Express One Zone eliminates that hop and gets you much faster access, but concentrates risk inside a single AZ. Faster, but less resilient. Neither is wrong. It depends entirely on what you're building and what failure modes you can live with.

How S3 scales throughput and where prefix design matters

S3 has per-prefix throughput limits. Per AWS documentation: 3,500 PUT/COPY/POST/DELETE or 5,500 GET/HEAD requests per second per prefix.

Here's the part people miss: there's no limit on the number of prefixes in a bucket. So throughput scales horizontally by adding prefixes and parallelizing work across them. Ten prefixes in one bucket gets you to 55,000 read requests per second. The architecture rewards intentional key design. If all your objects share the same prefix, you're leaving most of your available throughput sitting on the floor.

At data lake scale, this compounds fast. Applications scanning petabytes across billions of objects can reach very high aggregate throughput when the work is spread correctly across prefixes and parallelized across multiple compute instances. Get the key structure wrong from the start and you're rearchitecting later under pressure.

The HTTP Range header adds another dimension. You can issue concurrent requests pulling different byte ranges from the same object simultaneously. For large files and training data shards, that matters.

One number worth internalizing: the 90th-percentile time-to-first-byte for S3 Standard is typically around 20 milliseconds, regardless of object size. That's the latency floor. It doesn't shrink because your object is small. Teams designing for real-time use are working around that floor, not through it.

AWS launched S3 Files in early 2026. It's an abstraction that automatically scales throughput and IOPS without requiring manual provisioning. Internally it applies a two-tier model so that small-file and large-file workloads both get appropriate performance without you tuning key structures. Too new to have a real track record, but the direction is clear.

S3 throughput is not a fixed number. It's a function of how work is distributed across prefixes and how requests are parallelized.

S3 as the default storage layer for AI training pipelines

S3 is where most training datasets live. This is not a controversial claim. Datasets like Common Crawl (roughly 400 TB) and large computer vision corpora live in S3. The 50 TB per-object limit introduced in 2025 reduces the elaborate sharding gymnastics teams used to pull off for datasets this size.

The classic problem is simple. GPUs are expensive and they sit idle when the data pipeline can't feed them fast enough. Stream naively from S3 without deliberate design and the storage layer becomes the bottleneck, not the compute. You've paid for the GPUs. You're training at storage speed. It's like hiring a Formula 1 driver and then sending them out in rush-hour traffic.

AWS addressed this directly with the Amazon S3 Connector for PyTorch. It integrates into training loops, handles concurrent request management automatically, and supports both map-style (random access) and iterable-style (streaming sequential) dataset patterns. Per AWS, checkpoint saves are up to 40% faster than saving to EC2 instance storage. That last number matters because checkpointing happens constantly during long training runs.

Practices that close the gap:

• Shard datasets into chunks of 100 MB to 1 GB. This aligns with S3's throughput profile for sequential reads.
• Cache frequently accessed training data. Multi-epoch training means you're reading the same data many times. Repeated round-trips to S3 for the same objects add up.
• Favor sequential access over random access. S3 delivers significantly higher throughput for sequential reads.

SageMaker Pipe mode streams data directly from S3 into the training job, so your EBS volume only needs to hold final model artifacts. The full dataset doesn't need to be downloaded before training starts.

Teams who get this right treat data movement as a first-class design decision before writing a single training loop. Teams who don't end up building custom pipeline infrastructure to compensate. Sometimes that happens anyway. Usually it didn't have to.

S3's expanding role in AI inference: vectors, tables, and query-time retrieval

S3 Vectors went generally available in December 2025. Native vector storage and querying inside S3, built for RAG pipelines, AI agents, and semantic search over S3-resident content.

The scale numbers are notable: up to two billion vectors per index, ten thousand indexes per bucket. AWS reports warm query latency as low as 100 milliseconds, and costs for uploading, storing, and querying vectors reduced by up to 90% compared to typical external vector databases. Over 250,000 vector indexes were created and more than 40 billion vectors ingested within roughly four months of preview, with over one billion queries performed.

S3 Tables went generally available in December 2024. Storage optimized for Apache Iceberg analytics workloads, delivering up to three times faster query performance and ten times higher transactions per second versus self-managed Iceberg tables in general-purpose S3 buckets. Over 400,000 tables created since launch.

The pattern here is legible. AWS is building structured query and vector retrieval directly into the object store so teams don't have to copy data out into separate systems to do meaningful work with it. The storage layer is absorbing workloads that used to require a separate database entirely.

One honest caveat: S3 Vectors carries roughly 100 milliseconds of warm latency. Fine for many RAG patterns. Not fine for sub-millisecond lookup. The latency floor hasn't gone anywhere, and it still shapes what S3 can realistically do at the inference layer.

The S3 API as the de facto standard beyond AWS

At some point, the S3 REST API stopped being an AWS product feature and became an industry interface.

S3-compatible storage means any system that implements the S3 REST API. Applications written for S3 read and write to it without code changes. The interface became portable even when the underlying storage isn't AWS.

The list of who implements it is long: Cloudflare R2, Wasabi, Backblaze B2, MinIO, Ceph RGW, self-hosted on-premises appliances. All of them expose the same API surface.

What this practically unlocks: teams can run the same data access code against a local MinIO cluster during development, a Ceph deployment in a private data center, and AWS S3 in production. Storage infrastructure becomes swappable without application rewrites. The interface is stable enough that you can build against it without caring what's underneath, which is a genuinely unusual thing to be able to say about infrastructure software.

Compatibility is now the baseline. Table stakes. Vendors compete on zero-egress cost models (Cloudflare R2 and Wasabi are the notable examples), edge integration, and AI-native data services. The API itself is no longer a moat for anyone.

Per Statista, Amazon S3 held a 22.98% share of the global enterprise data storage software market in 2024. More than its next two competitors combined. That's what happens when an ecosystem builds itself around a single interface for nearly two decades.

Where S3's object model creates friction and what teams reach for instead

Every team hits the walls eventually. Here's what they are.

The 20 ms latency floor. S3 Standard's 90th-percentile time-to-first-byte is roughly 20 milliseconds. Fine for batch jobs and large sequential reads. A real constraint for anything needing sub-millisecond response. You cannot engineer below this floor with S3 Standard, and it will humble you if you try.

No POSIX semantics. S3 has no atomic rename. No file locking. No append. No in-place update. An object is immutable once written. "Updating" a file means writing a new object and deleting the old one. This is completely fine for immutable datasets and logs. It breaks workloads that assume a file system. Concurrent writers, checkpoint-and-resume patterns, anything calling flock: all of these are going to have a bad time. The error messages won't be obvious. The debugging will be annoying.

No real directory operations. There's no rename of a prefix, no atomic move of a "folder." These operations require copying every object under that prefix and then deleting the originals. Slow, non-atomic, and at scale it becomes a genuine operational headache.

Egress costs. Data leaving S3 to other regions or the public internet costs money. This is a structural cost, not an edge case. It shapes decisions around data locality in ways that compound over time and show up in bills before they show up in architectural reviews.

What teams actually reach for when they hit these walls:

• EFS or similar POSIX-compliant network filesystems when the code can't be rewritten and needs real file system semantics.
• Local NVMe or caching layers in front of S3 when latency is the binding constraint.
• S3 Express One Zone when the workload can tolerate single-AZ placement in exchange for single-digit millisecond access.

S3 is the right answer for durable, scalable, cost-efficient object storage. It's the wrong answer whenever workloads assume a file system interface, require sub-millisecond latency, or depend on atomic multi-object operations. The pain usually comes from not knowing which situation you're in until you're already in it.