Cloud Storage
Cloud Storage is Google's object storage for unstructured blobs - images, backups, logs, static sites. Objects live in buckets, bucket names are globally unique, and there are no real folders: a "folder" is just a / in the object's name.
Every bucket comes down to three choices: how cheap vs how reachable the data is (storage class), where the bytes physically live (location type), and what happens to objects over time (lifecycle and protection). This page walks them in that order.
Storage classes
Pick a storage class by how often you read the data. Colder = cheaper storage, pricier retrieval, longer minimum billing - durability and first-byte latency stay identical across all four. Walk it as a decision: is the data even unstructured (else use a database), then funnel by read frequency down to the coldest class that still fits.
The matrix below is the same decision seen side-on, with the price and durability detail the flow leaves out:
Delete or overwrite an Archive object after 10 days and you're still billed for the full 365-day minimum. All classes have the SAME 11-nines durability and millisecond first-byte latency - Archive is NOT tape and needs no "restore/thaw" wait.
11-nines durability means you won't lose data - it says nothing about whether you can reach it right now. Availability (the SLA above) is that "can I open the vault today" guarantee, and it drops for colder classes and single regions. Like a bank: your money is safe in the vault (durable), but you can't withdraw it while the branch is closed (available).
Location types
A storage class decides how the data is stored; a location type decides where. Every class is offered in all three, and you fix the choice when you create the bucket.
An object can also carry its own storage class that overrides the bucket default - set it at upload or change it later in place, without a new bucket or a new URL.
You can change a bucket's default storage class anytime, but you can never switch its location type - a regional bucket can't become multi/dual-region and vice versa. To "move" it you create a new bucket and copy the objects across.
Managing objects over time
Once an object is written, four features decide its fate - read them as a spectrum from letting it go to holding it forever: lifecycle rules age it out, versioning remembers old copies, Soft Delete catches accidental deletes, and Retention Lock forbids deletion outright.
Lifecycle rules
Lifecycle rules run automatically on a bucket to transition (downgrade class) or delete objects by age, version count, or creation date. A rule can only move objects to a colder class, never warm them back up. Common rules: downgrade objects older than a year to Coldline, delete objects created before a specific date, or keep only the N most recent versions.
Object inspection runs in asynchronous batches, and a lifecycle config change takes up to 24 hours to take effect - so Cloud Storage may keep acting on the OLD rules for up to a day after you edit them.
Autoclass
Lifecycle rules are one-way and hand-authored; Autoclass does the class management for you, both directions. Enable it on a bucket and every object - whatever class the upload requested - begins in Standard, then transitions colder when it sits unread past a threshold and back to Standard the instant it is read. Reach for it when access patterns are unknown, unpredictable, or varied across objects.
Because Autoclass owns the transitions, buckets with it enabled have no early-deletion charges, no retrieval charges, and no storage-class transition charges - the exact fees that bite you with manual lifecycle rules. In exchange it charges a small per-object management fee. Don't run lifecycle rules and Autoclass on the same bucket.
Object versioning
Objects are immutable - an uploaded object never changes during its lifetime. To recover objects that are deleted or overwritten, enable Object Versioning on the bucket. Each time the live version is overwritten or deleted, Cloud Storage keeps an archived copy, uniquely identified by a generation number.
With versioning on you can list archived versions, restore the live version to an older state, or permanently delete an archived version. You can turn versioning on or off at any time; turning it off leaves existing archived versions in place and just stops accumulating new ones.
Archived versions are charged as if they were multiple files, so a heavily-overwritten object quietly multiplies your storage bill. Combine versioning with a lifecycle rule (e.g. "keep only the 3 newest versions") to cap the cost.
Soft delete
Soft Delete is the safety net for accidental or malicious deletion, and every bucket gets it by default. Deleted objects - including versions removed by an overwrite - are retained for a set duration: restorable during that window, permanently gone after.
To guard against accidental or malicious deletion, Google recommends Soft Delete. Reach for Object Versioning instead only when you genuinely need a browsable history of every object revision.
| Setting | Value |
|---|---|
| Enabled by default | Yes, on every new bucket |
| Default retention duration | 7 days |
| Maximum retention duration | 90 days |
| Disable it | Set retention duration to 0 |
Object retention lock
Object Retention Lock sets a retention configuration on individual objects (in buckets where the feature is enabled). The configuration governs how long an object must be retained, with the option to permanently prevent that retention time from being reduced or removed.
Its purpose is meeting regulatory data-retention rules such as FINRA, SEC, and CFTC. Locking a retention period is one-way - you cannot shorten or remove it afterward - so set it deliberately.
Access control
Cloud Storage offers four ways to grant access, from coarse to fine, and they combine on the same bucket.
IAM vs ACLs is the choice you make most:
- Uniform bucket-level access - IAM only, applied at the bucket. Simple, recommended, auditable. All objects inherit bucket permissions.
- Fine-grained (ACLs) - per-object ACLs on top of IAM. Legacy; only use when individual objects need different access.
You can switch a bucket to uniform anytime, but once uniform has been on for 90 days you can NOT revert to fine-grained. Default new buckets to uniform unless you truly need per-object ACLs.
allUsers the Storage Object Viewer roleallUsers = literally anyone on the internet, no login required. allAuthenticatedUsers = anyone signed in with any Google account (not just yours, not your org). Neither means "people in my organization" - use IAM for that.
A signed URL grants temporary access to a specific object without the caller having a Google identity - the URL itself carries the (expiring) credential. Think of it as a valet key.
It works for GET, PUT, or DELETE - not POST. After you hand it out you can't revoke it, so set a short expiry. A signed policy document tightens it further by restricting what a holder is allowed to upload.
Cross-project access
To let a workload in one project reach a bucket in another project, don't make the bucket public - grant a service account the right Storage role in the bucket's project, then hand its key to the workload. The classic recipe: create the SA in the bucket's project, grant it Storage Object Viewer (read) or Storage Object Admin (read + write) on the bucket, download its JSON key, and on the accessing VM run gcloud auth activate-service-account --key-file=…. The VM now makes every request as that SA.
Access is bound to the service account's IAM role on the target bucket, so cross-project access works even though the VM lives elsewhere. With only Storage Object Viewer, a cp up into the bucket fails - you must add Storage Object Admin for writes. The downloaded JSON key is a long-lived credential: anyone holding it acts as the SA, so protect it like a password.
Consistency
Cloud Storage is strongly globally consistent: the moment an upload succeeds, the object is readable - with correct metadata - everywhere Google serves, whether it's brand new or an overwrite. You never get a 404 Not Found or stale data on a read-after-write.
| Operation | Guarantee |
|---|---|
| Read-after-write | New/overwritten object is immediately readable |
| Read-after-metadata-update | Updated metadata is immediately visible |
| Read-after-delete | Deleted object immediately returns 404 Not Found |
| Bucket listing | A just-created bucket appears in the list immediately |
| Object listing | A just-uploaded object appears in the list immediately |
Other features to know
| Feature | What it does |
|---|---|
| Customer-supplied encryption keys (CSEK) | Supply your own key instead of Google-managed keys (see CMEK page) |
| Directory synchronization | Sync a VM directory with a bucket |
| Object change notifications | Fire events on object changes - configured using Pub/Sub |
Bulk import
Getting data into Cloud Storage - pick the tool by source, size, and network.
gcloud storage cp (or gsutil cp)bq loadA large number of small objects uploads slowly one at a time. gsutil -m (or parallel composite uploads for big single files) parallelizes it. This is a common "speed up the upload" answer.
For larger datasets, three services bulk-load into buckets - pick by network vs volume:
- Storage Transfer Service - managed and online. Moves data from AWS S3, Azure Blob, other GCS buckets, HTTP/HTTPS URL lists, or on-prem (via an agent) into Cloud Storage, with schedules and incremental syncs. Needs bandwidth.
- Transfer Appliance - a rugged physical box Google ships to you. You fill it, ship it back, and Google loads it into Cloud Storage. Offline, for petabyte-scale (hundreds of TB up to 1 PB).
- Offline Media Import - a third-party provider uploads your physical media (storage arrays, HDDs, tapes, USB drives) into Cloud Storage. Use it when the data already lives on removable media.
If moving the data over your network would take weeks or more, use Transfer Appliance. Otherwise use Storage Transfer Service. Roughly: 1 TB over 100 Mbps ≈ a full day.