S3 is an excellent place to keep business files. It is durable, inexpensive, and already inside the account your security team governs. It is also not a file system, and most of the pain teams feel comes from treating it like one.

These are the decisions that make the difference between a bucket people can work in and a bucket only one engineer can navigate.

Design keys the way people look for files

S3 has no folders. It has keys, and a prefix is only the leading part of a key. Listing is by prefix, and there is no server-side search for a word in the middle of a file name. That makes the order of the key segments the most important design choice you will make.

Put the segment people filter by first. campaigns/2026-q3/brand-guidelines.pdf can be found by anyone who knows the campaign and quarter. 2026/09/12/upload-8841.pdf can only be found by someone who knows the upload date.

  • Use stable, lowercase, human-readable segments. Prefix listing is case sensitive.
  • Keep dates in ISO order so they sort correctly.
  • Do not encode information in the key that changes, such as status. Renaming in S3 is a copy and a delete.

Put facts about the file in tags and metadata

Each object can carry user-defined metadata, set at upload, and up to ten tags, which can be changed later and can drive lifecycle rules and access policies. Use tags for things the business cares about, such as retention class or client, and keep the key for location.

Protect against mistakes before you need to

  • Turn on versioning for any bucket holding documents people edit or replace. An overwrite or delete becomes recoverable.
  • Keep Block Public Access enabled at the account level. Business files should never be shared by making an object public.
  • Add a lifecycle rule to expire noncurrent versions and incomplete multipart uploads, or versioning will quietly grow your bill.

Let lifecycle rules manage cost, and plan for retrieval

Lifecycle rules can move objects to Standard-IA, Glacier Instant Retrieval, Glacier Flexible Retrieval or Deep Archive as they age. The colder classes are much cheaper to store and slower or more expensive to read. Glacier Flexible Retrieval and Deep Archive objects must be restored before anyone can open them.

Decide who is allowed to request a restore and which retrieval tier is acceptable before the day someone needs a three-year-old master file by the afternoon.

Give people roles, not keys

Long-lived access keys pasted into desktop clients are the most common way business buckets leak. Prefer IAM roles with temporary credentials, scoped to the buckets and prefixes each group needs. Record object-level activity with CloudTrail data events for the buckets that matter, so you can answer who opened or deleted a file.

Decide how non-engineers reach the files

The console and the CLI are the right tools for the people who run the account. They are the wrong tools for the people who use the documents. Those people need to browse, search within a folder, preview, share with someone outside the company, and occasionally pull something back from cold storage, without learning IAM.

BucketDesk provides that layer on top of the structure described here. It connects through a scoped IAM role you deploy with CloudFormation, shows prefixes as folders with size, storage class and modified date in view, and records activity. The files and the bill stay in your AWS account.

THE DECISION

Order key segments by how people search, keep changing facts in tags, turn on versioning with a cleanup rule, plan cold storage retrieval in advance, and give people a role-based way to reach files that does not involve access keys or the AWS console.

Primary sources