What Is a Cloud Storage Bucket in GCP? Naming, Location, and Configuration

What is a Cloud Storage bucket?

A Cloud Storage bucket is the primary container in Google Cloud Storage. It holds objects: the files, images, archives, logs, and binary data you upload. You cannot store objects without first creating a bucket to put them in.

Every bucket has three permanent properties you set at creation:

• Name. Must be globally unique across every GCP project worldwide.
• Location. The geographic region or multi-region where the data is physically stored.
• Default storage class. The cost and availability tier objects inherit unless you override it at upload time.

Everything else — access controls, versioning, lifecycle rules, labels — can be adjusted after creation. But name and location are fixed. Get those right before you create anything.

How Cloud Storage buckets work

Buckets sit between your application and the objects it stores. The bucket holds configuration that applies to everything inside it. Objects hold the actual data.

Here is the typical flow from creation to use:

1. Create the bucket. Choose a name, location, and default storage class.
2. Configure access. Enable uniform bucket-level access and apply IAM bindings.
3. Set defaults. Configure versioning, lifecycle rules, and labels if needed.
4. Upload objects. Files land in the bucket and inherit the default storage class.
5. Access objects. Via HTTPS URL, the gcloud CLI, client libraries, or signed URLs.
6. Manage over time. Lifecycle rules automatically move or delete objects as they age.

The bucket URL format is gs://bucket-name. An individual object is addressed as gs://bucket-name/path/to/file.jpg. Object names can contain slashes, which the console renders as folders, but there is no real directory structure. The full object name including slashes is just a flat string key.

For details on uploading and managing objects after your bucket exists, see Uploading Files with gsutil.

Why bucket decisions matter

Here is what is actually at stake:

• Latency. A bucket in us-central1 served to users in Europe adds round-trip overhead on every request. Choose a location close to your compute and your users.

• Cost. Multi-region and dual-region buckets cost more per GB than regional buckets, and egress between regions is billed separately. See Regional vs Multi-Regional Cloud Storage for a cost breakdown.

• Security. Access control decisions at the bucket level affect all objects inside it. Uniform bucket-level access prevents objects from being accidentally exposed via legacy ACLs. See Cloud Storage Security for more on securing buckets in production.

• Governance. Data residency rules in some industries require data to remain within a specific geography. A bucket in the EU multi-region does not guarantee data stays in a specific EU country. A regional bucket in europe-west2 does.

• Migration effort. Renaming, moving, or splitting a bucket later is a significant operational task. Plan your bucket structure before you upload production data.

Bucket naming rules

Bucket names have strict requirements because they form part of the public URL for your data. A bucket named my-app-assets is reachable at storage.googleapis.com/my-app-assets. You cannot rename a bucket after it is created, so get this right from the start.

The rules

• Must be globally unique across every GCP project in the world
• Must be between 3 and 63 characters long (up to 222 characters if the name contains dots)
• Can only contain lowercase letters, numbers, and hyphens
• Must start and end with a letter or number, not a hyphen
• Cannot resemble an IP address (for example, 192.168.0.1 is rejected)
• Cannot begin with goog or contain google

Naming best practices

The recommended pattern is {project-id}-{purpose}. Including the project ID avoids naming conflicts and makes ownership obvious in billing exports and audit logs:

• my-app-prod-assets — project context and purpose are clear
• my-app-prod-backups — environment and function are explicit
• my-app-staging-uploads — staging data is separated from prod
• my-bucket — almost certainly already taken; no ownership context
• test — too short, too generic, creation will fail
• customer-pii-data-prod — reveals architecture in a globally visible namespace

Location types

You choose a location when creating a bucket. This controls where Google physically stores the data and cannot be changed after creation. Choosing the wrong location means either a migration or permanent latency and cost overhead.

Region

Data is stored redundantly across multiple zones within a single region (for example, europe-west2 for London). Regional buckets have the lowest latency for workloads running in the same region and the lowest per-GB storage cost. Use regional buckets when all your compute is in one region and cross-region redundancy is not required.

Dual-region

