GCP Cloud Storage

Cloud Storage is Google object storage — the counterpart to AWS S3 and Alibaba OSS. Three things matter: data decoupled from compute, redundancy across zones by default, and the cost leverage from storage classes plus lifecycle rules. Most runaway storage bills are not a unit-rate problem; they happen because every byte sits in the Standard class forever. We open the GCP project and act as payment intermediary, with no personal credit card and no identity documents. Once the account is live you create buckets and rules in the console.

Specs & pricing

What object storage is: the layer decoupled from compute

Object storage breaks files into an object plus metadata, reached through an API — no directory tree, no filesystem semantics. Three practical consequences: data outlives the compute instance serving it, any language reads the same copy, and capacity scales with usage rather than instance size. A bucket region is fixed at creation and cannot be changed; migrating means a new bucket plus a data copy.

Storage classes: four tiers, four access frequencies

What you pay for: capacity, operations, retrieval, egress

• Capacity: class unit price times GB-months — colder classes cost less per GB
• Class A operations: writes, listings, copies, and iterative listings add up fast
• Class B operations: reads and deletes, where rarely-accessed data is genuinely cheap
• Retrieval and early deletion: reads out of a cold class are charged per GB, and deleting before the minimum duration costs extra

Bucket placement: zonal, dual-region, or multi-region

The main cost lever: lifecycle rules and tiering

1. Classify the data first: logs, backups, uploads, and assets have completely different read rates
2. Add SetStorageClass rules so data ages down automatically on object age, with no manual step
3. Set the class at write time for cold-on-arrival data — writing to Standard and reclassifying costs an extra operation
4. Pair versioning with noncurrent-version rules, or old versions keep accruing charges

How to get buckets running through us

1. Describe the data: volume, read frequency, and whether it must persist across regions — this picks zonal versus dual-region
2. We handle provisioning and payment: no personal credit card bound, no identity documents submitted
3. Create the bucket in the console: get the region right once, and enable uniform bucket-level access and default encryption
4. Configure lifecycle and budget alerts, then look at egress through Cloud CDN

Four common mistakes

1. Everything in Standard: the most common cause of a runaway bill, and the easiest to fix
2. Ignoring minimum durations: deleting a Nearline object a day after writing gives the early-deletion charge straight back
3. Iterative listings over huge buckets: every listing is a Class A operation — use batch operations instead
4. Living with a wrong bucket region: regions cannot be changed, only migrated, so decide early