Skip to main content
The AWS CLI is the fastest way to prove the full request path: AWS command, Cloud Adapter endpoint, service adapter, and native target service. It is also a useful diagnostic control because it removes your application code from the test. This walkthrough uses S3. The same pattern works for another AWS service when that service page documents the operation and target environment you need.

​
Start a local adapter

This guide’s bounded example uses S3 backed by Google Cloud Storage:
1

Install or update the Tensor9 CLI

Install the customer CLI with Homebrew, then confirm the binary is available:
If tensor9 is already installed, run brew upgrade tensor9 instead of the install command.
2

Authenticate with Tensor9

A Tensor9 API key is required. Use the key issued during onboarding, or email [email protected] to request one for your organization. Do not share your account or key with another customer or organization.If your secret manager has already supplied T9_API_KEY, skip the prompt. Otherwise, enter your key at a hidden prompt in the terminal where you will run tensor9:
Check that the variable is set without printing it, then verify your Tensor9 identity:
Confirm that the reported identity belongs to the intended customer account. Do not continue if authentication fails or the account is wrong. Keep shell tracing disabled while using the key. Do not paste the key into commands, shell profiles, source files, screenshots or support messages.See Install and Authenticate for the planned license lifecycle, entitlements and credential boundaries.
3

Inspect the S3 to Google Cloud Storage mapping

Ask Tensor9 to describe the exact directed service mapping used by this guide:
Read the supported S3 operations and Google Cloud Storage limitations before starting the process. The mapping is directional: this command describes S3 requests adapted to Google Cloud Storage, not the reverse direction.
4

Prepare Google Cloud access

Authenticate with Google Cloud using its standard Application Default Credentials chain. The adapter uses that identity when it calls Google Cloud Storage.Use a dedicated test project and narrowly scoped credentials. Do not put credentials in the command line, source code, or screenshots.
5

Start the S3 service adapter

Run the S3 to Google Cloud Storage adapter as a foreground process:
Leave this terminal open. This is the current foreground launcher, not the pending Docker launcher for local development mode. It calls your actual target-cloud services; it is separate from the in-memory emulator. Acquisition and license renewal require Tensor9 authentication. Keep the endpoint local to your test.
6

Copy the listening endpoint

When the command reports its listening endpoint, copy that exact value into a second terminal:
Keep the endpoint local to the test unless you have deliberately configured network access and authentication for another machine.
7

Run one bounded S3 request

Continue with this page’s client or tool instructions. Point only S3 at T9_CLOUD_ADAPTER_ENDPOINT, then perform one operation whose Google Cloud Storage effect you can verify independently.Check both sides: read the S3-shaped response and inspect the native object or bucket in Google Cloud Storage. A successful client response alone does not prove that the target state is correct.
8

Stop the local adapter

Return to the first terminal and press Control-C. Confirm the process exits before deleting the test object or bucket with Google Cloud’s native client.If the request failed, preserve the request ID, adapter endpoint, S3 operation name, Google Cloud request ID, and any x-t9-explain-* receipt headers before stopping the process.

​
Before you begin

You need:
  • an installed AWS-origin Cloud Adapter endpoint;
  • an origin-side test identity accepted by that endpoint;
  • a configured S3 service adapter and a target bucket;
  • AWS CLI v2;
  • a unique prefix that is safe to create and delete.
Read S3 service coverage before testing. Coverage is directional and operation-specific.

​
Choose the endpoint scope

​
Set S3 for the process

AWS CLI v2 supports the AWS-standard, service-specific endpoint variable:
This applies to every S3 command in the process without redirecting STS, DynamoDB, or another AWS service. The official pattern is AWS_ENDPOINT_URL_<SERVICE>; for S3 it is AWS_ENDPOINT_URL_S3.

​
Set one command at a time

Use --endpoint-url when the endpoint should be visible on each command or when one process talks to both AWS and Cloud Adapter. Keep the URL in a Tensor9-specific variable:
Confirm the active profile without printing secrets:
AWS_REQUEST_CHECKSUM_CALCULATION=WHEN_REQUIRED keeps the first smoke test on the required S3 checksum path. If your application uses optional flexible checksums, validate those algorithms separately against the selected target profile. An explicit --endpoint-url takes precedence over AWS_ENDPOINT_URL_S3. The remaining commands use the explicit form so each network destination is visible at the call site.

​
Run a read-only request first

Start with the smallest covered read. Passing --endpoint-url on every command makes accidental calls to AWS much less likely.
If the target uses a bucket name that differs from the origin name, use the origin-facing name from the service adapter configuration. Cloud Adapter owns the name translation.

​
Exercise a complete object lifecycle

Create a small local payload, upload it, read it back, compare it, and delete only the object created by this test.
Verify the corresponding object with the target cloud’s console or CLI. The AWS-shaped success response and target resource should agree.

​
Test the translated error path

Request a key that does not exist:
Record the command timestamp, AWS error code, and message. A translated not-found response proves more than an empty list because it exercises the service adapter’s error mapping. S3 can return permission denied instead when the caller lacks permission to establish that the object is missing. The normal CLI output does not expose arbitrary response headers; use the Python SDK guide when you need structured, redacted header capture.

​
Clean up

Delete only the unique object you created:
Confirm that get-object can no longer read the current object. Versioning or soft delete can retain prior versions, delete markers, or recovery state; use a disposable unversioned target for this walkthrough or remove the created version explicitly. Remove the local temporary files separately.

​
Common problems

Use --debug only in an isolated environment. Its output can include headers, canonical requests, endpoints, and payload details that should not enter shared logs.

​
Expand the test deliberately

After the basic lifecycle passes, add only the features your application uses, such as conditional reads, metadata, pagination, multipart upload, or versioning. Test each against the target-specific behavior in the service catalog before moving application traffic. See Debugging Your Adapters, Testing Your Adapters, and Deployment.