Data is stored across two specific regions (for example, EUR4 covers europe-north1 and europe-west4). Dual-region provides automatic geo-redundancy. Turbo Replication can be enabled to guarantee replication to the second region within 15 minutes, which is useful for disaster recovery with a defined RPO. For a full cost analysis of when the premium is justified, see Regional vs Multi-Regional Cloud Storage.

Multi-region

Data is stored across multiple data centres within a large geographic area. Available options are US, EU, and ASIA. Multi-region buckets are optimised for high availability and throughput when serving global audiences. They cost more than regional buckets and do not give you control over exactly which regions store your data within the multi-region boundary. If data residency within a specific country is a legal requirement, use a regional bucket instead.

Key bucket configuration options

Uniform bucket-level access

When enabled, all access to the bucket and its objects is controlled exclusively by IAM. Legacy object ACLs are disabled. This is the recommended setting for every new bucket. It makes permissions auditable from a single place and prevents objects from being accessible via an ACL that is invisible in the IAM policy view.

Once uniform bucket-level access has been enabled for 90 days, it becomes permanent and cannot be disabled. Treat this as a feature: it removes a whole category of unintended access. For a detailed explanation of the difference between bucket-level IAM and legacy ACLs, see Cloud Storage IAM vs ACLs.

Default storage class

Objects uploaded to a bucket inherit the bucket’s default storage class unless you specify one explicitly at upload time. Set the default based on how frequently objects in this bucket will be accessed. For a breakdown of Standard, Nearline, Coldline, and Archive, see Storage Classes in GCP.

Versioning

When enabled, overwriting or deleting an object creates a historical version rather than permanently removing the previous content. Versioning protects against accidental overwrites and application bugs that corrupt data.

Lifecycle policies

Rules that automatically delete objects or transition them to a cheaper storage class after a set number of days. Lifecycle policies are essential for controlling costs in buckets that accumulate data over time. Logs, exports, and backups especially need these rules. Without them, data accumulates indefinitely and costs grow without bound. See Object Lifecycle Management for how to configure them.

Public access prevention

Prevents objects in the bucket from being made publicly accessible, even if an IAM policy tries to grant allUsers access. Enable this on any bucket that should never be public: internal logs, backups, or private user data especially.

Retention policies

A retention policy sets a minimum time that objects must be kept before they can be deleted. Once set and locked, not even a project owner can delete objects before the retention period expires. This is useful for audit logs or regulatory compliance requirements. Locking a retention policy is irreversible.

Labels

Buckets support key-value labels for cost attribution. Labels appear in billing exports, so team=backend or env=prod lets you break down storage costs by team and environment across a project.

When to use Cloud Storage buckets

Cloud Storage is a good fit for any workload where you store and retrieve whole files rather than querying fields within them:

• User-uploaded files. Profile images, documents, and media files uploaded by your application’s users. Store the file in Cloud Storage and keep the reference URL in your database. Use signed URLs to give users time-limited access without changing IAM.

• Static website assets. CSS, JavaScript, images, and pre-built HTML served to browsers. Pair with Cloud CDN for global performance.

• Application backups. Database exports, Terraform state files, and configuration snapshots. Use a regional bucket close to your primary compute and apply lifecycle rules to expire old backups.

• Logs and analytics exports. Cloud Logging export sinks, BigQuery export files, and raw event data for downstream processing pipelines.

• Data exchange between services. One service writes a file; another reads it. Cloud Storage acts as a durable, decoupled staging area with no tight coupling between producer and consumer.

• Machine learning datasets and model artefacts. Training data, model weights, and inference outputs are commonly stored as objects and referenced by Vertex AI and other ML services.

• Large binary files. Videos, audio, archives, and any file too large or unstructured for a database.

When not to use a bucket

Cloud Storage stores and retrieves whole objects. It is not the right tool when you need to query, filter, or randomly access data within files:

• Structured data you need to query. If you need to filter rows, join tables, or search by field value, use Cloud SQL or Firestore. You cannot run SELECT * WHERE user_id = 123 against objects in a bucket.

• Disk-like access patterns. If your application needs a POSIX filesystem — shared mounts, file locking, or random byte-range writes — use Filestore instead. Cloud Storage does not support true directory semantics or file locking. See Cloud Storage vs Filestore.

