8.1 Cloud Storage Lifecycle and Signed Access

Cloud Storage (GCS): Classes, Lifecycle & Governance

Google Cloud Storage delivers exabyte-scale object storage with 99.999999999% (11 nines) annual durability.

Storage Classes & Autoclass

Object Versioning & Lifecycle Management

• Object Versioning: When enabled, overwriting or deleting the live object without a generation can preserve a noncurrent generation. Explicit generation deletion, lifecycle rules and soft-delete settings have separate behavior; versioning is not a promise that nothing can be permanently removed.
• Object Lifecycle Management Rules: Configured via declarative JSON policies to automate object retention and cost optimization:
  • Condition: Object age > 30 days, current storage class is Standard -> Action: Set storage class to Nearline.
  • Condition: Noncurrent versions older than 14 days, numNewerVersions > 3 -> Action: Delete permanently.
  • Condition: abortIncompleteMultipartUpload after 7 days -> Cleans up abandoned chunked uploads to prevent hidden storage costs.

Retention Policies & Bucket Lock (WORM Compliance)

• Retention Policy: Enforces a minimum retention period (e.g., 7 years) during which objects in the bucket cannot be deleted or overwritten by anyone, supporting write-once retention designs; regulatory compliance also depends on the full system and applicable requirements.
• Bucket Lock: Permanently locks the retention policy. Critical Safety Rule: Once a retention policy is locked, it cannot be deleted, disabled, or shortened, even by Project Owners or Google Cloud Support. The retention period can only be extended.

---

Direct Client Operations: Signed URLs & Cloud Storage FUSE

Cloud Storage Signed URLs

Routing multi-gigabyte media uploads or downloads through an intermediate application server (such as Cloud Run or GKE) consumes excessive CPU, memory, and double network bandwidth. Developers resolve this by generating Signed URLs:

+--------------------------------------------------------------------------+
| Cloud Storage Signed URL Workflow (Direct Client Upload)                 |
+--------------------------------------------------------------------------+
|                                                                          |
| [ Client Browser ]                                                       |
|        |                                                                 |
|        | 1. Request Upload Permission (POST /api/upload-ticket)          |
|        v                                                                 |
| [ Cloud Run API ] ---> 2. Calls IAM SignBlob API with GSA Credentials    |
|        |                  (Generates V4 Signed PUT URL, Valid for 15m)   |
|        | 3. Returns Signed URL to Client                                 |
|        v                                                                 |
| [ Client Browser ]                                                       |
|        |                                                                 |
|        | 4. Direct upload using signed PUT or authorized resumable session            |
|        v                                                                 |
| [ Cloud Storage Bucket ] (Bypasses Cloud Run Compute & Egress Completely)|
+--------------------------------------------------------------------------+

• Mechanics: The signer needs the IAM signBlob permission and storage permission for the chosen operation (for example Object Creator for a new upload or Object Viewer for a download). It can generate a cryptographic V4 Signed URL with a defined HTTP method (PUT, GET), expiration window (e.g., 15 minutes), and optional Content-MD5 checksum.
• Security: The client uploads the file directly to the Cloud Storage bucket without needing Google Cloud credentials or public bucket access permissions.

Cloud Storage FUSE

Cloud Storage FUSE is an open-source FUSE adapter that allows Linux instances, GKE Pods, and Cloud Run containers to mount Cloud Storage buckets as local filesystems.

• Operational Constraints: Cloud Storage is an object store, not a POSIX filesystem. GCS FUSE does not support file locking, symlinks, or in-place byte modifications ; supported streaming or append behavior varies by FUSE version, but it does not provide general database-grade POSIX semantics.
• Optimal Use Cases: Machine learning model training data ingestion, read-heavy media assets, and legacy file-processing containers requiring a directory-like interface.

---

NoSQL and Unstructured Storage Decision Matrix

Storage Consistency and Replication Boundaries

Cloud Storage object read-after-write, metadata reads, deletion and object listing are strongly consistent after a successful operation, including dual/multi-region buckets. This does not mean every administrative change propagates immediately: granting/revoking access and recreating deleted buckets have eventual behavior. Public caches can also serve an older object until the configured cache lifetime ends. Use generation preconditions for operations that must target a specific version instead of assuming successive ranged reads always see the same bytes.

Strong API visibility is different from replication recovery objectives. If an acknowledged object's initial location fails before cross-region replication completes, a retryable availability error can occur rather than returning stale object data. Choose the supported location/replication option and recovery commitments for the actual failure model. A regional application and multi-region object bucket do not share one universal RPO/RTO.

Official references checked October 18, 2026: Google Cloud 1, Google Cloud 2.