What Is an S3 Bucket? Names, Regions, Objects, and Folder Structure

Simple explanation

How S3 buckets work

This page covers general purpose buckets, which are the standard bucket type and the starting point for almost all S3 use cases. AWS has introduced other bucket types for specific workloads, but general purpose buckets are what you will use by default.

S3 is organised in three layers:

Bucket → Object → Key

A bucket is the top-level container. You create it once in a specific region and give it a globally unique name. Every object you store in S3 lives inside exactly one bucket.

An object is what you store: a file, an image, a log, a database backup. Every object has a key, which is its full name within the bucket. The key uniquely identifies the object.

A prefix is a shared string at the start of multiple keys. Prefixes look like folder paths but are just part of the key name.

Here is a concrete example. Suppose your bucket is named acme-corp-media-prod. It might contain these objects:

uploads/2025/january/report.pdf
uploads/2025/january/summary.csv
uploads/2025/february/report.pdf
thumbnails/user-123.jpg
thumbnails/user-456.jpg

In this example:

• uploads/2025/january/report.pdf is the key
• uploads/2025/ is a prefix
• thumbnails/ is a different prefix
• There are no real folders, only keys that share a prefix

This flat structure matters when you write lifecycle policies, apply bucket or IAM policies, or query objects with S3 Select. All of those operations work on key prefixes, not directories.

Bucket vs object vs prefix

Bucket names: rules and examples

Bucket names go into a shared global namespace. No two AWS accounts worldwide can hold the same bucket name at the same time. When you delete a bucket, the name is released and eventually becomes available for anyone to claim. Names are not permanently locked, but you should choose them carefully and avoid deleting a bucket just to free up the name.

The naming rules for general purpose buckets:

• Between 3 and 63 characters long
• Only lowercase letters, numbers, and hyphens (periods are technically allowed but not recommended, see note below)
• Must start and end with a letter or number
• No underscores, spaces, or uppercase letters
• Cannot look like an IP address (e.g. 192.168.1.4)
• Cannot begin with xn-- or end with -s3alias

Regions and why they matter

Every bucket belongs to a single AWS region. You choose the region at creation time and it cannot change later. This choice has real consequences.

Latency. If your application runs in eu-west-2 (London) and your bucket is in us-east-1 (Virginia), every upload and download crosses the Atlantic. Keeping your bucket and compute in the same region avoids this.

Transfer costs. Data transferred within the same region between S3 and other AWS services (EC2, Lambda) is generally free. Cross-region transfers incur egress charges that add up quickly at scale.

Compliance and data residency. If your data must remain within a specific country or jurisdiction, create buckets only in regions within that boundary. S3 does not automatically replicate data across regions. See S3 Security Best Practices for how to enforce this with policies.

# us-east-1: no LocationConstraint needed
aws s3api create-bucket \
  --bucket acme-corp-uploads-prod \
  --region us-east-1

# All other regions: LocationConstraint is required
aws s3api create-bucket \
  --bucket acme-corp-uploads-prod \
  --region eu-west-2 \
  --create-bucket-configuration LocationConstraint=eu-west-2

When to use one bucket vs multiple buckets

The default quota for general purpose buckets is 10,000 per AWS account, so you do not need to conserve buckets aggressively. The more useful question is what each bucket should contain.

One bucket with prefixes is usually enough when:

• You have one application with one access policy
• You want a single lifecycle rule to manage all data
• You want a single logging destination
• Your data all lives in the same region with the same compliance requirements

Separate buckets make sense when:

• Different environments. Keep prod, staging, and dev in separate buckets. This prevents accidents and makes IAM policies simpler. You grant prod access to the prod bucket, not to a prefix within a shared bucket.
• Different access boundaries. If one team should never see another team’s data, a separate bucket with its own policy is cleaner than prefix-based isolation.
• Different lifecycle or retention rules. Lifecycle policies apply at the bucket level or via prefix. If two data sets have fundamentally different retention requirements, separate buckets are easier to reason about.
• Static website hosting or access logging. These features are configured at the bucket level. If you need them for one data set but not another, a separate bucket keeps the configuration clean.
• Data residency or compliance separation. If one data set must stay in a specific region and another can go anywhere, keep them in separate buckets.

S3 buckets vs folders and filesystems

S3 is object storage, not a filesystem. It does not have directories, inodes, or POSIX semantics.

In a traditional filesystem (or Amazon EFS):

• Folders are real objects that exist on disk
• You can mv a directory and everything inside moves atomically
• Listing a directory shows only the direct children
• A file has a path relative to its parent directory

In S3:

• There are no folders, only object keys
• What looks like a folder in the console is every object whose key starts with that prefix
• “Moving” a folder means copying every object to a new key and deleting the originals, one API call per object
• Listing with a prefix returns everything under that prefix, arbitrarily deep

# These are NOT folder contents. They are three separate objects.
images/profile/user-123.jpg    (key)
images/profile/user-456.jpg    (key)
images/thumbnails/user-123.jpg (key)

The console shows images/ as a folder. If you delete images/profile/user-123.jpg, the “folder” images/profile/ disappears, because it was never a real object, just a shared prefix.

This matters for lifecycle rules, which match on key prefixes. It also matters when you expect filesystem-style operations and run into S3’s eventual-consistency model for large listings or bulk deletes.

If you need actual filesystem semantics such as shared mounts, file locking, or POSIX access, see S3 vs EFS to understand when EFS is the right choice.

Practical CLI examples

# List all buckets in your account
aws s3 ls

# Create a bucket in eu-west-2
aws s3api create-bucket \
  --bucket acme-corp-uploads-prod \
  --region eu-west-2 \
  --create-bucket-configuration LocationConstraint=eu-west-2

# Block all public access (recommended default for most buckets)
aws s3api put-public-access-block \
  --bucket acme-corp-uploads-prod \
  --public-access-block-configuration \
    "BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true"

# Enable versioning
aws s3api put-bucket-versioning \
  --bucket acme-corp-uploads-prod \
  --versioning-configuration Status=Enabled

# List all objects with a specific prefix
aws s3 ls s3://acme-corp-uploads-prod/customers/tenant-abc/ --recursive

# Delete an empty bucket
aws s3api delete-bucket --bucket acme-corp-uploads-prod --region eu-west-2

# Force-delete a bucket and all its contents (use with extreme caution)
aws s3 rb s3://acme-corp-uploads-prod --force

For uploading objects, copying, and syncing directories, see Uploading Files to S3 with the AWS CLI.