Skip to main content
This route preserves the Google Cloud Storage API while Cloud Adapter stores object data in Azure Blob Storage.
Google Cloud API requests pass through Tensor9 Cloud Adapter to Azure services.Google Cloud API requests pass through Tensor9 Cloud Adapter to Azure services.

Compatibility snapshot

The Cloud Storage to Azure profile supports object CRUD and compose through Azure block lists. Each bucket maps to a container, the profile marks bucket lifecycle as supported, and generation preconditions adapt to Blob ETags. Google V4 signed URLs, retention policy, and ARCHIVE reads are rejected. Uniform access is partial. Existing data, versions, and signed links are not migrated.

Prerequisites

  • an installed Google Cloud-origin endpoint;
  • a Cloud Storage to Blob Storage service adapter;
  • an origin-side Google credential;
  • an Azure runtime identity with access to one test container;
  • a separate Azure verification identity;
  • Python 3 with google-cloud-storage and Azure CLI.

Set values

The API endpoint shape and origin authentication in this sample are deployment-specific placeholders. Use the exact endpoint and caller credential mode supplied by your Cloud Adapter deployment. Target Azure credentials remain adapter-owned.

Write through the Google Cloud client

Verify Azure natively

Verify bytes, content type, and target container. Keep target Blob ETags and origin generation semantics within their respective APIs.

Test precondition and error behavior

Request a missing object and retain the Google API status, reason, request ID, and diagnostic headers. If the application uses generation preconditions, deliberately send one stale precondition and confirm the translated failure before relying on concurrency control. Do not include signed-URL, retention-policy, or ARCHIVE workflows in this route; the target profile rejects them.

Clean up

Confirm that the current Azure blob is no longer readable with az storage blob show. Versioned or soft-delete-enabled targets can retain prior versions or recovery state; use an unversioned disposable target for this quickstart or remove the created version explicitly. Keep container deletion separate.

Before production

Test compose sizes and ordering, generation conditions, list pagination, lifecycle, metadata, retries, and direct target writers. Plan existing data, versions, and shared-link migration separately. Establish a process for checking Azure state before retrying a timed-out mutation. Use Debugging Your Adapters when the Google response and Azure state disagree.