S3, short for Amazon Simple Storage Service, is a cloud object storage service that stores data as objects inside buckets and exposes them through an HTTP-based API. Each object is addressed by a bucket name and a key, holds up to 5 TB of data with metadata, and is stored redundantly across multiple facilities within a region.
In cloud storage, S3 matters beyond one provider because its API has become the de facto standard for object storage. Many other services and self-hosted systems advertise S3 compatibility, so tools written against the S3 API can often work with other object stores by changing only the endpoint and credentials.
How S3 stores and serves data
S3 uses a flat namespace: a bucket contains objects identified by keys, and the slashes in a key such as reports/2026/q3.pdf only imitate folders. Clients upload, read and delete whole objects with HTTP verbs such as PUT, GET and DELETE, and listing operations filter keys by prefix and delimiter.
Objects are immutable as units: changing one byte means writing a new object, although large uploads use multipart upload to send parts in parallel and retry failures individually. Since December 2020, S3 provides strong read-after-write consistency for all operations, so a successful write is immediately visible to subsequent reads and lists.
Buckets live in a chosen region, and bucket names are globally unique across all accounts. Beyond plain storage, S3 can emit event notifications when objects are created or deleted, replicate objects to another region, and serve a bucket as a static website, which makes it a common hub in data and application pipelines.
The following table summarizes core properties of the service.
| Property | Value or behavior | Practical effect |
|---|---|---|
| Maximum object size | 5 TB | Very large files need multipart upload |
| Single PUT limit | 5 GB | Larger objects must use multipart |
| Designed durability | 11 nines in standard classes | Data loss from hardware failure is extremely unlikely |
| Consistency | Strong read-after-write | No stale reads after successful writes |
| Request throughput | Thousands of requests per second per prefix | Spread hot keys across prefixes |
Storage classes and lifecycle rules
S3 offers several storage classes that trade storage price against retrieval cost, latency and availability. Lifecycle rules move objects between classes or delete them automatically after a set number of days, which is the main tool for controlling long-term cost.
| Storage class | Typical use | Retrieval | Minimum storage duration |
|---|---|---|---|
| Standard | Frequently accessed data | Milliseconds | None |
| Intelligent-Tiering | Unknown or changing access | Milliseconds for frequent tiers | None |
| Standard-IA | Infrequent access, quick need | Milliseconds, per-GB fee | 30 days |
| One Zone-IA | Re-creatable infrequent data | Milliseconds, single zone | 30 days |
| Glacier Flexible Retrieval | Archives | Minutes to hours | 90 days |
| Glacier Deep Archive | Long-term compliance archives | Up to about 48 hours | 180 days |
Infrequent and archive classes charge retrieval and early-deletion fees, so moving small or short-lived objects into them can cost more than leaving them in Standard.
Security and access control in S3
Access to S3 is controlled by identity policies, bucket policies and access points, evaluated together, with any explicit deny overriding allows. Block Public Access settings and disabled object ACLs are the default for new buckets, which prevents the accidental public exposure that caused many historical data leaks.
All new objects are encrypted at rest by default with service-managed keys, and teams can choose customer-managed keys in a key management service for tighter control and audit. Presigned URLs grant temporary access to a single object without sharing credentials, and object versioning keeps previous versions so deletions and overwrites can be reversed.
S3 compared with other storage types
S3 is object storage, which behaves differently from block volumes and file systems. Choosing the wrong type is a frequent architectural mistake.
| Aspect | S3 object storage | Block storage | Network file system |
|---|---|---|---|
| Access method | HTTP API | Attached disk device | POSIX mount over NFS or SMB |
| Update model | Replace whole object | Modify any block | Modify byte ranges |
| Scale | Practically unlimited | Size of the volume | Large, with throughput tiers |
| Sharing | Many clients over the network | Usually one instance | Many clients with file locking |
| Typical use | Backups, media, data lakes, static sites | Databases, boot disks | Shared home directories, legacy apps |
Pitfalls when using S3
Most S3 problems come from treating it like a file system or from overlooking cost dimensions beyond stored gigabytes.
- Request and egress charges: millions of small reads or data transferred out to the internet can outweigh storage cost.
- Small-file overhead: analytics over millions of tiny objects is slow; compact them into larger columnar files.
- Renaming is copying: moving a prefix rewrites every object, which costs time and requests.
- Unbounded versioning: without lifecycle rules for noncurrent versions, storage grows silently.
- Overbroad policies: wildcard principals or actions in bucket policies can expose data despite default protections.
In everyday language
S3 is a huge online warehouse for files. Each file is placed in a labeled box called a bucket and gets a unique label of its own, so any program with permission can fetch it over the internet.
Unlike the hard drive in a computer, it never runs out of shelves and keeps several copies of everything in different buildings. Customers pay for the space used and the trips in and out, and can move rarely needed files to cheaper back-room shelves that take longer to reach.
Seen in the real world
A regional news publisher stores about 60 TB of photos and videos for its website. Editors upload new media into an S3 bucket, a content delivery network serves the files to readers, and the website generates presigned URLs for unpublished material that only staff may preview.
Analysis showed that over 80 percent of files older than 90 days were almost never opened. The team added lifecycle rules that move objects to Standard-IA after 90 days and to Glacier Flexible Retrieval after two years, while versioning protects against accidental deletion. Monthly storage cost fell substantially without changing the website, and occasional requests for old archive footage are handled with a restore that completes within hours.