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.

​
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 Operations.