How it works
The explanation, with examples you can run.
Consistency, exactly
S3 provides strong read-after-write consistency for PUT and DELETE requests in all Regions, for new objects and overwrites alike, and for list operations. A successful write is immediately visible to every reader. This replaced the old eventual-consistency model in December 2020; older advice about waiting before reading, or using a separate index because listings lag, no longer applies.
What S3 does not give you is coordination between writers. Concurrent PUTs to one key resolve to whichever S3 processes last. When that matters, use conditional writes: If-None-Match: * makes a PUT fail if the key already exists (create-once semantics), and If-Match: <etag> fails if someone changed the object since you read it (optimistic concurrency).
aws s3api put-object --bucket example-locks --key jobs/42 --body owner.txt --if-none-match '*'# a second caller with the same key gets 412 Precondition FailedStorage classes
| Class | Good for | Watch out for |
|---|---|---|
| Standard | Frequently read data | Highest storage price |
| Intelligent-Tiering | Unknown or changing access | Small monthly monitoring fee per object; objects under 128 KB are never moved |
| Standard-IA, One Zone-IA | Read rarely, needed fast | 128 KB minimum size, 30-day minimum, retrieval fee; One Zone-IA lives in a single zone |
| Glacier Instant, Flexible, Deep Archive | Archives and backups | Longer minimums (90 to 180 days), retrieval fees, minutes to hours for the colder two |
| Express One Zone | Very low latency next to compute | Single zone, different bucket type |
Lifecycle rules move objects between classes by age and delete old versions, which is how most savings are made in practice. Turn on versioning for anything important: an overwrite or delete then keeps the previous version, which protects against bugs and ransomware, and lifecycle rules can expire old versions later.
Access and safety
New buckets have Block Public Access on and object ownership set so ACLs are disabled; access is decided by IAM policies and the bucket policy. Every new object is encrypted with SSE-S3 by default since January 2023; use SSE-KMS when you need key-level access control and audit. Common failure modes:
- Turning off Block Public Access for one public file and exposing the whole bucket. Serve public content through CloudFront with origin access control instead.
- Treating S3 as a file system: renames are copy plus delete, and there are no appends.
- Hot prefixes: S3 scales per prefix (at least 3,500 writes and 5,500 reads per second each), so spread very high request rates over several prefixes.
Check yourself
3 questions. Get them all right to finish this topic.
0 of 3 right so far. Get all three to finish this topic.