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, andARCHIVE 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-storageand Azure CLI.
Set values
Write through the Google Cloud client
Verify Azure natively
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, orARCHIVE workflows in this route; the target profile rejects them.
Clean up
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.