> ## 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. # What is Cloud Adapter? > Use familiar cloud APIs with services in another environment. **Cloud Adapter serves the API of the cloud your software already uses.** If your application was written for AWS, you can direct its AWS SDK (or the AWS CLI)at a Cloud Adapter endpoint and continue making supported AWS service calls. The adapter uses a selected service in the target environment to carry them out and answers in the AWS API's response format. Think of the endpoint as the place your origin-cloud client talks to, not as a new SDK you must adopt. An S3 client still sends `PutObject`; when S3 is mapped to Google Cloud Storage, Cloud Adapter translates that S3 request into a GCS API call and stores the object in Cloud Storage. A DynamoDB client still sends `GetItem`; when DynamoDB is mapped to provisioned Azure Cosmos DB, the adapter retrieves the item there and returns DynamoDB-typed attributes. You choose the backend, configure both sides' identities, and route the origin client to the endpoint. ![Tensor9 Cloud Adapter adapts cloud APIs to services in another environment.](https://mintcdn.com/tensor9/ufP2gYsEkScmc1Bt/images/cloud-adapter-early-access/diagrams/cloud-adapter-light.png?fit=max\&auto=format\&n=ufP2gYsEkScmc1Bt\&q=85\&s=6e69d0b9e2905414ce48ac4fa0c1a77a) This works with command-line tools as well as application code. For example, after you configure the endpoint and resources, `aws s3api put-object --endpoint-url "$T9_CLOUD_ADAPTER_ENDPOINT" ...` is still an AWS CLI command. Set `AWS_ENDPOINT_URL_S3` to route S3 commands process-wide, or `AWS_ENDPOINT_URL_DYNAMODB` for DynamoDB commands; other AWS services keep their own endpoints. See the [overview's two complete CLI examples](https://docs.tensor9.com/cloud-adapter-early-access.md#try-it-with-the-aws-cli) and the [AWS CLI guide](https://docs.tensor9.com/cloud-adapter-early-access/guides/aws-cli.md). The promise is an **origin API for documented operations**, not every feature of the origin cloud. Check the directed [S3](https://docs.tensor9.com/cloud-adapter-early-access/service-catalog/aws/databases-storage/s3.md#on-google-cloud) and [DynamoDB](https://docs.tensor9.com/cloud-adapter-early-access/service-catalog/aws/databases-storage/dynamodb-table.md#on-azure) service profiles for coverage and behavioral differences. Cloud Adapter also includes agents for [Support](https://docs.tensor9.com/cloud-adapter-early-access/support/agents.md) and [Operations](https://docs.tensor9.com/cloud-adapter-early-access/operations/overview.md). They help assess configuration, investigate request evidence and coordinate bounded work. Your team controls their tools, evidence access, model processing and resource-change permissions. Bringing your own agents is optional. ## What problems does Tensor9 Cloud Adapter solve? * **Cloud service portability:** Keep an origin-cloud API while selecting a backend in another cloud or environment. * **Application continuity:** Keep the origin CLI or SDK and its request and response model for operations covered by the selected service adapter. * **Target-native operation:** Store data and perform work in the target service rather than maintaining a separate application integration for it. * **Consistent operations:** Configure, deploy, update, tune and debug service adapters through one Cloud Adapter workflow. * **High-fidelity testing:** Exercise cloud API behavior locally before validating cloud-specific identity, networking, quota and lifecycle behavior against the target service. ## What makes the approach different? * **Adaptation, not abstraction:** Your application continues to use its existing cloud interface instead of being rewritten around a new portability API. * **Service-specific contracts:** Each mapping documents its backends, supported behavior, configuration and differences. Direction matters: an origin-to-target mapping is not automatically reversible. * **Target-native choices:** Tuning lets a supported origin request carry target-specific decisions without changing the application's primary API model. * **Explainable behavior:** Diagnostic response headers, service references and `tensor9 explain` help show how a request is handled and where to investigate a failure. ## How is it different from Tensor9 BYOC? Cloud Adapter focuses on cloud service APIs and their backends. You choose the adapters, configuration and deployment shape needed by your application. [Tensor9 BYOC](https://docs.tensor9.com/byoc/index.md) delivers and operates an entire software product inside a customer's infrastructure. It adapts the full application stack and includes the customer installation and operational model around it. ## What scenarios is Cloud Adapter useful for? * **Move a workload across clouds:** Keep the application's origin SDK while selected services run in the destination cloud. * **Meet regional or sovereignty requirements:** Place service data and operations in an environment selected for the workload. * **Use a different managed-service backend:** Retain the origin API while choosing a backend that fits the target environment's operational model. * **Develop and test locally:** Run bounded, repeatable tests with [High Fidelity Cloud Emulators](https://docs.tensor9.com/cloud-adapter-early-access/local-testing/overview.md), then verify target-cloud behavior with isolated resources. * **Support cloud-aware tools:** Point CLIs, SDKs and infrastructure tools at a Cloud Adapter endpoint when their required services and operations are supported. Start with [how Cloud Adapter works](https://docs.tensor9.com/cloud-adapter-early-access/how-it-works.md), then choose a direction in [Getting Started](https://docs.tensor9.com/cloud-adapter-early-access/getting-started/overview.md). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.