Storage classes as a cost-vs-retrieval-speed tradeoff, lifecycle policies for automatic aging, versioning against accidental deletion, presigned URLs, and how bucket policies and IAM policies interact.
Published September 23, 2026
S3 is the object storage layer referenced throughout this course wherever "object storage" came up — Video Streaming Platform's transcoded renditions, Payment — Security's tokenized-away-from-card-numbers architecture more generally. This lesson covers S3 itself.
Standard: frequent access, millisecond retrieval, highest cost per GB
Standard-IA: infrequent access, still millisecond retrieval, lower storage
cost but a retrieval fee per GB accessed
Glacier: archival, retrieval takes minutes to hours, lowest cost by far
The right storage class depends entirely on ACCESS PATTERN, not just data age (though the two often correlate): data accessed constantly belongs in Standard regardless of cost; data accessed rarely but needing to still be fast WHEN accessed (compliance records that might be audited) fits Infrequent Access; data that's essentially archival (old logs past their useful investigative window, but retained for compliance) belongs in Glacier, where the slow retrieval time is an acceptable tradeoff for the dramatically lower storage cost.
{
"Rules": [{
"Transitions": [
{ "Days": 30, "StorageClass": "STANDARD_IA" },
{ "Days": 90, "StorageClass": "GLACIER" }
],
"Expiration": { "Days": 365 }
}]
}
A lifecycle policy automates exactly the storage-tiering strategy described in Distributed Logging & Metrics Pipeline's hot/warm/cold tiers — objects automatically transition to cheaper storage classes as they age, and can be automatically DELETED past a defined retention window, without any application code needing to manage this manually. This is the standard, low-effort answer to "how do we keep storage costs from growing unbounded" for any data with a naturally declining access pattern over time (directly relevant to Cost Awareness later in this chapter).
With versioning enabled, S3 keeps every version of an object rather than overwriting it in place — an accidental DELETE or overwrite doesn't destroy data, it just creates a new "version" (a delete marker, in the delete case), with prior versions still recoverable. This is a meaningful operational safety net against the class of incident where a bug or human error overwrites/deletes something important — the tradeoff is storage cost for every retained version, which lifecycle policies can also manage (expiring OLD versions after some period, distinct from expiring the object entirely).
URL presignedUrl = s3Client.generatePresignedUrl(bucket, key, expiration = Duration.ofMinutes(15));
// gives the CLIENT temporary, scoped, time-limited access to ONE specific object,
// without making the object (or the bucket) publicly readable
A presigned URL grants temporary, scoped access to a private object — this is the exact mechanism referenced in Video Streaming Platform's upload flow ("a pre-signed URL pattern... rather than routing the full video file through the application server") and is broadly the standard answer whenever a client needs direct, time-limited access to a specific private S3 object without the bucket itself being public. The expiration window bounds the exposure if the URL is somehow leaked — a presigned URL for uploading, say, expiring in 15 minutes means it's useless to anyone who intercepts it an hour later.
Bucket policy: attached to the BUCKET, controls who (which principals) can access it
IAM policy: attached to a USER/ROLE, controls what THAT PRINCIPAL can access
Access is granted only if NEITHER an applicable bucket policy NOR IAM policy denies it,
and AT LEAST ONE of them explicitly allows it
Both mechanisms can grant or restrict S3 access, and they're evaluated TOGETHER — a request is allowed only if there's no explicit DENY from either, and at least one explicit ALLOW. This dual-mechanism model lets access control be expressed from whichever side makes more sense for a given case: a bucket policy is convenient for granting access to an external AWS account (cross-account access) or making a subset of objects public; an IAM policy is convenient for controlling what a SPECIFIC internal role/user can do across MANY buckets from one place — this connects directly to the least-privilege principle covered in IAM.
Q: If both a bucket policy and IAM policy apply, and they conflict, which wins? A: An explicit DENY in EITHER always wins, regardless of any ALLOW elsewhere — this 'deny always wins' rule is a deliberate, conservative default that prevents a maliciously or accidentally overly-permissive ALLOW in one policy from overriding an intentional restriction set in the other.
Q: Does versioning protect against a malicious actor with full delete permissions? A: Only partially — an attacker with sufficient permissions can also delete the OLD versions or disable versioning itself; genuinely strong protection against a compromised-credentials scenario typically adds MFA Delete (requiring multi-factor authentication specifically to permanently delete a version) as an additional, harder-to-bypass safeguard.
Q: Why would a presigned URL's expiration time matter for the upload use case specifically, given the upload only takes a few seconds? A: The window needs to cover the REALISTIC time between the URL being issued and the actual upload starting (a slow client connection, a user who navigates away and comes back) — too short an expiration causes legitimate, if slightly delayed, uploads to fail; too long unnecessarily extends the exposure window if the URL leaks, so it's tuned to the expected real-world usage pattern, not the theoretical minimum.
Q: How does S3's storage-class tiering interact with a CDN like the one described in Video Streaming Platform? A: They're complementary and address different layers — a CDN caches FREQUENTLY-ACCESSED content close to viewers regardless of which S3 storage class the origin copy sits in; S3 lifecycle tiering is about the ORIGIN copy's own cost over time, largely independent of how a CDN is separately caching hot content near viewers.