S3

Amazon S3 is an object store, not a file system. Data is stored as whole objects in a flat namespace, addressed by key over HTTPS, and retrieved or replaced whole rather than modified in place.

• A bucket is the container. Bucket names are globally unique and a bucket belongs to one Region.
• An object is the stored data plus its metadata.
• A key is the object’s name within the bucket. It never includes the bucket name.

In a bucket named parking holding an object at tickets/2026-01.csv, the bucket is parking, the key is tickets/2026-01.csv, and tickets/ is a prefix. Prefixes look like folders in the console, but S3 has no directories — the slash is just a character in the key.

1. Basics

• Objects can be up to 50 TB. A single PUT can carry up to 5 GB; larger objects require multipart upload. AWS suggests considering multipart upload from around 100 MB.
• The console can upload a single file up to 160 GB; beyond that, use the CLI, an SDK or the REST API.
• A bucket holds an unlimited number of objects and an unlimited amount of data.
• New objects are encrypted at rest by default, with S3-managed keys.

2. Storage classes

Class	Designed for	Availability (designed for)	AZs	Min duration	Min billable size
S3 Standard	Frequently accessed data, millisecond access	99.99%	≥ 3	None	None
S3 Intelligent-Tiering	Unknown or changing access patterns	99.9%	≥ 3	None	None
S3 Standard-IA	Long-lived, accessed about monthly	99.9%	≥ 3	30 days	128 KB
S3 One Zone-IA	Recreatable, infrequently accessed data	99.5%	1	30 days	128 KB
S3 Express One Zone	Latency-sensitive workloads in one zone	99.95%	1	None	None
S3 Glacier Instant Retrieval	Archive accessed about quarterly, millisecond access	99.9%	≥ 3	90 days	128 KB
S3 Glacier Flexible Retrieval	Archive accessed about yearly, retrieval in minutes to hours	99.99% after restore	≥ 3	90 days	—
S3 Glacier Deep Archive	Archive accessed less than yearly, retrieval in hours	99.99% after restore	≥ 3	180 days	—
S3 on Outposts	Object storage on premises	—	—	—	—

Every class except Reduced Redundancy Storage is designed for 99.999999999% (eleven nines) durability. Only One Zone-IA and Express One Zone store data in a single Availability Zone and are therefore not resilient to losing one. Reduced Redundancy Storage still exists but AWS recommends against it: Standard is both more durable and cheaper.

S3 Express One Zone (launched November 2023) is the high-performance class — single-digit millisecond access, up to ten times faster than Standard, with request costs about half. It uses directory buckets rather than general purpose buckets.

Retrieval from Glacier Flexible Retrieval and Glacier Deep Archive is asynchronous: an object must be restored before it can be read. Glacier Instant Retrieval is not — it serves objects in milliseconds, at archive prices, for data touched about once a quarter.

Prices vary by Region and by volume tier, so this page does not reproduce them. See Amazon S3 pricing for current rates.

Intelligent-Tiering

Intelligent-Tiering moves objects between access tiers automatically for a small monthly monitoring fee per object, with no retrieval fees. Three tiers operate automatically:

1. Frequent Access — where objects land on upload.
2. Infrequent Access — after 30 consecutive days without access.
3. Archive Instant Access — after 90 consecutive days without access.

All three serve objects in milliseconds. Two further tiers are optional and must be activated explicitly:

• Archive Access — archives objects untouched for at least 90 days.
• Deep Archive Access — archives objects untouched for at least 180 days.

Objects in either optional tier must be restored with RestoreObject before they can be read, taking minutes to hours. That is the difference that matters: the automatic tiers are transparent, the optional ones change how an application must read its own data.

Objects smaller than 128 KB are never monitored or tiered and stay in Frequent Access.

3. Consistency

S3 provides strong read-after-write consistency for GET, PUT, LIST, HEAD and DELETE across all storage classes. A write is visible to the next read, with no eventual-consistency window and no extra cost.

Concurrent writes to the same key are resolved last-writer-wins by timestamp; each individual write is atomic, so a reader sees either the old object or the new one, never a mixture. Applications that need to avoid clobbering a concurrent write can use conditional requests on PutObject and CompleteMultipartUpload.

4. Access control

Everything in S3 is private by default, and Block Public Access is on by default for new buckets, access points and objects.

• Bucket policies — resource-based JSON policies attached to the bucket, granting or denying access to named principals. See bucket policies.
• IAM policies — identity-based policies attached to users and roles, which is where most day-to-day permissions belong.
• Access point policies — separate policies per named access point, for splitting access to a shared dataset.
• Block Public Access — an override at bucket, account and organisation level that rejects attempts to make data public regardless of what the policies say.
• Presigned URLs — a time-limited URL granting access to one object without changing its permissions.
• VPC endpoint policies, service control policies and resource control policies — organisation-level restrictions evaluated alongside the above.

ACLs are disabled by default. Since April 2023 every new bucket is created with Object Ownership set to Bucket owner enforced, which disables ACLs entirely: PutBucketAcl and PutObjectAcl fail with AccessControlListNotSupported, and access is decided by policy alone. AWS recommends keeping them disabled. Object ACLs appear in older material as a normal access-control tool; treat them as legacy, and only re-enable them for the rare case that genuinely needs per-object ownership by the uploading account.

See managing permissions in S3 for how a request is evaluated, and MFA Delete vs Object Lock for delete protection.

5. Encryption

New objects are encrypted at rest automatically. There are four options:

• SSE-S3 — server-side encryption with S3-managed keys (AES-256). The default since January 2023, applied to every new object unless another option is specified. No configuration and no extra cost.
• SSE-KMS — server-side encryption with AWS KMS keys. Adds an audit trail of key usage in CloudTrail, key policies separate from bucket policies, and controlled rotation. The choice when key usage must be governed or evidenced.
• DSSE-KMS — dual-layer server-side encryption, applying two independent layers of KMS encryption for requirements that mandate it.
• SSE-C — server-side encryption with a customer-provided key. AWS never stores the key, so it must be supplied with every request, including every read.

Client-side encryption encrypts data before it reaches AWS, for instance with the AWS Encryption SDK. It gives complete control of the process at the cost of managing keys and complicating every consumer of the data.

In transit, S3 endpoints are served over HTTPS. A bucket policy condition on aws:SecureTransport is the usual way to reject any request that is not.

6. Versioning

Versioning keeps every version of an object under the same key.

• Overwrites create a new version rather than replacing the object.
• Deletes place a delete marker, so a deletion can be undone.
• Old versions are billable storage, and are the usual explanation for a bucket costing more than its visible contents suggest.
• Lifecycle rules can expire non-current versions on a schedule.

Versioning is a prerequisite for replication, MFA Delete and Object Lock.

7. Lifecycle management

Lifecycle rules transition objects between storage classes and expire them, scoped by prefix, by tag or by object size, and applied to current versions, non-current versions or both. This is where most of the saving in an S3 bill comes from — and note that a bucket policy cannot block a lifecycle rule, so an expiry rule deletes objects even if the policy denies every principal.

8. Replication

• Cross-Region Replication (CRR) copies objects to a bucket in another Region.
• Same-Region Replication (SRR) copies objects to another bucket in the same Region, typically for log aggregation or a separate compliance account.

Both require versioning on the source and destination. Replication is asynchronous and applies to objects written after it is configured; existing objects need a batch replication job.

9. Transfer Acceleration

Routes uploads through a nearby CloudFront edge location and over the AWS backbone to the bucket. It helps when clients are far from the bucket’s Region and the object is large; for clients close to the Region it adds nothing.

10. Event notifications

Bucket events — object created, removed, restored, replication failed — can be delivered to Lambda, SQS, SNS or EventBridge. This is the standard way to trigger processing on upload without polling.

11. Static website hosting

S3 can serve a static site directly from a bucket. In practice a production site puts CloudFront in front of it, which supplies TLS on a custom domain, caching and access control through an origin access control, and lets the bucket stay private.

12. Performance

• S3 handles at least 3,500 PUT/COPY/POST/DELETE or 5,500 GET/HEAD requests per second per partitioned prefix, and there is no limit on the number of prefixes in a bucket. Reads scale by spreading keys across more prefixes — ten prefixes support around 55,000 reads per second. The old advice to randomise or hash key prefixes dates from before July 2018 and no longer applies; readable, hierarchical keys are fine.
• Scaling to a higher request rate is gradual rather than instant, and 503 Slow Down responses during the ramp are expected. Retry with backoff.
• Use multipart upload for large objects: parts upload in parallel and a failed part is retried on its own.
• Single-instance transfer can reach tens of Gb/s on a large EC2 instance; aggregate throughput scales by using more instances.
• Byte-range fetches read part of a large object without transferring the whole thing.
• For lower latency or higher single-connection transfer rates, put CloudFront in front of the bucket.

S3 Select is closed to new customers as of 25 July 2024, as is S3 Glacier Select. Existing users may continue; nobody starting today can enable either. For querying data in place, use Amazon Athena (SQL over objects in S3), S3 Object Lambda (transform objects as they are read), or filtering in the client.

13. Access points

Named endpoints attached to a bucket, each with its own policy and network origin. They replace one sprawling bucket policy with a policy per application when many teams share a dataset.

14. Object Lock

Write-once-read-many retention: objects cannot be deleted or overwritten for a fixed period or indefinitely. Requires versioning. See MFA Delete vs Object Lock.

15. Inventory

S3 Inventory produces a scheduled flat-file report of objects and their metadata — storage class, encryption status, replication status, size, last modified. It is how questions about a bucket with hundreds of millions of objects get answered without listing it.

16. Analytics and the data lake

• Storage Class Analysis observes access patterns and suggests when to transition data to S3 Standard-IA.
• S3 Storage Lens reports usage and activity across buckets and accounts, with recommendations.
• As a data lake, S3 is queried directly by Athena and Redshift Spectrum, visualised through QuickSight, and fed by Amazon Data Firehose for streaming ingestion. Machine learning training data and model artefacts commonly live here too.

17. Other features

• Requester Pays shifts request and data transfer charges to the requester rather than the bucket owner, for publishing large datasets.
• Object tagging supports cost allocation, lifecycle scoping and policy conditions.
• Batch Operations applies an action — copy, tag, restore, invoke a Lambda — across millions of objects from an inventory report.

S3 no longer supports BitTorrent. The feature could not be enabled on new buckets after 29 April 2021, clients stopped being able to connect on 29 April 2022, and AWS removed the documentation. Older material recommending .torrent distribution to save S3 bandwidth is describing something that no longer exists; use CloudFront for distribution at scale.

Presigned URLs and CloudFront signed cookies

A presigned URL is an S3 feature. It encodes a signature and an expiry into a URL, so anyone holding it can perform the specified operation — usually GET, sometimes PUT — on one object until it expires, without any change to the object’s permissions. It is the standard way to hand a user a private download or a direct upload target.

Signed cookies are a CloudFront feature, not an S3 one. CloudFront supports both signed URLs and signed cookies for private content behind a distribution; the cookie is set in the browser and authorises access to multiple restricted files, which suits browsing a whole area of restricted content rather than fetching one file. S3 itself has no cookie mechanism, and there is no S3 API for one.

The distinction in practice: to share one private object, presign it in S3. To gate a set of private content served through a CDN, put it behind CloudFront and use signed cookies or signed URLs there.