Blob Storage

This page describes how Blob Storage maps to services in the environment where the application runs. Some profiles adapt origin API calls; others translate infrastructure or document target-native behavior.

​

Supported environments

API means the profile adapts origin API behavior. Infrastructure means the profile changes provisioned resources or documents a target-native alternative without promising an origin API endpoint. Check the operation and capability tables for the behavior your application depends on.

​

How the targets compare

Each row compares a capability of Blob Storage with its adaptation on each target. A dash means this profile does not state the capability for that target.

​

Cloud Adapter

​

On AWS

​

S3

S3 buckets and objects replace Azure containers and block blobs. Your application keeps its Blob Storage calls; the adapter translates reads, writes, lists and deletes to S3 operations. The adapter also stores lease state and handles lease acquisition, renewal and release because S3 has no blob-lease API.

​

Requests and lease ownership

Blob reads and writes pass through the adapter, which checks lease ownership before issuing the target object request. Lease state persists separately from the object. Restrict direct target writes for applications that rely on leases: a writer bypassing the adapter also bypasses that check.

​

Moving objects

Create the target buckets, copy the required object content and metadata, then coordinate writers before cutover. Check expired and renewed leases, stale ETag conditions, and retried writes. Creating the storage resources does not transfer existing objects or lease state.

​

Compatibility differences

Append blobs and page blobs are rejected at build time. An append must be atomic, while a page blob requires writes to individual 512-byte pages. Replacing either with whole-object reads and writes could lose concurrent changes.

​

On Google Cloud

​

Cloud Storage

Cloud Storage buckets and objects replace containers and block blobs. Conditional writes use the target object’s generation number to enforce the original ETag precondition. The adapter stores lease state and handles lease operations.

​

Requests and lease ownership

Blob reads and writes pass through the adapter, which checks lease ownership before issuing the target object request. Lease state persists separately from the object. Restrict direct target writes for applications that rely on leases: a writer bypassing the adapter also bypasses that check.

​

Moving objects

Create the target buckets, copy the required object content and metadata, then coordinate writers before cutover. Check expired and renewed leases, stale ETag conditions, and retried writes. Creating the storage resources does not transfer existing objects or lease state.

​

Compatibility differences

Append blobs and page blobs are rejected at build time because the target cannot perform their partial-object writes. A read-modify-write workaround could lose concurrent appends.

​

Existing data and credentials

Selecting a backend does not copy existing data, credentials or access policies. Plan and verify migration separately before changing an application’s endpoint. Do not assume an identifier, credential or encrypted value from the origin service works unchanged on the target.

​

Configure, tune and debug

Start with setup and configuration. Use tuning to understand supported request tags, debugging to investigate a request, and High Fidelity Cloud Emulators to validate a bounded reproduction.