Skip to main content
Your application can keep its S3 client while Cloud Adapter stores its objects in Google Cloud Storage, Azure Blob Storage, a managed S3-compatible service or MinIO. Each origin-to-target pair is a different service adapter: S3 → GCS, for example, or S3 → MinIO. The useful comparison starts with what the application does beyond reading and writing current objects: multipart uploads, versions, conditional requests, lifecycle rules and recovery can change the choice.

General trade-offs

Begin with the permitted location for object bytes and recovery copies. Then compare the S3 mappings available there, including their metadata, version, multipart and access-control behavior. The S3 service catalog defines the operations for each directed origin-to-target mapping. An S3-compatible native endpoint does not make every S3 feature available through its adapter. A new backend starts without the source data; changing configuration does not transfer objects or version history.

What the adapter changes

The same successful PutObject does not tell you how much work happened on the target. A multipart upload can create staging objects and several compose requests. A small-object workload may spend more on operations and metadata work than on stored bytes. A versioned bucket can retain data after the application deletes its current key. Separate three questions when comparing candidates:
  1. Does the directed mapping preserve the behavior the application requires?
  2. Which native resources and adapter-maintained records supply that behavior?
  3. Who restores those resources and records after a failure?
A round-tripping S3 tag is not automatically a native lifecycle or IAM selector. Likewise, a native GCS generation number does not by itself establish every S3 version-chain and delete-marker behavior. Follow the selected profile’s contract rather than inferring behavior from similar field names.
The S3-to-GCS adapter uses both version/configuration state and native GCS object data; recovery must preserve their relationship.The S3-to-GCS adapter uses both version/configuration state and native GCS object data; recovery must preserve their relationship.

Agree on recovery and operating ownership

Agree on direct-native access separately. Reading native objects for verification is different from allowing another writer to change native versions, tags or lifecycle outside the S3 path. Do not enable a second writer until its interaction with adapter-maintained state is understood. For retention-sensitive data, distinguish versioning, backups and enforced immutability. Require the exact deletion/hold contract and test the relevant identities. This article’s version probe does not establish that contract or make a legal-compliance determination.

Google Cloud

Cloud Storage

Cloud Storage is the documented Google Cloud target. It provides provider-operated object storage near the application. Cloud Adapter translates multipart, configuration and version behavior, so native operation counts and recovery state can differ from the application’s S3 request count and bucket view. For application assets, qualify object integrity, metadata and transfer behavior. For an archive, also qualify version recovery and the selected storage/lifecycle policies. These are workload and configuration choices within the GCS mapping, not different backend identities.

Assets near a Google Cloud application

An application running in Google Cloud serves images and reports. It uses PutObject, GetObject, HeadObject, byte ranges, metadata and occasional multipart uploads. Object bytes must remain in the permitted Google Cloud location. With S3 → GCS, Google operates the storage service and the adapter translates the application requests. The platform team configures placement, access and lifecycle, operates the adapter and preserves the state needed to interpret its S3-facing versions. The cost assessment should include the actual object-size distribution. Record small-object request counts, large-object transfer time, multipart staging/compose work, retries and network traffic. Include adapter CPU, memory and bandwidth. Measure completed and verified transfers rather than accepted requests. This mapping fits the workload when its documented object behavior and managed-storage controls meet the requirements. If the application requires an excluded S3 feature or direct control over storage nodes, more transfer concurrency will not address that constraint. A move to Private Kubernetes is a separate environment decision, not another backend in the Google Cloud catalog. Before cutover, copy the required objects and metadata, compare contents, account for writes arriving during the copy and move a small reader cohort. A source bucket retained for rollback becomes stale once the new target accepts writes unless the migration explicitly maintains it. Evaluation record: Google Cloud placement; current-object CRUD, ranges, metadata and multipart; S3 → GCS. Record verified behavior, complete transfer costs, storage-policy settings and recovery responsibilities before accepting the mapping for this application.

Try version recovery through S3 on GCS

This bounded experiment uses S3 → GCS as a concrete fixture, not a preferred adapter. It checks two version identities and a delete marker across an adapter restart. It does not certify retention enforcement, a full backup restore or concurrent direct-native writes. Use a dedicated GCS-backed test mapping with the S3 version-history behavior described in the profile.
1

Prepare an isolated versioned bucket

Follow the S3-to-GCS configuration example. Have the resource owner prepare an empty, versioned test bucket with no legal hold, retention lock or lifecycle expiration. This example calls its origin-facing bucket tradeoffs-media. Substitute your bucket name consistently; native bucket names must be globally unique.Reserve version-check/report.txt exclusively for this experiment. Ensure no other writer or cleanup job can change it. The restart test requires an operator-prepared durable installation. Have its owner identify the native version/marker metadata and any separate adapter state, and supply the configuration and restart procedure that preserve them. The cloud-direction configuration example alone does not establish this recovery setup. For a first object read/write trial without that fixture, use Validating Your Choice.Inspect the mapping without executing an object request:
2

