> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tensor9.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Amazon Web Services Service Adapters
> Use AWS service APIs while Cloud Adapter executes supported operations in another environment.
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.
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](/cloud-adapter/service-catalog/aws/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:
```text theme={null}
Origin: aws::1.0.0::s3
Backend: google::1.0.0::gcs
```
Inspect the mapping before starting a process:
```bash theme={null}
tensor9 explain \
-origin aws::1.0.0::s3 \
-target google::1.0.0::gcs \
-fmt Human
```
Then follow the [AWS to Google Cloud quickstart](/cloud-adapter/getting-started/aws-to-google-cloud) 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](/cloud-adapter/local-testing/testing-your-adapters). For a route-specific walkthrough, choose an [AWS quickstart](/cloud-adapter/getting-started/overview). If a request does not behave as expected, use [tensor9 explain](/cloud-adapter/debugging/explain) and the [diagnostic response headers](/cloud-adapter/debugging/response-headers) before changing application code.
Find canonical service names, target environments, and service-specific behavior.
Run a bounded object-storage request and verify both API response and target state.
Define the selected service mappings, identities, networking, and backend settings.
Separate endpoint, policy, adaptation, and target-service failures.