Skip to main content
CDK synthesis and CloudFormation deployment are different compatibility questions. cdk synth runs locally and produces a template. cdk deploy normally calls CloudFormation and may also call STS, S3, IAM, ECR, and service APIs for bootstrap assets and deployment monitoring. Do not infer deploy compatibility because the resources inside a synthesized template have service adapters. The deployment engine itself must be reachable through a documented CloudFormation mapping, and every auxiliary API in the tool’s call graph must be covered.

​
Start a local adapter

Start with one service mapping before assessing the larger deployment call graph. The 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.

​
Inventory the deployment path

For the exact AWS CLI, CDK CLI, bootstrap stack, and library versions you use, record:
  • CloudFormation operations such as stack create, change set, describe, event polling, and delete;
  • STS and account-discovery calls;
  • bootstrap bucket reads and writes;
  • ECR calls for container assets;
  • IAM role and policy calls;
  • service-specific operations performed outside CloudFormation;
  • endpoint configuration available for each client.
Compare that list with the AWS service catalog. A missing control-plane dependency blocks the workflow even when an individual resource type is supported through another adapter.

​
Safely use synthesis today

Synthesis is useful for understanding the intended origin-cloud resources without contacting Cloud Adapter:
Review the generated template for resources, IAM statements, custom resources, assets, lookups, and context providers. Lookups can make synthesis contact AWS unless their values are already in CDK context, so verify whether your app is truly offline.

​
Build a compatibility fixture

When the complete dependency graph is covered, start with a disposable stack containing one resource and no custom resources or external assets. Retain:
  1. the synthesized template;
  2. the list of API operations observed during deployment;
  3. stack events and request identifiers;
  4. native target state;
  5. the delete result.
Test create, event polling, read-back, update with no replacement, update with replacement, failure rollback, and delete. A successful create alone is not a CloudFormation lifecycle test.

​
Endpoint routing is multi-service

One --endpoint-url affects one AWS CLI service invocation. CDK creates several service clients internally. A single S3 endpoint override does not redirect CloudFormation, STS, IAM, or ECR. Keep the routing design explicit and do not use a catch-all endpoint override unless every call it captures is intentionally supported.

​
Failure interpretation

Until your complete call graph passes, use a directly supported client or IaC guide rather than presenting synthesis as deployment evidence. Start with Terraform/OpenTofu or AWS CLI.