Start the local adapter and configure the client

For an operator-prepared single-binary installation with its target identity and durable configuration already in place, the service-pair selection is:
This command selects the pair; it does not provision the recovery fixture. Use the installation owner’s complete launch configuration. If the owner supplies an already-running durable test deployment instead, use its endpoint and approved restart procedure rather than starting another instance. In a second terminal, use that endpoint and the origin credential profile accepted by your installation:
AWS_ENDPOINT_URL_S3 configures supporting S3 clients in this process and its children. The script below instead passes the endpoint directly to one client; replace its placeholder with the same printed value. Credentials for native GCS access belong to the adapter, separately from the S3 client’s origin identity.
3

Write two versions and verify the deleted current view

Save this as s3-version-check.py. It records only this test’s version IDs in s3-version-check.json. Do not rerun write over an existing test; inspect and clean it up first.
Run python s3-version-check.py write. Expected: two distinct named versions return their original bytes, while an unversioned read returns not found. An authentication error is not an acceptable substitute for that result. The GetObject and DeleteObject references describe the version-specific request parameters.
4

Restart without discarding durable state

Follow the owner’s restart procedure. For your local single-binary process, stop it with Control-C, then restart with the same complete launch configuration, identity and durable state. Do not stop a shared deployment. Update the explicit client endpoint if the listening address changes. Run python s3-version-check.py verify without rewriting the objects or regenerating version IDs.Expected: the same two IDs still read A and B, and the current view stays deleted. If not, preserve the record and inspect both native object state and adapter version metadata through Debugging Your Adapters. A native object listing alone cannot demonstrate the application’s version view. Explain can help identify the request path; x-t9-explain: true executes a request, so do not replay writes just to collect an explanation.
5

Remove only this experiment's versions

After saving the evidence, run python s3-version-check.py cleanup. Verify that no versions or marker remain for this key. If a write timed out or failed before its version ID was recorded, inspect that exact key’s history and account for it before declaring cleanup complete.Removing a delete marker can reveal an older version, so do not use this procedure on a shared key. Let the resource owner remove the now-empty test bucket and any dedicated infrastructure. Stop the local adapter and deactivate the virtual environment. Do not delete shared adapter state.

Microsoft Azure

Blob Storage

The native target is Azure Blob Storage. Cloud Adapter maps S3 objects and multipart operations to blobs and block operations. It is a candidate when object data belongs beside an Azure application and the listed S3 behavior meets that workload. The account/container layout affects access, shared capacity and recovery. Qualify object metadata, conditional requests, multipart completion and version recovery using the application’s real request shapes. Do not infer S3 configuration support from a similarly named Blob feature. For a report service, measure small-file operation work as well as large multipart transfers; for a versioned archive, retain and test the state needed to interpret S3 versions. Blob places storage infrastructure with the provider. If the required controls fall outside its configuration boundaries, assess a separately permitted Private Kubernetes environment. That changes the target environment and operating responsibilities; it does not introduce another backend into the Azure catalog.

DigitalOcean

Spaces

DigitalOcean Spaces supplies managed S3-compatible object storage. The adapter signs requests for the target; the directed profile still decides which object, version and multipart behaviors reach the application. This is a candidate for application assets and object data that must stay in the permitted DigitalOcean location. Compare the workload’s exact requests with the profile, particularly bucket settings, encryption, notification routing and version recovery. Calculate request, transfer, retained-version and storage costs from real object sizes rather than treating protocol compatibility as an operating-cost result. Spaces is the documented backend for this target environment. Qualify the application’s required behavior and verify copied data before changing endpoints. If it does not meet a hard requirement, revisit that requirement or evaluate a separately permitted target environment.

OCI

OCI Object Storage

OCI Object Storage is the native managed storage target. It fits OCI-local object workloads whose S3 calls match the listed mapping. Target identity, bucket placement and native capacity policies remain OCI configuration decisions. Test metadata, byte ranges, multipart uploads and the version/delete-marker operations the application uses. Include retained history, request counts, retries and migration transfer in the comparison. A successful current-object read does not establish historical-version recovery or retention enforcement. The catalog names one backend in OCI. The meaningful choices within it are the supported native configuration and operating policies. If those controls cannot meet the recovery objective, evaluate a separately permitted target environment rather than assuming another OCI store has the same S3 mapping.

Scaleway

Object Storage

Scaleway Object Storage is the documented backend in Scaleway. Its managed storage infrastructure and native S3 multipart/version mechanics can fit object workloads whose required calls match the profile. Class selection, lifecycle and access policies must still meet the application’s retrieval and recovery requirements.