• Large-scale SQL analytics. If you need to run SQL queries over petabytes of structured data, BigQuery is the right tool. Cloud Storage can act as a source for BigQuery external tables, but the querying happens in BigQuery, not in the bucket.

• Low-latency key-value lookups. Cloud Storage has per-operation latency in the tens to hundreds of milliseconds range. For sub-millisecond key lookups, use Bigtable or Memorystore.

Not sure which service fits your workload? See Choosing the Right GCP Storage Service for a decision flow across Cloud Storage, Cloud SQL, Firestore, Bigtable, and Spanner.

Bucket vs object: the key distinction

These two terms are often confused. Here is the distinction:

A single bucket can hold millions of objects. Object names can contain slashes, which makes them appear as folders in the console. In reality, there is no folder hierarchy. The object name including the slashes is a flat string key. The “folders” are a console convenience, not real resources.

How to create and configure a bucket

The fastest way to create a bucket is with the gcloud storage command. Always specify location and access settings explicitly rather than relying on defaults.

# Create a regional bucket with uniform bucket-level access enabled
gcloud storage buckets create gs://my-app-prod-assets \
  --location=europe-west2 \
  --uniform-bucket-level-access \
  --default-storage-class=STANDARD

# Create a multi-region bucket for global static content
gcloud storage buckets create gs://my-app-global-content \
  --location=EU \
  --uniform-bucket-level-access \
  --default-storage-class=STANDARD

# Add labels to an existing bucket
gcloud storage buckets update gs://my-app-prod-assets \
  --update-labels=team=backend,env=prod

# Enable versioning on a bucket
gcloud storage buckets update gs://my-app-prod-assets \
  --versioning

# View bucket metadata and configuration
gcloud storage buckets describe gs://my-app-prod-assets

# List all buckets in the current project
gcloud storage buckets list

After the bucket is created, see Uploading Files with gsutil for how to copy objects into it.

How access control works

With uniform bucket-level access enabled, all access is controlled through IAM bindings on the bucket. There are no per-object ACLs to manage. A principal gets access to all objects in the bucket based on their role.

The most common roles for service accounts accessing Cloud Storage are:

• roles/storage.objectViewer — read objects and their metadata; cannot list the bucket contents or modify anything
• roles/storage.objectCreator — upload new objects; cannot read, list, or delete existing objects
• roles/storage.objectAdmin — full control over objects: read, create, overwrite, and delete
• roles/storage.admin — full control over the bucket itself and all objects, including IAM policy changes; typically reserved for infrastructure automation only

Use the most restrictive role that satisfies the use case. An API server that reads images needs objectViewer. A service that generates reports and writes them needs objectCreator. Grant objectAdmin only when a service also needs to overwrite or delete existing objects.

# Grant a service account read access to a specific bucket
gcloud storage buckets add-iam-policy-binding gs://my-app-prod-assets \
  --member="serviceAccount:api-server@my-app-prod.iam.gserviceaccount.com" \
  --role="roles/storage.objectViewer"

# Grant a service account write access to upload objects
gcloud storage buckets add-iam-policy-binding gs://my-app-prod-assets \
  --member="serviceAccount:upload-worker@my-app-prod.iam.gserviceaccount.com" \
  --role="roles/storage.objectCreator"

For a detailed comparison of IAM and legacy ACLs, including how to migrate buckets created before uniform access was standard, see Cloud Storage IAM vs ACLs. For granting time-limited access to objects without changing IAM, see Signed URLs Explained.

Cloud Storage vs other storage options

Cloud Storage is the right tool for unstructured files and binary data. For other workloads, a different GCP service is usually a better fit:

• Cloud Storage vs Filestore. Filestore provides a managed NFS file system that VMs can mount directly. Use Filestore when your application needs a POSIX filesystem — shared mounts, file locking, or random byte-range access. Cloud Storage does not support any of these. See Cloud Storage vs Filestore.

• Cloud Storage vs Cloud SQL. Cloud SQL stores structured relational data you query with SQL. Use it for user records, orders, and anything with a schema. Use Cloud Storage for the files those records reference — profile images, invoice PDFs, export files.

• Cloud Storage vs Firestore. Firestore is a document database with real-time sync and rich query support. Use it for structured document data. Use Cloud Storage for binary files and large blobs that Firestore cannot store efficiently.