Skip to Content

S3: Buckets, Objects & Storage Classes

When to use

Store arbitrary blobs with 11-nines durability and variable cost tiers.

Analogy

S3 is a planetary hard drive - you push objects into named buckets via HTTP and pull them by key.

Data-flow diagram

  Bucket: my-app-data-2024
    ├── index.html         (1.2 KB)
    ├── logs/2024/01/15.gz
    └── archive/2023.zip   (500 MB)
  Classes:
    Standard | Std-IA | 1Z-IA | Glacier IR | Glacier | Deep Archive
       hot    cheaper   colder  archive (retrieval latency grows)

Deep explanation

S3 buckets are flat (the / is part of the key), globally unique, and live in a single region. Since Dec 2020, S3 is strongly consistent for ALL operations (read-after-write, list, delete). Lifecycle rules transition objects across classes: e.g. 30 days -> Standard-IA, 90 days -> Glacier. Pick by access frequency.

Examples

Example 1

aws s3 mb s3://my-app-data-2024 --region us-east-1
aws s3 cp ./local.txt s3://my-app-data-2024/index.html
aws s3 ls s3://my-app-data-2024/

creates bucket, uploads an object, lists contents. Names globally unique; no uppercase or _.

Example 2

aws s3 cp archive.zip s3://my-app-data-2024/archive/ \
  --storage-class GLACIER_IR

Glacier Instant Retrieval = 64% cheaper than Standard, ms retrieval.

Example 3

aws s3api put-bucket-lifecycle-configuration \
  --bucket my-app-data-2024 \
  --lifecycle-configuration file://lifecycle.json

automated class transitions: Standard -> Standard-IA -> Glacier as data ages.

Common mistake

Leaving the bucket public via bucket policy or ACL - anyone can list and download PII. Also: relying on eventual consistency (no longer an issue since 2020).

Key takeaway

encrypt at rest (SSE-S3 or SSE-KMS); enable versioning; block public access at account level; lifecycle transitions for cost; pre-signed URLs for short-lived sharing.

Production Failure Playbook

Failure scenario 1: public-s3-bucket

Failure scenario 2: no-versioning-accidental-delete