A versioned media archive in Scaleway

A media service keeps large files and must recover earlier versions after an accidental replacement. The customer requires Scaleway EU placement. Evaluate the S3 → Scaleway Object Storage mapping against those requirements. Scaleway supplies native S3 multipart and version mechanics for the adapter. Test the recovery path: naming an old version, reading it, copying it to the intended destination and restoring the desired current view. The version-recovery probe in the Google Cloud section illustrates the application assertions; prepare a Scaleway-specific fixture and follow this mapping’s contract before applying them here. The cheapest stored gigabyte is not enough to choose an archive policy. Calculate retrieval frequency, operation counts, minimum storage duration where applicable, staging, recovery time and migration traffic. Do not infer a retrieval delay or retention guarantee from the word “archive”; use the selected native class and location’s documented behavior. Scaleway owns the managed storage infrastructure while your team configures its exposed policies and classes. Check those controls against the archive’s recovery requirements. Accepting S3 requests does not give the target AWS’s durability figures. Use the selected service’s actual protection and recovery contract. Migration must inventory the historical versions the application needs alongside each key’s current body. Preserve relevant metadata and delete-marker meaning. Validate named historical versions before removing source access, and agree on the rollback horizon before applying lifecycle policies that could delete that history. Evaluation record: Scaleway EU placement; large multipart media; recoverable version history; S3 → Scaleway Object Storage. Record retrieval costs, version recovery and infrastructure responsibilities. The application owner signs off the old-version recovery test; the platform owner records lifecycle configuration, capacity and budget obligations.

Private Kubernetes

MinIO capabilities and operating responsibilities

MinIO keeps objects on customer-supplied disks. The adapter forwards the listed object, copy, tagging and multipart operations to its S3 endpoint. Versioned buckets can retain history; disk layout, parity and failure-domain placement determine the deployment’s recovery behavior. This option fits local or disconnected object-storage requirements when the deployment can provide the required usable capacity and recovery procedures. Runtime S3 bucket-configuration, object ACL, legal-hold and retention calls are outside the described adapter contract. Configure supported native policies through the deployment’s control path. The adapter also does not enforce S3 presigned-signature expiry; use the documented native access path for time-limited direct access. These are operation and security boundaries to check before sizing. A backend’s native feature set does not automatically become the adapter’s API contract.

Capacity and recovery choices within MinIO

Compare permitted storage layouts by usable capacity after parity, the drive and node failures they tolerate, rebuild headroom and recovery time. Include cluster capacity, disks and operator time in the budget. Capacity already purchased for Kubernetes still has competing users. Losing a storage node during a rebuild is a different test from stopping a stateless application pod. An asset-serving workload emphasizes transfer rates, object-size distribution, metadata and multipart integrity. A versioned archive also needs space for retained history and a tested path to restore a named old version. Exercise those application requirements on the actual layout before choosing its capacity and policies. Neither workload gains a durability guarantee merely from S3 protocol compatibility. These are deployment choices within the MinIO mapping. If the organization instead permits a managed public-cloud target, return to that environment’s catalog and assess its directed adapter separately, including migration and changes in recovery ownership.

Storage on disconnected customer infrastructure

For a customer that prohibits object bytes leaving its disconnected infrastructure, public GCS is not an eligible alternative. S3 → MinIO can be deployed inside that infrastructure; its directed mapping and operating model must still meet the application requirements. This excludes an option on placement grounds without ranking the services for other environments. This is a placement decision followed by an operating-model decision. It is not evidence that private storage will be faster or cheaper. Define drive and node placement, usable capacity, rebuild requirements, network reachability, backup location and upgrade ownership before sizing the application. Test loss of a disk and a node under the chosen deployment’s permitted procedures. Separately test restoration of both object data and the adapter state needed to interpret it. A replica in the same failure domain is not an independent recovery copy, and an intact object store does not prove that its S3-facing configuration has been restored. Import data over the permitted path, keep a verified inventory and rehearse recovery before retiring the original copy. If policy later permits managed storage, compare its costs, controls and operating responsibilities with the migration work and revised network/access model. Do not treat a configuration change as an offline data-transfer procedure. Constraint record: disconnected placement excludes public GCS. Evaluate S3 → MinIO against the required API behavior, capacity, recovery and local operating capabilities. Record the owner of disks, rebuilds, backups, certificates and recovery. A later placement-policy change would reopen the comparison; it would not itself decide the adapter.

Next steps

Once placement and recovery behavior fit, optimize the measured transfer workload and supported lifecycle policy. Keep a migration record that includes bytes, versions, configuration, operating owners and the requirement that would cause you to choose another mapping. Next, follow Tuning AWS S3 for bounded concurrency experiments, storage-policy examples and native verification.