Storage fundamentals
S3 bucket
An S3 bucket is the top-level container in which objects are stored in S3-compatible object storage. Every object lives in exactly one bucket and is addressed by the bucket name plus an object key. The bucket is also where most behavior is configured: who can access the data, whether versions are kept, how long objects are retained and where they are replicated.
What does a bucket contain?
A bucket holds objects in a flat namespace. There are no real folders. Keys such as reports/2026/q1.pdf contain slashes that tools present as a hierarchy, and listing requests can filter by prefix to give the same effect. A bucket has no fixed size and can hold anything from a handful of objects to billions, though very large object counts make listing slow. Each bucket belongs to one account.
Which settings are applied per bucket?
The bucket is the unit of configuration for most S3 features.
| Setting | What it controls |
|---|---|
| Bucket policy | Who may perform which operations |
| Versioning | Whether overwritten and deleted objects are kept as versions |
| Object Lock | Default retention and whether objects can be locked |
| Lifecycle rules | Expiration and transition of objects over time |
| Replication | Copying objects to another bucket or site |
| Encryption defaults | How objects are encrypted at rest |
| Logging and metrics | Recording of requests and usage |
How do buckets relate to accounts and tenants?
On multi-tenant storage, accounts sit above buckets. Each account has its own users, access keys and buckets, and by default one account cannot see another's. The account is therefore the stronger isolation boundary, suitable for separating teams or customers, and buckets divide data within an account by application or purpose. Multi-tenant storage covers the model.
How many buckets should a design use?
Enough that each data set can have the access, retention and replication rules it needs, and no more. Data sets that differ in owner, in immutability or versioning, in audience or in replication target belong in separate buckets, because those settings apply to the whole bucket. Where none of those differ, a key prefix inside one bucket is sufficient. Designs that create a bucket per user or per job become hard to audit. S3 bucket design goes through the patterns.
Frequently asked questions
Can a bucket be renamed?
No. The usual method is to create a new bucket and copy the objects across.
Is there a limit on objects in a bucket?
Not a fixed one in the API. Practical limits come from listing performance and the platform's metadata capacity.
Are bucket names global?
In Amazon S3 they are unique across the service. On other platforms uniqueness depends on the implementation, often per system or per account.
Related terms
- S3 API: the interface used to work with buckets.
- Bucket policy: access control attached to a bucket.
- Object versioning: a per-bucket setting for keeping versions.
- Multi-tenant storage: accounts above buckets.
- Object metadata: information stored with each object in a bucket.