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:
- Does the directed mapping preserve the behavior the application requires?
- Which native resources and adapter-maintained records supply that behavior?
- Who restores those resources and records after a failure?
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 usesPutObject, 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 Run
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.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.