Google Cloud Storage Overview: What It Is, Buckets, Pricing, and Use Cases

In plain English

Cloud Storage is a place to put files on the internet. You create a named container called a bucket, put files into it, and those files become available over a URL. Each file is called an object. The object has a name (its unique address within the bucket), the actual data, and a small set of metadata (file type, size, timestamps, and any custom labels you add).

Unlike a database, you cannot query the contents of a file. Unlike a hard drive, you cannot mount Cloud Storage and edit files in place. You upload whole files and download whole files. That constraint is also what makes Cloud Storage extremely durable and cost-effective at scale.

What is Google Cloud Storage?

Cloud Storage is a fully managed object storage service. You do not provision servers, manage disk replication, or configure RAID arrays. Google handles all of that. You interact with the service through a bucket API, command-line tools, client libraries, or the Cloud Console.

It is designed to store unstructured data at massive scale: images, videos, audio files, PDFs, log archives, database backups, trained model weights, compiled binaries, and any other file type. A single object can be up to 5 TB. A single bucket can hold effectively unlimited objects.

Cloud Storage is also designed for extreme durability. Google publishes a 99.999999999% (eleven nines) annual durability target, meaning data loss due to hardware failure is effectively eliminated through redundant storage across multiple physical locations. Availability SLAs are separate and depend on storage class and location type, ranging from 99% for Archive in a single region up to 99.95% for Standard in a multi-region.

Almost every GCP architecture uses Cloud Storage as the durable staging layer for unstructured data. It integrates directly with BigQuery (as a data source and export target), Cloud Run, Cloud Functions, Dataflow, and Vertex AI. It is the default place files land between processing steps.

How Cloud Storage works

Working with Cloud Storage follows a clear sequence:

1. Create a bucket. A bucket is the top-level container. You choose a globally unique name, a location (region, dual-region, or multi-region), and a default storage class. These choices are permanent or difficult to change after creation. See Storage Buckets Explained for naming rules and all configuration options.

2. Choose a location and storage class. Location determines where Google physically stores your data and affects latency and egress costs. Storage class determines how much you pay per GB per month and what minimum storage durations apply. See Storage Classes in GCP to match the right class to each workload.

3. Upload objects. Objects are uploaded whole, over HTTPS. For files over a few hundred megabytes, use a resumable upload so the transfer can restart from where it left off rather than the beginning. The Uploading Files guide covers both gcloud storage and the legacy gsutil tool.

4. Control access. By default a bucket is private. You grant access through IAM roles at the bucket level. For temporary or unauthenticated access, generate a signed URL. For a full walkthrough of the access model, see Cloud Storage IAM vs ACLs.

5. Add lifecycle, versioning, and retention controls. Versioning keeps previous copies of objects when they are overwritten or deleted. Lifecycle rules automate transitions to colder storage classes or deletions after a set number of days, the most practical way to control costs as buckets grow.

Key concepts

Buckets

A bucket is the top-level container for objects in Cloud Storage. Every object lives inside a bucket. Bucket names are globally unique across every GCP project in the world. If another customer has already created my-app, you cannot use that name. Location, access model, and default storage class are set at the bucket level. Some of these (such as location) cannot be changed after creation, so the decisions you make at bucket creation time matter.

Objects

An object is an individual item stored in a bucket. It has three components: the data bytes, a unique key (the object’s name within the bucket), and metadata (content type, custom labels, encryption details, timestamps). Object names are arbitrary strings up to 1,024 bytes. The maximum single-object size is 5 TB. Object names can contain forward slashes, which the console renders as folders, but those folders do not exist as separate resources. The namespace is genuinely flat.

Storage classes

Cloud Storage has four storage classes that trade monthly storage cost against access cost and minimum storage durations:

• Standard. Highest per-GB cost, no minimum duration, cheapest per-operation cost. Use for data accessed frequently or unpredictably.
• Nearline. Lower storage cost, 30-day minimum storage duration. Use for data accessed roughly once a month.
• Coldline. Lower still, 90-day minimum. Use for data accessed roughly once a quarter.
• Archive. Lowest storage cost, 365-day minimum, highest access cost. Use for long-term backups and compliance archives accessed rarely if ever.

Choosing the wrong class is one of the most direct causes of unexpected storage bills. The Storage Classes in GCP page covers each class with concrete examples and a guide to switching classes automatically with lifecycle rules.

Locations

Location is set at bucket creation and cannot be changed afterwards. There are three location types:

• Region. Data is stored redundantly across multiple zones within a single region (e.g., europe-west2 for London). Lowest latency for workloads in that region, lowest storage cost.
• Dual-region. Data is stored in two specific regions (e.g., EUR4 covers europe-north1 and europe-west4). Automatic geo-redundancy. Turbo Replication can guarantee replication to the second region within 15 minutes.
• Multi-region. Data is stored across multiple data centres within a large geographic area (US, EU, or ASIA). Highest availability for globally distributed access, at slightly higher cost.

Create buckets in the same region as the compute that accesses them. Cross-region reads incur network egress charges and increase latency.

Access methods

Cloud Storage objects can be accessed through several interfaces:

• Cloud Console. Browser-based upload, download, and bucket management.
• gcloud storage CLI. The modern command-line tool; prefer this for new work.
• gsutil. The legacy Python-based CLI, still widely used and fully functional.
• Client libraries. SDKs for Python, Go, Java, Node.js, and others.
• JSON and XML APIs. REST APIs for direct HTTP access.
• Signed URLs. Time-limited, pre-authorised URLs for temporary access without requiring a Google account.

