Visual overview
Applications address objects by key; lifecycle can change how older objects are stored.
Technical reference
S3 is an object API with bucket-level configuration and object-level data.
Keys identify objects; console folders are generally prefix conventions.
S3 provides strong consistency for object PUT/DELETE operations, including overwrites.
Large objects can be divided into independently uploaded parts and completed as one object.
These provide history, copies, and WORM-style retention respectively.
Service limits and capabilities can change. Values shown here reflect the current AWS documentation; use the linked official sources below as the source of truth.
Buckets contain objects; keys identify them
Amazon Simple Storage Service (Amazon S3) is AWS object storage. You create a bucket and store data as objects within it. Each object combines the data itself with metadata and is identified inside the bucket by an object key. Applications typically interact with S3 through HTTPS-based service APIs, AWS SDKs, the AWS CLI or services that integrate with S3 rather than by treating a general-purpose bucket as a locally attached disk.
A bucket is created in an AWS Region and provides the administrative boundary for settings such as permissions, versioning and lifecycle configuration. Object keys can contain slash characters and consoles can present them like folders, but the key remains the object's identifier. That distinction matters because S3's object model is fundamentally different from a traditional hierarchical file system even when a key naming convention looks like directories.
Why S3 appears in so many architectures
S3 is designed for very large amounts of object data and a broad range of use cases including backup and restore, data lakes, application assets, archives, analytics datasets, websites and content repositories. Compute does not have to remain attached to a particular storage device: an application with permission can access the bucket through S3 endpoints, and many AWS analytics, AI, integration and data services can use S3 as a durable data source or destination.
This decoupling is architecturally powerful. A fleet can be replaced or scaled without moving the objects with the servers, and multiple workflows can process the same stored data through controlled permissions. S3 automatically scales to high request rates and provides strong read-after-write consistency for object PUT and DELETE operations, including overwrites, across AWS Regions.
Durability is not the same as every other property
S3 is built for durable object storage, but storage design still requires separate decisions about availability, access frequency, recovery time, security and geographic resilience. Storage classes vary in access and resilience characteristics; versioning protects against accidental replacement or deletion; replication can create additional copies according to a policy; and lifecycle rules can transition or expire data as its value changes over time.
Do not reduce S3 to the phrase 'unlimited storage' or assume that one class fits every object. Cost can include stored capacity, requests, retrieval behavior, data transfer and optional management features. The efficient design is to understand how often data is accessed, how quickly it must be retrieved, how long it must be retained and which failures or mistakes the architecture must tolerate.
When S3 is—and is not—the natural choice
Choose S3 when the application naturally works with objects: static assets, documents, media, logs, backups, machine-learning datasets or analytic data are common examples. It is especially useful when storage should be decoupled from a single server and accessed by multiple services or workflows through APIs. Lifecycle and storage-class features make it possible to keep the same logical object-storage service while data moves from active use toward archival retention.
Choose another storage model when the application specifically requires a block device, boot disk or traditional shared file-system interface. EBS is designed for EC2 block storage. EFS and FSx provide file-system semantics for shared file workloads. The question is not whether S3 is more scalable than a disk; it is whether the application's data model is compatible with object storage.
Key takeaways
- 01
S3 stores data as objects inside regional buckets and addresses each object by key.
- 02
S3 decouples durable data from individual compute instances and integrates with a broad set of AWS services.
- 03
Strong consistency, storage classes, versioning, lifecycle and replication solve different parts of the storage problem.
- 04
S3 is object storage—not a general replacement for block devices or conventional shared file systems.
Official AWS sources
Use these primary AWS resources for the source material behind this article and for deeper reference.