> ## Documentation Index > Fetch the complete documentation index at: https://docs.tensor9.com/llms.txt > Use this file to discover all available pages before exploring further. # Blob Storage > Blob Storage APIs with Cloud Adapter. 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 | Environment | Mapping | | ------------ | ------- | | AWS | API | | Google Cloud | API | 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 | Capability | Blob Storage | AWS | Google Cloud | | ------------ | ------------ | ------- | ------------ | | API coverage | full | partial | partial | ## On AWS ### S3 | Operation | Area | Support | Depth | Notes | | --------------------------------- | ------- | -------------- | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Storage accounts and containers | Control | Supported | Common | The adapter retains storage-account and container identities and metadata while provisioning target buckets. Native bucket names follow the target naming rules. | | Append blobs | Data | Out of scope | Most usage | Append blobs are rejected by this mapping. S3 Express offers a separate append operation, but this profile does not map Azure's append-blob contract to it. Whole-object read-modify-write could lose concurrent appends. | | Blob leases | Data | Adapter-served | Most usage | A lease locks a blob for a specified period under a lease ID. The adapter persists that state and handles acquire, renew, change, release and break. | | Block blob read and write | Data | Supported | Common | Block blobs become objects. The adapter translates put, get, list and delete calls to the target's object operations. | | Index tags and Find Blobs by Tags | Data | Out of scope | Full surface | Rejected at build time: the target queries objects by key and prefix, without an equivalent query by index tags. | | Page blobs | Data | Out of scope | Full surface | Rejected at build time: page blobs require random access to 512-byte pages, while the target writes whole objects. | 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 | Operation | Area | Support | Depth | Notes | | --------------------------------- | ------- | -------------- | ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Storage accounts and containers | Control | Supported | Common | The adapter retains storage-account and container identities and metadata while provisioning target buckets. Native bucket names follow the target naming rules. | | Append blobs | Data | Out of scope | Most usage | Rejected at build time: the target cannot atomically append part of an object. A read-modify-write replacement could lose concurrent appends. | | Blob leases | Data | Adapter-served | Most usage | A lease locks a blob for a specified period under a lease ID. The adapter persists that state and handles acquire, renew, change, release and break. | | Block blob read and write | Data | Supported | Common | Block blobs become objects. The adapter translates put, get, list and delete calls to the target's object operations. | | Conditional writes on ETag | Data | Supported | Most usage | If-Match conditions use the target object's generation number to prevent writes against a changed object. | | Index tags and Find Blobs by Tags | Data | Out of scope | Full surface | Rejected at build time: the target queries objects by key and prefix, without an equivalent query by index tags. | | Page blobs | Data | Out of scope | Full surface | Rejected at build time: page blobs require random access to 512-byte pages, while the target writes whole objects. | 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](/cloud-adapter/getting-started/overview) and [configuration](/cloud-adapter/configuration/overview). Use [tuning](/cloud-adapter/tuning/overview) to understand supported request tags, [debugging](/cloud-adapter/debugging/overview) to investigate a request, and [High Fidelity Cloud Emulators](/cloud-adapter/local-testing/overview) to validate a bounded reproduction.