English for AWS S3 Developers
Vocabulary for developers working with Amazon S3 — buckets, objects, presigned URLs, and eventual consistency — for teams discussing object storage in English.
S3 looks like a filesystem but isn’t one, and most confusing S3 conversations come from someone applying filesystem intuitions (folders, atomic renames, instant listing) to a system that doesn’t actually have any of those things. Getting the object-storage vocabulary right avoids a lot of “but it worked on my machine” debugging.
Buckets and Objects
Bucket — a top-level, globally-uniquely-named container for objects, with its own region, permissions, and configuration.
“We need a separate bucket per environment — sharing one bucket between staging and production is how staging test data ends up in a prod listing.”
Object — the actual stored item in S3: a blob of data plus a key (its path-like identifier) and metadata; there’s no real directory structure underneath.
“There’s no such thing as an empty folder in S3 — what looks like a folder in the console is just a naming convention in object keys.”
Key — the unique string identifying an object within a bucket, often written to look like a file path (images/2026/07/photo.jpg) even though S3 treats it as a flat string.
“Listing by prefix is fast because it’s just a string match on the key — it’s not walking a directory tree the way a filesystem would.”
Access and Delivery
Presigned URL — a temporary, signed URL that grants time-limited access to a specific object without requiring the requester to have AWS credentials.
“Don’t make the bucket public — generate a presigned URL that expires in ten minutes and hand that to the client instead.”
Bucket policy vs. IAM policy — a bucket policy is attached to the bucket and controls who can access it; an IAM policy is attached to a user or role and controls what that identity can do, including across multiple buckets.
“This isn’t a bucket policy problem — the role itself doesn’t have
s3:PutObjectin its IAM policy, so it’ll fail no matter what the bucket allows.”
Multipart upload — splitting a large object into parts uploaded independently (and potentially in parallel, with retry on individual parts) then assembled by S3, used for large files.
“Switch to multipart upload for anything over 100MB — a single failed request on a huge upload means starting completely over otherwise.”
Consistency and Lifecycle
Eventual consistency (historically) — the older behavior where a newly written object might not immediately appear in a subsequent read or list; S3 now offers strong read-after-write consistency, but the term still surfaces in older docs and legacy assumptions.
“That flaky test assumed a PUT was immediately visible to a LIST — that assumption used to be wrong on S3, so check which consistency model your SDK docs are describing.”
Versioning — an optional bucket setting that keeps every version of an object instead of overwriting it, protecting against accidental deletes and overwrites.
“Turn on versioning before this migration — if the script overwrites the wrong keys, we want to be able to roll back to the previous version.”
Lifecycle policy — a rule that automatically transitions objects to cheaper storage tiers or deletes them after a set period.
“Add a lifecycle policy to move logs to Glacier after 30 days — we’re paying standard storage rates for data nobody’s read in months.”
Common Mistakes
- Talking about S3 “folders” as if deleting one deletes its contents atomically — it doesn’t; it’s a batch delete of every object sharing that key prefix.
- Assuming a bucket policy alone controls access, without checking whether the calling identity’s IAM policy even permits the action.
- Uploading large files as a single
PUTand being surprised a flaky network kills the entire transfer instead of just one part.
Practice Exercise
- Explain, in two sentences, why S3 doesn’t have real folders even though the console displays them that way.
- Write a short PR comment recommending a presigned URL instead of making a bucket public for client downloads.
- Draft a message explaining to a teammate why an IAM policy change, not a bucket policy change, is needed to fix an access error.