When to use Cloud Storage

Cloud Storage is the right choice when you need to store files durably, retrieve them by name or URL, and do not need to query fields inside them. Common use cases:

• Storing user-uploaded content (images, documents, videos) for web or mobile applications
• Serving static website assets and single-page applications
• Archiving logs, database dumps, and compliance records at low cost
• Staging data before loading it into BigQuery or another data warehouse
• Storing ML training datasets and model artefacts for Vertex AI pipelines
• Distributing large files (software releases, model weights) globally via Cloud CDN
• Holding pipeline inputs and outputs between processing steps in Dataflow or Cloud Run jobs
• Storing application backups that need to be retained for months or years

When not to use Cloud Storage

Cloud Storage is not the right tool for every storage problem. If your access pattern involves querying, filtering, or mounting, a different service is a better fit:

• Structured relational data. Use Cloud SQL. Cloud Storage cannot run SQL queries or join tables.
• Document and real-time app data. Use Firestore. If you need to query individual fields, filter records, or push updates to clients, Firestore is the right model.
• Shared network file system. Use Filestore. If your VMs or containers need to mount a shared POSIX-compatible filesystem, Cloud Storage cannot fill that role.
• Mounted block disk. Use Persistent Disk. If you need a low-latency disk attached to a Compute Engine VM with random read/write access, use block storage.
• High-throughput analytical row data. Use Bigtable for sub-10ms access to millions of rows per second in a wide-column model.

For a complete decision flow across all GCP storage options, see Choosing the Right Storage Service.

Object storage vs block storage vs file storage

There are three fundamental types of storage. Understanding the difference explains why Cloud Storage excels for some workloads and is wrong for others.

• Object storage stores data as discrete, self-contained objects each identified by a unique key. You access objects via HTTP APIs with no mounting, no partial reads, and no genuine directory tree. Cloud Storage is object storage. Ideal for files written once and read many times at scale.

• Block storage presents data as a raw disk split into fixed-size blocks. The operating system manages a filesystem on top. You can mount it, read arbitrary byte ranges, and update files in place. GCP’s block storage is Persistent Disk. Ideal for databases and OS volumes attached to VMs.

• File storage presents a shared filesystem with a genuine directory tree over a network protocol like NFS. Multiple clients can mount the same filesystem concurrently. GCP’s managed file storage is Filestore. Ideal for shared application data that must be mounted across multiple VMs simultaneously.

Cloud Storage wins on durability, global scale, and cost per GB for whole files accessed by name. It loses on latency and mutability compared to block or file storage. Pick based on your access pattern, not on which sounds most capable.

Pricing overview

Cloud Storage pricing has three main components. Understanding each helps you make decisions that avoid surprise charges:

• Storage cost. Charged per GB per month. The rate varies by storage class (Standard is highest, Archive is lowest) and by location (multi-region costs slightly more than regional). This is the largest cost component for most workloads.

• Operation cost. Charged per request. Class A operations (writes, bucket creates, listing) cost more than Class B operations (reads, metadata lookups). For most workloads this is small, but high-frequency workloads with many small objects can produce meaningful operation charges.

• Network egress cost. Charged when data leaves a region. Transfers within the same region are free. Transfers to a different GCP region or to the internet incur charges. Co-locating compute and storage in the same region eliminates most egress costs.

Security and access control

A newly created Cloud Storage bucket is private by default. All data is encrypted at rest using Google-managed AES-256 keys, and all data in transit uses TLS. These defaults are good starting points, but production buckets require deliberate configuration.

• IAM roles. Grant access at the bucket level using roles such as roles/storage.objectViewer (read-only), roles/storage.objectCreator (write-only), and roles/storage.objectAdmin (full object control). Follow least privilege: grant only what each service account or user actually needs.

• Uniform bucket-level access. Disables legacy object-level ACLs and makes IAM the sole access control mechanism. Enable this on every new bucket. Without it, both IAM and ACLs are active simultaneously, which makes permissions difficult to audit and creates unexpected access paths. See Cloud Storage IAM vs ACLs for details on migrating existing buckets.

• Public access prevention. An organisational policy constraint that blocks buckets from being made publicly accessible. Apply this to any project that should never serve public content.

• Customer-Managed Encryption Keys (CMEK). Supply your own Cloud KMS key instead of relying on Google-managed keys. This gives you revocation control: if you revoke access to the KMS key, Cloud Storage can no longer decrypt those objects. Required by some compliance frameworks.

For a complete treatment of hardening Cloud Storage buckets in production, see Cloud Storage Security.

Creating your first bucket

The following commands create a regional bucket with uniform bucket-level access enabled and upload a file:

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

# Upload a file
gcloud storage cp ./logo.png gs://my-app-assets/images/logo.png

# List objects in a bucket
gcloud storage ls gs://my-app-assets/

# Download a file
gcloud storage cp gs://my-app-assets/images/logo.png ./logo-copy.png

# Remove an object
gcloud storage rm gs://my-app-assets/images/logo.png

Cloud Storage vs other GCP storage services

Cloud Storage is the right tool for files. For other data shapes, GCP has purpose-built services:

For a full decision flow that walks through all GCP storage options in order, see Choosing the Right Storage Service.