A storage bucket is the top-level named container in cloud object storage that holds objects and defines the settings that apply to them: geographic location, access control, encryption, versioning and lifecycle rules. In cloud storage, the bucket is the unit at which most policy and billing decisions are made, while the objects inside it carry the actual data.
The term comes from Amazon S3 and Google Cloud Storage, which both use buckets; Microsoft Azure Blob Storage uses containers inside a storage account for the same role. Buckets are addressed by name through an HTTP API, so applications read and write data with requests such as PUT, GET and DELETE rather than through a mounted file system.
How a storage bucket organizes data
A bucket has a flat namespace: it contains objects identified by keys, not a true directory tree. A key such as invoices/2026/03/inv-1042.pdf looks like a path, but the slashes are only characters in the name. Consoles and tools display prefixes as folders for convenience, and list operations can filter by prefix and delimiter to simulate directories.
Each object consists of the data, a key and metadata, including system metadata such as size and content type and optional user-defined tags. Objects are written whole; changing part of an object means uploading a new version of it. Large files are sent with multipart upload, which splits them into parts that can be uploaded in parallel and retried individually.
| Property | What it controls | Typical options |
|---|---|---|
| Name | Global address of the bucket | Unique name, usually 3-63 lowercase characters |
| Location | Where data is physically stored | Single region, dual-region or multi-region |
| Default storage class | Price and retrieval behavior of new objects | Standard, infrequent access, archive |
| Access control | Who may read or write | Identity policies, bucket policies, uniform access |
| Encryption | Protection of data at rest | Provider-managed or customer-managed keys |
| Versioning | Whether old versions are kept | Disabled, enabled or suspended |
Bucket naming, location and limits
In Amazon S3 and Google Cloud Storage, bucket names are globally unique across all customers, because they form part of DNS names used to reach the data. Names cannot normally be changed after creation, and the location is fixed as well, so moving a bucket means copying its data to a new one.
Individual objects can be very large, up to 5 TB in the major services, while a single PUT request is limited to a few gigabytes, which is why multipart upload exists. The number of objects per bucket is effectively unlimited, but providers apply request-rate limits per prefix, so very high-throughput workloads spread keys across several prefixes.
Storage buckets compared with other storage types
A bucket is not a disk or a network share. Choosing between object, block and file storage depends on how the application accesses data and how much it needs to scale.
| Storage type | Access method | Strengths | Weaknesses |
|---|---|---|---|
| Object storage bucket | HTTP API by key | Massive scale, low cost, built-in durability | No in-place edits, higher latency per request |
| Block storage volume | Attached disk to one machine | Low latency, random writes | Tied to instances, limited size |
| File storage share | NFS or SMB protocols | Shared directories with file locking | Higher cost per gigabyte |
| Database | Query language or API | Structured queries and transactions | Unsuited to large binary files |
Buckets are designed for very high durability, commonly stated as eleven nines over a year for redundant storage classes, achieved by storing data across multiple devices and facilities. Durability protects against hardware loss, not against accidental deletion, which requires versioning or backups.
Securing and managing a bucket
Most serious cloud data leaks involving object storage have been caused by buckets that were readable by the public. Modern providers block public access by default, and the safest practice is to keep that block enabled and grant temporary access with presigned URLs when external users need a specific object.
| Need | Recommended setting | Effect |
|---|---|---|
| Prevent accidental exposure | Account-level public access block | Overrides permissive object or bucket settings |
| Recover deleted files | Object versioning with lifecycle cleanup | Keeps prior versions for a set number of days |
| Reduce storage cost | Lifecycle transitions to colder classes | Old data moves to cheaper tiers automatically |
| Meet retention rules | Object lock or retention policy | Objects cannot be deleted before a set date |
| Share a file temporarily | Presigned URL with short expiry | Access without changing bucket permissions |
| Disaster recovery | Cross-region replication | Copies new objects to a second region |
Access logging and inventory reports complete the picture: they show who accessed which objects and how storage is distributed across classes, which is essential for both security investigations and cost reviews.
Common mistakes with storage buckets
Bucket problems are usually configuration problems, not service failures. The following mistakes are among the most frequent in practice:
- Granting public read access to solve a sharing need that a presigned URL would cover.
- Enabling versioning without lifecycle rules, so noncurrent versions accumulate and costs grow silently.
- Treating a bucket as a file system, with frequent small rewrites and directory renames that are expensive.
- Ignoring retrieval fees of archive classes, which can exceed the storage savings for data read often.
- Choosing a distant region, which adds latency and data transfer charges for the main users.
A plain-language summary
A storage bucket is a named box in the cloud where files are kept. Each file inside has its own label, and the box itself has rules: where in the world it is stored, who may open it, how long files are kept and whether old copies are saved.
It resembles a rented storage unit with a strict front desk. The unit can hold almost unlimited amounts, but every visitor must show the right permission, and the owner decides the house rules once for everything inside.
An example from practice
A video production studio stores raw footage, edited projects and finished films. It creates one bucket in the region closest to its editors, enables versioning and server-side encryption, and keeps the public access block on. Editors upload multi-gigabyte clips with multipart upload, and clients receive finished films through presigned links valid for seven days.
A lifecycle rule moves raw footage to an infrequent access class after 60 days and to an archive class after one year, while deleting old noncurrent versions after 30 days. Within a year, the studio keeps every project available on request while cutting its monthly storage bill substantially, without anyone moving files by hand.