Google Cloud Storage

At a glance

Cloud Storage is worth considering for application uploads, datasets, static assets and backups when you want durable objects integrated with Google Cloud. It stores data in named buckets and objects, with location, access and lifecycle choices you control. The important decision is how the data will be read, shared and eventually removed, not just the advertised price per gigabyte.

Good fit

Applications that need independent storage for files rather than keeping them on a replaceable application instance. A Cloud Run service can handle application logic while a bucket holds the objects. Storage location and storage class answer different questions: region or multi-region placement concerns where data resides; Standard, Nearline, Coldline and Archive address different access/cost patterns for general-purpose storage. A signed URL can give temporary access to one object without making the whole bucket public. Your application still decides who should receive that access.

Consider something else when

You need a relational database, an ordinary shared drive for people, or full local-filesystem behavior. A mounted bucket does not change the underlying object-store semantics. The documented FUSE adapter is not POSIX-compliant, lacks file locking and is not recommended as a database backend. Likewise, choosing a colder storage class solely because its at-rest price is lower can be a poor match for frequently read or short-lived data. General-purpose storage guidance here does not evaluate the newer specialized Rapid storage options.

Start here

For an authorized sandbox trial, choose a bucket location and start with Standard storage and a tiny synthetic object. Use uniform bucket-level access for an IAM-based permission model and review public access prevention, then confirm an authorized identity can read the object while an ordinary unauthenticated request cannot. If sharing is needed, generate a narrowly scoped, short-lived signed URL and check its expiry behavior. Public access prevention does not block those signed links. Before cleanup, inspect soft delete and any retention settings. This is a documented test plan; no bucket, object, key, signed URL or cloud permission was created for this guide.

Cost and requirements

Estimate stored bytes, operations, retrieval, replication and network transfer together. Location and class affect rates. Typical minimum billable durations are 30 days for Nearline, 90 for Coldline and 365 for Archive; deleting or replacing early can still incur charges, with policy-specific exceptions such as Autoclass. Soft-deleted objects continue to incur storage charges until permanently removed. For supported buckets, the documented default is seven days of soft-delete retention; tags or explicit policy can change it. A storage bill can therefore continue after an object disappears from its normal listing. No workload-specific total or free-tier eligibility was established.

Limits to know

Uniform bucket-level access disables object ACLs; it does not by itself establish that every IAM grant is private. Public access prevention blocks access through public principals, while a valid signed URL remains usable by whoever holds it until expiry. Match these controls to the application’s ownership rules. Soft delete protects against some deletion mistakes, but is not proof that you can restore an entire application. File access, signed-link expiry, restore operations, transfer performance and actual billing were not tested. The recommendation comes from current product, pricing and access documentation, not a deployed storage workflow.

Related work

• Google Cloud: project, identity and billing context (context)
• Cloud Run: application execution alongside object storage (context)

Still unclear

• Application-specific storage, request and transfer costs were not measured.
• Access enforcement, signed-link expiry, restoration and workload performance were not tested.