S3 Doesn't Have Folders — Here's What's Really Going On

Adding one parameter to aws s3 ls reveals what's actually inside your S3 bucket — and exposes a quirk that trips up almost every S3 beginner: those tidy-looking folders aren't folders at all.

Picking up where we left off

In the last lesson, I covered the most basic form of the AWS CLI's S3 command: aws s3 ls. On its own, that command just lists the buckets in your account — a flat roll call of every bucket you own, with no way to peek inside any of them. It's a fine starting point, but it doesn't tell you much about what's actually stored where.

If you haven't run through that one yet, it's worth doing first, since everything here builds directly on it. Once you're comfortable listing your buckets, the natural next question is: how do I see what's inside one of them? That's what I want to walk through here — and along the way, I want to clear up something about S3's storage model that confuses a lot of people the first time they encounter it.

Listing what's inside a specific bucket

The trick is a single addition to the command you already know. Instead of running aws s3 ls by itself, you append the S3 URI of the bucket you want to look inside: aws s3 ls s3://your-bucket-name/. Notice the trailing forward slash after the bucket name — that's what tells the CLI you're asking for the bucket's contents rather than just confirming the bucket exists.

I ran this against one of my own buckets to show what the output actually looks like in practice. Instead of a flat list of files, the terminal returned a single line that looked like a folder — something you'd naturally read as "photos," as if it were a directory sitting inside the bucket, the same way a folder sits inside another folder on your laptop.

If you're following along on your own account, this is the point where I'd encourage you to try it yourself. Swap in one of your own bucket names, run the command, and see what comes back. Depending on how you've organized your uploads, you might see actual file names, folder-looking entries like I did, or a mix of both. Whatever you see, don't take the visual layout at face value just yet — that's exactly the part worth slowing down on.

Why AWS calls it "PRE" instead of "folder"

Here's the detail that's easy to miss if you're moving quickly: the CLI doesn't actually label that entry as a folder. It labels it PRE — short for prefix. That's not a cosmetic choice or an abbreviation for space. It's AWS being precise about what's really happening under the hood, and it's worth taking seriously rather than skimming past.

S3 uses what's usually described as a flat object storage model. There's no real directory tree sitting behind the scenes — no nested filesystem the way you'd find on a hard drive or in an EBS volume. Every object in a bucket has a single key, which is really just its full name, and that name can contain forward slashes. So when I uploaded a file named something like photos/2026.06.17-71.jpg, I wasn't placing a file into a folder called "photos" — I was giving the object a key that happens to start with the text "photos/".

The console, the CLI, and pretty much every S3 tool you'll use are designed to recognize that pattern and render it visually as a folder, because that's the mental model people expect and it makes browsing a bucket far more usable. But it's a rendering trick, not an underlying structure. When aws s3 ls shows you PRE photos/, it's telling you exactly what's true: there's a group of objects sharing that prefix, not a directory sitting one level down.

Why this distinction actually matters

It's tempting to treat this as a pedantic technicality, but it has real, practical consequences once you start scripting against S3 or troubleshooting unexpected behavior. Because folders aren't real, you can't create an empty one the way you would on a normal filesystem — some tools fake this by creating a zero-byte object with a trailing slash, but that's a workaround, not a native feature. You also can't "rename" a folder in the traditional sense. Renaming photos/ to images/ actually means copying every object whose key starts with photos/ to a new key starting with images/, then deleting the originals — which is why bulk renames in S3 can take noticeably longer than you'd expect from a simple drag-and-drop on your desktop.

It also explains some otherwise-confusing edge cases: why deleting the "last" file in a folder makes the folder disappear entirely (there was never a folder object to begin with, just a shared prefix that no longer has any matching keys), and why listing operations that filter by prefix are so central to how S3 SDKs and CLIs are designed. Once you internalize that a key is just a string and a prefix is just a substring match against the start of that string, a lot of S3's behavior stops feeling arbitrary and starts feeling like straightforward string logic.

This is also a good moment to flag something unrelated to the technical mechanics: if you're following along with your own bucket names on screen, either in a recording or a live demo, it's worth being a little careful about what you expose. Bucket names are sometimes globally unique and occasionally personally identifiable, so treating them the way you'd treat any other piece of account information — not broadcasting them unnecessarily — is a reasonable habit to build early.

Conclusion

The command itself is small — one extra parameter and a trailing slash — but it opens the door to understanding how S3 is actually built, which pays off the moment you start doing anything more advanced than uploading a few files by hand. If you haven't already, try running aws s3 ls against one of your own buckets, look for that PRE label, and see if you can spot the full object keys hiding behind what looks like a folder structure.