Amazon Web Services Service Adapters

Cloud Adapter lets an application keep using supported AWS APIs while the corresponding data and managed services live in another environment. The application continues to use its AWS SDK, CLI, infrastructure tool, request model, and response model. Cloud Adapter receives the AWS-shaped request, applies the selected service profile, and calls the configured target service with a target-cloud identity.

AWS API requests pass through Tensor9 Cloud Adapter to services in another environment.

This section treats Amazon Web Services as the origin API. For example, an application can issue an S3 PutObject request while Cloud Adapter stores the object in Google Cloud Storage. When AWS is the destination for an application using Google Cloud or Azure APIs, start from that origin cloud’s catalog instead.

Start with the service catalog

Open the AWS Service Catalog and find the AWS service your application calls. Each row provides:

the exact Tensor9 Service name used by tensor9 explain and tensor9 adapt svc run;
the service category;
the environments with a directed mapping;
whether the mapping adapts application API calls, infrastructure, or both.

A target shown in the catalog means a directed service profile exists. It does not mean every AWS operation or behavioral detail is identical. Open the linked service page and check the target-specific operation and capability tables before choosing a route.

Mapping direction matters. aws::1.0.0::s3 to google::1.0.0::gcs describes an application using the S3 API with Google Cloud Storage as its backend. It says nothing about applications using the Google Cloud Storage API.

A concrete S3 example

The canonical AWS-origin example uses these service names:

Origin:  aws::1.0.0::s3
Backend: google::1.0.0::gcs

Inspect the mapping before starting a process:

tensor9 explain \
  -origin aws::1.0.0::s3 \
  -target google::1.0.0::gcs \
  -fmt Human

Then follow the AWS to Google Cloud quickstart to start the adapter, point only the S3 client at its endpoint, write an object, read it through the S3 API, and verify the native object in Google Cloud Storage. That final native check is important. An S3-shaped success response proves the origin interface worked; inspecting the Google Cloud object proves the request reached the intended backend and produced the expected target state.

What stays the same

For a supported operation, application code continues to use the AWS-facing interface:

AWS SDK request and response types;
AWS CLI commands and service-specific endpoint settings;
service identifiers such as bucket names, table names, and object keys as defined by the selected profile;
AWS-shaped success and service-error responses;
the retry and timeout configuration in the application’s AWS client.

Point only the AWS service under test at Cloud Adapter. For S3, use AWS_ENDPOINT_URL_S3 or set the endpoint on one S3 client instance. Do not redirect every AWS client in the process unless the deployment intentionally serves each of those services.

What changes

Cloud Adapter owns the target-side execution path. It translates the supported request, uses the configured target identity, calls the native target API, and maps the result back to the AWS-facing response. The target service still determines native quotas, consistency, regional availability, encryption facilities, and operational limits. These differences are part of the service contract, not implementation details to ignore. For each operation your application depends on, verify:

Area	Question to answer
Operations	Is the exact create, read, update, delete, list, or administrative call covered?
Identifiers	How are AWS ARNs, URLs, versions, generations, or resource names represented?
Consistency	When does a successful write become visible to a read or list?
Errors	Which AWS error code and retry signal does a target failure produce?
Limits	Which target quota, payload, batch, or pagination limit applies?
Identity	Which target principal executes the native call, and which origin caller can reach the endpoint?

Authentication has two sides

The application authenticates to the AWS-shaped Cloud Adapter endpoint using the caller mode configured for the deployment. Separately, Cloud Adapter uses a target-cloud workload identity to call the backend. Redirecting an SDK endpoint changes the network destination; it does not grant either identity new permissions. Keep target credentials inside the adapter environment. Application code should not receive the Google Cloud, Azure, Scaleway, OCI, or Kubernetes credential used for native execution.

Test before connecting the workload

Use one operation with a small, uniquely named resource and an independently observable target effect. Capture the origin request ID, origin-shaped response, target request ID, and native target state. Include an expected failure so you understand how authorization, missing resources, or invalid input appears to the AWS client. For a local process, start with Testing Your Adapters. For a route-specific walkthrough, choose an AWS quickstart. If a request does not behave as expected, use tensor9 explain and the diagnostic response headers before changing application code.

Browse AWS services

Find canonical service names, target environments, and service-specific behavior.

Try S3 to Google Cloud Storage

Run a bounded object-storage request and verify both API response and target state.

Configure Cloud Adapter

Define the selected service mappings, identities, networking, and backend settings.

Debug a request

Separate endpoint, policy, adaptation, and target-service failures.

Tensor9 Cloud Adapter

How It Works

Getting Started

Configuration

Deployment

Operations

Tuning

Debugging

Testing