What Is Google Cloud Storage
Google Cloud Storage (GCS) is Google Cloud's fully managed object storage service: instead of files sitting on a disk attached to a server, every piece of data is stored as an immutable object inside a container called a bucket, addressed by a flat key rather than a folder path. This makes it ideal for unstructured data such as images, videos, backups, logs, and data lake files, because GCS scales storage and throughput automatically without you provisioning capacity in advance.
Cricket analogy: Think of a bucket like a franchise's video archive at the BCCI: every ball bowled by Bumrah across a decade is stored as a separate clip tagged with a match ID, not organized in nested folders by year and month.
Buckets, Objects, and Naming
Bucket names are globally unique across all of Google Cloud, must follow DNS-compliant naming rules, and are assigned to a specific location type when created: a single region for lowest latency, a dual-region for geo-redundancy with fast replication, or a multi-region for maximum availability across a continent. Objects inside a bucket are identified by a key, can carry custom metadata, and are versioned automatically if you enable Object Versioning, which keeps prior generations recoverable after an overwrite or delete.
Cricket analogy: It's like how every IPL team name (Mumbai Indians, Chennai Super Kings) must be globally unique across the league, and a team chooses its home ground location the way a bucket chooses a region for lowest latency.
# Create a new bucket in a single region with uniform access
gcloud storage buckets create gs://acme-app-assets \
--location=us-central1 \
--uniform-bucket-level-access
# Upload a local file as an object
gcloud storage cp ./product-photo.jpg gs://acme-app-assets/images/product-photo.jpg
# List objects with a prefix filter
gcloud storage ls gs://acme-app-assets/images/
# Download an object back to local disk
gcloud storage cp gs://acme-app-assets/images/product-photo.jpg ./downloaded.jpgAccess Control and URLs
GCS supports two access control models: fine-grained ACLs applied per object, and uniform bucket-level access, which disables ACLs and enforces IAM policies consistently across every object in the bucket. Google recommends uniform bucket-level access for almost all new buckets because it simplifies auditing and prevents accidentally public objects. For temporary, time-limited access without making data public, you generate a signed URL that embeds a cryptographic signature and expiration timestamp, letting an unauthenticated client download or upload a specific object until it expires.
Cricket analogy: It's like a stadium switching from checking individual seat tickets at every gate (per-object ACLs) to a single wristband policy that governs the entire stand (uniform bucket-level access) for simpler crowd control at a World Cup final.
Google explicitly recommends enabling uniform bucket-level access on every new bucket unless you have a specific legacy requirement for per-object ACLs. It closes off an entire class of misconfiguration where a single object is accidentally left publicly readable.
Consistency and Durability
GCS provides strong global consistency for all operations, meaning that once a write, overwrite, or delete succeeds, every subsequent read anywhere in the world returns the latest state immediately, with no eventual-consistency window to reason about. Behind that guarantee, GCS is engineered for 99.999999999% (eleven nines) annual durability by erasure-coding and replicating object data across multiple devices and, for multi-region buckets, across geographically separated locations, so the practical chance of losing an object is effectively zero.
Cricket analogy: It's like the third umpire's DRS review being instantly binding for every camera angle and broadcaster the moment it's confirmed, with no delay where some viewers still see the old decision on screen.
A deleted bucket name is not immediately available for reuse and, for buckets that were ever publicly accessible, Google may reserve the name permanently. Always double-check a bucket name before deletion, since recreating an identically named bucket is not guaranteed to succeed later.
- Google Cloud Storage is object storage: data is stored as immutable objects inside globally-unique-named buckets, not as files in a traditional directory tree.
- Buckets are created in a location type — region, dual-region, or multi-region — which trades off latency against availability and redundancy.
- Uniform bucket-level access is the recommended access model; it replaces per-object ACLs with a single IAM policy for the whole bucket.
- Signed URLs grant time-limited, unauthenticated access to a specific object without making the object or bucket public.
- GCS guarantees strong global consistency: reads always reflect the latest successful write immediately, everywhere.
- Durability is engineered at eleven nines (99.999999999%) annually through erasure coding and replication.
- Deleted bucket names are not reliably reusable, so naming and deletion should be treated as a deliberate, careful action.
Practice what you learned
1. What is the recommended access control model for new Cloud Storage buckets?
2. What consistency model does Google Cloud Storage provide for object reads and writes?
3. What is a signed URL used for?
4. What must be true of every Cloud Storage bucket name?
5. Roughly what annual durability does Google Cloud Storage engineer for?
Was this page helpful?
You May Also Like
Storage Classes in GCP
How to choose between Standard, Nearline, Coldline, and Archive storage classes in Cloud Storage, and how lifecycle rules and Autoclass automate the transitions.
Choosing the Right GCP Storage
A decision framework for picking between Cloud Storage, Persistent Disks, and Filestore based on access pattern, cost, and performance needs.
Filestore Basics
How Google Cloud's managed NFS file storage service works — service tiers, mounting, shared multi-VM use cases, and backup versus snapshot protection.