- Coverage by target cloud
- How the targets compare
- On Google Cloud
- On Azure
- On OCI
- On Private Kubernetes
Coverage by target cloud
How the targets compare
Each row compares a capability of S3 with its adaptation on each target. A dash means this row is not stated for that target.Max adaptation
Infrastructure-only adaptation
On Google Cloud
S3 requests in the customer environment
The application continues using the S3 API. The Tensor9 adapter runs in the customer environment and sends object requests to Google Cloud Storage. It also serves bucket creation, deletion, listing, and configuration through a persistent bucket store. Google Cloud Storage stores the objects; Tensor9 operates the adapter and its bucket-management service.Request flow
Object requests use the target storage service. Bucket settings persist separately and are applied to the target resource.
Object requests
Core GetObject, HeadObject, PutObject, CopyObject, DeleteObject, and listing requests use GCS’s S3-interoperable XML endpoint with target credentials. Batch deletion sends per-object deletes and returns S3 Deleted/Error entries. Object tags are encoded in reserved GCS object metadata and reconstructed as S3 tagging documents. The object data stays in GCS; the bucket store does not hold object bodies.Bucket creation and configuration
Each S3 bucket has a durable record containing its name, owner, requested configuration, and target reference. For a bucket namedbucket-name, the S3-facing identifier is arn:aws:s3:::bucket-name; the target resource is a GCS bucket. ListBuckets returns the caller’s buckets, and configuration reads use the stored request state.
A configuration worker applies the stored settings to the target. CreateBucket waits for the target bucket to be ready before returning success, so an immediate object write does not race bucket creation. DeleteBucket waits for removal and returns BucketNotEmpty if objects prevent deletion. A lifecycle update also waits for target application. For other configuration changes, a successful read of the new setting describes stored configuration; it does not imply every target-side change has already completed.
Versions and multipart uploads
GCS multipart uploads use temporary objects for individual parts. Completion calls the GCS JSON compose API to form the final object. At Max, the adapter retains part checksums to supply S3’s composite multipart ETag and maintains the S3 version history and delete markers that differ from native GCS generations. A deployment that only forwards object requests instead exposes the native generation model and compose ETag. ListMultipartUploads and UploadPartCopy remain outside the listed mapping.Target configuration
Bucket versioning, tagging, lifecycle and encryption settings are managed through runtime S3 calls. Lifecycle translation supports the rules listed in the feature comparison: prefix-scoped, relative-age expiration and transitions to STANDARD_IA or ONEZONE_IA, both mapped to Nearline. Unsupported date, filter, noncurrent-version and archival-transition forms return an error rather than a different retention or cost policy. Encryption uses Google-managed keys, Cloud KMS customer-managed keys or customer-supplied keys as applicable; DSSE-KMS and S3 Bucket Keys have no direct equivalent.Placement and operation
GCS provides strong read-after-write consistency and designs for 99.999999999% annual durability. Region, dual-region or multi-region placement controls where the provider stores the data. Cross-bucket replication uses Storage Transfer Service rather than the S3 replication-rule engine. Object notifications go to Pub/Sub; routing to other destination types requires downstream integration. Tensor9 operates the bucket-management adapter, while Google operates object storage.Compatibility limits
Bucket policy is unsupported at every adaptation tier. Object ACL, retention/legal-hold, S3 Select and RestoreObject APIs remain outside the listed S3 endpoint. Native GCS features such as Bucket Lock, Requester Pays and Autoclass must be assessed with their own configuration and semantics; native availability does not turn them into unrestricted S3 API equivalents.Migration and leaving the adapter
A newly provisioned target bucket starts empty. Copy existing objects and required versions with a migration tool or a coordinated dual-write, then verify object data and application reads before switching. Preserve version history through the S3 API when the application depends on S3 version identifiers or delete markers. Leaving the Max adapter requires moving bucket configuration as well as object data. Apply the retained settings to native target resources, resolve any S3-specific version metadata, and move clients to the target’s own API. Keep the adapter and its persistent state until the application no longer depends on those S3 behaviors.On Azure
S3 requests in the customer environment
The application continues using the S3 API. The Tensor9 adapter runs in the customer environment and sends object requests to Azure Blob Storage. It also serves bucket creation, deletion, listing, and configuration through a persistent bucket store. Azure Blob Storage stores the objects; Tensor9 operates the adapter and its bucket-management service.Request flow
Object requests use the target storage service. Bucket settings persist separately and are applied to the target resource.
Object requests
Azure Blob uses its own API, so the adapter translates S3 requests, headers, XML results and errors into Blob operations. It streams reads and writes, maps object tags to Blob Index Tags, and handles batch deletion as individual blob deletes. CopyObject downloads and uploads the object rather than using a server-side copy. Flat listing supports prefixes and pagination; delimiter/CommonPrefixes grouping is outside the listed mapping.Bucket creation and configuration
Each S3 bucket has a durable record containing its name, owner, requested configuration, and target reference. For a bucket namedbucket-name, the S3-facing identifier is arn:aws:s3:::bucket-name; the target resource is a Blob container in a selected storage account. ListBuckets returns the caller’s buckets, and configuration reads use the stored request state.
A configuration worker applies the stored settings to the target. CreateBucket waits for the target bucket to be ready before returning success, so an immediate object write does not race bucket creation. DeleteBucket waits for removal and returns BucketNotEmpty if objects prevent deletion. A lifecycle update also waits for target application. For other configuration changes, a successful read of the new setting describes stored configuration; it does not imply every target-side change has already completed.
Versions and multipart uploads
Multipart uploads store parts as Azure blocks and commit a block list at completion. Max retains the part checksums and S3 version metadata needed for composite multipart ETags, S3 version IDs and delete markers. The simpler request-translation path uses Azure’s native version and completion-ETag behavior instead. Single-part writes compute the content MD5 and persist it as Blob Content-MD5. Azure tag-character restrictions still apply, including rejection of @ and non-ASCII characters.Target configuration
The adapter stores per-bucket configuration and reconciles each bucket to a container. Several Azure settings belong to the storage account, including region, redundancy, native versioning and default encryption; a container cannot independently choose them. Shared-account configuration must be planned for all buckets using that account. S3 lifecycle settings use the supported target mappings, and unsupported conditions must not change retention behavior silently. Max supplies S3 metadata where native account-level behavior alone is insufficient.Placement and operation
Azure provides strong consistency. Its documented durability depends on redundancy: 11 nines for LRS, 12 for ZRS, and 16 for GRS or GZRS. Choose the account region and redundancy to meet the customer’s placement and recovery needs. A bucket’s S3 location field does not relocate the storage account. Tensor9 operates the adapter and persistent bucket state; Microsoft operates Blob Storage.Compatibility limits
Bucket policy remains unsupported. The listed object API still has copy-source conditional and hierarchical-listing limits, and suffix or multiple byte ranges use a full-download fallback. A single PutObject is limited to 5000 MiB on this path. Azure has no S3 Requester Pays or direct One Zone storage-class equivalent. Object retention and legal-hold capabilities must be evaluated separately from the runtime APIs this mapping serves.Migration and leaving the adapter
A newly provisioned target bucket starts empty. Copy existing objects and required versions with a migration tool or a coordinated dual-write, then verify object data and application reads before switching. Preserve version history through the S3 API when the application depends on S3 version identifiers or delete markers. Leaving the Max adapter requires moving bucket configuration as well as object data. Apply the retained settings to native target resources, resolve any S3-specific version metadata, and move clients to the target’s own API. Keep the adapter and its persistent state until the application no longer depends on those S3 behaviors.On OCI
S3 requests in the customer environment
The application continues using the S3 API. The Tensor9 adapter runs in the customer environment and sends object requests to OCI Object Storage. It also serves bucket creation, deletion, listing, and configuration through a persistent bucket store. OCI Object Storage stores the objects; Tensor9 operates the adapter and its bucket-management service.Request flow
Object requests use the target storage service. Bucket settings persist separately and are applied to the target resource.
Object requests
Object requests use OCI’s Amazon S3 Compatibility endpoint. The adapter changes the endpoint and signs with the customer’s OCI S3-compatible access and secret keys. Core reads, writes, copies, deletes and multipart uploads use the provider API. Object bodies remain in OCI Object Storage, while the adapter stores bucket configuration separately.Bucket creation and configuration
Each S3 bucket has a durable record containing its name, owner, requested configuration, and target reference. For a bucket namedbucket-name, the S3-facing identifier is arn:aws:s3:::bucket-name; the target resource is an OCI Object Storage bucket. ListBuckets returns the caller’s buckets, and configuration reads use the stored request state.
A configuration worker applies the stored settings to the target. CreateBucket waits for the target bucket to be ready before returning success, so an immediate object write does not race bucket creation. DeleteBucket waits for removal and returns BucketNotEmpty if objects prevent deletion. A lifecycle update also waits for target application. For other configuration changes, a successful read of the new setting describes stored configuration; it does not imply every target-side change has already completed.
Versions and multipart uploads
OCI provides native multipart uploads and accepts a versionId on object reads, metadata reads and deletion. Its compatibility endpoint does not provide the S3 version-listing behavior used by the application. At Max, the adapter retains the version and deletion metadata needed by S3-addressed object operations. ListObjectVersions remains outside this mapping; maintaining version metadata does not add that API. Native multipart operations retain the provider’s behavior.Target configuration
Runtime bucket configuration is stored by the adapter and applied through the target bucket-management design. Native OCI bucket settings provide lifecycle, encryption, replication and retention. Encryption can use provider-managed, Vault-managed or customer-supplied keys; DSSE-KMS and S3 Bucket Keys have no direct equivalent. OCI tags apply to buckets; object tagging is outside the listed mapping. Retention rules combine time-based retention with optional locking and do not provide an independent S3 legal-hold object.Placement and operation
OCI provides strong read-after-write consistency and designs for eleven-nines durability. It replicates across three availability domains, or three fault domains in a single-domain region. Cross-region replication targets a preexisting destination bucket. Object events use OCI Events. Tensor9 operates the bucket-management adapter, and Oracle operates the object store.Compatibility limits
Bucket policy is unsupported at every tier. OCI’s compatibility endpoint has no configurable CORS; its fixed response is not an S3 CORS rule set. Website hosting and Requester Pays have no direct OCI Object Storage equivalent. Presigned access uses OCI Pre-Authenticated Requests outside this S3 adapter path. The API table identifies operations that remain unavailable despite native storage features.Migration and leaving the adapter
A newly provisioned target bucket starts empty. Copy existing objects and required versions with a migration tool or a coordinated dual-write, then verify object data and application reads before switching. Preserve version history through the S3 API when the application depends on S3 version identifiers or delete markers. Leaving the Max adapter requires moving bucket configuration as well as object data. Apply the retained settings to native target resources, resolve any S3-specific version metadata, and move clients to the target’s own API. Keep the adapter and its persistent state until the application no longer depends on those S3 behaviors.On Private Kubernetes
S3 on the customer’s own storage
The application uses its S3 client to reach the Tensor9 adapter. The adapter signs requests with the customer’s MinIO credentials and forwards the supported operations to MinIO’s S3 endpoint. Tensor9 deploys and operates MinIO inside the appliance, including in disconnected environments. Objects remain on the customer’s disks.
Object operations
The adapter forwards the listed reads, writes, listings, deletes, server-side copies and multipart uploads. Versioned buckets also support version listing. Object tags are stored as MinIO object tags, so MinIO can use them in its lifecycle and access-policy conditions. MinIO’s broader API does not determine what this endpoint accepts. The adapter rejects object ACL requests, bucket-policy requests, S3 Select, Glacier restore and runtime retention or legal-hold calls. MinIO implements Object Lock, including GOVERNANCE and COMPLIANCE retention and independent legal holds; configure those features directly on MinIO.Consistency and recovery
MinIO provides strict read-after-write and list-after-write consistency. A completed write is visible to subsequent reads and listings. MinIO splits objects into data and parity shards across drives. Parity lets it reconstruct missing or damaged shards while enough drives remain available. Failure tolerance depends on the configured parity and the placement of drives across nodes. Read and write availability have separate quorum requirements: recovering data after an outage does not guarantee that writes can continue throughout it. MinIO checks reads with HighwayHash and can repair detected corruption from surviving shards. Tensor9 operates recovery and monitors the deployment; durability depends on its hardware and layout. There is no MinIO durability percentage or availability SLA to substitute for that design. See MinIO’s erasure-coding documentation for parity and quorum requirements.
