S3: Object Storage

Chapter 1 named S3 as AWS's own real first service — launched 14 March 2006 in the US, expanding to Europe in November 2007, ahead even of EC2. Where EC2 (Chapter 3) gives you a virtual disk attached to a running machine, S3 is genuinely different: object storage, with no server to manage at all — you store and retrieve whole files ("objects") directly over HTTP, addressed by a key, not a filesystem path.

Buckets & Objects

An S3 bucket is a real, top-level container with a name that must be globally unique across the whole of AWS — not just your own account. Inside a bucket, every object (a file, plus metadata) is addressed by a real, flat key — S3 has no true folder hierarchy, even though its own console displays keys containing / as if they were nested folders.

Real Storage Classes

S3 offers several real, distinct storage classes, each trading cost against retrieval speed and access frequency:

Durability vs. Availability — a Real, Important Distinction

S3 Standard is designed for a real, documented 99.999999999% durability figure — informally, "11 nines" — meaning the odds of losing an object due to real infrastructure failure are vanishingly small, since S3 automatically stores redundant copies across multiple facilities. Availability is a genuinely separate real number (typically 99.9% for S3 Standard) — the odds S3 is reachable and responsive at any given moment. An object can be perfectly durable (never lost) while briefly unavailable (temporarily unreachable) — the two numbers answer different real questions.

Versioning

S3 versioning is real, and disabled by default. Once enabled on a bucket, every overwrite or delete of an object keeps the prior version recoverable instead of discarding it outright — a real, direct defense against the single most common real S3 accident: an application (or a person) overwriting or deleting the wrong object.

Lifecycle Policies

A lifecycle policy automatically transitions objects between storage classes, or expires (deletes) them entirely, based on real, defined rules — for example, "move to S3 Glacier after 90 days, delete after 7 years." This turns the cost/retrieval-speed tradeoff from Chapter's own storage-class table into something managed automatically over an object's own real lifetime, rather than requiring manual intervention.

Static Website Hosting

A bucket can be configured to serve its own objects directly as a website — an index.html, CSS, JavaScript, and images, all served straight from S3 with no real web server to patch or manage. This works well for genuinely static content; anything needing server-side logic still needs EC2, Lambda (Chapter 7), or an equivalent compute service behind it.

A Real Case Study: The 2017 Deep Root Analytics Leak

This is a real, direct parallel to Chapter 2's own Capital One case study, applied to storage instead of compute: the failure sat squarely on the customer's side of the shared responsibility model (Chapter 1). AWS later introduced S3 Block Public Access, a real, account- and bucket-level setting that can override individual bucket policies to prevent exactly this class of accidental public exposure — now recommended as the default, on-by-default safeguard for any bucket that isn't deliberately, intentionally public (like a static website).

Hands-On Exercises