Skip to main content
Keep the Google Cloud Storage client and request model while Cloud Adapter stores objects in Amazon S3.
Google Cloud API requests pass through Tensor9 Cloud Adapter to AWS services.Google Cloud API requests pass through Tensor9 Cloud Adapter to AWS services.

Compatibility snapshot

The Cloud Storage to AWS profile supports core JSON object CRUD and listing, XML request re-signing, lifecycle, and versioning behavior. Google retention policies and notifications are outside the profile. Generation identifiers adapt to S3 version or ETag behavior. ARCHIVE and COLDLINE semantics differ because some S3 objects require restore before read, and compose rejects non-final parts smaller than 5 MiB. Existing object bodies, versions, and shared links are not copied automatically.

Prerequisites

  • an installed Google Cloud-origin Cloud Adapter endpoint;
  • a Cloud Storage to S3 service adapter;
  • an origin-side Google credential accepted by the endpoint;
  • an AWS runtime identity with access to one test bucket;
  • a separate read-only AWS verification profile;
  • Python 3 with google-cloud-storage and AWS CLI v2.

Set values

The API endpoint shape and origin authentication in this sample are deployment-specific placeholders. Use the exact endpoint and caller credential mode supplied by your Cloud Adapter deployment. Target AWS credentials remain adapter-owned.

Write through the Cloud Storage client

Keep endpoint construction in one client factory. Target AWS credentials do not belong in the Google Cloud application.

Verify S3 natively

Confirm content type and bytes. Do not copy a Google generation into code that expects an S3 version ID without following the documented identity translation.

Exercise a failure

Request an object name that does not exist and retain the Google API error code, HTTP status, request ID, and diagnostic headers. Also test a stale generation precondition if your application uses optimistic concurrency.

Clean up

Confirm that the current target object is no longer readable. Versioned or soft-delete-enabled targets can retain prior versions or recovery state; use an unversioned disposable target for this quickstart or remove the created version explicitly. Bucket deletion and retained target data have separate ownership.

Before production

Test listing and pagination, generation preconditions, compose part sizes, lifecycle, versioning, storage classes, retries, and uncertain writes. Plan existing data and shared-link migration separately. If the workload uses retention or notifications, do not assume this route supplies them. Read the full Cloud Storage profile and add the lifecycle to CI/CD.