> ## 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.

# Step Functions

> Step Functions APIs with Cloud Adapter.

Preview

This page describes how Step Functions maps to services in the environment where the application runs, including backend choices, supported operations and service-specific behavior.

## Supported environments

* Akamai
* Azure
* DigitalOcean
* Google Cloud
* OCI
* Private Kubernetes
* Scaleway

Check the operation and capability tables for the behavior your application depends on. A supported environment does not imply that every operation of the origin service is available.

## How the backends compare

Each row compares a capability of Step Functions with its adaptation on each backend.
A dash means this profile does not state the capability for that backend.

### Cloud Adapter

| Capability | Step Functions | Akamai, Azure, DigitalOcean, Google Cloud, OCI, Private Kubernetes, and Scaleway · Temporal (Self-Hosted) | Azure · Azure Durable Functions | Azure, Google Cloud, OCI, and Private Kubernetes · Temporal Cloud (Managed) | Google Cloud · Cloud Workflows |
| - | - | - | - | - | - |
| Execution engine | Step Functions interprets ASL | a generic Tensor9-maintained Temporal workflow interprets Standard executions; Express runs separately in the adapter | - | a generic Tensor9-maintained Temporal workflow interprets Standard executions; Express runs separately in the adapter | - |
| Execution state | AWS holds state and history | self-hosted Temporal holds native history; the adapter retains AWS identities and public records | - | Temporal Cloud holds native history in the namespace region; the adapter retains AWS identities and public records | - |
| Activities and callbacks | AWS hosts Activity queues and accepts task tokens | the adapter serves Activity queues and durable token completion; Temporal activities perform internal service calls | - | the adapter serves Activity queues and durable token completion; Temporal activities perform internal service calls | - |
| Service integrations | optimized and SDK integrations with AWS services | only supported service mappings and invocation patterns in the deployment | - | only supported service mappings and invocation patterns in the deployment | - |
| Execution debugging | AWS console, CloudWatch Logs and X-Ray | Temporal Web UI and deployment logs; the AWS graph and X-Ray tracing are not reproduced | - | Temporal Web UI and deployment logs; the AWS graph and X-Ray tracing are not reproduced | - |
| Capacity | service quotas govern concurrency | cluster, database and worker capacity govern throughput; the deployment operator maintains them | - | namespace and worker capacity govern throughput; customer billing covers Temporal Cloud and worker compute | - |
| API coverage | full | partial | partial | partial | partial |
| Execution engine · what runs the state machine | the Step Functions service interprets the Amazon States Language definition | - | a Tensor9-maintained orchestrator function on Azure Functions interprets the same definition, one Durable Functions orchestration per Standard execution; an Express execution runs inline in the adapter | - | Cloud Workflows runs workflow modules the adapter prepares from the definition per revision, with ASL data and expression semantics from an adapter helper the workflow calls; an Express execution runs inline in the adapter |
| Execution state · where progress is checkpointed | held by the service | - | checkpointed in a task hub in an Azure Storage account; an execution survives a restart of the function app or of the adapter | - | held by Cloud Workflows per execution; the adapter keeps the execution's identity, input and outcome |
| Long-running executions · Wait states and timeouts | up to one year; a Wait state holds no compute | - | up to one year; a Wait is a durable timer held in the task hub | - | up to one year, the Workflows ceiling; a Wait is the engine's own sleep |
| Express workflows · 5-minute, high-volume runs | at-least-once asynchronous runs and at-most-once synchronous runs, no API history | - | an inline run in the adapter with no durable record, within the 5-minute ceiling and with no API history; a fresh start is never deduplicated | - | an inline run in the adapter with no durable record, within the 5-minute ceiling and with no API history; a fresh start is never deduplicated |
| Activities and task tokens · work handed to outside workers | a service-hosted queue polled by GetActivityTask | - | a queue the adapter serves; the token is minted and checked by the adapter, and workers reach the adapter's endpoint | - | a queue the adapter serves; the token is minted by the adapter and completion resumes the workflow through its callback |
| Versions and aliases · immutable versions, weighted routing | native | - | adapter records; an execution pins the version it was routed to | - | - |
| Service integrations · what a Task state can call | AWS services through optimized and SDK integrations | - | the services adapted on the same Cloud Adapter deployment, through their own mappings; a Resource the Cloud Adapter deployment does not serve is refused at CreateStateMachine | - | the services adapted on the same Cloud Adapter deployment, through their own mappings; a Resource the Cloud Adapter deployment does not serve is refused at CreateStateMachine |
| Logs and traces · where execution logs go | CloudWatch Logs and X-Ray | - | the Cloud Adapter deployment's logging; X-Ray tracing is not reproduced | - | Cloud Logging captures execution and step logs; X-Ray tracing is not reproduced |
| Definition size · the largest state machine | 1 MB of Amazon States Language | - | - | - | 1 MB accepted; split across prepared modules because one Workflows source is capped at 128 KB |

## On Akamai, Azure, DigitalOcean, Google Cloud, OCI, Private Kubernetes, and Scaleway

### Temporal (Self-Hosted)

| Capability | Area | Support | Operations | Notes |
| - | - | - | - | - |
| ASL state types and data flow | Amazon States Language | Supported | - | Pass, Succeed, Fail, Choice, Wait, Task, Parallel and Map use the generic interpreter, including paths, intrinsic functions, JSONata, variables and Assign. |
| Map and Parallel | Amazon States Language | Supported | - | Child workflows preserve branch and item ordering, dynamic concurrency, item-level retries and failure thresholds. Capacity admission may delay runnable items. |
| Retry, Catch and timeouts | Amazon States Language | Supported | - | The interpreter controls ASL retries, error matching, backoff and jitter; transport retries do not silently add business attempts. Temporal timers drive waits and timeout handling. |
| Encryption configuration | Configuration | Supported | - | Customer-managed encryption uses the deployment's KMS mapping for adapter records and a worker payload codec for Temporal payloads; decoded history requires key authorization. |
| Logging configuration | Configuration | Partial | - | The configured destination and includeExecutionData setting control deployment logs. Logs do not reach AWS CloudWatch Logs. |
| Tracing configuration | Configuration | Out of scope | - | Enabling AWS X-Ray tracing is rejected; X-Ray is not supplied by this mapping. |
| EXPRESS workflows | Execution model | Supported | - | The adapter executes Express separately within five minutes, without Standard API history. Activities, Distributed Map, .sync, callbacks and Standard-only execution APIs are unavailable for Express. |
| STANDARD workflows | Execution model | Supported | - | Temporal persists Standard execution history and timers. The interpreter preserves the execution identity across worker restart and continue-as-new; external side effects retain their integration's idempotency rules. |
| Service integrations | Integrations | Partial | - | Task resources, .sync, .waitForTaskToken and Task.Credentials are supported only where the deployment has the corresponding service mapping and authorization. Unsupported combinations are rejected at admission. |
| AWS visual console | Operator interface | Out of scope | - | Temporal Web UI shows workflow history, timers and pending work. It does not reproduce the AWS console's ASL graph and highlighted execution path. |

| Operation | Area | Support | Depth | Notes |
| - | - | - | - | - |
| CreateActivity | Activities | Adapter-served | Most usage | Creates an AWS Activity record and a durable task queue served by the adapter; it is separate from Temporal's internal activities. |
| DeleteActivity | Activities | Adapter-served | Full surface | Deletes the Activity and refuses subsequent completion for removed tasks. |
| DescribeActivity | Activities | Adapter-served | Full surface | Returns the Activity ARN, name and creation time. |
| GetActivityTask | Activities | Adapter-served | Most usage | Long-polls the adapter queue and gives one worker a task and attempt-specific token; workers connect to the adapter endpoint. |
| ListActivities | Activities | Adapter-served | Full surface | Lists Activity records with pagination. |
| SendTaskFailure | Activities and callbacks | Adapter-served | Most usage | Records the active attempt's error and cause and resumes ASL error handling. |
| SendTaskHeartbeat | Activities and callbacks | Adapter-served | Full surface | Renews the active task's heartbeat window without extending its absolute timeout. |
| SendTaskSuccess | Activities and callbacks | Adapter-served | Most usage | Durably records completion of the active task attempt and wakes the Temporal workflow; stale tokens are refused and a transport acknowledgment is insufficient. |
| TestState | Diagnostics | Supported | Full surface | Evaluates a single state through the same ASL evaluator; an external Task call requires the caller's authorization and a supported integration. |
| ValidateStateMachineDefinition | Diagnostics | Supported | Most usage | Validates ASL without creating a resource and reports diagnostics, including unsupported Task resources and invocation patterns. |
| DescribeMapRun | Distributed Map | Supported | Most usage | Returns Map Run status, item counts, concurrency and tolerated-failure settings. |
| ListMapRuns | Distributed Map | Supported | Full surface | Lists an execution's Map Runs. |
| UpdateMapRun | Distributed Map | Supported | Full surface | Updates concurrency and failure thresholds in the running interpreter; an update that cannot reach it fails explicitly. Existing child work is retained. |
| DescribeExecution | Executions | Supported | Common | Returns Standard execution status, input, output, failure and redrive details through the adapter's execution record. |
| GetExecutionHistory | Executions | Supported | Most usage | Returns Step Functions events in causal order, including event links and timestamps; Temporal history is translated into the public event model. Express has no API history. |
| ListExecutions | Executions | Supported | Common | Lists Standard executions by state machine or Map Run, with status filters and pagination. |
| RedriveExecution | Executions | Supported | Most usage | Resumes eligible unsuccessful Standard work under the same execution identity and revision within the redrive window; successful states are retained and rerun states reset their retry counters. |
| StartExecution | Executions | Supported | Common | Admits a Standard execution durably and runs the selected ASL revision as a Temporal workflow. Standard name/input deduplication is kept; Express uses a separate short-lived execution path and fresh starts are not deduplicated. |
| StartSyncExecution | Executions | Supported | Most usage | Returns the result of an Express execution within its five-minute limit, including execution failures in the response body; caller disconnection does not cancel accepted work. |
| StopExecution | Executions | Supported | Common | Stops the Standard workflow and records ABORTED with the supplied error and cause; cancellation of an already accepted external effect depends on its integration. |
| CreateStateMachine | State machines | Supported | Common | Validates ASL and stores the definition, role, mode, encryption, logging and tags; unsupported integrations are rejected. |
| DeleteStateMachine | State machines | Supported | Common | Reports DELETING, terminates executions at their next state transition and retires the definition, versions and aliases once executions have closed. Express deletion is eventually consistent. |
| DescribeStateMachine | State machines | Supported | Common | Returns the adapter's definition, role, mode, revision and configuration. |
| DescribeStateMachineForExecution | State machines | Supported | Most usage | Returns the immutable definition and revision selected for a Standard execution. |
| ListStateMachines | State machines | Supported | Common | Lists state machines using opaque pagination tokens. |
| UpdateStateMachine | State machines | Supported | Common | Creates a new revision for subsequent executions; active executions retain their selected definition and runtime version. |
| ListTagsForResource | Tags | Supported | Full surface | Returns the resource's tags. |
| TagResource | Tags | Supported | Full surface | Attaches tags to state-machine or Activity records. |
| UntagResource | Tags | Supported | Full surface | Removes tags from the adapter's resource record. |
| CreateStateMachineAlias | Versions and aliases | Supported | Most usage | Stores weighted routing to one or two versions; each new execution retains the selected version. |
| DeleteStateMachineAlias | Versions and aliases | Supported | Full surface | Deletes the alias without interrupting executions previously started through it. |
| DeleteStateMachineVersion | Versions and aliases | Supported | Full surface | Deletes an unreferenced version; a version used by an alias cannot be deleted. |
| DescribeStateMachineAlias | Versions and aliases | Supported | Full surface | Returns the alias and routing configuration. |
| ListStateMachineAliases | Versions and aliases | Supported | Full surface | Lists aliases with pagination. |
| ListStateMachineVersions | Versions and aliases | Supported | Most usage | Lists published versions with pagination. |
| PublishStateMachineVersion | Versions and aliases | Supported | Most usage | Publishes an immutable numbered revision. |
| UpdateStateMachineAlias | Versions and aliases | Supported | Full surface | Updates routing for subsequent starts; existing executions keep their selected version. |

#### How it works

Your application keeps calling the Step Functions API, now in the target environment. A Tensor9 service adapter stores your state-machine definitions, revisions, versions and aliases. When a Standard execution starts, a worker maintained by Tensor9 reads the selected Amazon States Language (ASL) definition and runs it as a Temporal workflow. One worker runs many definitions, so your team has no generated code to maintain.

The Temporal service and its database run in the deployment environment. Workers use Temporal's task queues, timers and execution history, so an execution continues after a worker restarts. The adapter keeps the AWS execution ARN and returns execution status and history in the Step Functions response format. Express executions run separately in the adapter, on a short-lived path.

#### Tasks, callbacks and an approval example

A Task's `Resource` names an AWS integration, not a Temporal workflow. The adapter looks up the requested operation in the service mappings available in this deployment and checks the execution role before calling it. Temporal activities make the external calls. Your ASL `Retry` and `Catch` rules decide each attempt, so a Temporal retry never quietly adds another one. AWS Activities stay a separate queue that your workers poll with `GetActivityTask`.

Take an order waiting for approval with `.waitForTaskToken`. While the workflow waits, the adapter ties the task token to the current attempt. An authorized `SendTaskSuccess` or `SendTaskFailure` call records that attempt's result and resumes the workflow. A network acknowledgment alone does not complete the task. A `.sync` task instead watches the submitted job until it finishes.

Parallel branches and Map items run as child workflows. Item order, concurrency limits, and the difference between retrying one item and retrying the whole Map are kept. When a long execution continues in a fresh Temporal history (continue-as-new), or workers are upgraded, the execution keeps its ARN and its definition revision.

#### Debugging and worker upgrades

Operators use Temporal Web UI to inspect Standard executions. Its history, pending activities and timers show whether an execution is stuck on an external call or waiting for a callback. It does not show the AWS console's ASL graph or highlighted state path. `GetExecutionHistory` returns the Step Functions view of a Standard execution. Seeing decoded payloads needs separate permission.

Tensor9 maintains the interpreter and compatible worker versions. Running executions keep their program and evaluator versions during an upgrade. Your deployment operator keeps the Temporal service available and owns database backups and restores. Keeping the Helm release without backing up the database is not enough to recover.

#### Limitations

Where Step Functions and self-hosted Temporal differ

* **Only the service integrations in this deployment are supported.** A Task can call only an operation and invocation pattern that has a service mapping here. A Glue or SageMaker ARN does not work just because Temporal can schedule an activity.
* **External calls behave differently: replay does not make them safe to repeat.** Temporal's replay does not make a remote, non-idempotent operation safe to submit twice. Work a service has already accepted follows that service's recovery and cancellation rules.
* **Capacity behaves differently: the installed cluster sets it.** Worker capacity, database throughput and Temporal history limits cap concurrency. ASL `MaxConcurrency` is an upper bound, not reserved throughput.
* **X-Ray tracing and CloudWatch Logs are not supported.** Enabling X-Ray tracing is rejected, and configured logs do not go to AWS CloudWatch Logs. Use Temporal Web UI and the deployment's logs instead of the AWS console.
* **Express executions behave differently.** They have no Standard execution-history API and cannot use Activities, Distributed Map, `.sync` or `.waitForTaskToken`.

#### Other considerations

* **Moving from AWS.** Deploy definitions, versions and aliases through the Step Functions API. Existing AWS executions and callbacks finish on AWS; their running state and history are not imported.
* **Operations.** The deployment operator owns the Temporal cluster, its database, backups, network access and upgrades. Tensor9 maintains the adapter and interpreter workers. Running costs include the workers and database as well as the Temporal services.
* **Data and credentials.** Protect both the adapter's records and Temporal's history. Configure authentication and encryption for the cluster and restrict Web UI access; a namespace name alone does not control access.
* **Changing engines.** A backend change applies to new executions. Keep the old workers, credentials and callback routes until their executions finish and their retention period ends.

Temporal documents the [self-hosted service](https://github.com/temporalio/documentation/blob/main/docs/production-deployment/self-hosted-guide/index.mdx) and [Web UI](https://docs.temporal.io/web-ui).

#### Example monthly charges

This Tensor9 Cloud Adapter scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. [How Tensor9 estimates costs](https://docs.tensor9.com/cloud-adapter-early-access/costs/overview.md) explains the method and what the estimates include.

##### Step Functions Standard · State transitions

Feature: Step Functions Standard.

Estimated monthly service charges by State transitions. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD.

![Step Functions Standard · State transitions: monthly service charges by State transitions. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/d0c1e3cd0dd87dddf2f25e98936baa297a187224af90eba6096c5889511013dd-light.svg)

![Step Functions Standard · State transitions: monthly service charges by State transitions. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/862b513e5f6758478e412e0003dbf7bcd601982ae078b4f105829efdacfff798-dark.svg)

Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples.

Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more.

| State transitions (per second) | Step Functions | Target scenario | Temporal (Self-Hosted) | Difference |
| -: | -: | - | -: | -: |
| 0 | 0.00 | Temporal (Self-Hosted) (one copy) | 80.90 | 80.90 |
| 0 | 0.00 | Temporal (Self-Hosted) (two copies) | 161.79 | 161.79 |
| 1 | 65.70 | Temporal (Self-Hosted) (one copy) | 80.90 | 15.20 |
| 1 | 65.70 | Temporal (Self-Hosted) (two copies) | 161.79 | 96.09 |
| 10 | 657.00 | Temporal (Self-Hosted) (one copy) | 80.90 | -576.10 |
| 10 | 657.00 | Temporal (Self-Hosted) (two copies) | 161.79 | -495.21 |
| 100 | 6,570.00 | Temporal (Self-Hosted) (one copy) | 170.63 | -6,399.37 |
| 100 | 6,570.00 | Temporal (Self-Hosted) (two copies) | 341.26 | -6,228.74 |
| 1,000 | 65,700.00 | Temporal (Self-Hosted) (one copy) | 1,493.10 | -64,206.90 |
| 1,000 | 65,700.00 | Temporal (Self-Hosted) (two copies) | 2,986.19 | -62,713.81 |
| 10,000 | 657,000.00 | Temporal (Self-Hosted) (one copy) | 7,791.59 | -649,208.41 |
| 10,000 | 657,000.00 | Temporal (Self-Hosted) (two copies) | 15,583.18 | -641,416.82 |

Estimated allocation, not benchmark calibrated: sized from 2 vCPU, 8 GiB memory and 100 GiB SSD at 0 per second to 128 vCPU, 864 GiB memory and 21,655 GiB SSD at 10,000 per second.

**Curve assumptions**

| Target scenario | Assumption | Value | Unit |
| - | - | -: | - |
| Temporal (Self-Hosted) (one copy) | Origin list price · Standard state transitions | 0.000025 | USD/transitions |
| Temporal (Self-Hosted) (one copy) | Target steps per source transition | 2 | steps |
| Temporal (Self-Hosted) (one copy) | History bytes per transition | 3,072 | bytes |
| Temporal (Self-Hosted) (one copy) | History retention | 7 | days |
| Temporal (Self-Hosted) (one copy) | Worker CPU per transition | 5 | vCPU-ms |
| Temporal (Self-Hosted) (one copy) | Target price guess · read | 0 | USD/read |
| Temporal (Self-Hosted) (one copy) | Target price guess · write | 0 | USD/write |
| Temporal (Self-Hosted) (one copy) | Target price guess · provider operation | 0 | USD/provider operation |
| Temporal (Self-Hosted) (one copy) | Target list price · GiB-month | 0.1 | USD/GiB-month |
| Temporal (Self-Hosted) (one copy) | Target price guess · published GiB | 0 | USD/published GiB |
| Temporal (Self-Hosted) (one copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Temporal (Self-Hosted) (one copy) | Target list price · network GiB | 0.12 | USD/network GiB |
| Temporal (Self-Hosted) (one copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Temporal (Self-Hosted) (one copy) | Target list price · vCPU-hour | 0.031611 | USD/vCPU-hour |
| Temporal (Self-Hosted) (one copy) | Target list price · GiB-hour | 0.004237 | USD/GiB-hour |
| Temporal (Self-Hosted) (one copy) | Target price guess · resource-hour | 0 | USD/resource-hour |
| Temporal (Self-Hosted) (one copy) | Target price guess · resource-month | 0 | USD/resource-month |
| Temporal (Self-Hosted) (one copy) | Target price guess · input token | 0 | USD/input token |
| Temporal (Self-Hosted) (one copy) | Target price guess · output token | 0 | USD/output token |
| Temporal (Self-Hosted) (one copy) | Target monthly base charge | 0 | USD/month |
| Temporal (Self-Hosted) (one copy) | Approximate target service minimum | 0 | USD/month |
| Temporal (Self-Hosted) (one copy) | Minimum primary CPU | 2 | vCPU |
| Temporal (Self-Hosted) (one copy) | Minimum primary RAM | 8 | GiB |
| Temporal (Self-Hosted) (one copy) | Minimum primary disk | 100 | GiB |
| Temporal (Self-Hosted) (one copy) | Additional full-price standby copy | 0 | 0 or 1 |
| Temporal (Self-Hosted) (one copy) | Allocated share of provisioned cost | 1 | fraction |
| Temporal (Self-Hosted) (one copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Temporal (Self-Hosted) (one copy) | Planning peak / mean work | 2 | multiplier |
| Temporal (Self-Hosted) (one copy) | Planning primary CPU utilization | 0.7 | fraction |
| Temporal (Self-Hosted) (one copy) | Resident state reserved in RAM | 0.1 | fraction |
| Temporal (Self-Hosted) (one copy) | Planning disk utilization | 0.8 | fraction |
| Temporal (Self-Hosted) (one copy) | Maintenance and log disk reserve | 20 | GiB |
| Temporal (Self-Hosted) (one copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Temporal (Self-Hosted) (one copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Temporal (Self-Hosted) (one copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Temporal (Self-Hosted) (one copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Temporal (Self-Hosted) (one copy) | Dependent object sink write price guess | 0.000005 | USD/write |
| Temporal (Self-Hosted) (two copies) | Origin list price · Standard state transitions | 0.000025 | USD/transitions |
| Temporal (Self-Hosted) (two copies) | Target steps per source transition | 2 | steps |
| Temporal (Self-Hosted) (two copies) | History bytes per transition | 3,072 | bytes |
| Temporal (Self-Hosted) (two copies) | History retention | 7 | days |
| Temporal (Self-Hosted) (two copies) | Worker CPU per transition | 5 | vCPU-ms |
| Temporal (Self-Hosted) (two copies) | Target price guess · read | 0 | USD/read |
| Temporal (Self-Hosted) (two copies) | Target price guess · write | 0 | USD/write |
| Temporal (Self-Hosted) (two copies) | Target price guess · provider operation | 0 | USD/provider operation |
| Temporal (Self-Hosted) (two copies) | Target list price · GiB-month | 0.1 | USD/GiB-month |
| Temporal (Self-Hosted) (two copies) | Target price guess · published GiB | 0 | USD/published GiB |
| Temporal (Self-Hosted) (two copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Temporal (Self-Hosted) (two copies) | Target list price · network GiB | 0.12 | USD/network GiB |
| Temporal (Self-Hosted) (two copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Temporal (Self-Hosted) (two copies) | Target list price · vCPU-hour | 0.031611 | USD/vCPU-hour |
| Temporal (Self-Hosted) (two copies) | Target list price · GiB-hour | 0.004237 | USD/GiB-hour |
| Temporal (Self-Hosted) (two copies) | Target price guess · resource-hour | 0 | USD/resource-hour |
| Temporal (Self-Hosted) (two copies) | Target price guess · resource-month | 0 | USD/resource-month |
| Temporal (Self-Hosted) (two copies) | Target price guess · input token | 0 | USD/input token |
| Temporal (Self-Hosted) (two copies) | Target price guess · output token | 0 | USD/output token |
| Temporal (Self-Hosted) (two copies) | Target monthly base charge | 0 | USD/month |
| Temporal (Self-Hosted) (two copies) | Approximate target service minimum | 0 | USD/month |
| Temporal (Self-Hosted) (two copies) | Minimum primary CPU | 2 | vCPU |
| Temporal (Self-Hosted) (two copies) | Minimum primary RAM | 8 | GiB |
| Temporal (Self-Hosted) (two copies) | Minimum primary disk | 100 | GiB |
| Temporal (Self-Hosted) (two copies) | Additional full-price standby copy | 1 | 0 or 1 |
| Temporal (Self-Hosted) (two copies) | Allocated share of provisioned cost | 1 | fraction |
| Temporal (Self-Hosted) (two copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Temporal (Self-Hosted) (two copies) | Planning peak / mean work | 2 | multiplier |
| Temporal (Self-Hosted) (two copies) | Planning primary CPU utilization | 0.7 | fraction |
| Temporal (Self-Hosted) (two copies) | Resident state reserved in RAM | 0.1 | fraction |
| Temporal (Self-Hosted) (two copies) | Planning disk utilization | 0.8 | fraction |
| Temporal (Self-Hosted) (two copies) | Maintenance and log disk reserve | 20 | GiB |
| Temporal (Self-Hosted) (two copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Temporal (Self-Hosted) (two copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Temporal (Self-Hosted) (two copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Temporal (Self-Hosted) (two copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Temporal (Self-Hosted) (two copies) | Dependent object sink write price guess | 0.000005 | USD/write |

* Includes source retries; target amplification is applied only once. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements.
* Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → us-central1, USD/month.
* Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
* Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
* Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve's workload note.
* Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
* Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
* Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
* Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
* A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
* This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
* Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts.
* A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent.
* Managed steps, worker CPU and durable history are distinct target cost components. Internal/external step split needs target-specific assumptions.
* Standard-only origin profile; no inference of Express duration, memory or task execution cost.
* Self-hosted target: Temporal server (MIT, [https://github.com/temporalio/temporal/blob/main/LICENSE](https://github.com/temporalio/temporal/blob/main/LICENSE)); Temporal Cloud is a separate target. Selected CPU, RAM and physical disk allocation grow with workload; no per-operation price is assumed. No vendor charge: the target runs on the customer's Kubernetes nodes, so CPU, RAM and disk bill at the Kubernetes node reference rates, Compute Engine N2 in us-central1 (USD 0.031611/vCPU-hour, 0.004237/GiB-hour) with pd-balanced disk (0.10/GiB-month) and Premium Tier egress. The cost-optimized E2 series lists 0.02181159/vCPU-hour and 0.00292353/GiB-hour; AWS m6i/r6i and Azure D2s v5/E2s v5 both decompose to 0.033/vCPU-hour and 0.00375/GiB-hour. Requested CPU and RAM are billed; node bin-packing waste, system reservations and the cluster control-plane fee are not.
* Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1\_0\_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.
* Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing ([https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size](https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size)): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.
* Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)). The 20 GiB reserve exceeds PostgreSQL's 1 GB default max\_wal\_size; the remainder of that reserve is unmeasured.
* CPU tiers double from 2 vCPUs to the target's largest node at 4 GiB per vCPU; each target's documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead.
* No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.
* Node bounds: Compute Engine n2-highmem-128 has 128 vCPUs and 864 GB ([https://docs.cloud.google.com/compute/docs/general-purpose-machines](https://docs.cloud.google.com/compute/docs/general-purpose-machines)); a Persistent Disk volume holds up to 64 TiB ([https://docs.cloud.google.com/compute/docs/disks/persistent-disks](https://docs.cloud.google.com/compute/docs/disks/persistent-disks)).
* Stored GiB already includes the origin family's physical footprint assumptions; no second storage amplification is applied.
* The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.
* Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
* AWS Price List API, AmazonStates offer: [https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonStates/current/us-east-1/index.json](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonStates/current/us-east-1/index.json)
* Compute Engine general-purpose machine pricing: [https://cloud.google.com/products/compute/pricing/general-purpose](https://cloud.google.com/products/compute/pricing/general-purpose)
* Disk and image pricing: [https://cloud.google.com/compute/disks-image-pricing](https://cloud.google.com/compute/disks-image-pricing)
* Network pricing: [https://cloud.google.com/vpc/network-pricing](https://cloud.google.com/vpc/network-pricing)

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied.

Excluded costs and workload features:

* Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them.
* Destination application execution and separately billed downstream services; supply those allocations separately.
* Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
* Unmodeled dependent services, task execution and operations outside the selected workload family.

List prices read: 2026-10-22. Model: `plan-3d0b8bb9b6b5c0aa92054cdfa7cba72cf3c79b5c` / `2026-10-22.planning.2`. Curve: `workload-1`.

Sources: [AWS Price List API, AmazonStates offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonStates/current/us-east-1/index.json), [Compute Engine general-purpose machine pricing](https://cloud.google.com/products/compute/pricing/general-purpose), [Disk and image pricing](https://cloud.google.com/compute/disks-image-pricing), [Network pricing](https://cloud.google.com/vpc/network-pricing).

**Step Functions Standard → Temporal (Self-Hosted): Authored native-usage planning example.** Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts.

Scenario source region: us-east-1. Scenario target region: us-central1. Currency: USD.

| Monthly component | USD |
| - | -: |
| Origin: Standard state transitions | 0.00 |
| Target: Provisioned primary CPU | 46.15 |
| Target: Provisioned primary RAM | 24.74 |
| Target: Provisioned primary disk | 10.00 |
| Target: Selected billable network | 0.00 |
| Target: Independent provisioned resources | 0.00 |
| Target: Independent managed resources | 0.00 |
| **Origin service subtotal** | **0.00** |
| **Target service subtotal** | **80.90** |

Estimated allocation, not benchmark calibrated: sized at 2 vCPU, 8 GiB memory and 100 GiB SSD for this scenario.

Unestimated components: Adapter hosting, Tensor9 fees. A modeled adapted total and savings require these costs.

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied.

Excluded costs and workload features:

* Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them.
* Destination application execution and separately billed downstream services; supply those allocations separately.
* Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
* Unmodeled dependent services, task execution and operations outside the selected workload family.

**Scenario assumptions**

| Input | Value | Unit |
| - | -: | - |
| Origin list price · Standard state transitions | 0.000025 | USD/transitions |
| Target steps per source transition | 2 | steps |
| History bytes per transition | 3,072 | bytes |
| History retention | 7 | days |
| Worker CPU per transition | 5 | vCPU-ms |
| Target price guess · read | 0 | USD/read |
| Target price guess · write | 0 | USD/write |
| Target price guess · provider operation | 0 | USD/provider operation |
| Target list price · GiB-month | 0.1 | USD/GiB-month |
| Target price guess · published GiB | 0 | USD/published GiB |
| Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Target list price · network GiB | 0.12 | USD/network GiB |
| Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Target list price · vCPU-hour | 0.031611 | USD/vCPU-hour |
| Target list price · GiB-hour | 0.004237 | USD/GiB-hour |
| Target price guess · resource-hour | 0 | USD/resource-hour |
| Target price guess · resource-month | 0 | USD/resource-month |
| Target price guess · input token | 0 | USD/input token |
| Target price guess · output token | 0 | USD/output token |
| Target monthly base charge | 0 | USD/month |
| Approximate target service minimum | 0 | USD/month |
| Minimum primary CPU | 2 | vCPU |
| Minimum primary RAM | 8 | GiB |
| Minimum primary disk | 100 | GiB |
| Additional full-price standby copy | 0 | 0 or 1 |
| Allocated share of provisioned cost | 1 | fraction |
| Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Planning peak / mean work | 2 | multiplier |
| Planning primary CPU utilization | 0.7 | fraction |
| Resident state reserved in RAM | 0.1 | fraction |
| Planning disk utilization | 0.8 | fraction |
| Maintenance and log disk reserve | 20 | GiB |
| Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Dependent object sink write price guess | 0.000005 | USD/write |
| Standard state transitions | 0 | transitions |

* Translated reads: 0 operations.

* Translated writes: 0 operations.

* Translated resident physical data: 0 GiB-month.

* Native provider operations: 0 operations.

* Published payload: 0 GiB.

* Delivered payload: 0 GiB.

* Allocated execution CPU: 0 vCPU-hour.

* Allocated execution RAM: 0 GiB-hour.

* Independent resource allocation: 0 resource-hour.

* Independent inventory: 0 resource-month.

* Input tokens: 0 tokens.

* Output tokens: 0 tokens.

* Billable network: 0 GiB.

* Dependent object sink retained data: 0 GiB-month.

* Dependent object sink writes: 0 writes.

* Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.

* Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.

* Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.

* Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.

* A declared adapter mapping and cost model do not establish implementation availability or service equivalence.

* This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.

* Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts.

* A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent.

* Managed steps, worker CPU and durable history are distinct target cost components. Internal/external step split needs target-specific assumptions.

* Standard-only origin profile; no inference of Express duration, memory or task execution cost.

* Self-hosted target: Temporal server (MIT, [https://github.com/temporalio/temporal/blob/main/LICENSE](https://github.com/temporalio/temporal/blob/main/LICENSE)); Temporal Cloud is a separate target. Selected CPU, RAM and physical disk allocation grow with workload; no per-operation price is assumed. No vendor charge: the target runs on the customer's Kubernetes nodes, so CPU, RAM and disk bill at the Kubernetes node reference rates, Compute Engine N2 in us-central1 (USD 0.031611/vCPU-hour, 0.004237/GiB-hour) with pd-balanced disk (0.10/GiB-month) and Premium Tier egress. The cost-optimized E2 series lists 0.02181159/vCPU-hour and 0.00292353/GiB-hour; AWS m6i/r6i and Azure D2s v5/E2s v5 both decompose to 0.033/vCPU-hour and 0.00375/GiB-hour. Requested CPU and RAM are billed; node bin-packing waste, system reservations and the cluster control-plane fee are not.

* Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1\_0\_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.

* Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing ([https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size](https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size)): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.

* Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)). The 20 GiB reserve exceeds PostgreSQL's 1 GB default max\_wal\_size; the remainder of that reserve is unmeasured.

* CPU tiers double from 2 vCPUs to the target's largest node at 4 GiB per vCPU; each target's documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead.

* No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.

* Node bounds: Compute Engine n2-highmem-128 has 128 vCPUs and 864 GB ([https://docs.cloud.google.com/compute/docs/general-purpose-machines](https://docs.cloud.google.com/compute/docs/general-purpose-machines)); a Persistent Disk volume holds up to 64 TiB ([https://docs.cloud.google.com/compute/docs/disks/persistent-disks](https://docs.cloud.google.com/compute/docs/disks/persistent-disks)).

* Stored GiB already includes the origin family's physical footprint assumptions; no second storage amplification is applied.

* The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.

* Copies and allocation fractions change cost only; they do not increase modeled primary capacity.

List prices read: 2026-10-22. Model: `plan-3d0b8bb9b6b5c0aa92054cdfa7cba72cf3c79b5c` / `2026-10-22.planning.2`. Scenario: `planning-example`.

Sources: [AWS Price List API, AmazonStates offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonStates/current/us-east-1/index.json), [Compute Engine general-purpose machine pricing](https://cloud.google.com/products/compute/pricing/general-purpose), [Disk and image pricing](https://cloud.google.com/compute/disks-image-pricing), [Network pricing](https://cloud.google.com/vpc/network-pricing).

## On Azure

### Azure Durable Functions

| Capability | Area | Support | Operations | Notes |
| - | - | - | - | - |
| Data flow and expressions | Amazon States Language | Supported | - | InputPath, Parameters, ResultSelector, ResultPath, OutputPath, intrinsic functions, JSONata, variables and Assign are evaluated by the orchestrator |
| Distributed Map | Amazon States Language | Supported | - | a Map Run fans out into child orchestrations within MaxConcurrency; item slots and ordered output survive a worker restart, an item retry never becomes a whole-Map retry, and UpdateMapRun reaches children already running or fails with a named error. A large Map Run is paced by shared admission and backpressure without any change to its semantics |
| Error handling | Amazon States Language | Supported | - | Retry and Catch with backoff, jitter and error matching; a retried attempt is one explicit attempt and is never multiplied by the platform's own retry |
| Parallel and inline Map | Amazon States Language | Supported | - | branches and items run as child orchestrations and their outputs are aggregated in order |
| Wait states and timeouts | Amazon States Language | Supported | - | a Wait is a durable timer held as a scheduled message in the task hub, whether it lasts seconds or months; state and execution timeouts fire as States.Timeout |
| Encryption configuration | Configuration | Supported | - | a customer-managed key names a key served by the KMS mapping on the same Cloud Adapter deployment (Key Vault on Azure); definitions and execution payloads are encrypted under it and become unreadable when it is revoked |
| Logging configuration | Configuration | Partial | - | includeExecutionData decides whether execution payloads are written at all, and the configured destination decides whose log they reach; the destination is served by the Cloud Adapter deployment's logging, since CloudWatch Logs is a service the Cloud Adapter deployment does not adapt |
| Tracing configuration | Configuration | Out of scope | - | X-Ray is not adapted, so a configuration that enables tracing is rejected at CreateStateMachine and UpdateStateMachine rather than stored and ignored |
| EXPRESS workflows | Execution model | Supported | - | an Express execution is an inline run in the adapter with no durable record, within the 5-minute ceiling; as on AWS it has no history through the API, cannot use Activities, Distributed Map, .sync or .waitForTaskToken, and DescribeStateMachineForExecution, GetExecutionHistory, ListExecutions, RedriveExecution and StopExecution refuse it. A fresh Express start is never deduplicated, and an interrupted delivery is retried under the same accepted start |
| STANDARD workflows | Execution model | Supported | - | exactly-once execution with a durable record, up to one year |
| Service integrations | Integrations | Partial | - | a Task Resource naming an AWS service is served by that service's mapping on the same Cloud Adapter deployment, including the .sync and .waitForTaskToken patterns, nested executions and Task.Credentials role overrides; a Resource naming a service the Cloud Adapter deployment does not serve is refused at CreateStateMachine |
| Payload and definition limits | Limits | Supported | - | the 256 KiB ceiling on inputs, outputs and state payloads and the 1 MB definition ceiling are enforced at the API, so a definition that fits on AWS fits here |

| Operation | Area | Support | Depth | Notes |
| - | - | - | - | - |
| CreateActivity | Activities | Adapter-served | Most usage | an Activity is a record and a task queue the adapter itself serves, since Azure has no resource that an outside worker long-polls by name |
| DeleteActivity | Activities | Adapter-served | Full surface | deletes the Activity even while workers hold tasks from it, as on AWS; a worker's next SendTaskSuccess for such a task answers TaskDoesNotExist |
| DescribeActivity | Activities | Adapter-served | Full surface | returns the Activity's ARN, name and creation date |
| GetActivityTask | Activities | Adapter-served | Most usage | holds the poll open for up to 60 seconds and hands one task to one worker with a task token the adapter mints; an empty poll returns a null token, so workers keep the 65-second socket timeout AWS recommends |
| ListActivities | Activities | Adapter-served | Full surface | lists the Activities |
| SendTaskFailure | Activities | Adapter-served | Most usage | fails the task with the error and cause supplied |
| SendTaskHeartbeat | Activities | Adapter-served | Full surface | renews the task's heartbeat window; a task whose heartbeat lapses fails with States.Timeout |
| SendTaskSuccess | Activities | Adapter-served | Most usage | completes the task the token identifies, once; a stale or unknown token is refused |
| TestState | Diagnostics | Supported | Full surface | runs a single state through the same evaluator without starting an execution; a Task state that reaches a real service does so under the caller's own authorization |
| ValidateStateMachineDefinition | Diagnostics | Supported | Most usage | validates a definition without creating anything and returns the diagnostics with their severity; a Task whose Resource names a service the Cloud Adapter deployment does not serve is reported here |
| DescribeMapRun | Distributed Map | Supported | Most usage | returns the Map Run's status, item counts, tolerated-failure settings and concurrency |
| ListMapRuns | Distributed Map | Supported | Full surface | lists the Map Runs of an execution |
| UpdateMapRun | Distributed Map | Supported | Full surface | changes MaxConcurrency or the tolerated-failure thresholds of a running Map Run; child runs already in flight continue |
| DescribeExecution | Executions | Supported | Common | returns status, input, output, error, cause and redrive details for the execution |
| GetExecutionHistory | Executions | Supported | Most usage | returns the execution's transitions as Step Functions events with ids, previous-event ids and timestamps in causal order, derived from the orchestration's record; EXPRESS executions have no history through the API, as on AWS |
| ListExecutions | Executions | Supported | Common | lists executions by state machine or Map Run, filtered by status and redrive filter, with opaque pagination tokens |
| RedriveExecution | Executions | Supported | Most usage | resumes a failed, aborted or timed-out STANDARD execution from its unsuccessful states within 14 days of closing, under the same execution ARN and revision; successful states are not rerun, retry counters on the rerun states reset, and on a Distributed Map only the failed child runs restart |
| StartExecution | Executions | Supported | Common | admits the execution, pins its revision and returns while it runs: a STANDARD execution as a Durable Functions orchestration, an EXPRESS execution as an inline run with no durable record. A STANDARD start with the name and input of a running execution returns the original response; a closed execution or a different input returns ExecutionAlreadyExists, and a name is reusable 90 days after it closes. EXPRESS starts are never deduplicated |
| StartSyncExecution | Executions | Supported | Most usage | the synchronous result API of an EXPRESS state machine: the request is held open until the inline run completes or the 5-minute ceiling passes, a failed run is reported in the response body, and a caller that disconnects does not cancel accepted work |
| StopExecution | Executions | Supported | Common | terminates the orchestration and records the ABORTED outcome with the error and cause supplied |
| CreateStateMachine | State machines | Supported | Common | validates the Amazon States Language definition and records the state machine with its role, type, encryption, logging and tags; the definition is kept as written and interpreted at run time, so nothing is rewritten by hand |
| DeleteStateMachine | State machines | Supported | Common | succeeds at once and the state machine reads DELETING; it is retired when its running executions have completed, and its versions and aliases are retired with it |
| DescribeStateMachine | State machines | Supported | Common | returns the definition, role, type, revision and configuration from the adapter's record |
| DescribeStateMachineForExecution | State machines | Supported | Most usage | returns the exact definition and revision an execution runs, which is pinned when the execution starts |
| ListStateMachines | State machines | Supported | Common | lists state machines with opaque pagination tokens |
| UpdateStateMachine | State machines | Supported | Common | replaces the definition, role or configuration and returns a new revision; executions already running keep the revision they started on |
| ListTagsForResource | Tags | Supported | Full surface | lists the tags on a state machine or Activity |
| TagResource | Tags | Supported | Full surface | attaches tags to a state machine or Activity |
| UntagResource | Tags | Supported | Full surface | removes tags |
| CreateStateMachineAlias | Versions and aliases | Supported | Most usage | an alias routes to one or two versions by weight; an execution started through the alias pins the version it was routed to |
| DeleteStateMachineAlias | Versions and aliases | Supported | Full surface | deletes the alias; executions it routed keep running |
| DeleteStateMachineVersion | Versions and aliases | Supported | Full surface | deletes a version; refused while an alias still routes to it, as on AWS |
| DescribeStateMachineAlias | Versions and aliases | Supported | Full surface | returns the alias and its routing configuration |
| ListStateMachineAliases | Versions and aliases | Supported | Full surface | lists the aliases of a state machine |
| ListStateMachineVersions | Versions and aliases | Supported | Most usage | lists the published versions |
| PublishStateMachineVersion | Versions and aliases | Supported | Most usage | publishes the current revision as an immutable numbered version |
| UpdateStateMachineAlias | Versions and aliases | Supported | Full surface | changes the routing for executions started afterwards; running executions are unaffected |

#### How it works

Your application keeps calling the Step Functions API. In the target environment those calls reach a Tensor9 service adapter instead of AWS. The adapter holds each state machine as a record: the Amazon States Language definition as you wrote it, the execution role, the type, the versions, the aliases and the tags. It answers every `states:` operation from that record and from the executions it has admitted.

A Standard execution is a Durable Functions orchestration instance; an Express execution runs inline in the adapter and leaves no durable record, as on AWS. StartExecution admits the execution, pins the revision it will run, and for a Standard execution hands it to an orchestrator function that Tensor9 maintains and deploys into an Azure Functions app in the target environment. That orchestrator is generic: it interprets the definition state by state, so a state machine is never rewritten into orchestrator code and an UpdateStateMachine deploys nothing. Durable timers serve Wait states, activity functions serve Task states, sub-orchestrations serve Parallel branches and Map items, and external events serve callbacks and task tokens; StopExecution terminates the instance. Durable Functions checkpoints the orchestration's progress in its task hub, so an execution survives a restart of the function app or of the adapter and resumes where it left off. GetExecutionHistory returns Step Functions events built from that record in causal order; the platform's own replay events are not part of it.

A Task state's Resource names an AWS service, and it is served by that service's mapping on the same Cloud Adapter deployment: a Lambda ARN invokes the function the Lambda mapping runs, an SQS or SNS integration reaches the queue or topic served there, and a `.waitForTaskToken` integration parks the orchestration on an external event until SendTaskSuccess or SendTaskFailure arrives. Each Task effect is authorized against the state machine's execution role, or the Task.Credentials role where one is set, before it is made, and the call itself travels on the Cloud Adapter deployment's own identity; no AWS credential is involved.

#### Azure resources behind a deployment

Two Azure resources sit behind a Step Functions deployment: a function app on a Premium plan, which gives the orchestrator always-ready instances and virtual-network access, and a storage account whose task hub holds orchestration history and queued work. Both are owned in the target environment. Tensor9 deploys its orchestrator code into the function app and upgrades it, and removing a backend selection never deletes the function app or the storage account.

In the Azure portal you see orchestration instances named by the adapter, activity invocations, and the storage account's queues and tables. State machines, executions and ARNs are not Azure resources; they exist in the adapter's record and are what the Step Functions API returns, so DescribeExecution, ListExecutions and GetExecutionHistory are the way to observe an execution, exactly as on AWS.

#### Limitations

* **Activities are served by the adapter.** Azure has no resource that a worker outside the platform long-polls by name, so an Activity is a queue the adapter itself serves: GetActivityTask holds the poll open for up to 60 seconds, the task token is minted by the adapter, and SendTaskSuccess, SendTaskFailure and SendTaskHeartbeat are checked against it. Workers need no code change; they must reach the adapter's endpoint. - **Large Map Runs are paced by the Cloud Adapter deployment.** A Map Run becomes N child orchestrations within MaxConcurrency, and a large one is admitted with backpressure rather than all at once; its semantics do not change. An UpdateMapRun that cannot reach children already running fails with a named error instead of reporting a change that did not happen. - **Logs and traces do not reach CloudWatch or X-Ray.** `includeExecutionData` decides whether execution payloads are written at all and the configured destination decides whose log they reach; the destination is served by the Cloud Adapter deployment's logging, since CloudWatch Logs is a service the Cloud Adapter deployment does not adapt. A `tracingConfiguration` that enables X-Ray tracing is rejected at CreateStateMachine and UpdateStateMachine, because X-Ray is not adapted and a setting that is stored but ignored would misreport what runs. - **Service integrations are bounded by the Cloud Adapter deployment.** A Task state reaches the services adapted on the same Cloud Adapter deployment. A Resource naming a service the Cloud Adapter deployment does not serve is reported by ValidateStateMachineDefinition and refused at CreateStateMachine with an error naming the state; a definition is never admitted only to fail on its first execution. - **The engine choice is fixed per execution.** Which engine runs a state machine is chosen per deployment and recorded with each execution. Changing it affects executions started afterwards; executions already running, their history and their outstanding task tokens stay on the engine they started on until they complete and their retention expires. Nothing migrates a live execution.

#### Other considerations

* **Migration.** State machines are created by your own deployment: applying your Step Functions resources against the adapter creates them through CreateStateMachine, versions and aliases included. Executions do not migrate. One started on AWS completes on AWS, one started after cutover runs on Azure, and AWS execution history is not copied. - **Who operates what.** The function app and the storage account are owned in the target environment and operated by Microsoft. Tensor9 maintains the orchestrator code deployed into the function app, upgrades it, and operates the adapter; an upgrade keeps in-flight orchestrations on the orchestrator version they started with, so a running execution is not replayed against changed code. - **Cost shape.** AWS bills a Standard execution per state transition and an Express one per run, duration and memory. On Azure the cost is the Premium plan's instances, which run whether or not executions are in flight, plus storage transactions on the task hub. - **Durability.** Orchestration state lives in the storage account; the adapter's own record of state machines, versions, aliases and Activities lives in the Cloud Adapter deployment's durable store. Both are in the target environment.

#### Example monthly charges

This Tensor9 Cloud Adapter scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. [How Tensor9 estimates costs](https://docs.tensor9.com/cloud-adapter-early-access/costs/overview.md) explains the method and what the estimates include.

##### Step Functions Standard · State transitions

Feature: Step Functions Standard.

Estimated monthly service charges by State transitions. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: East US; currency: USD.

![Step Functions Standard · State transitions: monthly service charges by State transitions. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/24530f5d19502a95d0c5473f82cc1a687ae096a10d502860e11634fb8c22fe3f-light.svg)

![Step Functions Standard · State transitions: monthly service charges by State transitions. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/ca59989bc1cf2cb2064f23e5109aa7c9911bf6b8c29499332be536909631c372-dark.svg)

Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples.

Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more.

| State transitions (per second) | Step Functions | Target scenario | Azure Durable Functions | Difference |
| -: | -: | - | -: | -: |
| 0 | 0.00 | Azure Durable Functions (one staging copy) | 118.18 | 118.18 |
| 0 | 0.00 | Azure Durable Functions (two staging copies) | 236.36 | 236.36 |
| 1 | 65.70 | Azure Durable Functions (one staging copy) | 129.07 | 63.37 |
| 1 | 65.70 | Azure Durable Functions (two staging copies) | 247.25 | 181.55 |
| 10 | 657.00 | Azure Durable Functions (one staging copy) | 227.08 | -429.92 |
| 10 | 657.00 | Azure Durable Functions (two staging copies) | 345.26 | -311.74 |
| 100 | 6,570.00 | Azure Durable Functions (one staging copy) | 1,340.20 | -5,229.80 |
| 100 | 6,570.00 | Azure Durable Functions (two staging copies) | 1,591.37 | -4,978.63 |
| 1,000 | 65,700.00 | Azure Durable Functions (one staging copy) | 13,112.47 | -52,587.53 |
| 1,000 | 65,700.00 | Azure Durable Functions (two staging copies) | 15,334.50 | -50,365.50 |
| 10,000 | 657,000.00 | Azure Durable Functions (one staging copy) | 118,668.61 | -538,331.39 |
| 10,000 | 657,000.00 | Azure Durable Functions (two staging copies) | 128,432.91 | -528,567.09 |

Estimated allocation, not benchmark calibrated: sized from 2 vCPU, 8 GiB memory and 100 GiB SSD at 0 per second to 96 vCPU, 624 GiB memory and 21,655 GiB SSD at 10,000 per second.

**Curve assumptions**

| Target scenario | Assumption | Value | Unit |
| - | - | -: | - |
| Azure Durable Functions (one staging copy) | Origin list price · Standard state transitions | 0.000025 | USD/transitions |
| Azure Durable Functions (one staging copy) | Target steps per source transition | 2 | steps |
| Azure Durable Functions (one staging copy) | History bytes per transition | 3,072 | bytes |
| Azure Durable Functions (one staging copy) | History retention | 7 | days |
| Azure Durable Functions (one staging copy) | Worker CPU per transition | 5 | vCPU-ms |
| Azure Durable Functions (one staging copy) | Target price guess · read | 0 | USD/read |
| Azure Durable Functions (one staging copy) | Target price guess · write | 0 | USD/write |
| Azure Durable Functions (one staging copy) | Target list price · provider operation | 0.000002072 | USD/provider operation |
| Azure Durable Functions (one staging copy) | Target price guess · GiB-month | 0 | USD/GiB-month |
| Azure Durable Functions (one staging copy) | Target price guess · published GiB | 0 | USD/published GiB |
| Azure Durable Functions (one staging copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Azure Durable Functions (one staging copy) | Target price guess · network GiB | 0 | USD/network GiB |
| Azure Durable Functions (one staging copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Azure Durable Functions (one staging copy) | Target price guess · vCPU-hour | 0 | USD/vCPU-hour |
| Azure Durable Functions (one staging copy) | Target price guess · GiB-hour | 0 | USD/GiB-hour |
| Azure Durable Functions (one staging copy) | Target price guess · resource-hour | 0 | USD/resource-hour |
| Azure Durable Functions (one staging copy) | Target price guess · resource-month | 0 | USD/resource-month |
| Azure Durable Functions (one staging copy) | Target price guess · input token | 0 | USD/input token |
| Azure Durable Functions (one staging copy) | Target price guess · output token | 0 | USD/output token |
| Azure Durable Functions (one staging copy) | Target monthly base charge | 0 | USD/month |
| Azure Durable Functions (one staging copy) | Approximate target service minimum | 0 | USD/month |
| Azure Durable Functions (one staging copy) | Minimum primary CPU | 2 | vCPU |
| Azure Durable Functions (one staging copy) | Minimum primary RAM | 8 | GiB |
| Azure Durable Functions (one staging copy) | Minimum primary disk | 100 | GiB |
| Azure Durable Functions (one staging copy) | Additional full-price standby copy | 0 | 0 or 1 |
| Azure Durable Functions (one staging copy) | Allocated share of provisioned cost | 1 | fraction |
| Azure Durable Functions (one staging copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Azure Durable Functions (one staging copy) | Planning peak / mean work | 2 | multiplier |
| Azure Durable Functions (one staging copy) | Planning primary CPU utilization | 0.7 | fraction |
| Azure Durable Functions (one staging copy) | Resident state reserved in RAM | 0.1 | fraction |
| Azure Durable Functions (one staging copy) | Planning disk utilization | 0.8 | fraction |
| Azure Durable Functions (one staging copy) | Maintenance and log disk reserve | 20 | GiB |
| Azure Durable Functions (one staging copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Azure Durable Functions (one staging copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Azure Durable Functions (one staging copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Azure Durable Functions (one staging copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Azure Durable Functions (one staging copy) | Dependent object sink write price guess | 0.000005 | USD/write |
| Azure Durable Functions (two staging copies) | Origin list price · Standard state transitions | 0.000025 | USD/transitions |
| Azure Durable Functions (two staging copies) | Target steps per source transition | 2 | steps |
| Azure Durable Functions (two staging copies) | History bytes per transition | 3,072 | bytes |
| Azure Durable Functions (two staging copies) | History retention | 7 | days |
| Azure Durable Functions (two staging copies) | Worker CPU per transition | 5 | vCPU-ms |
| Azure Durable Functions (two staging copies) | Target price guess · read | 0 | USD/read |
| Azure Durable Functions (two staging copies) | Target price guess · write | 0 | USD/write |
| Azure Durable Functions (two staging copies) | Target list price · provider operation | 0.000002072 | USD/provider operation |
| Azure Durable Functions (two staging copies) | Target price guess · GiB-month | 0 | USD/GiB-month |
| Azure Durable Functions (two staging copies) | Target price guess · published GiB | 0 | USD/published GiB |
| Azure Durable Functions (two staging copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Azure Durable Functions (two staging copies) | Target price guess · network GiB | 0 | USD/network GiB |
| Azure Durable Functions (two staging copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Azure Durable Functions (two staging copies) | Target price guess · vCPU-hour | 0 | USD/vCPU-hour |
| Azure Durable Functions (two staging copies) | Target price guess · GiB-hour | 0 | USD/GiB-hour |
| Azure Durable Functions (two staging copies) | Target price guess · resource-hour | 0 | USD/resource-hour |
| Azure Durable Functions (two staging copies) | Target price guess · resource-month | 0 | USD/resource-month |
| Azure Durable Functions (two staging copies) | Target price guess · input token | 0 | USD/input token |
| Azure Durable Functions (two staging copies) | Target price guess · output token | 0 | USD/output token |
| Azure Durable Functions (two staging copies) | Target monthly base charge | 0 | USD/month |
| Azure Durable Functions (two staging copies) | Approximate target service minimum | 0 | USD/month |
| Azure Durable Functions (two staging copies) | Minimum primary CPU | 2 | vCPU |
| Azure Durable Functions (two staging copies) | Minimum primary RAM | 8 | GiB |
| Azure Durable Functions (two staging copies) | Minimum primary disk | 100 | GiB |
| Azure Durable Functions (two staging copies) | Additional full-price standby copy | 1 | 0 or 1 |
| Azure Durable Functions (two staging copies) | Allocated share of provisioned cost | 1 | fraction |
| Azure Durable Functions (two staging copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Azure Durable Functions (two staging copies) | Planning peak / mean work | 2 | multiplier |
| Azure Durable Functions (two staging copies) | Planning primary CPU utilization | 0.7 | fraction |
| Azure Durable Functions (two staging copies) | Resident state reserved in RAM | 0.1 | fraction |
| Azure Durable Functions (two staging copies) | Planning disk utilization | 0.8 | fraction |
| Azure Durable Functions (two staging copies) | Maintenance and log disk reserve | 20 | GiB |
| Azure Durable Functions (two staging copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Azure Durable Functions (two staging copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Azure Durable Functions (two staging copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Azure Durable Functions (two staging copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Azure Durable Functions (two staging copies) | Dependent object sink write price guess | 0.000005 | USD/write |

* Includes source retries; target amplification is applied only once. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements.
* Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → East US, USD/month.
* Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
* Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
* Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve's workload note.
* Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
* Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
* Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
* Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
* A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
* This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
* Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts.
* A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent.
* Managed steps, worker CPU and durable history are distinct target cost components. Internal/external step split needs target-specific assumptions.
* Standard-only origin profile; no inference of Express duration, memory or task execution cost.
* Azure Durable Functions has no orchestration charge of its own: with the default Azure Storage provider it bills the function executions that run orchestrator and activity steps plus the queue and table transactions that persist their messages and history in the customer's storage account. The step rate is that composite on Flex Consumption. Execution GB-seconds (USD 0.000026 per GB-second on Flex Consumption), idle queue polling (a few hundred thousand transactions a month per app) and table storage (USD 0.045 per GB-month) are not modeled, and the family's worker CPU is not a Durable Functions charge. The Durable Task Scheduler (Dedicated USD 0.684932 per capacity-unit hour) is an alternative backend and is not selected.
* Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1\_0\_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.
* Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing ([https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size](https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size)): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.
* Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)). The 20 GiB reserve exceeds PostgreSQL's 1 GB default max\_wal\_size; the remainder of that reserve is unmeasured.
* CPU tiers double from 2 vCPUs to the target's largest node at 4 GiB per vCPU; each target's documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead.
* No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.
* Node bounds: Cloud SQL Enterprise allows 1-96 vCPUs at 0.9-6.5 GB per vCPU and up to 64 TB with a dedicated vCPU ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)).
* Stored GiB already includes the origin family's physical footprint assumptions; no second storage amplification is applied.
* The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.
* Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
* AWS Price List API, AmazonStates offer: [https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonStates/current/us-east-1/index.json](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonStates/current/us-east-1/index.json)
* Azure Retail Prices API: [https://prices.azure.com/api/retail/prices](https://prices.azure.com/api/retail/prices)

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied.

Excluded costs and workload features:

* Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them.
* Destination application execution and separately billed downstream services; supply those allocations separately.
* Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
* Unmodeled dependent services, task execution and operations outside the selected workload family.

List prices read: 2026-10-22. Model: `plan-8165b354acdf9b1901b0eeb4a8430b57478f42e2` / `2026-10-22.planning.2`. Curve: `workload-1`.

Sources: [AWS Price List API, AmazonStates offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonStates/current/us-east-1/index.json), [Azure Retail Prices API](https://prices.azure.com/api/retail/prices).

**Step Functions Standard → Azure Durable Functions: Authored native-usage planning example.** Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts.

Scenario source region: us-east-1. Scenario target region: East US. Currency: USD.

| Monthly component | USD |
| - | -: |
| Origin: Standard state transitions | 0.00 |
| Target: Target retained physical data | 0.00 |
| Target: Additional broker replica storage | 0.00 |
| Target: Target native provider operations | 0.00 |
| Target: Execution or worker CPU | 0.00 |
| Target: Execution or worker RAM | 0.00 |
| Target: Selected billable network | 0.00 |
| Target: Independent native resources | 0.00 |
| Target: Independent native resources | 0.00 |
| Target: Durable staging CPU | 60.30 |
| Target: Durable staging RAM | 40.88 |
| Target: Durable staging disk | 17.00 |
| **Origin service subtotal** | **0.00** |
| **Target service subtotal** | **118.18** |

Estimated allocation, not benchmark calibrated: sized at 2 vCPU, 8 GiB memory and 100 GiB SSD for this scenario.

Unestimated components: Adapter hosting, Tensor9 fees. A modeled adapted total and savings require these costs.

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied.

Excluded costs and workload features:

* Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them.
* Destination application execution and separately billed downstream services; supply those allocations separately.
* Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
* Unmodeled dependent services, task execution and operations outside the selected workload family.

**Scenario assumptions**

| Input | Value | Unit |
| - | -: | - |
| Origin list price · Standard state transitions | 0.000025 | USD/transitions |
| Target steps per source transition | 2 | steps |
| History bytes per transition | 3,072 | bytes |
| History retention | 7 | days |
| Worker CPU per transition | 5 | vCPU-ms |
| Target price guess · read | 0 | USD/read |
| Target price guess · write | 0 | USD/write |
| Target list price · provider operation | 0.000002072 | USD/provider operation |
| Target price guess · GiB-month | 0 | USD/GiB-month |
| Target price guess · published GiB | 0 | USD/published GiB |
| Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Target price guess · network GiB | 0 | USD/network GiB |
| Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Target price guess · vCPU-hour | 0 | USD/vCPU-hour |
| Target price guess · GiB-hour | 0 | USD/GiB-hour |
| Target price guess · resource-hour | 0 | USD/resource-hour |
| Target price guess · resource-month | 0 | USD/resource-month |
| Target price guess · input token | 0 | USD/input token |
| Target price guess · output token | 0 | USD/output token |
| Target monthly base charge | 0 | USD/month |
| Approximate target service minimum | 0 | USD/month |
| Minimum primary CPU | 2 | vCPU |
| Minimum primary RAM | 8 | GiB |
| Minimum primary disk | 100 | GiB |
| Additional full-price standby copy | 0 | 0 or 1 |
| Allocated share of provisioned cost | 1 | fraction |
| Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Planning peak / mean work | 2 | multiplier |
| Planning primary CPU utilization | 0.7 | fraction |
| Resident state reserved in RAM | 0.1 | fraction |
| Planning disk utilization | 0.8 | fraction |
| Maintenance and log disk reserve | 20 | GiB |
| Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Dependent object sink write price guess | 0.000005 | USD/write |
| Standard state transitions | 0 | transitions |

* Translated reads: 0 operations.

* Translated writes: 0 operations.

* Translated resident physical data: 0 GiB-month.

* Native provider operations: 0 operations.

* Published payload: 0 GiB.

* Delivered payload: 0 GiB.

* Allocated execution CPU: 0 vCPU-hour.

* Allocated execution RAM: 0 GiB-hour.

* Independent resource allocation: 0 resource-hour.

* Independent inventory: 0 resource-month.

* Input tokens: 0 tokens.

* Output tokens: 0 tokens.

* Billable network: 0 GiB.

* Dependent object sink retained data: 0 GiB-month.

* Dependent object sink writes: 0 writes.

* Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.

* Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.

* Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.

* Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.

* A declared adapter mapping and cost model do not establish implementation availability or service equivalence.

* This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.

* Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts.

* A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent.

* Managed steps, worker CPU and durable history are distinct target cost components. Internal/external step split needs target-specific assumptions.

* Standard-only origin profile; no inference of Express duration, memory or task execution cost.

* Azure Durable Functions has no orchestration charge of its own: with the default Azure Storage provider it bills the function executions that run orchestrator and activity steps plus the queue and table transactions that persist their messages and history in the customer's storage account. The step rate is that composite on Flex Consumption. Execution GB-seconds (USD 0.000026 per GB-second on Flex Consumption), idle queue polling (a few hundred thousand transactions a month per app) and table storage (USD 0.045 per GB-month) are not modeled, and the family's worker CPU is not a Durable Functions charge. The Durable Task Scheduler (Dedicated USD 0.684932 per capacity-unit hour) is an alternative backend and is not selected.

* Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1\_0\_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.

* Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing ([https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size](https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size)): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.

* Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)). The 20 GiB reserve exceeds PostgreSQL's 1 GB default max\_wal\_size; the remainder of that reserve is unmeasured.

* CPU tiers double from 2 vCPUs to the target's largest node at 4 GiB per vCPU; each target's documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead.

* No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.

* Node bounds: Cloud SQL Enterprise allows 1-96 vCPUs at 0.9-6.5 GB per vCPU and up to 64 TB with a dedicated vCPU ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)).

* Stored GiB already includes the origin family's physical footprint assumptions; no second storage amplification is applied.

* The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.

* Copies and allocation fractions change cost only; they do not increase modeled primary capacity.

List prices read: 2026-10-22. Model: `plan-8165b354acdf9b1901b0eeb4a8430b57478f42e2` / `2026-10-22.planning.2`. Scenario: `planning-example`.

Sources: [AWS Price List API, AmazonStates offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonStates/current/us-east-1/index.json), [Azure Retail Prices API](https://prices.azure.com/api/retail/prices).

## On Azure, Google Cloud, OCI, and Private Kubernetes

### Temporal Cloud (Managed)

| Capability | Area | Support | Operations | Notes |
| - | - | - | - | - |
| ASL state types and data flow | Amazon States Language | Supported | - | Pass, Succeed, Fail, Choice, Wait, Task, Parallel and Map use the generic interpreter, including paths, intrinsic functions, JSONata, variables and Assign. |
| Map and Parallel | Amazon States Language | Supported | - | Child workflows preserve branch and item ordering, dynamic concurrency, item-level retries and failure thresholds. Capacity admission may delay runnable items. |
| Retry, Catch and timeouts | Amazon States Language | Supported | - | The interpreter controls ASL retries, error matching, backoff and jitter; transport retries do not silently add business attempts. Temporal timers drive waits and timeout handling. |
| Encryption configuration | Configuration | Supported | - | Customer-managed encryption uses the deployment's KMS mapping for adapter records and a worker payload codec for Temporal payloads; decoded history requires key authorization. |
| Logging configuration | Configuration | Partial | - | The configured destination and includeExecutionData setting control deployment logs. Logs do not reach AWS CloudWatch Logs. |
| Tracing configuration | Configuration | Out of scope | - | Enabling AWS X-Ray tracing is rejected; X-Ray is not supplied by this mapping. |
| EXPRESS workflows | Execution model | Supported | - | The adapter executes Express separately within five minutes, without Standard API history. Activities, Distributed Map, .sync, callbacks and Standard-only execution APIs are unavailable for Express. |
| STANDARD workflows | Execution model | Supported | - | Temporal persists Standard execution history and timers. The interpreter preserves the execution identity across worker restart and continue-as-new; external side effects retain their integration's idempotency rules. |
| Service integrations | Integrations | Partial | - | Task resources, .sync, .waitForTaskToken and Task.Credentials are supported only where the deployment has the corresponding service mapping and authorization. Unsupported combinations are rejected at admission. |
| AWS visual console | Operator interface | Out of scope | - | Temporal Web UI shows workflow history, timers and pending work. It does not reproduce the AWS console's ASL graph and highlighted execution path. |

| Operation | Area | Support | Depth | Notes |
| - | - | - | - | - |
| CreateActivity | Activities | Adapter-served | Most usage | Creates an AWS Activity record and a durable task queue served by the adapter; it is separate from Temporal's internal activities. |
| DeleteActivity | Activities | Adapter-served | Full surface | Deletes the Activity and refuses subsequent completion for removed tasks. |
| DescribeActivity | Activities | Adapter-served | Full surface | Returns the Activity ARN, name and creation time. |
| GetActivityTask | Activities | Adapter-served | Most usage | Long-polls the adapter queue and gives one worker a task and attempt-specific token; workers connect to the adapter endpoint. |
| ListActivities | Activities | Adapter-served | Full surface | Lists Activity records with pagination. |
| SendTaskFailure | Activities and callbacks | Adapter-served | Most usage | Records the active attempt's error and cause and resumes ASL error handling. |
| SendTaskHeartbeat | Activities and callbacks | Adapter-served | Full surface | Renews the active task's heartbeat window without extending its absolute timeout. |
| SendTaskSuccess | Activities and callbacks | Adapter-served | Most usage | Durably records completion of the active task attempt and wakes the Temporal workflow; stale tokens are refused and a transport acknowledgment is insufficient. |
| TestState | Diagnostics | Supported | Full surface | Evaluates a single state through the same ASL evaluator; an external Task call requires the caller's authorization and a supported integration. |
| ValidateStateMachineDefinition | Diagnostics | Supported | Most usage | Validates ASL without creating a resource and reports diagnostics, including unsupported Task resources and invocation patterns. |
| DescribeMapRun | Distributed Map | Supported | Most usage | Returns Map Run status, item counts, concurrency and tolerated-failure settings. |
| ListMapRuns | Distributed Map | Supported | Full surface | Lists an execution's Map Runs. |
| UpdateMapRun | Distributed Map | Supported | Full surface | Updates concurrency and failure thresholds in the running interpreter; an update that cannot reach it fails explicitly. Existing child work is retained. |
| DescribeExecution | Executions | Supported | Common | Returns Standard execution status, input, output, failure and redrive details through the adapter's execution record. |
| GetExecutionHistory | Executions | Supported | Most usage | Returns Step Functions events in causal order, including event links and timestamps; Temporal history is translated into the public event model. Express has no API history. |
| ListExecutions | Executions | Supported | Common | Lists Standard executions by state machine or Map Run, with status filters and pagination. |
| RedriveExecution | Executions | Supported | Most usage | Resumes eligible unsuccessful Standard work under the same execution identity and revision within the redrive window; successful states are retained and rerun states reset their retry counters. |
| StartExecution | Executions | Supported | Common | Admits a Standard execution durably and runs the selected ASL revision as a Temporal workflow. Standard name/input deduplication is kept; Express uses a separate short-lived execution path and fresh starts are not deduplicated. |
| StartSyncExecution | Executions | Supported | Most usage | Returns the result of an Express execution within its five-minute limit, including execution failures in the response body; caller disconnection does not cancel accepted work. |
| StopExecution | Executions | Supported | Common | Stops the Standard workflow and records ABORTED with the supplied error and cause; cancellation of an already accepted external effect depends on its integration. |
| CreateStateMachine | State machines | Supported | Common | Validates ASL and stores the definition, role, mode, encryption, logging and tags; unsupported integrations are rejected. |
| DeleteStateMachine | State machines | Supported | Common | Reports DELETING, terminates executions at their next state transition and retires the definition, versions and aliases once executions have closed. Express deletion is eventually consistent. |
| DescribeStateMachine | State machines | Supported | Common | Returns the adapter's definition, role, mode, revision and configuration. |
| DescribeStateMachineForExecution | State machines | Supported | Most usage | Returns the immutable definition and revision selected for a Standard execution. |
| ListStateMachines | State machines | Supported | Common | Lists state machines using opaque pagination tokens. |
| UpdateStateMachine | State machines | Supported | Common | Creates a new revision for subsequent executions; active executions retain their selected definition and runtime version. |
| ListTagsForResource | Tags | Supported | Full surface | Returns the resource's tags. |
| TagResource | Tags | Supported | Full surface | Attaches tags to state-machine or Activity records. |
| UntagResource | Tags | Supported | Full surface | Removes tags from the adapter's resource record. |
| CreateStateMachineAlias | Versions and aliases | Supported | Most usage | Stores weighted routing to one or two versions; each new execution retains the selected version. |
| DeleteStateMachineAlias | Versions and aliases | Supported | Full surface | Deletes the alias without interrupting executions previously started through it. |
| DeleteStateMachineVersion | Versions and aliases | Supported | Full surface | Deletes an unreferenced version; a version used by an alias cannot be deleted. |
| DescribeStateMachineAlias | Versions and aliases | Supported | Full surface | Returns the alias and routing configuration. |
| ListStateMachineAliases | Versions and aliases | Supported | Full surface | Lists aliases with pagination. |
| ListStateMachineVersions | Versions and aliases | Supported | Most usage | Lists published versions with pagination. |
| PublishStateMachineVersion | Versions and aliases | Supported | Most usage | Publishes an immutable numbered revision. |
| UpdateStateMachineAlias | Versions and aliases | Supported | Full surface | Updates routing for subsequent starts; existing executions keep their selected version. |

#### How it works

Your application keeps calling the Step Functions API in the target environment. A Tensor9 service adapter stores definitions, revisions, versions and aliases, and starts Standard executions in a Temporal Cloud namespace that the customer owns. Interpreter workers maintained by Tensor9 run beside the adapter in the deployment environment and run the original Amazon States Language (ASL) definition.

Temporal operates the workflow service and stores execution history in the namespace's region. The workers run the orchestration and make the service calls; Temporal Cloud does not host them. Express executions run separately in the adapter, on a short-lived path.

#### Connecting the namespace

You connect an existing namespace that the customer owns, using its full namespace ID, its endpoint and an authorized credential. The first connection uses mutual TLS. The customer creates the namespace and handles billing and account administration. Deploying or removing the adapter never creates or deletes the namespace.

The workers need network access to Temporal Cloud and to the service adapters that Tasks call. An application on Azure, Google Cloud, Kubernetes or OCI can use the namespace wherever its history is stored. Choose the namespace region and connectivity to meet the deployment's data-residency requirements. This option needs access to the managed service, so it does not work in a disconnected deployment.

#### An execution waiting for approval

`StartExecution` returns an AWS execution ARN while the Standard workflow runs. The interpreter uses Temporal timers for Wait states, activities for external calls, and child workflows for Parallel branches and Map items. Your ASL `Retry` and `Catch` rules decide each attempt. When a service gives an unclear answer, the integration adapter handles it under its own idempotency rules.

For an approval task using `.waitForTaskToken`, an authorized callback goes to the Step Functions adapter in the deployment environment. The adapter records the result for the exact attempt that is waiting and passes it to the workflow in Temporal Cloud. The caller gets a success response only after that result is saved; a notification from Temporal alone is not enough.

If a worker restarts during the wait, a compatible worker resumes from Temporal's history. The execution keeps its ARN, its definition and its worker version. Switching the deployment to another engine affects only later executions; it does not move this waiting approval.

#### Limitations

Where Step Functions and Temporal Cloud differ

* **Execution history behaves differently: it is stored outside the deployment environment.** Temporal Cloud stores workflow history and any encoded payloads in the namespace's region. Encrypting payloads does not move that storage into the local cluster. Keep secrets out of searchable metadata.
* **AWS service integrations are not provided by the namespace.** A Task's `Resource` must map to a supported service operation and invocation pattern in this deployment. `.sync` and callback behavior depend on that integration.
* **Capacity behaves differently: service and worker limits both apply.** Namespace limits, history size, worker slots and downstream service limits affect throughput. Choosing Temporal Cloud does not reserve concurrency for every Map item.
* **The AWS console view and X-Ray tracing are not supported.** Temporal Web UI shows workflow history and pending work, not the AWS console's ASL graph. Decoding payloads needs permission. Logs go to the deployment's logging destination, and enabling X-Ray tracing is rejected.
* **Express executions behave differently.** They have no Standard execution-history API and cannot use Activities, Distributed Map, `.sync` or `.waitForTaskToken`.

#### Other considerations

* **Responsibility and cost.** Temporal operates the managed service. The customer owns the account, namespace, credentials and billing. Tensor9 maintains the service adapter and interpreter workers, whose compute runs in the deployment environment.
* **Retention and encryption.** Set namespace retention to match the adapter's history and redrive retention requirements. If you use customer-managed encryption, configure the workers' payload codec and key access. Web UI access and permission to decode payloads are separate controls.
* **Moving from AWS.** Deploy definitions, versions and aliases through the adapter. Existing AWS executions finish on AWS; running executions, outstanding task tokens and past runs are not imported into Temporal Cloud.
* **Credentials and removal.** Rotate namespace credentials while keeping access for running executions. Removing the adapter releases its connection and its workers, and leaves the customer's namespace and unrelated workflows intact.

See Temporal's [namespace and region configuration](https://docs.temporal.io/cloud/namespaces), [worker architecture](https://docs.temporal.io/encyclopedia/architecture/temporal-sdks) and [Web UI documentation](https://docs.temporal.io/web-ui).

#### Example monthly charges

This Tensor9 Cloud Adapter scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. [How Tensor9 estimates costs](https://docs.tensor9.com/cloud-adapter-early-access/costs/overview.md) explains the method and what the estimates include.

##### Step Functions Standard · State transitions

Feature: Step Functions Standard.

Estimated monthly service charges by State transitions. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: Temporal Cloud (global list); currency: USD.

![Step Functions Standard · State transitions: monthly service charges by State transitions. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/a46541d1500d2cd7d06abc1834452779d7f4c49596607716dc1a6ba8eb32aac8-light.svg)

![Step Functions Standard · State transitions: monthly service charges by State transitions. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/179a1ad1026776d7ce5e640805913cb13fec343f086e021809b97ac7731f8fd5-dark.svg)

Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples.

Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more.

| State transitions (per second) | Step Functions | Target scenario | Temporal Cloud (Managed) | Difference |
| -: | -: | - | -: | -: |
| 0 | 0.00 | Temporal Cloud (Managed) (one staging copy) | 618.18 | 618.18 |
| 0 | 0.00 | Temporal Cloud (Managed) (two staging copies) | 736.36 | 736.36 |
| 1 | 65.70 | Temporal Cloud (Managed) (one staging copy) | 755.98 | 690.28 |
| 1 | 65.70 | Temporal Cloud (Managed) (two staging copies) | 874.16 | 808.46 |
| 10 | 657.00 | Temporal Cloud (Managed) (one staging copy) | 2,544.98 | 1,887.98 |
| 10 | 657.00 | Temporal Cloud (Managed) (two staging copies) | 2,663.16 | 2,006.16 |
| 100 | 6,570.00 | Temporal Cloud (Managed) (one staging copy) | 14,809.64 | 8,239.64 |
| 100 | 6,570.00 | Temporal Cloud (Managed) (two staging copies) | 15,060.80 | 8,490.80 |
| 1,000 | 65,700.00 | Temporal Cloud (Managed) (one staging copy) | 136,234.20 | 70,534.20 |
| 1,000 | 65,700.00 | Temporal Cloud (Managed) (two staging copies) | 138,456.23 | 72,756.23 |
| 10,000 | 657,000.00 | Temporal Cloud (Managed) (one staging copy) | 1,338,313.25 | 681,313.25 |
| 10,000 | 657,000.00 | Temporal Cloud (Managed) (two staging copies) | 1,348,077.55 | 691,077.55 |

Estimated allocation, not benchmark calibrated: sized from 2 vCPU, 8 GiB memory and 100 GiB SSD at 0 per second to 96 vCPU, 624 GiB memory and 21,655 GiB SSD at 10,000 per second.

**Curve assumptions**

| Target scenario | Assumption | Value | Unit |
| - | - | -: | - |
| Temporal Cloud (Managed) (one staging copy) | Origin list price · Standard state transitions | 0.000025 | USD/transitions |
| Temporal Cloud (Managed) (one staging copy) | Target steps per source transition | 2 | steps |
| Temporal Cloud (Managed) (one staging copy) | History bytes per transition | 3,072 | bytes |
| Temporal Cloud (Managed) (one staging copy) | History retention | 7 | days |
| Temporal Cloud (Managed) (one staging copy) | Worker CPU per transition | 5 | vCPU-ms |
| Temporal Cloud (Managed) (one staging copy) | Target price guess · read | 0 | USD/read |
| Temporal Cloud (Managed) (one staging copy) | Target price guess · write | 0 | USD/write |
| Temporal Cloud (Managed) (one staging copy) | Target list price · provider operation | 0.00005 | USD/provider operation |
| Temporal Cloud (Managed) (one staging copy) | Target list price · GiB-month | 0.7665 | USD/GiB-month |
| Temporal Cloud (Managed) (one staging copy) | Target price guess · published GiB | 0 | USD/published GiB |
| Temporal Cloud (Managed) (one staging copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Temporal Cloud (Managed) (one staging copy) | Target price guess · network GiB | 0 | USD/network GiB |
| Temporal Cloud (Managed) (one staging copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Temporal Cloud (Managed) (one staging copy) | Target price guess · vCPU-hour | 0 | USD/vCPU-hour |
| Temporal Cloud (Managed) (one staging copy) | Target price guess · GiB-hour | 0 | USD/GiB-hour |
| Temporal Cloud (Managed) (one staging copy) | Target price guess · resource-hour | 0 | USD/resource-hour |
| Temporal Cloud (Managed) (one staging copy) | Target price guess · resource-month | 0 | USD/resource-month |
| Temporal Cloud (Managed) (one staging copy) | Target price guess · input token | 0 | USD/input token |
| Temporal Cloud (Managed) (one staging copy) | Target price guess · output token | 0 | USD/output token |
| Temporal Cloud (Managed) (one staging copy) | Included before billing · provider operation | 2,500,000 | provider operation |
| Temporal Cloud (Managed) (one staging copy) | Included before billing · GiB-month | 100 | GiB-month |
| Temporal Cloud (Managed) (one staging copy) | Target monthly base charge · list price | 500 | USD/month |
| Temporal Cloud (Managed) (one staging copy) | Approximate target service minimum | 0 | USD/month |
| Temporal Cloud (Managed) (one staging copy) | Minimum primary CPU | 2 | vCPU |
| Temporal Cloud (Managed) (one staging copy) | Minimum primary RAM | 8 | GiB |
| Temporal Cloud (Managed) (one staging copy) | Minimum primary disk | 100 | GiB |
| Temporal Cloud (Managed) (one staging copy) | Additional full-price standby copy | 0 | 0 or 1 |
| Temporal Cloud (Managed) (one staging copy) | Allocated share of provisioned cost | 1 | fraction |
| Temporal Cloud (Managed) (one staging copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Temporal Cloud (Managed) (one staging copy) | Planning peak / mean work | 2 | multiplier |
| Temporal Cloud (Managed) (one staging copy) | Planning primary CPU utilization | 0.7 | fraction |
| Temporal Cloud (Managed) (one staging copy) | Resident state reserved in RAM | 0.1 | fraction |
| Temporal Cloud (Managed) (one staging copy) | Planning disk utilization | 0.8 | fraction |
| Temporal Cloud (Managed) (one staging copy) | Maintenance and log disk reserve | 20 | GiB |
| Temporal Cloud (Managed) (one staging copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Temporal Cloud (Managed) (one staging copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Temporal Cloud (Managed) (one staging copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Temporal Cloud (Managed) (one staging copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Temporal Cloud (Managed) (one staging copy) | Dependent object sink write price guess | 0.000005 | USD/write |
| Temporal Cloud (Managed) (two staging copies) | Origin list price · Standard state transitions | 0.000025 | USD/transitions |
| Temporal Cloud (Managed) (two staging copies) | Target steps per source transition | 2 | steps |
| Temporal Cloud (Managed) (two staging copies) | History bytes per transition | 3,072 | bytes |
| Temporal Cloud (Managed) (two staging copies) | History retention | 7 | days |
| Temporal Cloud (Managed) (two staging copies) | Worker CPU per transition | 5 | vCPU-ms |
| Temporal Cloud (Managed) (two staging copies) | Target price guess · read | 0 | USD/read |
| Temporal Cloud (Managed) (two staging copies) | Target price guess · write | 0 | USD/write |
| Temporal Cloud (Managed) (two staging copies) | Target list price · provider operation | 0.00005 | USD/provider operation |
| Temporal Cloud (Managed) (two staging copies) | Target list price · GiB-month | 0.7665 | USD/GiB-month |
| Temporal Cloud (Managed) (two staging copies) | Target price guess · published GiB | 0 | USD/published GiB |
| Temporal Cloud (Managed) (two staging copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Temporal Cloud (Managed) (two staging copies) | Target price guess · network GiB | 0 | USD/network GiB |
| Temporal Cloud (Managed) (two staging copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Temporal Cloud (Managed) (two staging copies) | Target price guess · vCPU-hour | 0 | USD/vCPU-hour |
| Temporal Cloud (Managed) (two staging copies) | Target price guess · GiB-hour | 0 | USD/GiB-hour |
| Temporal Cloud (Managed) (two staging copies) | Target price guess · resource-hour | 0 | USD/resource-hour |
| Temporal Cloud (Managed) (two staging copies) | Target price guess · resource-month | 0 | USD/resource-month |
| Temporal Cloud (Managed) (two staging copies) | Target price guess · input token | 0 | USD/input token |
| Temporal Cloud (Managed) (two staging copies) | Target price guess · output token | 0 | USD/output token |
| Temporal Cloud (Managed) (two staging copies) | Included before billing · provider operation | 2,500,000 | provider operation |
| Temporal Cloud (Managed) (two staging copies) | Included before billing · GiB-month | 100 | GiB-month |
| Temporal Cloud (Managed) (two staging copies) | Target monthly base charge · list price | 500 | USD/month |
| Temporal Cloud (Managed) (two staging copies) | Approximate target service minimum | 0 | USD/month |
| Temporal Cloud (Managed) (two staging copies) | Minimum primary CPU | 2 | vCPU |
| Temporal Cloud (Managed) (two staging copies) | Minimum primary RAM | 8 | GiB |
| Temporal Cloud (Managed) (two staging copies) | Minimum primary disk | 100 | GiB |
| Temporal Cloud (Managed) (two staging copies) | Additional full-price standby copy | 1 | 0 or 1 |
| Temporal Cloud (Managed) (two staging copies) | Allocated share of provisioned cost | 1 | fraction |
| Temporal Cloud (Managed) (two staging copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Temporal Cloud (Managed) (two staging copies) | Planning peak / mean work | 2 | multiplier |
| Temporal Cloud (Managed) (two staging copies) | Planning primary CPU utilization | 0.7 | fraction |
| Temporal Cloud (Managed) (two staging copies) | Resident state reserved in RAM | 0.1 | fraction |
| Temporal Cloud (Managed) (two staging copies) | Planning disk utilization | 0.8 | fraction |
| Temporal Cloud (Managed) (two staging copies) | Maintenance and log disk reserve | 20 | GiB |
| Temporal Cloud (Managed) (two staging copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Temporal Cloud (Managed) (two staging copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Temporal Cloud (Managed) (two staging copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Temporal Cloud (Managed) (two staging copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Temporal Cloud (Managed) (two staging copies) | Dependent object sink write price guess | 0.000005 | USD/write |

* Includes source retries; target amplification is applied only once. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements.
* Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → Temporal Cloud (global list), USD/month.
* Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
* Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
* Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve's workload note.
* Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
* Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
* Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
* Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
* A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
* This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
* Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts.
* A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent.
* Managed steps, worker CPU and durable history are distinct target cost components. Internal/external step split needs target-specific assumptions.
* Standard-only origin profile; no inference of Express duration, memory or task execution cost.
* Temporal Cloud bills Actions, active and retained workflow-history storage, and a plan. The profile selects the Business plan: the greater of USD 500/month or 10% of consumption, with 2.5 million Actions, 2.5 GB of active and 100 GB of retained storage included. The 500 base is exact while consumption stays under USD 5,000/month; above that the plan adds 10% of consumption, which is not modeled. Pay-as-you-go Actions graduate from USD 50 to 25 per million by volume beyond the included Actions. History storage bills USD 0.042 per active GBh and 0.00105 per retained GBh. The family's retained history of closed executions bills at the retained rate beyond the 100 GB included; active history of running executions is small for Step Functions workloads and is not modeled. The Developer plan (no base, 10% of consumption, USD 50 per million Actions at every volume) is not selected. Workers run on the customer's own compute.
* Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1\_0\_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.
* Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing ([https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size](https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size)): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.
* Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)). The 20 GiB reserve exceeds PostgreSQL's 1 GB default max\_wal\_size; the remainder of that reserve is unmeasured.
* CPU tiers double from 2 vCPUs to the target's largest node at 4 GiB per vCPU; each target's documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead.
* No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.
* Node bounds: Cloud SQL Enterprise allows 1-96 vCPUs at 0.9-6.5 GB per vCPU and up to 64 TB with a dedicated vCPU ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)).
* Stored GiB already includes the origin family's physical footprint assumptions; no second storage amplification is applied.
* The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.
* Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
* AWS Price List API, AmazonStates offer: [https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonStates/current/us-east-1/index.json](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonStates/current/us-east-1/index.json)
* Temporal Cloud pricing: [https://docs.temporal.io/cloud/pricing](https://docs.temporal.io/cloud/pricing)

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied.

Excluded costs and workload features:

* Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them.
* Destination application execution and separately billed downstream services; supply those allocations separately.
* Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
* Unmodeled dependent services, task execution and operations outside the selected workload family.

List prices read: 2026-10-22. Model: `plan-da083b8e1fb5732303b4a2a29ceac0278a9dbc01` / `2026-10-22.planning.2`. Curve: `workload-1`.

Sources: [AWS Price List API, AmazonStates offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonStates/current/us-east-1/index.json), [Temporal Cloud pricing](https://docs.temporal.io/cloud/pricing).

**Step Functions Standard → Temporal Cloud (Managed): Authored native-usage planning example.** Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts.

Scenario source region: us-east-1. Scenario target region: Temporal Cloud (global list). Currency: USD.

| Monthly component | USD |
| - | -: |
| Origin: Standard state transitions | 0.00 |
| Target: Target retained physical data after 100 included | 0.00 |
| Target: Additional broker replica storage | 0.00 |
| Target: Target native provider operations after 2500000 included | 0.00 |
| Target: Execution or worker CPU | 0.00 |
| Target: Execution or worker RAM | 0.00 |
| Target: Selected billable network | 0.00 |
| Target: Independent native resources | 0.00 |
| Target: Independent native resources | 0.00 |
| Target: Target monthly base charge | 500.00 |
| Target: Durable staging CPU | 60.30 |
| Target: Durable staging RAM | 40.88 |
| Target: Durable staging disk | 17.00 |
| **Origin service subtotal** | **0.00** |
| **Target service subtotal** | **618.18** |

Estimated allocation, not benchmark calibrated: sized at 2 vCPU, 8 GiB memory and 100 GiB SSD for this scenario.

Unestimated components: Adapter hosting, Tensor9 fees. A modeled adapted total and savings require these costs.

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied.

Excluded costs and workload features:

* Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them.
* Destination application execution and separately billed downstream services; supply those allocations separately.
* Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
* Unmodeled dependent services, task execution and operations outside the selected workload family.

**Scenario assumptions**

| Input | Value | Unit |
| - | -: | - |
| Origin list price · Standard state transitions | 0.000025 | USD/transitions |
| Target steps per source transition | 2 | steps |
| History bytes per transition | 3,072 | bytes |
| History retention | 7 | days |
| Worker CPU per transition | 5 | vCPU-ms |
| Target price guess · read | 0 | USD/read |
| Target price guess · write | 0 | USD/write |
| Target list price · provider operation | 0.00005 | USD/provider operation |
| Target list price · GiB-month | 0.7665 | USD/GiB-month |
| Target price guess · published GiB | 0 | USD/published GiB |
| Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Target price guess · network GiB | 0 | USD/network GiB |
| Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Target price guess · vCPU-hour | 0 | USD/vCPU-hour |
| Target price guess · GiB-hour | 0 | USD/GiB-hour |
| Target price guess · resource-hour | 0 | USD/resource-hour |
| Target price guess · resource-month | 0 | USD/resource-month |
| Target price guess · input token | 0 | USD/input token |
| Target price guess · output token | 0 | USD/output token |
| Included before billing · provider operation | 2,500,000 | provider operation |
| Included before billing · GiB-month | 100 | GiB-month |
| Target monthly base charge · list price | 500 | USD/month |
| Approximate target service minimum | 0 | USD/month |
| Minimum primary CPU | 2 | vCPU |
| Minimum primary RAM | 8 | GiB |
| Minimum primary disk | 100 | GiB |
| Additional full-price standby copy | 0 | 0 or 1 |
| Allocated share of provisioned cost | 1 | fraction |
| Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Planning peak / mean work | 2 | multiplier |
| Planning primary CPU utilization | 0.7 | fraction |
| Resident state reserved in RAM | 0.1 | fraction |
| Planning disk utilization | 0.8 | fraction |
| Maintenance and log disk reserve | 20 | GiB |
| Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Dependent object sink write price guess | 0.000005 | USD/write |
| Standard state transitions | 0 | transitions |

* Translated reads: 0 operations.

* Translated writes: 0 operations.

* Translated resident physical data: 0 GiB-month.

* Native provider operations: 0 operations.

* Published payload: 0 GiB.

* Delivered payload: 0 GiB.

* Allocated execution CPU: 0 vCPU-hour.

* Allocated execution RAM: 0 GiB-hour.

* Independent resource allocation: 0 resource-hour.

* Independent inventory: 0 resource-month.

* Input tokens: 0 tokens.

* Output tokens: 0 tokens.

* Billable network: 0 GiB.

* Dependent object sink retained data: 0 GiB-month.

* Dependent object sink writes: 0 writes.

* Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.

* Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.

* Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.

* Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.

* A declared adapter mapping and cost model do not establish implementation availability or service equivalence.

* This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.

* Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts.

* A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent.

* Managed steps, worker CPU and durable history are distinct target cost components. Internal/external step split needs target-specific assumptions.

* Standard-only origin profile; no inference of Express duration, memory or task execution cost.

* Temporal Cloud bills Actions, active and retained workflow-history storage, and a plan. The profile selects the Business plan: the greater of USD 500/month or 10% of consumption, with 2.5 million Actions, 2.5 GB of active and 100 GB of retained storage included. The 500 base is exact while consumption stays under USD 5,000/month; above that the plan adds 10% of consumption, which is not modeled. Pay-as-you-go Actions graduate from USD 50 to 25 per million by volume beyond the included Actions. History storage bills USD 0.042 per active GBh and 0.00105 per retained GBh. The family's retained history of closed executions bills at the retained rate beyond the 100 GB included; active history of running executions is small for Step Functions workloads and is not modeled. The Developer plan (no base, 10% of consumption, USD 50 per million Actions at every volume) is not selected. Workers run on the customer's own compute.

* Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1\_0\_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.

* Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing ([https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size](https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size)): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.

* Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)). The 20 GiB reserve exceeds PostgreSQL's 1 GB default max\_wal\_size; the remainder of that reserve is unmeasured.

* CPU tiers double from 2 vCPUs to the target's largest node at 4 GiB per vCPU; each target's documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead.

* No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.

* Node bounds: Cloud SQL Enterprise allows 1-96 vCPUs at 0.9-6.5 GB per vCPU and up to 64 TB with a dedicated vCPU ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)).

* Stored GiB already includes the origin family's physical footprint assumptions; no second storage amplification is applied.

* The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.

* Copies and allocation fractions change cost only; they do not increase modeled primary capacity.

List prices read: 2026-10-22. Model: `plan-da083b8e1fb5732303b4a2a29ceac0278a9dbc01` / `2026-10-22.planning.2`. Scenario: `planning-example`.

Sources: [AWS Price List API, AmazonStates offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonStates/current/us-east-1/index.json), [Temporal Cloud pricing](https://docs.temporal.io/cloud/pricing).

## On Google Cloud

### Cloud Workflows

| Capability | Area | Support | Operations | Notes |
| - | - | - | - | - |
| Data flow and expressions | Amazon States Language | Supported | - | InputPath, Parameters, ResultSelector, ResultPath, OutputPath, intrinsic functions, JSONata, variables and Assign are evaluated for the workflow by an adapter helper, since the Workflows language has no equivalent |
| Distributed Map | Amazon States Language | Supported | - | a Map Run fans out into child Workflows executions scheduled by the parent within MaxConcurrency; item slots and ordered output survive a restart, an item retry never becomes a whole-Map retry, and UpdateMapRun reaches children already running or fails with a named error. A large Map Run is paced by shared admission and backpressure without any change to its semantics |
| Error handling | Amazon States Language | Supported | - | Retry and Catch with backoff, jitter and error matching; one ASL attempt is one submission, never multiplied by the platform's own retry |
| Parallel and inline Map | Amazon States Language | Supported | - | Cloud Workflows nests parallel steps two deep and runs 20 branches at once within one execution; a Parallel or Map beyond that runs its branches as child executions, so the definition's shape is preserved |
| Wait states and timeouts | Amazon States Language | Supported | - | a Wait is served by the engine itself, which sleeps within the execution for up to a year; state and execution timeouts fire as States.Timeout |
| Encryption configuration | Configuration | Supported | - | a customer-managed key names a key served by the KMS mapping on the same Cloud Adapter deployment (Cloud KMS on Google Cloud); the definition, the prepared modules' data and execution payloads are encrypted under it and become unreadable when it is revoked |
| Logging configuration | Configuration | Partial | - | includeExecutionData decides whether execution payloads are written at all, and the configured destination decides whose log they reach; the entries land in Cloud Logging, since CloudWatch Logs is a service the Cloud Adapter deployment does not adapt |
| Tracing configuration | Configuration | Out of scope | - | X-Ray is not adapted, so a configuration that enables tracing is rejected at CreateStateMachine and UpdateStateMachine rather than stored and ignored |
| EXPRESS workflows | Execution model | Supported | - | an Express execution is an inline run in the adapter with no durable record, within the 5-minute ceiling; as on AWS it has no history through the API, cannot use Activities, Distributed Map, .sync or .waitForTaskToken, and DescribeStateMachineForExecution, GetExecutionHistory, ListExecutions, RedriveExecution and StopExecution refuse it. A fresh Express start is never deduplicated, and an interrupted delivery is retried under the same accepted start |
| STANDARD workflows | Execution model | Supported | - | exactly-once execution with a durable record, up to one year, which is also the ceiling of a Cloud Workflows execution |
| Service integrations | Integrations | Partial | - | a Task Resource naming an AWS service is served by that service's mapping on the same Cloud Adapter deployment, including .sync and .waitForTaskToken, nested executions and Task.Credentials role overrides; a Resource naming a service the Cloud Adapter deployment does not serve is refused at CreateStateMachine |
| Payload and definition limits | Limits | Supported | - | the 256 KiB payload ceiling and the 1 MB definition ceiling are enforced at the API; a definition larger than Workflows' 128 KB source limit is split across prepared modules, so the AWS ceiling is the one you plan against |

| Operation | Area | Support | Depth | Notes |
| - | - | - | - | - |
| CreateActivity | Activities | Adapter-served | Most usage | an Activity is a record and a task queue the adapter serves; Cloud Workflows has callback endpoints but nothing an outside worker long-polls by name |
| DeleteActivity | Activities | Adapter-served | Full surface | deletes the Activity even while workers hold tasks from it, as on AWS; a worker's next SendTaskSuccess for such a task answers TaskDoesNotExist |
| DescribeActivity | Activities | Adapter-served | Full surface | returns the Activity's ARN, name and creation date |
| GetActivityTask | Activities | Adapter-served | Most usage | holds the poll open for up to 60 seconds and hands one task to one worker with an adapter-minted token; an empty poll returns a null token |
| ListActivities | Activities | Adapter-served | Full surface | lists the Activities |
| SendTaskFailure | Activities | Adapter-served | Most usage | fails the task with the error and cause supplied |
| SendTaskHeartbeat | Activities | Adapter-served | Full surface | renews the heartbeat window; a lapsed heartbeat fails the task with States.Timeout |
| SendTaskSuccess | Activities | Adapter-served | Most usage | completes the task the token identifies, once; the waiting Workflows execution resumes through its callback |
| TestState | Diagnostics | Supported | Full surface | evaluates a single state without starting an execution; a Task state that reaches a real service does so under the caller's own authorization |
| ValidateStateMachineDefinition | Diagnostics | Supported | Most usage | validates a definition without creating anything and returns diagnostics with severity; a Task whose Resource names a service the Cloud Adapter deployment does not serve is reported here |
| DescribeMapRun | Distributed Map | Supported | Most usage | returns the Map Run's status, item counts, tolerated-failure settings and concurrency |
| ListMapRuns | Distributed Map | Supported | Full surface | lists the Map Runs of an execution |
| UpdateMapRun | Distributed Map | Supported | Full surface | changes MaxConcurrency or the tolerated-failure thresholds of a running Map Run; children in flight continue |
| DescribeExecution | Executions | Supported | Common | returns status, input, output, error, cause and redrive details |
| GetExecutionHistory | Executions | Supported | Most usage | returns the execution's transitions as Step Functions events in causal order, derived from the adapter's record and the Workflows execution; EXPRESS executions have no history through the API, as on AWS |
| ListExecutions | Executions | Supported | Common | lists executions by state machine or Map Run with status and redrive filters |
| RedriveExecution | Executions | Supported | Most usage | resumes a failed, aborted or timed-out STANDARD execution from its unsuccessful states within 14 days, under the same execution ARN and revision; successful states are not rerun and only failed Map Run children restart |
| StartExecution | Executions | Supported | Common | admits the execution, pins its revision and runs it: a STANDARD execution as a Cloud Workflows execution of that revision's prepared workflow under the workflow's own service account, an EXPRESS execution as an inline run in the adapter with no durable record. STANDARD starts are idempotent on name and input while the execution runs, ExecutionAlreadyExists is returned for a closed execution or a different input, and a name is reusable 90 days after closing; EXPRESS starts are never deduplicated |
| StartSyncExecution | Executions | Supported | Most usage | the synchronous result API of an EXPRESS state machine: the request is held open until the inline run completes or the 5-minute ceiling passes, a failed run is reported in the response body, and a caller that disconnects does not cancel accepted work |
| StopExecution | Executions | Supported | Common | cancels the Workflows execution and records the ABORTED outcome with the error and cause supplied |
| CreateStateMachine | State machines | Supported | Common | validates the definition, records the state machine, and prepares for that revision an immutable set of workflow modules and a manifest in Cloud Workflows; the definition itself is kept as written |
| DeleteStateMachine | State machines | Supported | Common | succeeds at once and reads DELETING until running executions complete; the prepared modules of its revisions are retired with it |
| DescribeStateMachine | State machines | Supported | Common | returns the definition, role, type, revision and configuration from the adapter's record |
| DescribeStateMachineForExecution | State machines | Supported | Most usage | returns the definition and revision the execution is pinned to |
| ListStateMachines | State machines | Supported | Common | lists state machines with opaque pagination tokens |
| UpdateStateMachine | State machines | Supported | Common | returns a new revision with its own prepared modules; executions in flight keep the revision and modules they started on |
| ListTagsForResource | Tags | Supported | Full surface | lists the tags |
| TagResource | Tags | Supported | Full surface | attaches tags to a state machine or Activity |
| UntagResource | Tags | Supported | Full surface | removes tags |
| CreateStateMachineAlias | Versions and aliases | Supported | Most usage | an alias routes to one or two versions by weight; an execution pins the version it was routed to |
| DeleteStateMachineAlias | Versions and aliases | Supported | Full surface | deletes the alias; executions it routed keep running |
| DeleteStateMachineVersion | Versions and aliases | Supported | Full surface | deletes a version; refused while an alias still routes to it |
| DescribeStateMachineAlias | Versions and aliases | Supported | Full surface | returns the alias and its routing |
| ListStateMachineAliases | Versions and aliases | Supported | Full surface | lists the aliases |
| ListStateMachineVersions | Versions and aliases | Supported | Most usage | lists the published versions |
| PublishStateMachineVersion | Versions and aliases | Supported | Most usage | publishes the current revision as an immutable numbered version; the version shares the revision's prepared modules |
| UpdateStateMachineAlias | Versions and aliases | Supported | Full surface | changes the routing for executions started afterwards |

#### How it works

Your application keeps calling the Step Functions API. On Google Cloud those calls reach a Tensor9 service adapter instead of AWS. The adapter holds each state machine as a record (the Amazon States Language definition as you wrote it, the role, the type, the versions, the aliases and the tags) and answers every `states:` operation from that record and from the executions it has admitted.

Cloud Workflows executes its own language, so for each revision of a state machine the adapter prepares an immutable set of bounded workflow modules and a manifest in Cloud Workflows. Four quotas make that split necessary: a single workflow source is capped at 128 KB against the 1 MB an ASL definition may be, parallel steps nest two deep, 20 branches run at once within one execution, and variables, arguments and events share 512 KB. A Parallel or Map that exceeds the depth or width runs its branches as child executions; a large definition spans several modules. Data flow and expression semantics (paths, intrinsics, JSONata, Choice rules) are evaluated by an adapter helper the workflow calls, so ASL behaves as it does on AWS rather than as an approximation in the Workflows language.

StartExecution admits the execution and pins its revision. A Standard execution runs as a Workflows execution of that revision's prepared workflow; an Express execution runs inline in the adapter and leaves no durable record, as on AWS. The workflow runs under a service account the adapter creates for that revision, so its calls to other services present an identity of their own and are authorized per workflow rather than for the whole project. A Task state's Resource names an AWS service and is served by that service's mapping on the same Cloud Adapter deployment; a `.waitForTaskToken` integration parks the execution on a Workflows callback until SendTaskSuccess or SendTaskFailure arrives. Each Task effect is authorized against the state machine's execution role, or the Task.Credentials role where one is set, before it is made. GetExecutionHistory returns Step Functions events built from the adapter's record and the Workflows execution in causal order.

#### Infrastructure-only translation

A deployment that translates infrastructure only, with no adapter, treats the state machine as a Terraform resource. The Tensor9 compiler emits a Cloud Workflows workflow with the state machine's name in the Cloud Adapter deployment's region and stops there: the Amazon States Language definition has no mechanical translation to the Workflows language (Task, Wait, Choice, Map and Parallel states against Workflows steps, switch, try/retry/except, for and parallel), so the workflow's source is left unset and reported as an omission, and the logic must be re-authored by hand in Workflows YAML. The execution role, an EXPRESS type, the logging configuration and tags are reported as lossy for the same reason: the role is a separate IAM object with no service-account email to bind, Workflows has one durable execution model, logging is a Cloud Logging setting, and label keys must be lowercase without dots.

That path exists so a deployment with a state machine still produces a valid Google Cloud stack; it does not answer the Step Functions API, and an application that calls `states:` needs the adapter above.

#### Limitations

* **Activities are served by the adapter.** Cloud Workflows has callback endpoints but no resource a worker outside the platform long-polls by name, so an Activity is a queue the adapter serves: GetActivityTask holds the poll open for up to 60 seconds, the token is minted by the adapter, and a completion resumes the workflow through its callback. Workers need no code change; they must reach the adapter's endpoint. - **Large Map Runs are paced by the Cloud Adapter deployment.** A Map Run becomes child Workflows executions within MaxConcurrency, and a Parallel or inline Map wider than 20 branches also runs as child executions. A large Map Run is admitted with backpressure rather than all at once; its semantics do not change, and an UpdateMapRun that cannot reach children already running fails with a named error instead of reporting a change that did not happen. - **A ceiling reached mid-execution is named.** Cloud Workflows has budgets of its own, such as its step budget per execution. When one is reached inside a window AWS would still honour, the execution fails with an error naming the ceiling rather than as an ordinary timeout, and a task token outstanding for as long as AWS allows is either honoured or fails the same way. - **Definitions span modules.** A definition larger than 128 KB, or nested deeper than Workflows allows, is split across prepared modules. The split is the adapter's and is invisible to the API, but the prepared workflows are visible in the Google Cloud console, named per revision. - **Logs and traces do not reach CloudWatch or X-Ray.** `includeExecutionData` decides whether execution payloads are written at all and the configured destination decides whose log they reach; the entries land in Cloud Logging, since CloudWatch Logs is a service the Cloud Adapter deployment does not adapt. A `tracingConfiguration` that enables X-Ray tracing is rejected at CreateStateMachine and UpdateStateMachine rather than stored and ignored. - **Service integrations are bounded by the Cloud Adapter deployment.** A Resource naming a service the Cloud Adapter deployment does not serve is reported by ValidateStateMachineDefinition and refused at CreateStateMachine with an error naming the state. - **Without the adapter, the definition does not come across.** The infrastructure-only translation emits the Workflows shell and leaves its source unset; the state machine's logic must be re-authored by hand. - **The engine choice is fixed per execution.** Which engine runs a state machine is chosen per deployment and recorded with each execution. Changing it affects executions started afterwards; executions already running, their history and their outstanding task tokens stay on the engine they started on until they complete and their retention expires. Nothing migrates a live execution.

#### Other considerations

* **Migration.** State machines are created by your own deployment through CreateStateMachine, versions and aliases included; the adapter prepares each revision's modules at that point. Executions do not migrate, and AWS execution history is not copied. - **Who operates what.** Google operates Cloud Workflows and stores each execution's state and history for 90 days after it completes. Tensor9 operates the adapter, the prepared modules and the helper service; an adapter upgrade leaves a revision's prepared modules in place, so a running execution keeps the code it started with. - **Cost shape.** AWS bills a Standard execution per state transition. Cloud Workflows bills per step executed and per external call, and the adapter helper's evaluations count as external calls. - **What you see in the Google Cloud console.** Workflows named per revision and their executions, under the per-revision service accounts the adapter creates. State machines, execution ARNs and versions exist in the adapter's record and are what the Step Functions API returns.

#### Example monthly charges

This Tensor9 Cloud Adapter scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. [How Tensor9 estimates costs](https://docs.tensor9.com/cloud-adapter-early-access/costs/overview.md) explains the method and what the estimates include.

##### Step Functions Standard · State transitions

Feature: Step Functions Standard.

Estimated monthly service charges by State transitions. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD.

![Step Functions Standard · State transitions: monthly service charges by State transitions. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/6780b706a8068029385772227d6b6d574ab2975ba4fdc50e81d6e8ae5699e807-light.svg)

![Step Functions Standard · State transitions: monthly service charges by State transitions. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/243317b8f9a22542b22ff7a6c8ad1c31fc924c5a168d56908545d68130afe8b4-dark.svg)

Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples.

Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more.

| State transitions (per second) | Step Functions | Target scenario | Cloud Workflows | Difference |
| -: | -: | - | -: | -: |
| 0 | 0.00 | Cloud Workflows (one staging copy) | 118.18 | 118.18 |
| 0 | 0.00 | Cloud Workflows (two staging copies) | 236.36 | 236.36 |
| 1 | 65.70 | Cloud Workflows (one staging copy) | 170.69 | 104.99 |
| 1 | 65.70 | Cloud Workflows (two staging copies) | 288.87 | 223.17 |
| 10 | 657.00 | Cloud Workflows (one staging copy) | 643.73 | -13.27 |
| 10 | 657.00 | Cloud Workflows (two staging copies) | 761.91 | 104.91 |
| 100 | 6,570.00 | Cloud Workflows (one staging copy) | 5,507.11 | -1,062.89 |
| 100 | 6,570.00 | Cloud Workflows (two staging copies) | 5,758.27 | -811.73 |
| 1,000 | 65,700.00 | Cloud Workflows (one staging copy) | 54,781.99 | -10,918.01 |
| 1,000 | 65,700.00 | Cloud Workflows (two staging copies) | 57,004.02 | -8,695.98 |
| 10,000 | 657,000.00 | Cloud Workflows (one staging copy) | 535,364.24 | -121,635.76 |
| 10,000 | 657,000.00 | Cloud Workflows (two staging copies) | 545,128.54 | -111,871.46 |

Estimated allocation, not benchmark calibrated: sized from 2 vCPU, 8 GiB memory and 100 GiB SSD at 0 per second to 96 vCPU, 624 GiB memory and 21,655 GiB SSD at 10,000 per second.

**Curve assumptions**

| Target scenario | Assumption | Value | Unit |
| - | - | -: | - |
| Cloud Workflows (one staging copy) | Origin list price · Standard state transitions | 0.000025 | USD/transitions |
| Cloud Workflows (one staging copy) | Target steps per source transition | 2 | steps |
| Cloud Workflows (one staging copy) | History bytes per transition | 3,072 | bytes |
| Cloud Workflows (one staging copy) | History retention | 7 | days |
| Cloud Workflows (one staging copy) | Worker CPU per transition | 5 | vCPU-ms |
| Cloud Workflows (one staging copy) | Target price guess · read | 0 | USD/read |
| Cloud Workflows (one staging copy) | Target price guess · write | 0 | USD/write |
| Cloud Workflows (one staging copy) | Target list price · provider operation | 0.00001 | USD/provider operation |
| Cloud Workflows (one staging copy) | Target price guess · GiB-month | 0 | USD/GiB-month |
| Cloud Workflows (one staging copy) | Target price guess · published GiB | 0 | USD/published GiB |
| Cloud Workflows (one staging copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Cloud Workflows (one staging copy) | Target price guess · network GiB | 0 | USD/network GiB |
| Cloud Workflows (one staging copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Cloud Workflows (one staging copy) | Target price guess · vCPU-hour | 0 | USD/vCPU-hour |
| Cloud Workflows (one staging copy) | Target price guess · GiB-hour | 0 | USD/GiB-hour |
| Cloud Workflows (one staging copy) | Target price guess · resource-hour | 0 | USD/resource-hour |
| Cloud Workflows (one staging copy) | Target price guess · resource-month | 0 | USD/resource-month |
| Cloud Workflows (one staging copy) | Target price guess · input token | 0 | USD/input token |
| Cloud Workflows (one staging copy) | Target price guess · output token | 0 | USD/output token |
| Cloud Workflows (one staging copy) | Included before billing · provider operation | 5,000 | provider operation |
| Cloud Workflows (one staging copy) | Target monthly base charge | 0 | USD/month |
| Cloud Workflows (one staging copy) | Approximate target service minimum | 0 | USD/month |
| Cloud Workflows (one staging copy) | Minimum primary CPU | 2 | vCPU |
| Cloud Workflows (one staging copy) | Minimum primary RAM | 8 | GiB |
| Cloud Workflows (one staging copy) | Minimum primary disk | 100 | GiB |
| Cloud Workflows (one staging copy) | Additional full-price standby copy | 0 | 0 or 1 |
| Cloud Workflows (one staging copy) | Allocated share of provisioned cost | 1 | fraction |
| Cloud Workflows (one staging copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Cloud Workflows (one staging copy) | Planning peak / mean work | 2 | multiplier |
| Cloud Workflows (one staging copy) | Planning primary CPU utilization | 0.7 | fraction |
| Cloud Workflows (one staging copy) | Resident state reserved in RAM | 0.1 | fraction |
| Cloud Workflows (one staging copy) | Planning disk utilization | 0.8 | fraction |
| Cloud Workflows (one staging copy) | Maintenance and log disk reserve | 20 | GiB |
| Cloud Workflows (one staging copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Cloud Workflows (one staging copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Cloud Workflows (one staging copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Cloud Workflows (one staging copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Cloud Workflows (one staging copy) | Dependent object sink write price guess | 0.000005 | USD/write |
| Cloud Workflows (two staging copies) | Origin list price · Standard state transitions | 0.000025 | USD/transitions |
| Cloud Workflows (two staging copies) | Target steps per source transition | 2 | steps |
| Cloud Workflows (two staging copies) | History bytes per transition | 3,072 | bytes |
| Cloud Workflows (two staging copies) | History retention | 7 | days |
| Cloud Workflows (two staging copies) | Worker CPU per transition | 5 | vCPU-ms |
| Cloud Workflows (two staging copies) | Target price guess · read | 0 | USD/read |
| Cloud Workflows (two staging copies) | Target price guess · write | 0 | USD/write |
| Cloud Workflows (two staging copies) | Target list price · provider operation | 0.00001 | USD/provider operation |
| Cloud Workflows (two staging copies) | Target price guess · GiB-month | 0 | USD/GiB-month |
| Cloud Workflows (two staging copies) | Target price guess · published GiB | 0 | USD/published GiB |
| Cloud Workflows (two staging copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Cloud Workflows (two staging copies) | Target price guess · network GiB | 0 | USD/network GiB |
| Cloud Workflows (two staging copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Cloud Workflows (two staging copies) | Target price guess · vCPU-hour | 0 | USD/vCPU-hour |
| Cloud Workflows (two staging copies) | Target price guess · GiB-hour | 0 | USD/GiB-hour |
| Cloud Workflows (two staging copies) | Target price guess · resource-hour | 0 | USD/resource-hour |
| Cloud Workflows (two staging copies) | Target price guess · resource-month | 0 | USD/resource-month |
| Cloud Workflows (two staging copies) | Target price guess · input token | 0 | USD/input token |
| Cloud Workflows (two staging copies) | Target price guess · output token | 0 | USD/output token |
| Cloud Workflows (two staging copies) | Included before billing · provider operation | 5,000 | provider operation |
| Cloud Workflows (two staging copies) | Target monthly base charge | 0 | USD/month |
| Cloud Workflows (two staging copies) | Approximate target service minimum | 0 | USD/month |
| Cloud Workflows (two staging copies) | Minimum primary CPU | 2 | vCPU |
| Cloud Workflows (two staging copies) | Minimum primary RAM | 8 | GiB |
| Cloud Workflows (two staging copies) | Minimum primary disk | 100 | GiB |
| Cloud Workflows (two staging copies) | Additional full-price standby copy | 1 | 0 or 1 |
| Cloud Workflows (two staging copies) | Allocated share of provisioned cost | 1 | fraction |
| Cloud Workflows (two staging copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Cloud Workflows (two staging copies) | Planning peak / mean work | 2 | multiplier |
| Cloud Workflows (two staging copies) | Planning primary CPU utilization | 0.7 | fraction |
| Cloud Workflows (two staging copies) | Resident state reserved in RAM | 0.1 | fraction |
| Cloud Workflows (two staging copies) | Planning disk utilization | 0.8 | fraction |
| Cloud Workflows (two staging copies) | Maintenance and log disk reserve | 20 | GiB |
| Cloud Workflows (two staging copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Cloud Workflows (two staging copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Cloud Workflows (two staging copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Cloud Workflows (two staging copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Cloud Workflows (two staging copies) | Dependent object sink write price guess | 0.000005 | USD/write |

* Includes source retries; target amplification is applied only once. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements.
* Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → us-central1, USD/month.
* Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
* Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
* Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve's workload note.
* Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
* Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
* Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
* Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
* A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
* This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
* Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts.
* A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent.
* Managed steps, worker CPU and durable history are distinct target cost components. Internal/external step split needs target-specific assumptions.
* Standard-only origin profile; no inference of Express duration, memory or task execution cost.
* Google Workflows bills executed steps, including failed and retried ones, in increments of 1,000. Translated Step Functions steps are priced as internal steps (USD 0.01 per 1,000 after 5,000 free): assignments, conditions, subworkflow calls and calls to \*.googleapis.com, Cloud Run and Cloud Run functions, which is where translated state-machine work runs. External steps (HTTP to endpoints outside Google Cloud or custom domains, and callback waits) bill USD 0.025 per 1,000 after 2,000 free; a workflow dominated by those should set the step rate to 0.000025. Worker CPU is not a Workflows charge.
* Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1\_0\_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.
* Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing ([https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size](https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size)): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.
* Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)). The 20 GiB reserve exceeds PostgreSQL's 1 GB default max\_wal\_size; the remainder of that reserve is unmeasured.
* CPU tiers double from 2 vCPUs to the target's largest node at 4 GiB per vCPU; each target's documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead.
* No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.
* Node bounds: Cloud SQL Enterprise allows 1-96 vCPUs at 0.9-6.5 GB per vCPU and up to 64 TB with a dedicated vCPU ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)).
* Stored GiB already includes the origin family's physical footprint assumptions; no second storage amplification is applied.
* The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.
* Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
* AWS Price List API, AmazonStates offer: [https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonStates/current/us-east-1/index.json](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonStates/current/us-east-1/index.json)
* Workflows pricing: [https://cloud.google.com/workflows/pricing](https://cloud.google.com/workflows/pricing)

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied.

Excluded costs and workload features:

* Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them.
* Destination application execution and separately billed downstream services; supply those allocations separately.
* Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
* Unmodeled dependent services, task execution and operations outside the selected workload family.

List prices read: 2026-10-22. Model: `plan-ad343f795f60d331cee21f2d116f519470c34325` / `2026-10-22.planning.2`. Curve: `workload-1`.

Sources: [AWS Price List API, AmazonStates offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonStates/current/us-east-1/index.json), [Workflows pricing](https://cloud.google.com/workflows/pricing).

**Step Functions Standard → Cloud Workflows: Authored native-usage planning example.** Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts.

Scenario source region: us-east-1. Scenario target region: us-central1. Currency: USD.

| Monthly component | USD |
| - | -: |
| Origin: Standard state transitions | 0.00 |
| Target: Target retained physical data | 0.00 |
| Target: Additional broker replica storage | 0.00 |
| Target: Target native provider operations after 5000 included | 0.00 |
| Target: Execution or worker CPU | 0.00 |
| Target: Execution or worker RAM | 0.00 |
| Target: Selected billable network | 0.00 |
| Target: Independent native resources | 0.00 |
| Target: Independent native resources | 0.00 |
| Target: Durable staging CPU | 60.30 |
| Target: Durable staging RAM | 40.88 |
| Target: Durable staging disk | 17.00 |
| **Origin service subtotal** | **0.00** |
| **Target service subtotal** | **118.18** |

Estimated allocation, not benchmark calibrated: sized at 2 vCPU, 8 GiB memory and 100 GiB SSD for this scenario.

Unestimated components: Adapter hosting, Tensor9 fees. A modeled adapted total and savings require these costs.

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied.

Excluded costs and workload features:

* Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them.
* Destination application execution and separately billed downstream services; supply those allocations separately.
* Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
* Unmodeled dependent services, task execution and operations outside the selected workload family.

**Scenario assumptions**

| Input | Value | Unit |
| - | -: | - |
| Origin list price · Standard state transitions | 0.000025 | USD/transitions |
| Target steps per source transition | 2 | steps |
| History bytes per transition | 3,072 | bytes |
| History retention | 7 | days |
| Worker CPU per transition | 5 | vCPU-ms |
| Target price guess · read | 0 | USD/read |
| Target price guess · write | 0 | USD/write |
| Target list price · provider operation | 0.00001 | USD/provider operation |
| Target price guess · GiB-month | 0 | USD/GiB-month |
| Target price guess · published GiB | 0 | USD/published GiB |
| Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Target price guess · network GiB | 0 | USD/network GiB |
| Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Target price guess · vCPU-hour | 0 | USD/vCPU-hour |
| Target price guess · GiB-hour | 0 | USD/GiB-hour |
| Target price guess · resource-hour | 0 | USD/resource-hour |
| Target price guess · resource-month | 0 | USD/resource-month |
| Target price guess · input token | 0 | USD/input token |
| Target price guess · output token | 0 | USD/output token |
| Included before billing · provider operation | 5,000 | provider operation |
| Target monthly base charge | 0 | USD/month |
| Approximate target service minimum | 0 | USD/month |
| Minimum primary CPU | 2 | vCPU |
| Minimum primary RAM | 8 | GiB |
| Minimum primary disk | 100 | GiB |
| Additional full-price standby copy | 0 | 0 or 1 |
| Allocated share of provisioned cost | 1 | fraction |
| Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Planning peak / mean work | 2 | multiplier |
| Planning primary CPU utilization | 0.7 | fraction |
| Resident state reserved in RAM | 0.1 | fraction |
| Planning disk utilization | 0.8 | fraction |
| Maintenance and log disk reserve | 20 | GiB |
| Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Dependent object sink write price guess | 0.000005 | USD/write |
| Standard state transitions | 0 | transitions |

* Translated reads: 0 operations.

* Translated writes: 0 operations.

* Translated resident physical data: 0 GiB-month.

* Native provider operations: 0 operations.

* Published payload: 0 GiB.

* Delivered payload: 0 GiB.

* Allocated execution CPU: 0 vCPU-hour.

* Allocated execution RAM: 0 GiB-hour.

* Independent resource allocation: 0 resource-hour.

* Independent inventory: 0 resource-month.

* Input tokens: 0 tokens.

* Output tokens: 0 tokens.

* Billable network: 0 GiB.

* Dependent object sink retained data: 0 GiB-month.

* Dependent object sink writes: 0 writes.

* Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.

* Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.

* Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.

* Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.

* A declared adapter mapping and cost model do not establish implementation availability or service equivalence.

* This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.

* Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts.

* A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent.

* Managed steps, worker CPU and durable history are distinct target cost components. Internal/external step split needs target-specific assumptions.

* Standard-only origin profile; no inference of Express duration, memory or task execution cost.

* Google Workflows bills executed steps, including failed and retried ones, in increments of 1,000. Translated Step Functions steps are priced as internal steps (USD 0.01 per 1,000 after 5,000 free): assignments, conditions, subworkflow calls and calls to \*.googleapis.com, Cloud Run and Cloud Run functions, which is where translated state-machine work runs. External steps (HTTP to endpoints outside Google Cloud or custom domains, and callback waits) bill USD 0.025 per 1,000 after 2,000 free; a workflow dominated by those should set the step rate to 0.000025. Worker CPU is not a Workflows charge.

* Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1\_0\_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.

* Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing ([https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size](https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size)): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.

* Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)). The 20 GiB reserve exceeds PostgreSQL's 1 GB default max\_wal\_size; the remainder of that reserve is unmeasured.

* CPU tiers double from 2 vCPUs to the target's largest node at 4 GiB per vCPU; each target's documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead.

* No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.

* Node bounds: Cloud SQL Enterprise allows 1-96 vCPUs at 0.9-6.5 GB per vCPU and up to 64 TB with a dedicated vCPU ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)).

* Stored GiB already includes the origin family's physical footprint assumptions; no second storage amplification is applied.

* The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.

* Copies and allocation fractions change cost only; they do not increase modeled primary capacity.

List prices read: 2026-10-22. Model: `plan-ad343f795f60d331cee21f2d116f519470c34325` / `2026-10-22.planning.2`. Scenario: `planning-example`.

Sources: [AWS Price List API, AmazonStates offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonStates/current/us-east-1/index.json), [Workflows pricing](https://cloud.google.com/workflows/pricing).

## State-machine administration

The state-machine API manages definitions, versions, aliases and configuration. These target-specific administration operations accompany the execution behavior above.

### On Akamai, Azure, DigitalOcean, Google Cloud, OCI, Private Kubernetes, and Scaleway

#### Temporal (Self-Hosted)

| Capability | Area | Support | Operations | Notes |
| - | - | - | - | - |
| Logging configuration | Configuration | Partial | - | Configured logs use the deployment's logging destination and honor includeExecutionData; CloudWatch Logs is not written. |
| Tracing configuration | Configuration | Out of scope | - | Enabling X-Ray tracing is rejected when creating or updating a state machine. |
| Integration validation | Definitions | Partial | - | Definitions can use only the deployment's supported Task resources and invocation patterns. |

| Operation | Area | Support | Depth | Notes |
| - | - | - | - | - |
| ValidateStateMachineDefinition | Diagnostics | Supported | Most usage | Validates ASL without creating a resource and reports diagnostics, including unsupported Task resources and invocation patterns. |
| CreateStateMachine | State machines | Supported | Common | Validates ASL and stores the definition, role, mode, encryption, logging and tags; unsupported integrations are rejected. |
| DeleteStateMachine | State machines | Supported | Common | Reports DELETING, terminates executions at their next state transition and retires the definition, versions and aliases once executions have closed. Express deletion is eventually consistent. |
| DescribeStateMachine | State machines | Supported | Common | Returns the adapter's definition, role, mode, revision and configuration. |
| DescribeStateMachineForExecution | State machines | Supported | Most usage | Returns the immutable definition and revision selected for a Standard execution. |
| ListStateMachines | State machines | Supported | Common | Lists state machines using opaque pagination tokens. |
| UpdateStateMachine | State machines | Supported | Common | Creates a new revision for subsequent executions; active executions retain their selected definition and runtime version. |
| ListTagsForResource | Tags | Supported | Full surface | Returns the resource's tags. |
| TagResource | Tags | Supported | Full surface | Attaches tags to state-machine or Activity records. |
| UntagResource | Tags | Supported | Full surface | Removes tags from the adapter's resource record. |
| CreateStateMachineAlias | Versions and aliases | Supported | Most usage | Stores weighted routing to one or two versions; each new execution retains the selected version. |
| DeleteStateMachineAlias | Versions and aliases | Supported | Full surface | Deletes the alias without interrupting executions previously started through it. |
| DeleteStateMachineVersion | Versions and aliases | Supported | Full surface | Deletes an unreferenced version; a version used by an alias cannot be deleted. |
| DescribeStateMachineAlias | Versions and aliases | Supported | Full surface | Returns the alias and routing configuration. |
| ListStateMachineAliases | Versions and aliases | Supported | Full surface | Lists aliases with pagination. |
| ListStateMachineVersions | Versions and aliases | Supported | Most usage | Lists published versions with pagination. |
| PublishStateMachineVersion | Versions and aliases | Supported | Most usage | Publishes an immutable numbered revision. |
| UpdateStateMachineAlias | Versions and aliases | Supported | Full surface | Updates routing for subsequent starts; existing executions keep their selected version. |

##### How it works

A Step Functions state machine is a record in the Tensor9 service adapter: its ASL definition, execution role, type and settings. Creating one does not create a Temporal workflow type or a new Temporal cluster. The interpreter workers are shared. A Standard execution reads the definition revision selected when it starts, and that revision never changes.

`UpdateStateMachine` changes later executions only. Published versions keep their definitions, and an alias picks a version by weight for each new execution. `DeleteStateMachine` reports `DELETING` and ends running executions at their next state transition. Once they have closed, the state machine, its versions and its aliases are removed. Deleting an Express state machine is eventually consistent.

##### Limitations

Where the Step Functions state-machine mapping differs

* **Task resources without a supported integration are rejected.** `ValidateStateMachineDefinition` reports them, and `CreateStateMachine` rejects them. Enabling X-Ray tracing is also rejected.
* **State machines behave differently: Temporal does not store them.** Temporal Web UI shows executions and their history. `DescribeStateMachine` and the versions and aliases APIs read the adapter's records.

##### Other considerations

* **Backups.** Protect the adapter's records as well as the self-hosted Temporal database. Restoring only one of them does not restore the service.
* **Deployment.** Apply state-machine resources and publish versions through the Step Functions endpoint. Your team receives no workflow-specific worker code.
* **Operations.** The deployment operator maintains the Temporal cluster and backups; Tensor9 maintains the adapter and interpreter. Execution, callback and capacity behavior are described on the Step Functions card.

##### Example monthly charges

This Tensor9 Cloud Adapter scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. [How Tensor9 estimates costs](https://docs.tensor9.com/cloud-adapter-early-access/costs/overview.md) explains the method and what the estimates include.

##### Step Functions Standard · State transitions

Feature: Step Functions Standard.

Estimated monthly service charges by State transitions. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD.

![Step Functions Standard · State transitions: monthly service charges by State transitions. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/c39c2e0d1a0a33dd5ab99d6a50d5f6ff5bad81ddf3a920e853319b699917516c-light.svg)

![Step Functions Standard · State transitions: monthly service charges by State transitions. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/d1093707357c360999af18083dac35c86cd14dd0982303e121956fff88bd063e-dark.svg)

Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples.

Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more.

| State transitions (per second) | Step Functions State Machine | Target scenario | Temporal (Self-Hosted) | Difference |
| -: | -: | - | -: | -: |
| 0 | 0.00 | Temporal (Self-Hosted) (one copy) | 80.90 | 80.90 |
| 0 | 0.00 | Temporal (Self-Hosted) (two copies) | 161.79 | 161.79 |
| 1 | 65.70 | Temporal (Self-Hosted) (one copy) | 80.90 | 15.20 |
| 1 | 65.70 | Temporal (Self-Hosted) (two copies) | 161.79 | 96.09 |
| 10 | 657.00 | Temporal (Self-Hosted) (one copy) | 80.90 | -576.10 |
| 10 | 657.00 | Temporal (Self-Hosted) (two copies) | 161.79 | -495.21 |
| 100 | 6,570.00 | Temporal (Self-Hosted) (one copy) | 170.63 | -6,399.37 |
| 100 | 6,570.00 | Temporal (Self-Hosted) (two copies) | 341.26 | -6,228.74 |
| 1,000 | 65,700.00 | Temporal (Self-Hosted) (one copy) | 1,493.10 | -64,206.90 |
| 1,000 | 65,700.00 | Temporal (Self-Hosted) (two copies) | 2,986.19 | -62,713.81 |
| 10,000 | 657,000.00 | Temporal (Self-Hosted) (one copy) | 7,791.59 | -649,208.41 |
| 10,000 | 657,000.00 | Temporal (Self-Hosted) (two copies) | 15,583.18 | -641,416.82 |

Estimated allocation, not benchmark calibrated: sized from 2 vCPU, 8 GiB memory and 100 GiB SSD at 0 per second to 128 vCPU, 864 GiB memory and 21,655 GiB SSD at 10,000 per second.

**Curve assumptions**

| Target scenario | Assumption | Value | Unit |
| - | - | -: | - |
| Temporal (Self-Hosted) (one copy) | Origin list price · Standard state transitions | 0.000025 | USD/transitions |
| Temporal (Self-Hosted) (one copy) | Target steps per source transition | 2 | steps |
| Temporal (Self-Hosted) (one copy) | History bytes per transition | 3,072 | bytes |
| Temporal (Self-Hosted) (one copy) | History retention | 7 | days |
| Temporal (Self-Hosted) (one copy) | Worker CPU per transition | 5 | vCPU-ms |
| Temporal (Self-Hosted) (one copy) | Target price guess · read | 0 | USD/read |
| Temporal (Self-Hosted) (one copy) | Target price guess · write | 0 | USD/write |
| Temporal (Self-Hosted) (one copy) | Target price guess · provider operation | 0 | USD/provider operation |
| Temporal (Self-Hosted) (one copy) | Target list price · GiB-month | 0.1 | USD/GiB-month |
| Temporal (Self-Hosted) (one copy) | Target price guess · published GiB | 0 | USD/published GiB |
| Temporal (Self-Hosted) (one copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Temporal (Self-Hosted) (one copy) | Target list price · network GiB | 0.12 | USD/network GiB |
| Temporal (Self-Hosted) (one copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Temporal (Self-Hosted) (one copy) | Target list price · vCPU-hour | 0.031611 | USD/vCPU-hour |
| Temporal (Self-Hosted) (one copy) | Target list price · GiB-hour | 0.004237 | USD/GiB-hour |
| Temporal (Self-Hosted) (one copy) | Target price guess · resource-hour | 0 | USD/resource-hour |
| Temporal (Self-Hosted) (one copy) | Target price guess · resource-month | 0 | USD/resource-month |
| Temporal (Self-Hosted) (one copy) | Target price guess · input token | 0 | USD/input token |
| Temporal (Self-Hosted) (one copy) | Target price guess · output token | 0 | USD/output token |
| Temporal (Self-Hosted) (one copy) | Target monthly base charge | 0 | USD/month |
| Temporal (Self-Hosted) (one copy) | Approximate target service minimum | 0 | USD/month |
| Temporal (Self-Hosted) (one copy) | Minimum primary CPU | 2 | vCPU |
| Temporal (Self-Hosted) (one copy) | Minimum primary RAM | 8 | GiB |
| Temporal (Self-Hosted) (one copy) | Minimum primary disk | 100 | GiB |
| Temporal (Self-Hosted) (one copy) | Additional full-price standby copy | 0 | 0 or 1 |
| Temporal (Self-Hosted) (one copy) | Allocated share of provisioned cost | 1 | fraction |
| Temporal (Self-Hosted) (one copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Temporal (Self-Hosted) (one copy) | Planning peak / mean work | 2 | multiplier |
| Temporal (Self-Hosted) (one copy) | Planning primary CPU utilization | 0.7 | fraction |
| Temporal (Self-Hosted) (one copy) | Resident state reserved in RAM | 0.1 | fraction |
| Temporal (Self-Hosted) (one copy) | Planning disk utilization | 0.8 | fraction |
| Temporal (Self-Hosted) (one copy) | Maintenance and log disk reserve | 20 | GiB |
| Temporal (Self-Hosted) (one copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Temporal (Self-Hosted) (one copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Temporal (Self-Hosted) (one copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Temporal (Self-Hosted) (one copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Temporal (Self-Hosted) (one copy) | Dependent object sink write price guess | 0.000005 | USD/write |
| Temporal (Self-Hosted) (two copies) | Origin list price · Standard state transitions | 0.000025 | USD/transitions |
| Temporal (Self-Hosted) (two copies) | Target steps per source transition | 2 | steps |
| Temporal (Self-Hosted) (two copies) | History bytes per transition | 3,072 | bytes |
| Temporal (Self-Hosted) (two copies) | History retention | 7 | days |
| Temporal (Self-Hosted) (two copies) | Worker CPU per transition | 5 | vCPU-ms |
| Temporal (Self-Hosted) (two copies) | Target price guess · read | 0 | USD/read |
| Temporal (Self-Hosted) (two copies) | Target price guess · write | 0 | USD/write |
| Temporal (Self-Hosted) (two copies) | Target price guess · provider operation | 0 | USD/provider operation |
| Temporal (Self-Hosted) (two copies) | Target list price · GiB-month | 0.1 | USD/GiB-month |
| Temporal (Self-Hosted) (two copies) | Target price guess · published GiB | 0 | USD/published GiB |
| Temporal (Self-Hosted) (two copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Temporal (Self-Hosted) (two copies) | Target list price · network GiB | 0.12 | USD/network GiB |
| Temporal (Self-Hosted) (two copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Temporal (Self-Hosted) (two copies) | Target list price · vCPU-hour | 0.031611 | USD/vCPU-hour |
| Temporal (Self-Hosted) (two copies) | Target list price · GiB-hour | 0.004237 | USD/GiB-hour |
| Temporal (Self-Hosted) (two copies) | Target price guess · resource-hour | 0 | USD/resource-hour |
| Temporal (Self-Hosted) (two copies) | Target price guess · resource-month | 0 | USD/resource-month |
| Temporal (Self-Hosted) (two copies) | Target price guess · input token | 0 | USD/input token |
| Temporal (Self-Hosted) (two copies) | Target price guess · output token | 0 | USD/output token |
| Temporal (Self-Hosted) (two copies) | Target monthly base charge | 0 | USD/month |
| Temporal (Self-Hosted) (two copies) | Approximate target service minimum | 0 | USD/month |
| Temporal (Self-Hosted) (two copies) | Minimum primary CPU | 2 | vCPU |
| Temporal (Self-Hosted) (two copies) | Minimum primary RAM | 8 | GiB |
| Temporal (Self-Hosted) (two copies) | Minimum primary disk | 100 | GiB |
| Temporal (Self-Hosted) (two copies) | Additional full-price standby copy | 1 | 0 or 1 |
| Temporal (Self-Hosted) (two copies) | Allocated share of provisioned cost | 1 | fraction |
| Temporal (Self-Hosted) (two copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Temporal (Self-Hosted) (two copies) | Planning peak / mean work | 2 | multiplier |
| Temporal (Self-Hosted) (two copies) | Planning primary CPU utilization | 0.7 | fraction |
| Temporal (Self-Hosted) (two copies) | Resident state reserved in RAM | 0.1 | fraction |
| Temporal (Self-Hosted) (two copies) | Planning disk utilization | 0.8 | fraction |
| Temporal (Self-Hosted) (two copies) | Maintenance and log disk reserve | 20 | GiB |
| Temporal (Self-Hosted) (two copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Temporal (Self-Hosted) (two copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Temporal (Self-Hosted) (two copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Temporal (Self-Hosted) (two copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Temporal (Self-Hosted) (two copies) | Dependent object sink write price guess | 0.000005 | USD/write |

* Includes source retries; target amplification is applied only once. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements.
* Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → us-central1, USD/month.
* Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
* Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
* Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve's workload note.
* Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
* Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
* Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
* Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
* A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
* This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
* Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts.
* A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent.
* Managed steps, worker CPU and durable history are distinct target cost components. Internal/external step split needs target-specific assumptions.
* Standard-only origin profile; no inference of Express duration, memory or task execution cost.
* Self-hosted target: Temporal server (MIT, [https://github.com/temporalio/temporal/blob/main/LICENSE](https://github.com/temporalio/temporal/blob/main/LICENSE)); Temporal Cloud is a separate target. Selected CPU, RAM and physical disk allocation grow with workload; no per-operation price is assumed. No vendor charge: the target runs on the customer's Kubernetes nodes, so CPU, RAM and disk bill at the Kubernetes node reference rates, Compute Engine N2 in us-central1 (USD 0.031611/vCPU-hour, 0.004237/GiB-hour) with pd-balanced disk (0.10/GiB-month) and Premium Tier egress. The cost-optimized E2 series lists 0.02181159/vCPU-hour and 0.00292353/GiB-hour; AWS m6i/r6i and Azure D2s v5/E2s v5 both decompose to 0.033/vCPU-hour and 0.00375/GiB-hour. Requested CPU and RAM are billed; node bin-packing waste, system reservations and the cluster control-plane fee are not.
* Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1\_0\_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.
* Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing ([https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size](https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size)): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.
* Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)). The 20 GiB reserve exceeds PostgreSQL's 1 GB default max\_wal\_size; the remainder of that reserve is unmeasured.
* CPU tiers double from 2 vCPUs to the target's largest node at 4 GiB per vCPU; each target's documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead.
* No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.
* Node bounds: Compute Engine n2-highmem-128 has 128 vCPUs and 864 GB ([https://docs.cloud.google.com/compute/docs/general-purpose-machines](https://docs.cloud.google.com/compute/docs/general-purpose-machines)); a Persistent Disk volume holds up to 64 TiB ([https://docs.cloud.google.com/compute/docs/disks/persistent-disks](https://docs.cloud.google.com/compute/docs/disks/persistent-disks)).
* Stored GiB already includes the origin family's physical footprint assumptions; no second storage amplification is applied.
* The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.
* Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
* AWS Price List API, AmazonStates offer: [https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonStates/current/us-east-1/index.json](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonStates/current/us-east-1/index.json)
* Compute Engine general-purpose machine pricing: [https://cloud.google.com/products/compute/pricing/general-purpose](https://cloud.google.com/products/compute/pricing/general-purpose)
* Disk and image pricing: [https://cloud.google.com/compute/disks-image-pricing](https://cloud.google.com/compute/disks-image-pricing)
* Network pricing: [https://cloud.google.com/vpc/network-pricing](https://cloud.google.com/vpc/network-pricing)

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied.

Excluded costs and workload features:

* Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them.
* Destination application execution and separately billed downstream services; supply those allocations separately.
* Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
* Unmodeled dependent services, task execution and operations outside the selected workload family.

List prices read: 2026-10-22. Model: `plan-9910f41b4207fb4a6bfcd36d62f40d9657403e70` / `2026-10-22.planning.2`. Curve: `workload-1`.

Sources: [AWS Price List API, AmazonStates offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonStates/current/us-east-1/index.json), [Compute Engine general-purpose machine pricing](https://cloud.google.com/products/compute/pricing/general-purpose), [Disk and image pricing](https://cloud.google.com/compute/disks-image-pricing), [Network pricing](https://cloud.google.com/vpc/network-pricing).

**Step Functions Standard → Temporal (Self-Hosted): Authored native-usage planning example.** Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts.

Scenario source region: us-east-1. Scenario target region: us-central1. Currency: USD.

| Monthly component | USD |
| - | -: |
| Origin: Standard state transitions | 0.00 |
| Target: Provisioned primary CPU | 46.15 |
| Target: Provisioned primary RAM | 24.74 |
| Target: Provisioned primary disk | 10.00 |
| Target: Selected billable network | 0.00 |
| Target: Independent provisioned resources | 0.00 |
| Target: Independent managed resources | 0.00 |
| **Origin service subtotal** | **0.00** |
| **Target service subtotal** | **80.90** |

Estimated allocation, not benchmark calibrated: sized at 2 vCPU, 8 GiB memory and 100 GiB SSD for this scenario.

Unestimated components: Adapter hosting, Tensor9 fees. A modeled adapted total and savings require these costs.

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied.

Excluded costs and workload features:

* Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them.
* Destination application execution and separately billed downstream services; supply those allocations separately.
* Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
* Unmodeled dependent services, task execution and operations outside the selected workload family.

**Scenario assumptions**

| Input | Value | Unit |
| - | -: | - |
| Origin list price · Standard state transitions | 0.000025 | USD/transitions |
| Target steps per source transition | 2 | steps |
| History bytes per transition | 3,072 | bytes |
| History retention | 7 | days |
| Worker CPU per transition | 5 | vCPU-ms |
| Target price guess · read | 0 | USD/read |
| Target price guess · write | 0 | USD/write |
| Target price guess · provider operation | 0 | USD/provider operation |
| Target list price · GiB-month | 0.1 | USD/GiB-month |
| Target price guess · published GiB | 0 | USD/published GiB |
| Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Target list price · network GiB | 0.12 | USD/network GiB |
| Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Target list price · vCPU-hour | 0.031611 | USD/vCPU-hour |
| Target list price · GiB-hour | 0.004237 | USD/GiB-hour |
| Target price guess · resource-hour | 0 | USD/resource-hour |
| Target price guess · resource-month | 0 | USD/resource-month |
| Target price guess · input token | 0 | USD/input token |
| Target price guess · output token | 0 | USD/output token |
| Target monthly base charge | 0 | USD/month |
| Approximate target service minimum | 0 | USD/month |
| Minimum primary CPU | 2 | vCPU |
| Minimum primary RAM | 8 | GiB |
| Minimum primary disk | 100 | GiB |
| Additional full-price standby copy | 0 | 0 or 1 |
| Allocated share of provisioned cost | 1 | fraction |
| Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Planning peak / mean work | 2 | multiplier |
| Planning primary CPU utilization | 0.7 | fraction |
| Resident state reserved in RAM | 0.1 | fraction |
| Planning disk utilization | 0.8 | fraction |
| Maintenance and log disk reserve | 20 | GiB |
| Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Dependent object sink write price guess | 0.000005 | USD/write |
| Standard state transitions | 0 | transitions |

* Translated reads: 0 operations.

* Translated writes: 0 operations.

* Translated resident physical data: 0 GiB-month.

* Native provider operations: 0 operations.

* Published payload: 0 GiB.

* Delivered payload: 0 GiB.

* Allocated execution CPU: 0 vCPU-hour.

* Allocated execution RAM: 0 GiB-hour.

* Independent resource allocation: 0 resource-hour.

* Independent inventory: 0 resource-month.

* Input tokens: 0 tokens.

* Output tokens: 0 tokens.

* Billable network: 0 GiB.

* Dependent object sink retained data: 0 GiB-month.

* Dependent object sink writes: 0 writes.

* Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.

* Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.

* Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.

* Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.

* A declared adapter mapping and cost model do not establish implementation availability or service equivalence.

* This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.

* Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts.

* A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent.

* Managed steps, worker CPU and durable history are distinct target cost components. Internal/external step split needs target-specific assumptions.

* Standard-only origin profile; no inference of Express duration, memory or task execution cost.

* Self-hosted target: Temporal server (MIT, [https://github.com/temporalio/temporal/blob/main/LICENSE](https://github.com/temporalio/temporal/blob/main/LICENSE)); Temporal Cloud is a separate target. Selected CPU, RAM and physical disk allocation grow with workload; no per-operation price is assumed. No vendor charge: the target runs on the customer's Kubernetes nodes, so CPU, RAM and disk bill at the Kubernetes node reference rates, Compute Engine N2 in us-central1 (USD 0.031611/vCPU-hour, 0.004237/GiB-hour) with pd-balanced disk (0.10/GiB-month) and Premium Tier egress. The cost-optimized E2 series lists 0.02181159/vCPU-hour and 0.00292353/GiB-hour; AWS m6i/r6i and Azure D2s v5/E2s v5 both decompose to 0.033/vCPU-hour and 0.00375/GiB-hour. Requested CPU and RAM are billed; node bin-packing waste, system reservations and the cluster control-plane fee are not.

* Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1\_0\_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.

* Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing ([https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size](https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size)): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.

* Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)). The 20 GiB reserve exceeds PostgreSQL's 1 GB default max\_wal\_size; the remainder of that reserve is unmeasured.

* CPU tiers double from 2 vCPUs to the target's largest node at 4 GiB per vCPU; each target's documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead.

* No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.

* Node bounds: Compute Engine n2-highmem-128 has 128 vCPUs and 864 GB ([https://docs.cloud.google.com/compute/docs/general-purpose-machines](https://docs.cloud.google.com/compute/docs/general-purpose-machines)); a Persistent Disk volume holds up to 64 TiB ([https://docs.cloud.google.com/compute/docs/disks/persistent-disks](https://docs.cloud.google.com/compute/docs/disks/persistent-disks)).

* Stored GiB already includes the origin family's physical footprint assumptions; no second storage amplification is applied.

* The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.

* Copies and allocation fractions change cost only; they do not increase modeled primary capacity.

List prices read: 2026-10-22. Model: `plan-9910f41b4207fb4a6bfcd36d62f40d9657403e70` / `2026-10-22.planning.2`. Scenario: `planning-example`.

Sources: [AWS Price List API, AmazonStates offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonStates/current/us-east-1/index.json), [Compute Engine general-purpose machine pricing](https://cloud.google.com/products/compute/pricing/general-purpose), [Disk and image pricing](https://cloud.google.com/compute/disks-image-pricing), [Network pricing](https://cloud.google.com/vpc/network-pricing).

### On Azure

#### Azure Durable Functions

| Capability | Area | Support | Operations | Notes |
| - | - | - | - | - |
| Encryption configuration | Configuration | Supported | - | a customer-managed key names a key served by the KMS mapping on the same Cloud Adapter deployment (Key Vault on Azure); the definition and execution payloads are encrypted under it and become unreadable when it is revoked |
| Logging configuration | Configuration | Partial | - | includeExecutionData and the configured destination are honoured; the destination is served by the Cloud Adapter deployment's logging, since CloudWatch Logs is a service the Cloud Adapter deployment does not adapt |
| Tracing configuration | Configuration | Out of scope | - | X-Ray is not adapted, so a configuration that enables tracing is rejected rather than stored and ignored |
| Definition limit | Limits | Supported | - | the 1 MB definition ceiling is enforced at the API |

| Operation | Area | Support | Depth | Notes |
| - | - | - | - | - |
| ValidateStateMachineDefinition | Diagnostics | Supported | Most usage | validates a definition without creating anything and returns diagnostics with severity |
| CreateStateMachine | State machines | Supported | Common | validates the definition and records the state machine with its role, type, encryption, logging and tags; the definition is stored as written, since it is interpreted at run time rather than translated |
| DeleteStateMachine | State machines | Supported | Common | succeeds at once and the state machine reads DELETING until its running executions complete; versions and aliases are retired with it |
| DescribeStateMachine | State machines | Supported | Common | returns the definition, role, type, revision and configuration |
| DescribeStateMachineForExecution | State machines | Supported | Most usage | returns the definition and revision pinned by a given execution |
| ListStateMachines | State machines | Supported | Common | lists state machines with opaque pagination tokens |
| UpdateStateMachine | State machines | Supported | Common | replaces the definition, role or configuration and returns a new revision; executions in flight keep the revision they started on |
| ListTagsForResource | Tags | Supported | Full surface | lists the tags |
| TagResource | Tags | Supported | Full surface | attaches tags to the state machine |
| UntagResource | Tags | Supported | Full surface | removes tags |
| CreateStateMachineAlias | Versions and aliases | Supported | Most usage | an alias routes to one or two versions by weight |
| DeleteStateMachineAlias | Versions and aliases | Supported | Full surface | deletes the alias |
| DeleteStateMachineVersion | Versions and aliases | Supported | Full surface | deletes a version; refused while an alias still routes to it |
| DescribeStateMachineAlias | Versions and aliases | Supported | Full surface | returns the alias and its routing |
| ListStateMachineAliases | Versions and aliases | Supported | Full surface | lists the aliases |
| ListStateMachineVersions | Versions and aliases | Supported | Most usage | lists the published versions |
| PublishStateMachineVersion | Versions and aliases | Supported | Most usage | publishes the current revision as an immutable numbered version |
| UpdateStateMachineAlias | Versions and aliases | Supported | Full surface | changes the routing for executions started afterwards |

##### The state machine as an adapter record

CreateStateMachine stores the definition, role, type, encryption, logging and tags as one revision. UpdateStateMachine produces the next revision, and an execution pins the revision it starts on, so a definition change never alters a run in flight. PublishStateMachineVersion freezes a revision as a numbered version and an alias routes new executions across one or two versions by weight, exactly as on AWS.

DeleteStateMachine succeeds immediately and the state machine reads DELETING; it is retired once its running executions complete, and its versions and aliases go with it. No Azure resource is created or removed by any of these calls: the orchestrator function app is shared by every state machine on the Cloud Adapter deployment and reads the record at run time.

##### Limitations

* **Tracing cannot be enabled.** X-Ray is not adapted, so a `tracingConfiguration` that enables tracing is rejected at CreateStateMachine and UpdateStateMachine rather than stored and ignored. - **Logs stay on the Cloud Adapter deployment.** `includeExecutionData` and the configured destination are honoured; the destination is served by the Cloud Adapter deployment's logging, since CloudWatch Logs is a service the Cloud Adapter deployment does not adapt. - **A Task Resource must name a served service.** ValidateStateMachineDefinition reports, and CreateStateMachine refuses, a Resource naming a service the Cloud Adapter deployment does not serve. Run-time limits (Express semantics, Activities, Distributed Map fan-out) are on the Step Functions card for Azure Durable Functions.

##### Example monthly charges

This Tensor9 Cloud Adapter scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. [How Tensor9 estimates costs](https://docs.tensor9.com/cloud-adapter-early-access/costs/overview.md) explains the method and what the estimates include.

##### Step Functions Standard · State transitions

Feature: Step Functions Standard.

Estimated monthly service charges by State transitions. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: East US; currency: USD.

![Step Functions Standard · State transitions: monthly service charges by State transitions. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/28d5c1903aeb6721e9816f1dea632ab36ba898c44bb6afeac6b3d18a2bb00158-light.svg)

![Step Functions Standard · State transitions: monthly service charges by State transitions. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/25f5a94541e66987be5eab15265c5d3fcf97d78ee1f822178f5ffb879c24db03-dark.svg)

Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples.

Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more.

| State transitions (per second) | Step Functions State Machine | Target scenario | Azure Durable Functions | Difference |
| -: | -: | - | -: | -: |
| 0 | 0.00 | Azure Durable Functions (one staging copy) | 118.18 | 118.18 |
| 0 | 0.00 | Azure Durable Functions (two staging copies) | 236.36 | 236.36 |
| 1 | 65.70 | Azure Durable Functions (one staging copy) | 129.07 | 63.37 |
| 1 | 65.70 | Azure Durable Functions (two staging copies) | 247.25 | 181.55 |
| 10 | 657.00 | Azure Durable Functions (one staging copy) | 227.08 | -429.92 |
| 10 | 657.00 | Azure Durable Functions (two staging copies) | 345.26 | -311.74 |
| 100 | 6,570.00 | Azure Durable Functions (one staging copy) | 1,340.20 | -5,229.80 |
| 100 | 6,570.00 | Azure Durable Functions (two staging copies) | 1,591.37 | -4,978.63 |
| 1,000 | 65,700.00 | Azure Durable Functions (one staging copy) | 13,112.47 | -52,587.53 |
| 1,000 | 65,700.00 | Azure Durable Functions (two staging copies) | 15,334.50 | -50,365.50 |
| 10,000 | 657,000.00 | Azure Durable Functions (one staging copy) | 118,668.61 | -538,331.39 |
| 10,000 | 657,000.00 | Azure Durable Functions (two staging copies) | 128,432.91 | -528,567.09 |

Estimated allocation, not benchmark calibrated: sized from 2 vCPU, 8 GiB memory and 100 GiB SSD at 0 per second to 96 vCPU, 624 GiB memory and 21,655 GiB SSD at 10,000 per second.

**Curve assumptions**

| Target scenario | Assumption | Value | Unit |
| - | - | -: | - |
| Azure Durable Functions (one staging copy) | Origin list price · Standard state transitions | 0.000025 | USD/transitions |
| Azure Durable Functions (one staging copy) | Target steps per source transition | 2 | steps |
| Azure Durable Functions (one staging copy) | History bytes per transition | 3,072 | bytes |
| Azure Durable Functions (one staging copy) | History retention | 7 | days |
| Azure Durable Functions (one staging copy) | Worker CPU per transition | 5 | vCPU-ms |
| Azure Durable Functions (one staging copy) | Target price guess · read | 0 | USD/read |
| Azure Durable Functions (one staging copy) | Target price guess · write | 0 | USD/write |
| Azure Durable Functions (one staging copy) | Target list price · provider operation | 0.000002072 | USD/provider operation |
| Azure Durable Functions (one staging copy) | Target price guess · GiB-month | 0 | USD/GiB-month |
| Azure Durable Functions (one staging copy) | Target price guess · published GiB | 0 | USD/published GiB |
| Azure Durable Functions (one staging copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Azure Durable Functions (one staging copy) | Target price guess · network GiB | 0 | USD/network GiB |
| Azure Durable Functions (one staging copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Azure Durable Functions (one staging copy) | Target price guess · vCPU-hour | 0 | USD/vCPU-hour |
| Azure Durable Functions (one staging copy) | Target price guess · GiB-hour | 0 | USD/GiB-hour |
| Azure Durable Functions (one staging copy) | Target price guess · resource-hour | 0 | USD/resource-hour |
| Azure Durable Functions (one staging copy) | Target price guess · resource-month | 0 | USD/resource-month |
| Azure Durable Functions (one staging copy) | Target price guess · input token | 0 | USD/input token |
| Azure Durable Functions (one staging copy) | Target price guess · output token | 0 | USD/output token |
| Azure Durable Functions (one staging copy) | Target monthly base charge | 0 | USD/month |
| Azure Durable Functions (one staging copy) | Approximate target service minimum | 0 | USD/month |
| Azure Durable Functions (one staging copy) | Minimum primary CPU | 2 | vCPU |
| Azure Durable Functions (one staging copy) | Minimum primary RAM | 8 | GiB |
| Azure Durable Functions (one staging copy) | Minimum primary disk | 100 | GiB |
| Azure Durable Functions (one staging copy) | Additional full-price standby copy | 0 | 0 or 1 |
| Azure Durable Functions (one staging copy) | Allocated share of provisioned cost | 1 | fraction |
| Azure Durable Functions (one staging copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Azure Durable Functions (one staging copy) | Planning peak / mean work | 2 | multiplier |
| Azure Durable Functions (one staging copy) | Planning primary CPU utilization | 0.7 | fraction |
| Azure Durable Functions (one staging copy) | Resident state reserved in RAM | 0.1 | fraction |
| Azure Durable Functions (one staging copy) | Planning disk utilization | 0.8 | fraction |
| Azure Durable Functions (one staging copy) | Maintenance and log disk reserve | 20 | GiB |
| Azure Durable Functions (one staging copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Azure Durable Functions (one staging copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Azure Durable Functions (one staging copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Azure Durable Functions (one staging copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Azure Durable Functions (one staging copy) | Dependent object sink write price guess | 0.000005 | USD/write |
| Azure Durable Functions (two staging copies) | Origin list price · Standard state transitions | 0.000025 | USD/transitions |
| Azure Durable Functions (two staging copies) | Target steps per source transition | 2 | steps |
| Azure Durable Functions (two staging copies) | History bytes per transition | 3,072 | bytes |
| Azure Durable Functions (two staging copies) | History retention | 7 | days |
| Azure Durable Functions (two staging copies) | Worker CPU per transition | 5 | vCPU-ms |
| Azure Durable Functions (two staging copies) | Target price guess · read | 0 | USD/read |
| Azure Durable Functions (two staging copies) | Target price guess · write | 0 | USD/write |
| Azure Durable Functions (two staging copies) | Target list price · provider operation | 0.000002072 | USD/provider operation |
| Azure Durable Functions (two staging copies) | Target price guess · GiB-month | 0 | USD/GiB-month |
| Azure Durable Functions (two staging copies) | Target price guess · published GiB | 0 | USD/published GiB |
| Azure Durable Functions (two staging copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Azure Durable Functions (two staging copies) | Target price guess · network GiB | 0 | USD/network GiB |
| Azure Durable Functions (two staging copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Azure Durable Functions (two staging copies) | Target price guess · vCPU-hour | 0 | USD/vCPU-hour |
| Azure Durable Functions (two staging copies) | Target price guess · GiB-hour | 0 | USD/GiB-hour |
| Azure Durable Functions (two staging copies) | Target price guess · resource-hour | 0 | USD/resource-hour |
| Azure Durable Functions (two staging copies) | Target price guess · resource-month | 0 | USD/resource-month |
| Azure Durable Functions (two staging copies) | Target price guess · input token | 0 | USD/input token |
| Azure Durable Functions (two staging copies) | Target price guess · output token | 0 | USD/output token |
| Azure Durable Functions (two staging copies) | Target monthly base charge | 0 | USD/month |
| Azure Durable Functions (two staging copies) | Approximate target service minimum | 0 | USD/month |
| Azure Durable Functions (two staging copies) | Minimum primary CPU | 2 | vCPU |
| Azure Durable Functions (two staging copies) | Minimum primary RAM | 8 | GiB |
| Azure Durable Functions (two staging copies) | Minimum primary disk | 100 | GiB |
| Azure Durable Functions (two staging copies) | Additional full-price standby copy | 1 | 0 or 1 |
| Azure Durable Functions (two staging copies) | Allocated share of provisioned cost | 1 | fraction |
| Azure Durable Functions (two staging copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Azure Durable Functions (two staging copies) | Planning peak / mean work | 2 | multiplier |
| Azure Durable Functions (two staging copies) | Planning primary CPU utilization | 0.7 | fraction |
| Azure Durable Functions (two staging copies) | Resident state reserved in RAM | 0.1 | fraction |
| Azure Durable Functions (two staging copies) | Planning disk utilization | 0.8 | fraction |
| Azure Durable Functions (two staging copies) | Maintenance and log disk reserve | 20 | GiB |
| Azure Durable Functions (two staging copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Azure Durable Functions (two staging copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Azure Durable Functions (two staging copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Azure Durable Functions (two staging copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Azure Durable Functions (two staging copies) | Dependent object sink write price guess | 0.000005 | USD/write |

* Includes source retries; target amplification is applied only once. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements.
* Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → East US, USD/month.
* Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
* Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
* Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve's workload note.
* Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
* Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
* Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
* Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
* A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
* This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
* Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts.
* A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent.
* Managed steps, worker CPU and durable history are distinct target cost components. Internal/external step split needs target-specific assumptions.
* Standard-only origin profile; no inference of Express duration, memory or task execution cost.
* Azure Durable Functions has no orchestration charge of its own: with the default Azure Storage provider it bills the function executions that run orchestrator and activity steps plus the queue and table transactions that persist their messages and history in the customer's storage account. The step rate is that composite on Flex Consumption. Execution GB-seconds (USD 0.000026 per GB-second on Flex Consumption), idle queue polling (a few hundred thousand transactions a month per app) and table storage (USD 0.045 per GB-month) are not modeled, and the family's worker CPU is not a Durable Functions charge. The Durable Task Scheduler (Dedicated USD 0.684932 per capacity-unit hour) is an alternative backend and is not selected.
* Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1\_0\_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.
* Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing ([https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size](https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size)): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.
* Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)). The 20 GiB reserve exceeds PostgreSQL's 1 GB default max\_wal\_size; the remainder of that reserve is unmeasured.
* CPU tiers double from 2 vCPUs to the target's largest node at 4 GiB per vCPU; each target's documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead.
* No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.
* Node bounds: Cloud SQL Enterprise allows 1-96 vCPUs at 0.9-6.5 GB per vCPU and up to 64 TB with a dedicated vCPU ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)).
* Stored GiB already includes the origin family's physical footprint assumptions; no second storage amplification is applied.
* The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.
* Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
* AWS Price List API, AmazonStates offer: [https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonStates/current/us-east-1/index.json](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonStates/current/us-east-1/index.json)
* Azure Retail Prices API: [https://prices.azure.com/api/retail/prices](https://prices.azure.com/api/retail/prices)

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied.

Excluded costs and workload features:

* Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them.
* Destination application execution and separately billed downstream services; supply those allocations separately.
* Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
* Unmodeled dependent services, task execution and operations outside the selected workload family.

List prices read: 2026-10-22. Model: `plan-b44eea033c349a8f21b56cb8f9cca7198297c072` / `2026-10-22.planning.2`. Curve: `workload-1`.

Sources: [AWS Price List API, AmazonStates offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonStates/current/us-east-1/index.json), [Azure Retail Prices API](https://prices.azure.com/api/retail/prices).

**Step Functions Standard → Azure Durable Functions: Authored native-usage planning example.** Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts.

Scenario source region: us-east-1. Scenario target region: East US. Currency: USD.

| Monthly component | USD |
| - | -: |
| Origin: Standard state transitions | 0.00 |
| Target: Target retained physical data | 0.00 |
| Target: Additional broker replica storage | 0.00 |
| Target: Target native provider operations | 0.00 |
| Target: Execution or worker CPU | 0.00 |
| Target: Execution or worker RAM | 0.00 |
| Target: Selected billable network | 0.00 |
| Target: Independent native resources | 0.00 |
| Target: Independent native resources | 0.00 |
| Target: Durable staging CPU | 60.30 |
| Target: Durable staging RAM | 40.88 |
| Target: Durable staging disk | 17.00 |
| **Origin service subtotal** | **0.00** |
| **Target service subtotal** | **118.18** |

Estimated allocation, not benchmark calibrated: sized at 2 vCPU, 8 GiB memory and 100 GiB SSD for this scenario.

Unestimated components: Adapter hosting, Tensor9 fees. A modeled adapted total and savings require these costs.

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied.

Excluded costs and workload features:

* Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them.
* Destination application execution and separately billed downstream services; supply those allocations separately.
* Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
* Unmodeled dependent services, task execution and operations outside the selected workload family.

**Scenario assumptions**

| Input | Value | Unit |
| - | -: | - |
| Origin list price · Standard state transitions | 0.000025 | USD/transitions |
| Target steps per source transition | 2 | steps |
| History bytes per transition | 3,072 | bytes |
| History retention | 7 | days |
| Worker CPU per transition | 5 | vCPU-ms |
| Target price guess · read | 0 | USD/read |
| Target price guess · write | 0 | USD/write |
| Target list price · provider operation | 0.000002072 | USD/provider operation |
| Target price guess · GiB-month | 0 | USD/GiB-month |
| Target price guess · published GiB | 0 | USD/published GiB |
| Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Target price guess · network GiB | 0 | USD/network GiB |
| Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Target price guess · vCPU-hour | 0 | USD/vCPU-hour |
| Target price guess · GiB-hour | 0 | USD/GiB-hour |
| Target price guess · resource-hour | 0 | USD/resource-hour |
| Target price guess · resource-month | 0 | USD/resource-month |
| Target price guess · input token | 0 | USD/input token |
| Target price guess · output token | 0 | USD/output token |
| Target monthly base charge | 0 | USD/month |
| Approximate target service minimum | 0 | USD/month |
| Minimum primary CPU | 2 | vCPU |
| Minimum primary RAM | 8 | GiB |
| Minimum primary disk | 100 | GiB |
| Additional full-price standby copy | 0 | 0 or 1 |
| Allocated share of provisioned cost | 1 | fraction |
| Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Planning peak / mean work | 2 | multiplier |
| Planning primary CPU utilization | 0.7 | fraction |
| Resident state reserved in RAM | 0.1 | fraction |
| Planning disk utilization | 0.8 | fraction |
| Maintenance and log disk reserve | 20 | GiB |
| Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Dependent object sink write price guess | 0.000005 | USD/write |
| Standard state transitions | 0 | transitions |

* Translated reads: 0 operations.

* Translated writes: 0 operations.

* Translated resident physical data: 0 GiB-month.

* Native provider operations: 0 operations.

* Published payload: 0 GiB.

* Delivered payload: 0 GiB.

* Allocated execution CPU: 0 vCPU-hour.

* Allocated execution RAM: 0 GiB-hour.

* Independent resource allocation: 0 resource-hour.

* Independent inventory: 0 resource-month.

* Input tokens: 0 tokens.

* Output tokens: 0 tokens.

* Billable network: 0 GiB.

* Dependent object sink retained data: 0 GiB-month.

* Dependent object sink writes: 0 writes.

* Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.

* Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.

* Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.

* Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.

* A declared adapter mapping and cost model do not establish implementation availability or service equivalence.

* This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.

* Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts.

* A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent.

* Managed steps, worker CPU and durable history are distinct target cost components. Internal/external step split needs target-specific assumptions.

* Standard-only origin profile; no inference of Express duration, memory or task execution cost.

* Azure Durable Functions has no orchestration charge of its own: with the default Azure Storage provider it bills the function executions that run orchestrator and activity steps plus the queue and table transactions that persist their messages and history in the customer's storage account. The step rate is that composite on Flex Consumption. Execution GB-seconds (USD 0.000026 per GB-second on Flex Consumption), idle queue polling (a few hundred thousand transactions a month per app) and table storage (USD 0.045 per GB-month) are not modeled, and the family's worker CPU is not a Durable Functions charge. The Durable Task Scheduler (Dedicated USD 0.684932 per capacity-unit hour) is an alternative backend and is not selected.

* Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1\_0\_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.

* Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing ([https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size](https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size)): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.

* Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)). The 20 GiB reserve exceeds PostgreSQL's 1 GB default max\_wal\_size; the remainder of that reserve is unmeasured.

* CPU tiers double from 2 vCPUs to the target's largest node at 4 GiB per vCPU; each target's documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead.

* No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.

* Node bounds: Cloud SQL Enterprise allows 1-96 vCPUs at 0.9-6.5 GB per vCPU and up to 64 TB with a dedicated vCPU ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)).

* Stored GiB already includes the origin family's physical footprint assumptions; no second storage amplification is applied.

* The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.

* Copies and allocation fractions change cost only; they do not increase modeled primary capacity.

List prices read: 2026-10-22. Model: `plan-b44eea033c349a8f21b56cb8f9cca7198297c072` / `2026-10-22.planning.2`. Scenario: `planning-example`.

Sources: [AWS Price List API, AmazonStates offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonStates/current/us-east-1/index.json), [Azure Retail Prices API](https://prices.azure.com/api/retail/prices).

### On Azure, Google Cloud, OCI, and Private Kubernetes

#### Temporal Cloud (Managed)

| Capability | Area | Support | Operations | Notes |
| - | - | - | - | - |
| Logging configuration | Configuration | Partial | - | Configured logs use the deployment's logging destination and honor includeExecutionData; CloudWatch Logs is not written. |
| Tracing configuration | Configuration | Out of scope | - | Enabling X-Ray tracing is rejected when creating or updating a state machine. |
| Integration validation | Definitions | Partial | - | Definitions can use only the deployment's supported Task resources and invocation patterns. |

| Operation | Area | Support | Depth | Notes |
| - | - | - | - | - |
| ValidateStateMachineDefinition | Diagnostics | Supported | Most usage | Validates ASL without creating a resource and reports diagnostics, including unsupported Task resources and invocation patterns. |
| CreateStateMachine | State machines | Supported | Common | Validates ASL and stores the definition, role, mode, encryption, logging and tags; unsupported integrations are rejected. |
| DeleteStateMachine | State machines | Supported | Common | Reports DELETING, terminates executions at their next state transition and retires the definition, versions and aliases once executions have closed. Express deletion is eventually consistent. |
| DescribeStateMachine | State machines | Supported | Common | Returns the adapter's definition, role, mode, revision and configuration. |
| DescribeStateMachineForExecution | State machines | Supported | Most usage | Returns the immutable definition and revision selected for a Standard execution. |
| ListStateMachines | State machines | Supported | Common | Lists state machines using opaque pagination tokens. |
| UpdateStateMachine | State machines | Supported | Common | Creates a new revision for subsequent executions; active executions retain their selected definition and runtime version. |
| ListTagsForResource | Tags | Supported | Full surface | Returns the resource's tags. |
| TagResource | Tags | Supported | Full surface | Attaches tags to state-machine or Activity records. |
| UntagResource | Tags | Supported | Full surface | Removes tags from the adapter's resource record. |
| CreateStateMachineAlias | Versions and aliases | Supported | Most usage | Stores weighted routing to one or two versions; each new execution retains the selected version. |
| DeleteStateMachineAlias | Versions and aliases | Supported | Full surface | Deletes the alias without interrupting executions previously started through it. |
| DeleteStateMachineVersion | Versions and aliases | Supported | Full surface | Deletes an unreferenced version; a version used by an alias cannot be deleted. |
| DescribeStateMachineAlias | Versions and aliases | Supported | Full surface | Returns the alias and routing configuration. |
| ListStateMachineAliases | Versions and aliases | Supported | Full surface | Lists aliases with pagination. |
| ListStateMachineVersions | Versions and aliases | Supported | Most usage | Lists published versions with pagination. |
| PublishStateMachineVersion | Versions and aliases | Supported | Most usage | Publishes an immutable numbered revision. |
| UpdateStateMachineAlias | Versions and aliases | Supported | Full surface | Updates routing for subsequent starts; existing executions keep their selected version. |

##### How it works

The Tensor9 service adapter stores each state machine's ASL definition, execution role, type and settings. The customer supplies an existing Temporal Cloud namespace. Creating a state machine saves a definition; it does not create a namespace or change who owns the account.

Published versions are saved in the adapter and never change. Aliases route new executions across versions, and each execution keeps the revision it started with. Updating a state machine does not change running executions. Deleting it ends running executions at their next state transition, then removes the definition, versions and aliases once they close. Deleting an Express state machine is eventually consistent. The Temporal Cloud namespace stays intact.

##### Limitations

Where the Step Functions state-machine mapping differs

* **Namespace settings are not managed through Step Functions.** The state-machine APIs do not set Temporal Cloud regions, retention, account permissions or billing. You configure these when you connect the deployment.
* **Unsupported integrations and X-Ray tracing are rejected.** Definitions must use the service integrations available in this deployment. Enabling X-Ray tracing is rejected, and logs go to the deployment's logging destination.

##### Other considerations

* **Definitions and history.** Definitions, versions and aliases are saved in the adapter; Temporal Cloud holds execution history in the namespace's region. Keep both for as long as your retention requirements say.
* **Ownership.** The customer controls the namespace and its credentials. Tensor9 maintains the adapter and interpreter workers in the deployment environment; Temporal operates the managed workflow service.
* **Moving from AWS.** Recreate definitions and versions through the Step Functions API. Running executions, their history and outstanding task tokens stay with the original service.

##### Example monthly charges

This Tensor9 Cloud Adapter scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. [How Tensor9 estimates costs](https://docs.tensor9.com/cloud-adapter-early-access/costs/overview.md) explains the method and what the estimates include.

##### Step Functions Standard · State transitions

Feature: Step Functions Standard.

Estimated monthly service charges by State transitions. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: Temporal Cloud (global list); currency: USD.

![Step Functions Standard · State transitions: monthly service charges by State transitions. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/2332558b7a53715518740dde45c15dae2ae5950d87374f295b95c268edf5e52b-light.svg)

![Step Functions Standard · State transitions: monthly service charges by State transitions. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/0d39bc309b796620bcd18c25cac48a886d32ee756d85e9f2d32dd1e81ad4d706-dark.svg)

Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples.

Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more.

| State transitions (per second) | Step Functions State Machine | Target scenario | Temporal Cloud (Managed) | Difference |
| -: | -: | - | -: | -: |
| 0 | 0.00 | Temporal Cloud (Managed) (one staging copy) | 618.18 | 618.18 |
| 0 | 0.00 | Temporal Cloud (Managed) (two staging copies) | 736.36 | 736.36 |
| 1 | 65.70 | Temporal Cloud (Managed) (one staging copy) | 755.98 | 690.28 |
| 1 | 65.70 | Temporal Cloud (Managed) (two staging copies) | 874.16 | 808.46 |
| 10 | 657.00 | Temporal Cloud (Managed) (one staging copy) | 2,544.98 | 1,887.98 |
| 10 | 657.00 | Temporal Cloud (Managed) (two staging copies) | 2,663.16 | 2,006.16 |
| 100 | 6,570.00 | Temporal Cloud (Managed) (one staging copy) | 14,809.64 | 8,239.64 |
| 100 | 6,570.00 | Temporal Cloud (Managed) (two staging copies) | 15,060.80 | 8,490.80 |
| 1,000 | 65,700.00 | Temporal Cloud (Managed) (one staging copy) | 136,234.20 | 70,534.20 |
| 1,000 | 65,700.00 | Temporal Cloud (Managed) (two staging copies) | 138,456.23 | 72,756.23 |
| 10,000 | 657,000.00 | Temporal Cloud (Managed) (one staging copy) | 1,338,313.25 | 681,313.25 |
| 10,000 | 657,000.00 | Temporal Cloud (Managed) (two staging copies) | 1,348,077.55 | 691,077.55 |

Estimated allocation, not benchmark calibrated: sized from 2 vCPU, 8 GiB memory and 100 GiB SSD at 0 per second to 96 vCPU, 624 GiB memory and 21,655 GiB SSD at 10,000 per second.

**Curve assumptions**

| Target scenario | Assumption | Value | Unit |
| - | - | -: | - |
| Temporal Cloud (Managed) (one staging copy) | Origin list price · Standard state transitions | 0.000025 | USD/transitions |
| Temporal Cloud (Managed) (one staging copy) | Target steps per source transition | 2 | steps |
| Temporal Cloud (Managed) (one staging copy) | History bytes per transition | 3,072 | bytes |
| Temporal Cloud (Managed) (one staging copy) | History retention | 7 | days |
| Temporal Cloud (Managed) (one staging copy) | Worker CPU per transition | 5 | vCPU-ms |
| Temporal Cloud (Managed) (one staging copy) | Target price guess · read | 0 | USD/read |
| Temporal Cloud (Managed) (one staging copy) | Target price guess · write | 0 | USD/write |
| Temporal Cloud (Managed) (one staging copy) | Target list price · provider operation | 0.00005 | USD/provider operation |
| Temporal Cloud (Managed) (one staging copy) | Target list price · GiB-month | 0.7665 | USD/GiB-month |
| Temporal Cloud (Managed) (one staging copy) | Target price guess · published GiB | 0 | USD/published GiB |
| Temporal Cloud (Managed) (one staging copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Temporal Cloud (Managed) (one staging copy) | Target price guess · network GiB | 0 | USD/network GiB |
| Temporal Cloud (Managed) (one staging copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Temporal Cloud (Managed) (one staging copy) | Target price guess · vCPU-hour | 0 | USD/vCPU-hour |
| Temporal Cloud (Managed) (one staging copy) | Target price guess · GiB-hour | 0 | USD/GiB-hour |
| Temporal Cloud (Managed) (one staging copy) | Target price guess · resource-hour | 0 | USD/resource-hour |
| Temporal Cloud (Managed) (one staging copy) | Target price guess · resource-month | 0 | USD/resource-month |
| Temporal Cloud (Managed) (one staging copy) | Target price guess · input token | 0 | USD/input token |
| Temporal Cloud (Managed) (one staging copy) | Target price guess · output token | 0 | USD/output token |
| Temporal Cloud (Managed) (one staging copy) | Included before billing · provider operation | 2,500,000 | provider operation |
| Temporal Cloud (Managed) (one staging copy) | Included before billing · GiB-month | 100 | GiB-month |
| Temporal Cloud (Managed) (one staging copy) | Target monthly base charge · list price | 500 | USD/month |
| Temporal Cloud (Managed) (one staging copy) | Approximate target service minimum | 0 | USD/month |
| Temporal Cloud (Managed) (one staging copy) | Minimum primary CPU | 2 | vCPU |
| Temporal Cloud (Managed) (one staging copy) | Minimum primary RAM | 8 | GiB |
| Temporal Cloud (Managed) (one staging copy) | Minimum primary disk | 100 | GiB |
| Temporal Cloud (Managed) (one staging copy) | Additional full-price standby copy | 0 | 0 or 1 |
| Temporal Cloud (Managed) (one staging copy) | Allocated share of provisioned cost | 1 | fraction |
| Temporal Cloud (Managed) (one staging copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Temporal Cloud (Managed) (one staging copy) | Planning peak / mean work | 2 | multiplier |
| Temporal Cloud (Managed) (one staging copy) | Planning primary CPU utilization | 0.7 | fraction |
| Temporal Cloud (Managed) (one staging copy) | Resident state reserved in RAM | 0.1 | fraction |
| Temporal Cloud (Managed) (one staging copy) | Planning disk utilization | 0.8 | fraction |
| Temporal Cloud (Managed) (one staging copy) | Maintenance and log disk reserve | 20 | GiB |
| Temporal Cloud (Managed) (one staging copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Temporal Cloud (Managed) (one staging copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Temporal Cloud (Managed) (one staging copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Temporal Cloud (Managed) (one staging copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Temporal Cloud (Managed) (one staging copy) | Dependent object sink write price guess | 0.000005 | USD/write |
| Temporal Cloud (Managed) (two staging copies) | Origin list price · Standard state transitions | 0.000025 | USD/transitions |
| Temporal Cloud (Managed) (two staging copies) | Target steps per source transition | 2 | steps |
| Temporal Cloud (Managed) (two staging copies) | History bytes per transition | 3,072 | bytes |
| Temporal Cloud (Managed) (two staging copies) | History retention | 7 | days |
| Temporal Cloud (Managed) (two staging copies) | Worker CPU per transition | 5 | vCPU-ms |
| Temporal Cloud (Managed) (two staging copies) | Target price guess · read | 0 | USD/read |
| Temporal Cloud (Managed) (two staging copies) | Target price guess · write | 0 | USD/write |
| Temporal Cloud (Managed) (two staging copies) | Target list price · provider operation | 0.00005 | USD/provider operation |
| Temporal Cloud (Managed) (two staging copies) | Target list price · GiB-month | 0.7665 | USD/GiB-month |
| Temporal Cloud (Managed) (two staging copies) | Target price guess · published GiB | 0 | USD/published GiB |
| Temporal Cloud (Managed) (two staging copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Temporal Cloud (Managed) (two staging copies) | Target price guess · network GiB | 0 | USD/network GiB |
| Temporal Cloud (Managed) (two staging copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Temporal Cloud (Managed) (two staging copies) | Target price guess · vCPU-hour | 0 | USD/vCPU-hour |
| Temporal Cloud (Managed) (two staging copies) | Target price guess · GiB-hour | 0 | USD/GiB-hour |
| Temporal Cloud (Managed) (two staging copies) | Target price guess · resource-hour | 0 | USD/resource-hour |
| Temporal Cloud (Managed) (two staging copies) | Target price guess · resource-month | 0 | USD/resource-month |
| Temporal Cloud (Managed) (two staging copies) | Target price guess · input token | 0 | USD/input token |
| Temporal Cloud (Managed) (two staging copies) | Target price guess · output token | 0 | USD/output token |
| Temporal Cloud (Managed) (two staging copies) | Included before billing · provider operation | 2,500,000 | provider operation |
| Temporal Cloud (Managed) (two staging copies) | Included before billing · GiB-month | 100 | GiB-month |
| Temporal Cloud (Managed) (two staging copies) | Target monthly base charge · list price | 500 | USD/month |
| Temporal Cloud (Managed) (two staging copies) | Approximate target service minimum | 0 | USD/month |
| Temporal Cloud (Managed) (two staging copies) | Minimum primary CPU | 2 | vCPU |
| Temporal Cloud (Managed) (two staging copies) | Minimum primary RAM | 8 | GiB |
| Temporal Cloud (Managed) (two staging copies) | Minimum primary disk | 100 | GiB |
| Temporal Cloud (Managed) (two staging copies) | Additional full-price standby copy | 1 | 0 or 1 |
| Temporal Cloud (Managed) (two staging copies) | Allocated share of provisioned cost | 1 | fraction |
| Temporal Cloud (Managed) (two staging copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Temporal Cloud (Managed) (two staging copies) | Planning peak / mean work | 2 | multiplier |
| Temporal Cloud (Managed) (two staging copies) | Planning primary CPU utilization | 0.7 | fraction |
| Temporal Cloud (Managed) (two staging copies) | Resident state reserved in RAM | 0.1 | fraction |
| Temporal Cloud (Managed) (two staging copies) | Planning disk utilization | 0.8 | fraction |
| Temporal Cloud (Managed) (two staging copies) | Maintenance and log disk reserve | 20 | GiB |
| Temporal Cloud (Managed) (two staging copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Temporal Cloud (Managed) (two staging copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Temporal Cloud (Managed) (two staging copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Temporal Cloud (Managed) (two staging copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Temporal Cloud (Managed) (two staging copies) | Dependent object sink write price guess | 0.000005 | USD/write |

* Includes source retries; target amplification is applied only once. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements.
* Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → Temporal Cloud (global list), USD/month.
* Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
* Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
* Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve's workload note.
* Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
* Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
* Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
* Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
* A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
* This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
* Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts.
* A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent.
* Managed steps, worker CPU and durable history are distinct target cost components. Internal/external step split needs target-specific assumptions.
* Standard-only origin profile; no inference of Express duration, memory or task execution cost.
* Temporal Cloud bills Actions, active and retained workflow-history storage, and a plan. The profile selects the Business plan: the greater of USD 500/month or 10% of consumption, with 2.5 million Actions, 2.5 GB of active and 100 GB of retained storage included. The 500 base is exact while consumption stays under USD 5,000/month; above that the plan adds 10% of consumption, which is not modeled. Pay-as-you-go Actions graduate from USD 50 to 25 per million by volume beyond the included Actions. History storage bills USD 0.042 per active GBh and 0.00105 per retained GBh. The family's retained history of closed executions bills at the retained rate beyond the 100 GB included; active history of running executions is small for Step Functions workloads and is not modeled. The Developer plan (no base, 10% of consumption, USD 50 per million Actions at every volume) is not selected. Workers run on the customer's own compute.
* Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1\_0\_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.
* Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing ([https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size](https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size)): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.
* Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)). The 20 GiB reserve exceeds PostgreSQL's 1 GB default max\_wal\_size; the remainder of that reserve is unmeasured.
* CPU tiers double from 2 vCPUs to the target's largest node at 4 GiB per vCPU; each target's documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead.
* No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.
* Node bounds: Cloud SQL Enterprise allows 1-96 vCPUs at 0.9-6.5 GB per vCPU and up to 64 TB with a dedicated vCPU ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)).
* Stored GiB already includes the origin family's physical footprint assumptions; no second storage amplification is applied.
* The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.
* Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
* AWS Price List API, AmazonStates offer: [https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonStates/current/us-east-1/index.json](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonStates/current/us-east-1/index.json)
* Temporal Cloud pricing: [https://docs.temporal.io/cloud/pricing](https://docs.temporal.io/cloud/pricing)

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied.

Excluded costs and workload features:

* Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them.
* Destination application execution and separately billed downstream services; supply those allocations separately.
* Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
* Unmodeled dependent services, task execution and operations outside the selected workload family.

List prices read: 2026-10-22. Model: `plan-0d058f5a872975ffcd87b6e3a105b9cefcb43a6b` / `2026-10-22.planning.2`. Curve: `workload-1`.

Sources: [AWS Price List API, AmazonStates offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonStates/current/us-east-1/index.json), [Temporal Cloud pricing](https://docs.temporal.io/cloud/pricing).

**Step Functions Standard → Temporal Cloud (Managed): Authored native-usage planning example.** Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts.

Scenario source region: us-east-1. Scenario target region: Temporal Cloud (global list). Currency: USD.

| Monthly component | USD |
| - | -: |
| Origin: Standard state transitions | 0.00 |
| Target: Target retained physical data after 100 included | 0.00 |
| Target: Additional broker replica storage | 0.00 |
| Target: Target native provider operations after 2500000 included | 0.00 |
| Target: Execution or worker CPU | 0.00 |
| Target: Execution or worker RAM | 0.00 |
| Target: Selected billable network | 0.00 |
| Target: Independent native resources | 0.00 |
| Target: Independent native resources | 0.00 |
| Target: Target monthly base charge | 500.00 |
| Target: Durable staging CPU | 60.30 |
| Target: Durable staging RAM | 40.88 |
| Target: Durable staging disk | 17.00 |
| **Origin service subtotal** | **0.00** |
| **Target service subtotal** | **618.18** |

Estimated allocation, not benchmark calibrated: sized at 2 vCPU, 8 GiB memory and 100 GiB SSD for this scenario.

Unestimated components: Adapter hosting, Tensor9 fees. A modeled adapted total and savings require these costs.

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied.

Excluded costs and workload features:

* Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them.
* Destination application execution and separately billed downstream services; supply those allocations separately.
* Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
* Unmodeled dependent services, task execution and operations outside the selected workload family.

**Scenario assumptions**

| Input | Value | Unit |
| - | -: | - |
| Origin list price · Standard state transitions | 0.000025 | USD/transitions |
| Target steps per source transition | 2 | steps |
| History bytes per transition | 3,072 | bytes |
| History retention | 7 | days |
| Worker CPU per transition | 5 | vCPU-ms |
| Target price guess · read | 0 | USD/read |
| Target price guess · write | 0 | USD/write |
| Target list price · provider operation | 0.00005 | USD/provider operation |
| Target list price · GiB-month | 0.7665 | USD/GiB-month |
| Target price guess · published GiB | 0 | USD/published GiB |
| Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Target price guess · network GiB | 0 | USD/network GiB |
| Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Target price guess · vCPU-hour | 0 | USD/vCPU-hour |
| Target price guess · GiB-hour | 0 | USD/GiB-hour |
| Target price guess · resource-hour | 0 | USD/resource-hour |
| Target price guess · resource-month | 0 | USD/resource-month |
| Target price guess · input token | 0 | USD/input token |
| Target price guess · output token | 0 | USD/output token |
| Included before billing · provider operation | 2,500,000 | provider operation |
| Included before billing · GiB-month | 100 | GiB-month |
| Target monthly base charge · list price | 500 | USD/month |
| Approximate target service minimum | 0 | USD/month |
| Minimum primary CPU | 2 | vCPU |
| Minimum primary RAM | 8 | GiB |
| Minimum primary disk | 100 | GiB |
| Additional full-price standby copy | 0 | 0 or 1 |
| Allocated share of provisioned cost | 1 | fraction |
| Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Planning peak / mean work | 2 | multiplier |
| Planning primary CPU utilization | 0.7 | fraction |
| Resident state reserved in RAM | 0.1 | fraction |
| Planning disk utilization | 0.8 | fraction |
| Maintenance and log disk reserve | 20 | GiB |
| Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Dependent object sink write price guess | 0.000005 | USD/write |
| Standard state transitions | 0 | transitions |

* Translated reads: 0 operations.

* Translated writes: 0 operations.

* Translated resident physical data: 0 GiB-month.

* Native provider operations: 0 operations.

* Published payload: 0 GiB.

* Delivered payload: 0 GiB.

* Allocated execution CPU: 0 vCPU-hour.

* Allocated execution RAM: 0 GiB-hour.

* Independent resource allocation: 0 resource-hour.

* Independent inventory: 0 resource-month.

* Input tokens: 0 tokens.

* Output tokens: 0 tokens.

* Billable network: 0 GiB.

* Dependent object sink retained data: 0 GiB-month.

* Dependent object sink writes: 0 writes.

* Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.

* Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.

* Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.

* Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.

* A declared adapter mapping and cost model do not establish implementation availability or service equivalence.

* This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.

* Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts.

* A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent.

* Managed steps, worker CPU and durable history are distinct target cost components. Internal/external step split needs target-specific assumptions.

* Standard-only origin profile; no inference of Express duration, memory or task execution cost.

* Temporal Cloud bills Actions, active and retained workflow-history storage, and a plan. The profile selects the Business plan: the greater of USD 500/month or 10% of consumption, with 2.5 million Actions, 2.5 GB of active and 100 GB of retained storage included. The 500 base is exact while consumption stays under USD 5,000/month; above that the plan adds 10% of consumption, which is not modeled. Pay-as-you-go Actions graduate from USD 50 to 25 per million by volume beyond the included Actions. History storage bills USD 0.042 per active GBh and 0.00105 per retained GBh. The family's retained history of closed executions bills at the retained rate beyond the 100 GB included; active history of running executions is small for Step Functions workloads and is not modeled. The Developer plan (no base, 10% of consumption, USD 50 per million Actions at every volume) is not selected. Workers run on the customer's own compute.

* Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1\_0\_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.

* Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing ([https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size](https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size)): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.

* Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)). The 20 GiB reserve exceeds PostgreSQL's 1 GB default max\_wal\_size; the remainder of that reserve is unmeasured.

* CPU tiers double from 2 vCPUs to the target's largest node at 4 GiB per vCPU; each target's documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead.

* No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.

* Node bounds: Cloud SQL Enterprise allows 1-96 vCPUs at 0.9-6.5 GB per vCPU and up to 64 TB with a dedicated vCPU ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)).

* Stored GiB already includes the origin family's physical footprint assumptions; no second storage amplification is applied.

* The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.

* Copies and allocation fractions change cost only; they do not increase modeled primary capacity.

List prices read: 2026-10-22. Model: `plan-0d058f5a872975ffcd87b6e3a105b9cefcb43a6b` / `2026-10-22.planning.2`. Scenario: `planning-example`.

Sources: [AWS Price List API, AmazonStates offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonStates/current/us-east-1/index.json), [Temporal Cloud pricing](https://docs.temporal.io/cloud/pricing).

### On Google Cloud

#### Cloud Workflows

| Capability | Area | Support | Operations | Notes |
| - | - | - | - | - |
| Encryption configuration | Configuration | Supported | - | a customer-managed key names a key served by the KMS mapping on the same Cloud Adapter deployment |
| Logging configuration | Configuration | Partial | - | includeExecutionData and the configured destination are honoured; the destination is served by the Cloud Adapter deployment, since CloudWatch Logs is not adapted |
| Tracing configuration | Configuration | Out of scope | - | X-Ray is not adapted, so a configuration that enables tracing is rejected |
| Definition limit | Limits | Supported | - | the 1 MB definition ceiling is enforced at the API; a definition is split across prepared modules because one Workflows source is capped at 128 KB |

| Operation | Area | Support | Depth | Notes |
| - | - | - | - | - |
| CreateStateMachineAlias | Aliases | Supported | Most usage | weighted routing across up to two of this machine's versions, held by the adapter |
| DeleteStateMachineAlias | Aliases | Supported | Most usage | - |
| DescribeStateMachineAlias | Aliases | Supported | Most usage | - |
| ListStateMachineAliases | Aliases | Supported | Most usage | - |
| UpdateStateMachineAlias | Aliases | Supported | Most usage | - |
| CreateStateMachine | State machines | Supported | Common | stores the definition, role, type and configuration as revision one and prepares its workflow modules; a state or field the translation cannot express is refused here rather than dropped |
| DeleteStateMachine | State machines | Supported | Common | succeeds immediately and the state machine reads DELETING until running executions finish |
| DescribeStateMachine | State machines | Supported | Common | reads the record; a version or alias ARN reads that revision's definition |
| ListStateMachines | State machines | Supported | Common | - |
| UpdateStateMachine | State machines | Supported | Common | produces the next revision and prepares new modules; running executions keep the modules they started on |
| ValidateStateMachineDefinition | State machines | Supported | Common | the shared ASL validator, plus this engine's own refusals for states it does not run |
| ListTagsForResource | Tags | Supported | Full surface | - |
| TagResource | Tags | Supported | Full surface | - |
| UntagResource | Tags | Supported | Full surface | - |
| DeleteStateMachineVersion | Versions | Supported | Most usage | refused while an alias routes to it |
| DescribeStateMachineVersion | Versions | Supported | Most usage | - |
| ListStateMachineVersions | Versions | Supported | Most usage | - |
| PublishStateMachineVersion | Versions | Supported | Most usage | an immutable version of the current revision, held by the adapter |

##### The state machine as an adapter record, prepared per revision

CreateStateMachine stores the definition, role, type, encryption, logging and tags as one revision and prepares that revision's Cloud Workflows modules. UpdateStateMachine produces the next revision and prepares its own modules; nothing already prepared is changed, so an execution keeps running the modules it started on. DeleteStateMachine succeeds immediately and the state machine reads DELETING; it is retired once its running executions complete.

##### Limitations

* **A state the translation cannot express is refused, not dropped.** The engine keeps its own list of runnable state types and refused fields and applies it at CreateStateMachine and ValidateStateMachineDefinition, because a workflow that silently omitted a state would run to a different answer than the one asked for. - **Tracing cannot be enabled.** X-Ray is not adapted, so a `tracingConfiguration` that enables tracing is rejected at CreateStateMachine and UpdateStateMachine. - **Logs stay on the Cloud Adapter deployment.** `includeExecutionData` and the configured destination are honoured; the destination is served by the Cloud Adapter deployment, since CloudWatch Logs is not adapted. - **A Task Resource must name a served service.** ValidateStateMachineDefinition reports, and CreateStateMachine refuses, a Resource naming a service this Cloud Adapter deployment does not adapt.

##### Other considerations

Cloud Workflows creates a new workflow revision only when a workflow's source or service account changes, and every execution records the revision it is using. The adapter relies on exactly that: a Step Functions version or alias maps onto prepared modules that are never edited in place, so AWS's immutable-version guarantee holds without Cloud Workflows needing an alias concept of its own.

##### Example monthly charges

This Tensor9 Cloud Adapter scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. [How Tensor9 estimates costs](https://docs.tensor9.com/cloud-adapter-early-access/costs/overview.md) explains the method and what the estimates include.

##### Step Functions Standard · State transitions

Feature: Step Functions Standard.

Estimated monthly service charges by State transitions. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD.

![Step Functions Standard · State transitions: monthly service charges by State transitions. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/e823712759bca21be0f7b1706e879427be0f150e25c8b7efb14bed145ff05fdc-light.svg)

![Step Functions Standard · State transitions: monthly service charges by State transitions. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/b2f8efbfa5f4a0ee43e7eeb0416085381dbc4fd68003022a7b4dd55b93792367-dark.svg)

Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples.

Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more.

| State transitions (per second) | Step Functions State Machine | Target scenario | Cloud Workflows | Difference |
| -: | -: | - | -: | -: |
| 0 | 0.00 | Cloud Workflows (one staging copy) | 118.18 | 118.18 |
| 0 | 0.00 | Cloud Workflows (two staging copies) | 236.36 | 236.36 |
| 1 | 65.70 | Cloud Workflows (one staging copy) | 170.69 | 104.99 |
| 1 | 65.70 | Cloud Workflows (two staging copies) | 288.87 | 223.17 |
| 10 | 657.00 | Cloud Workflows (one staging copy) | 643.73 | -13.27 |
| 10 | 657.00 | Cloud Workflows (two staging copies) | 761.91 | 104.91 |
| 100 | 6,570.00 | Cloud Workflows (one staging copy) | 5,507.11 | -1,062.89 |
| 100 | 6,570.00 | Cloud Workflows (two staging copies) | 5,758.27 | -811.73 |
| 1,000 | 65,700.00 | Cloud Workflows (one staging copy) | 54,781.99 | -10,918.01 |
| 1,000 | 65,700.00 | Cloud Workflows (two staging copies) | 57,004.02 | -8,695.98 |
| 10,000 | 657,000.00 | Cloud Workflows (one staging copy) | 535,364.24 | -121,635.76 |
| 10,000 | 657,000.00 | Cloud Workflows (two staging copies) | 545,128.54 | -111,871.46 |

Estimated allocation, not benchmark calibrated: sized from 2 vCPU, 8 GiB memory and 100 GiB SSD at 0 per second to 96 vCPU, 624 GiB memory and 21,655 GiB SSD at 10,000 per second.

**Curve assumptions**

| Target scenario | Assumption | Value | Unit |
| - | - | -: | - |
| Cloud Workflows (one staging copy) | Origin list price · Standard state transitions | 0.000025 | USD/transitions |
| Cloud Workflows (one staging copy) | Target steps per source transition | 2 | steps |
| Cloud Workflows (one staging copy) | History bytes per transition | 3,072 | bytes |
| Cloud Workflows (one staging copy) | History retention | 7 | days |
| Cloud Workflows (one staging copy) | Worker CPU per transition | 5 | vCPU-ms |
| Cloud Workflows (one staging copy) | Target price guess · read | 0 | USD/read |
| Cloud Workflows (one staging copy) | Target price guess · write | 0 | USD/write |
| Cloud Workflows (one staging copy) | Target list price · provider operation | 0.00001 | USD/provider operation |
| Cloud Workflows (one staging copy) | Target price guess · GiB-month | 0 | USD/GiB-month |
| Cloud Workflows (one staging copy) | Target price guess · published GiB | 0 | USD/published GiB |
| Cloud Workflows (one staging copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Cloud Workflows (one staging copy) | Target price guess · network GiB | 0 | USD/network GiB |
| Cloud Workflows (one staging copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Cloud Workflows (one staging copy) | Target price guess · vCPU-hour | 0 | USD/vCPU-hour |
| Cloud Workflows (one staging copy) | Target price guess · GiB-hour | 0 | USD/GiB-hour |
| Cloud Workflows (one staging copy) | Target price guess · resource-hour | 0 | USD/resource-hour |
| Cloud Workflows (one staging copy) | Target price guess · resource-month | 0 | USD/resource-month |
| Cloud Workflows (one staging copy) | Target price guess · input token | 0 | USD/input token |
| Cloud Workflows (one staging copy) | Target price guess · output token | 0 | USD/output token |
| Cloud Workflows (one staging copy) | Included before billing · provider operation | 5,000 | provider operation |
| Cloud Workflows (one staging copy) | Target monthly base charge | 0 | USD/month |
| Cloud Workflows (one staging copy) | Approximate target service minimum | 0 | USD/month |
| Cloud Workflows (one staging copy) | Minimum primary CPU | 2 | vCPU |
| Cloud Workflows (one staging copy) | Minimum primary RAM | 8 | GiB |
| Cloud Workflows (one staging copy) | Minimum primary disk | 100 | GiB |
| Cloud Workflows (one staging copy) | Additional full-price standby copy | 0 | 0 or 1 |
| Cloud Workflows (one staging copy) | Allocated share of provisioned cost | 1 | fraction |
| Cloud Workflows (one staging copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Cloud Workflows (one staging copy) | Planning peak / mean work | 2 | multiplier |
| Cloud Workflows (one staging copy) | Planning primary CPU utilization | 0.7 | fraction |
| Cloud Workflows (one staging copy) | Resident state reserved in RAM | 0.1 | fraction |
| Cloud Workflows (one staging copy) | Planning disk utilization | 0.8 | fraction |
| Cloud Workflows (one staging copy) | Maintenance and log disk reserve | 20 | GiB |
| Cloud Workflows (one staging copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Cloud Workflows (one staging copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Cloud Workflows (one staging copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Cloud Workflows (one staging copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Cloud Workflows (one staging copy) | Dependent object sink write price guess | 0.000005 | USD/write |
| Cloud Workflows (two staging copies) | Origin list price · Standard state transitions | 0.000025 | USD/transitions |
| Cloud Workflows (two staging copies) | Target steps per source transition | 2 | steps |
| Cloud Workflows (two staging copies) | History bytes per transition | 3,072 | bytes |
| Cloud Workflows (two staging copies) | History retention | 7 | days |
| Cloud Workflows (two staging copies) | Worker CPU per transition | 5 | vCPU-ms |
| Cloud Workflows (two staging copies) | Target price guess · read | 0 | USD/read |
| Cloud Workflows (two staging copies) | Target price guess · write | 0 | USD/write |
| Cloud Workflows (two staging copies) | Target list price · provider operation | 0.00001 | USD/provider operation |
| Cloud Workflows (two staging copies) | Target price guess · GiB-month | 0 | USD/GiB-month |
| Cloud Workflows (two staging copies) | Target price guess · published GiB | 0 | USD/published GiB |
| Cloud Workflows (two staging copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Cloud Workflows (two staging copies) | Target price guess · network GiB | 0 | USD/network GiB |
| Cloud Workflows (two staging copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Cloud Workflows (two staging copies) | Target price guess · vCPU-hour | 0 | USD/vCPU-hour |
| Cloud Workflows (two staging copies) | Target price guess · GiB-hour | 0 | USD/GiB-hour |
| Cloud Workflows (two staging copies) | Target price guess · resource-hour | 0 | USD/resource-hour |
| Cloud Workflows (two staging copies) | Target price guess · resource-month | 0 | USD/resource-month |
| Cloud Workflows (two staging copies) | Target price guess · input token | 0 | USD/input token |
| Cloud Workflows (two staging copies) | Target price guess · output token | 0 | USD/output token |
| Cloud Workflows (two staging copies) | Included before billing · provider operation | 5,000 | provider operation |
| Cloud Workflows (two staging copies) | Target monthly base charge | 0 | USD/month |
| Cloud Workflows (two staging copies) | Approximate target service minimum | 0 | USD/month |
| Cloud Workflows (two staging copies) | Minimum primary CPU | 2 | vCPU |
| Cloud Workflows (two staging copies) | Minimum primary RAM | 8 | GiB |
| Cloud Workflows (two staging copies) | Minimum primary disk | 100 | GiB |
| Cloud Workflows (two staging copies) | Additional full-price standby copy | 1 | 0 or 1 |
| Cloud Workflows (two staging copies) | Allocated share of provisioned cost | 1 | fraction |
| Cloud Workflows (two staging copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Cloud Workflows (two staging copies) | Planning peak / mean work | 2 | multiplier |
| Cloud Workflows (two staging copies) | Planning primary CPU utilization | 0.7 | fraction |
| Cloud Workflows (two staging copies) | Resident state reserved in RAM | 0.1 | fraction |
| Cloud Workflows (two staging copies) | Planning disk utilization | 0.8 | fraction |
| Cloud Workflows (two staging copies) | Maintenance and log disk reserve | 20 | GiB |
| Cloud Workflows (two staging copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Cloud Workflows (two staging copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Cloud Workflows (two staging copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Cloud Workflows (two staging copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Cloud Workflows (two staging copies) | Dependent object sink write price guess | 0.000005 | USD/write |

* Includes source retries; target amplification is applied only once. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements.
* Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → us-central1, USD/month.
* Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
* Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
* Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve's workload note.
* Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
* Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
* Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
* Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
* A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
* This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
* Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts.
* A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent.
* Managed steps, worker CPU and durable history are distinct target cost components. Internal/external step split needs target-specific assumptions.
* Standard-only origin profile; no inference of Express duration, memory or task execution cost.
* Google Workflows bills executed steps, including failed and retried ones, in increments of 1,000. Translated Step Functions steps are priced as internal steps (USD 0.01 per 1,000 after 5,000 free): assignments, conditions, subworkflow calls and calls to \*.googleapis.com, Cloud Run and Cloud Run functions, which is where translated state-machine work runs. External steps (HTTP to endpoints outside Google Cloud or custom domains, and callback waits) bill USD 0.025 per 1,000 after 2,000 free; a workflow dominated by those should set the step rate to 0.000025. Worker CPU is not a Workflows charge.
* Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1\_0\_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.
* Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing ([https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size](https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size)): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.
* Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)). The 20 GiB reserve exceeds PostgreSQL's 1 GB default max\_wal\_size; the remainder of that reserve is unmeasured.
* CPU tiers double from 2 vCPUs to the target's largest node at 4 GiB per vCPU; each target's documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead.
* No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.
* Node bounds: Cloud SQL Enterprise allows 1-96 vCPUs at 0.9-6.5 GB per vCPU and up to 64 TB with a dedicated vCPU ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)).
* Stored GiB already includes the origin family's physical footprint assumptions; no second storage amplification is applied.
* The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.
* Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
* AWS Price List API, AmazonStates offer: [https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonStates/current/us-east-1/index.json](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonStates/current/us-east-1/index.json)
* Workflows pricing: [https://cloud.google.com/workflows/pricing](https://cloud.google.com/workflows/pricing)

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied.

Excluded costs and workload features:

* Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them.
* Destination application execution and separately billed downstream services; supply those allocations separately.
* Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
* Unmodeled dependent services, task execution and operations outside the selected workload family.

List prices read: 2026-10-22. Model: `plan-dd928168a42606a9934f60caa9c01c39c2e315fe` / `2026-10-22.planning.2`. Curve: `workload-1`.

Sources: [AWS Price List API, AmazonStates offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonStates/current/us-east-1/index.json), [Workflows pricing](https://cloud.google.com/workflows/pricing).

**Step Functions Standard → Cloud Workflows: Authored native-usage planning example.** Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts.

Scenario source region: us-east-1. Scenario target region: us-central1. Currency: USD.

| Monthly component | USD |
| - | -: |
| Origin: Standard state transitions | 0.00 |
| Target: Target retained physical data | 0.00 |
| Target: Additional broker replica storage | 0.00 |
| Target: Target native provider operations after 5000 included | 0.00 |
| Target: Execution or worker CPU | 0.00 |
| Target: Execution or worker RAM | 0.00 |
| Target: Selected billable network | 0.00 |
| Target: Independent native resources | 0.00 |
| Target: Independent native resources | 0.00 |
| Target: Durable staging CPU | 60.30 |
| Target: Durable staging RAM | 40.88 |
| Target: Durable staging disk | 17.00 |
| **Origin service subtotal** | **0.00** |
| **Target service subtotal** | **118.18** |

Estimated allocation, not benchmark calibrated: sized at 2 vCPU, 8 GiB memory and 100 GiB SSD for this scenario.

Unestimated components: Adapter hosting, Tensor9 fees. A modeled adapted total and savings require these costs.

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied.

Excluded costs and workload features:

* Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them.
* Destination application execution and separately billed downstream services; supply those allocations separately.
* Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
* Unmodeled dependent services, task execution and operations outside the selected workload family.

**Scenario assumptions**

| Input | Value | Unit |
| - | -: | - |
| Origin list price · Standard state transitions | 0.000025 | USD/transitions |
| Target steps per source transition | 2 | steps |
| History bytes per transition | 3,072 | bytes |
| History retention | 7 | days |
| Worker CPU per transition | 5 | vCPU-ms |
| Target price guess · read | 0 | USD/read |
| Target price guess · write | 0 | USD/write |
| Target list price · provider operation | 0.00001 | USD/provider operation |
| Target price guess · GiB-month | 0 | USD/GiB-month |
| Target price guess · published GiB | 0 | USD/published GiB |
| Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Target price guess · network GiB | 0 | USD/network GiB |
| Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Target price guess · vCPU-hour | 0 | USD/vCPU-hour |
| Target price guess · GiB-hour | 0 | USD/GiB-hour |
| Target price guess · resource-hour | 0 | USD/resource-hour |
| Target price guess · resource-month | 0 | USD/resource-month |
| Target price guess · input token | 0 | USD/input token |
| Target price guess · output token | 0 | USD/output token |
| Included before billing · provider operation | 5,000 | provider operation |
| Target monthly base charge | 0 | USD/month |
| Approximate target service minimum | 0 | USD/month |
| Minimum primary CPU | 2 | vCPU |
| Minimum primary RAM | 8 | GiB |
| Minimum primary disk | 100 | GiB |
| Additional full-price standby copy | 0 | 0 or 1 |
| Allocated share of provisioned cost | 1 | fraction |
| Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Planning peak / mean work | 2 | multiplier |
| Planning primary CPU utilization | 0.7 | fraction |
| Resident state reserved in RAM | 0.1 | fraction |
| Planning disk utilization | 0.8 | fraction |
| Maintenance and log disk reserve | 20 | GiB |
| Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Dependent object sink write price guess | 0.000005 | USD/write |
| Standard state transitions | 0 | transitions |

* Translated reads: 0 operations.

* Translated writes: 0 operations.

* Translated resident physical data: 0 GiB-month.

* Native provider operations: 0 operations.

* Published payload: 0 GiB.

* Delivered payload: 0 GiB.

* Allocated execution CPU: 0 vCPU-hour.

* Allocated execution RAM: 0 GiB-hour.

* Independent resource allocation: 0 resource-hour.

* Independent inventory: 0 resource-month.

* Input tokens: 0 tokens.

* Output tokens: 0 tokens.

* Billable network: 0 GiB.

* Dependent object sink retained data: 0 GiB-month.

* Dependent object sink writes: 0 writes.

* Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.

* Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.

* Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.

* Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.

* A declared adapter mapping and cost model do not establish implementation availability or service equivalence.

* This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.

* Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts.

* A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent.

* Managed steps, worker CPU and durable history are distinct target cost components. Internal/external step split needs target-specific assumptions.

* Standard-only origin profile; no inference of Express duration, memory or task execution cost.

* Google Workflows bills executed steps, including failed and retried ones, in increments of 1,000. Translated Step Functions steps are priced as internal steps (USD 0.01 per 1,000 after 5,000 free): assignments, conditions, subworkflow calls and calls to \*.googleapis.com, Cloud Run and Cloud Run functions, which is where translated state-machine work runs. External steps (HTTP to endpoints outside Google Cloud or custom domains, and callback waits) bill USD 0.025 per 1,000 after 2,000 free; a workflow dominated by those should set the step rate to 0.000025. Worker CPU is not a Workflows charge.

* Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1\_0\_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.

* Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing ([https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size](https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size)): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.

* Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)). The 20 GiB reserve exceeds PostgreSQL's 1 GB default max\_wal\_size; the remainder of that reserve is unmeasured.

* CPU tiers double from 2 vCPUs to the target's largest node at 4 GiB per vCPU; each target's documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead.

* No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.

* Node bounds: Cloud SQL Enterprise allows 1-96 vCPUs at 0.9-6.5 GB per vCPU and up to 64 TB with a dedicated vCPU ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)).

* Stored GiB already includes the origin family's physical footprint assumptions; no second storage amplification is applied.

* The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.

* Copies and allocation fractions change cost only; they do not increase modeled primary capacity.

List prices read: 2026-10-22. Model: `plan-dd928168a42606a9934f60caa9c01c39c2e315fe` / `2026-10-22.planning.2`. Scenario: `planning-example`.

Sources: [AWS Price List API, AmazonStates offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonStates/current/us-east-1/index.json), [Workflows pricing](https://cloud.google.com/workflows/pricing).

## Costs

Estimated monthly service charges for each backend with a published cost model, at one sampled workload from that model's cost curve. Adapter hosting and Tensor9 fees are excluded. [How Tensor9 estimates costs](https://docs.tensor9.com/cloud-adapter-early-access/costs/overview.md) explains the method, what the estimates include and how to read their qualifications.

| Origin API | Backend | Sampled workload | Price basis | Origin USD/month | Backend USD/month | Difference | Mapping |
| - | - | - | - | -: | -: | -: | - |
| `aws::1.0.0::sfn` | Azure Durable Functions | State transitions: 100 per second; one staging copy | Cited list prices, 2026-10-22 | 6,570.00 | 1,340.20 | -5,229.80 | Service adapter |
| `aws::1.0.0::sfn` | Cloud Workflows | State transitions: 100 per second; one staging copy | Cited list prices, 2026-10-22 | 6,570.00 | 5,507.11 | -1,062.89 | Service adapter |
| `aws::1.0.0::sfn` | Temporal (Self-Hosted) | State transitions: 100 per second; one copy | Cited list prices, 2026-10-22 | 6,570.00 | 170.63 | -6,399.37 | Service adapter |
| `aws::1.0.0::sfn` | Temporal Cloud (Managed) | State transitions: 100 per second; one staging copy | Cited list prices, 2026-10-22 | 6,570.00 | 14,809.64 | +8,239.64 | Service adapter |
| `aws::1.0.0::sfn::state-machine` | Azure Durable Functions | State transitions: 100 per second; one staging copy | Cited list prices, 2026-10-22 | 6,570.00 | 1,340.20 | -5,229.80 | Service adapter |
| `aws::1.0.0::sfn::state-machine` | Cloud Workflows | State transitions: 100 per second; one staging copy | Cited list prices, 2026-10-22 | 6,570.00 | 5,507.11 | -1,062.89 | Service adapter |
| `aws::1.0.0::sfn::state-machine` | Temporal (Self-Hosted) | State transitions: 100 per second; one copy | Cited list prices, 2026-10-22 | 6,570.00 | 170.63 | -6,399.37 | Service adapter |
| `aws::1.0.0::sfn::state-machine` | Temporal Cloud (Managed) | State transitions: 100 per second; one staging copy | Cited list prices, 2026-10-22 | 6,570.00 | 14,809.64 | +8,239.64 | Service adapter |

Difference means backend minus origin; a positive difference means the backend costs more. Workloads and target configurations differ by model, so compare each row's difference at its stated workload rather than charges across rows.
Cost curves across workload sizes, with every assumption and exclusion: [Step Functions costs](https://docs.tensor9.com/cloud-adapter-early-access/costs/additional-services/aws-sfn), [Step Functions State Machine costs](https://docs.tensor9.com/cloud-adapter-early-access/costs/additional-services/aws-sfn-state-machine).

## Service level agreements

> [!WARNING]
>
> These tables show Tensor9's standard service levels and adapters whose standard terms are still being defined. Your signed agreement determines the SLAs, covered adapters and operations, limits, remedies and support terms that apply to your deployment.

Listed terms cover requests sent through this service adapter. They do not cover direct connections to the target service or replace the cloud provider's own SLA. Each origin-to-target pair has its own terms or an explicit pending status.

See the [SLA tables](https://docs.tensor9.com/cloud-adapter-early-access/support/service-adapter-slas.md), [measurement rules](https://docs.tensor9.com/cloud-adapter-early-access/support/service-levels.md), and [scaling conditions](https://docs.tensor9.com/cloud-adapter-early-access/support/scaling-and-limits.md).

### Step Functions to Azure Durable Functions

| SLA | Service level | What is covered | Conditions |
| - | - | - | - |
| Workflow and execution reads adapter-added latency | +8 ms monthly p99 | `aws::1.0.0::sfn`: `DescribeActivity`, `DescribeExecution`, `DescribeMapRun`, `DescribeStateMachine`, `DescribeStateMachineAlias`, `DescribeStateMachineForExecution`, `GetExecutionHistory`, `ListActivities`, `ListExecutions`, `ListMapRuns`, `ListStateMachineAliases`, `ListStateMachineVersions`, `ListStateMachines`, `ListTagsForResource` | at most 100 returned records/history events and at most 1 MiB payload. |
| Definition, version, alias and tag mutation adapter-added latency | +15 ms monthly p99 | `aws::1.0.0::sfn`: `CreateActivity`, `CreateStateMachine`, `CreateStateMachineAlias`, `DeleteActivity`, `DeleteStateMachine`, `DeleteStateMachineAlias`, `DeleteStateMachineVersion`, `PublishStateMachineVersion`, `TagResource`, `UntagResource`, `UpdateStateMachine`, `UpdateStateMachineAlias`, `ValidateStateMachineDefinition` | Definition at most 1 MiB and at most 100 states; one named resource. |
| Execution and task coordination adapter-added latency | +12 ms monthly p99 | `aws::1.0.0::sfn`: `RedriveExecution`, `SendTaskFailure`, `SendTaskHeartbeat`, `SendTaskSuccess`, `StartExecution`, `StopExecution`, `TestState`, `UpdateMapRun` | Payload at most 256 KiB; one execution/task token; customer task execution excluded. |
| Activity poll processing adapter-added latency | +5 ms monthly p99 | `aws::1.0.0::sfn`: `GetActivityTask` | Adapter processing before the poll and after task availability; intentional wait time is excluded and reported separately. |
| Bounded synchronous workflow processing adapter-added latency | +25 ms monthly p99 | `aws::1.0.0::sfn`: `StartSyncExecution` | Payload at most 256 KiB and at most 32 workflow transitions; customer-service execution and intentional waits excluded by observed spans. |
| Documented adapter behavior | Preserve the supported behavior documented for this adapter | `aws::1.0.0::sfn`: `DescribeActivity`, `DescribeExecution`, `DescribeMapRun`, `DescribeStateMachine`, `DescribeStateMachineAlias`, `DescribeStateMachineForExecution`, `GetExecutionHistory`, `ListActivities`, `ListExecutions`, `ListMapRuns`, `ListStateMachineAliases`, `ListStateMachineVersions`, `ListStateMachines`, `ListTagsForResource`, `CreateActivity`, `CreateStateMachine`, `CreateStateMachineAlias`, `DeleteActivity`, `DeleteStateMachine`, `DeleteStateMachineAlias`, `DeleteStateMachineVersion`, `PublishStateMachineVersion`, `TagResource`, `UntagResource`, `UpdateStateMachine`, `UpdateStateMachineAlias`, `ValidateStateMachineDefinition`, `RedriveExecution`, `SendTaskFailure`, `SendTaskHeartbeat`, `SendTaskSuccess`, `StartExecution`, `StopExecution`, `TestState`, `UpdateMapRun`, `GetActivityTask`, `StartSyncExecution` | Accepted transitions and task outcomes are durable and idempotent, retries follow the definition, aliases resolve consistently, and redrive never skips required history. Unsupported ASL or target integrations fail before execution rather than being silently ignored. |
| Endpoint reachability | 99.9% per calendar month | Adapter endpoint reachability | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider's service. |
| Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Adapter behavior across requests | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. |

**Adapter-added latency.** A + prefix marks time added by the adapter, not the total time your application waits. Total request time includes adapter processing, backend service time and network time. The backend provider's SLA applies independently. Only separately measured target-service wait may be subtracted, and only when your agreement permits it; internal metadata, coordination and retry processing still count. For one request, 12 ms of adapter processing plus 90 ms waiting for the backend means at least 102 ms total. This example does not add monthly p99 values.

**What Tensor9 covers.** These service levels cover the adapter between the origin API and target API. They do not replace the target provider's SLA.

**How latency is counted.** Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.

**Which terms apply.** Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.

#### What this adapter does

Control calls validate and durably record state-machine definitions, versions and aliases. Execution calls admit work, evaluate ASL transitions and coordinate activities or azure::1.0.0::durable-functions. Time inside invoked customer services is separately observed; interpreter work, durable transition logging, retry decisions and response conversion remain covered.

#### How the latency targets were chosen

**Workflow and execution reads: +8 ms monthly p99 (adapter-added).** `DescribeActivity`, `DescribeExecution`, `DescribeMapRun`, `DescribeStateMachine`, `DescribeStateMachineAlias`, `DescribeStateMachineForExecution`, `GetExecutionHistory`, `ListActivities`, `ListExecutions`, `ListMapRuns`, `ListStateMachineAliases`, `ListStateMachineVersions`, `ListStateMachines`, `ListTagsForResource`. Bounded durable-log or definition-state response mapping.

**Definition, version, alias and tag mutation: +15 ms monthly p99 (adapter-added).** `CreateActivity`, `CreateStateMachine`, `CreateStateMachineAlias`, `DeleteActivity`, `DeleteStateMachine`, `DeleteStateMachineAlias`, `DeleteStateMachineVersion`, `PublishStateMachineVersion`, `TagResource`, `UntagResource`, `UpdateStateMachine`, `UpdateStateMachineAlias`, `ValidateStateMachineDefinition`. ASL validation and serialized durable metadata mutation.

**Execution and task coordination: +12 ms monthly p99 (adapter-added).** `RedriveExecution`, `SendTaskFailure`, `SendTaskHeartbeat`, `SendTaskSuccess`, `StartExecution`, `StopExecution`, `TestState`, `UpdateMapRun`. Durable transition admission and bounded workflow evaluation.

**Activity poll processing: +5 ms monthly p99 (adapter-added).** `GetActivityTask`. Authorization, bounded task lookup and response conversion around the documented long poll.

**Bounded synchronous workflow processing: +25 ms monthly p99 (adapter-added).** `StartSyncExecution`. Durable admission, bounded transition evaluation and final response conversion.

Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.

#### What counts toward latency

For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter's own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it.

For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request's adapter duration first, then the monthly p99. Do not subtract one service's p99 from another's. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.

#### Endpoint reachability and request failures

The endpoint-reachability target measures adapter health checks. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures remain Tensor9's responsibility even when the target is healthy.

Correctness and data-integrity requirements apply to every supported request. Endpoint reachability does not measure request correctness or grant an allowance for incorrect results.

#### Scaling and target-service capacity

Executions shard by execution identity; ordered transitions within one execution remain serialized. Qualification fixes definition size, history events, payload bytes, map concurrency, activity waiters and execution mix. Lists and histories are bounded pages, and a hot execution cannot monopolize unrelated workflows.

Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service's capacity with Tensor9's help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.

#### Data and behavior guarantees

Accepted transitions and task outcomes are durable and idempotent, retries follow the definition, aliases resolve consistently, and redrive never skips required history. Unsupported ASL or target integrations fail before execution rather than being silently ignored.

#### Example and diagnosis

StartExecution durably creates one execution and returns its stable ARN. A three-state workflow then records each transition; Lambda or cloud-workflow execution time is external, while ASL evaluation and log commits remain covered. GetExecutionHistory returns one bounded page from that durable sequence.

Use `tensor9 explain` and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider's latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.

### Step Functions to Cloud Workflows

| SLA | Service level | What is covered | Conditions |
| - | - | - | - |
| Workflow and execution reads adapter-added latency | +8 ms monthly p99 | `aws::1.0.0::sfn`: `DescribeActivity`, `DescribeExecution`, `DescribeMapRun`, `DescribeStateMachine`, `DescribeStateMachineAlias`, `DescribeStateMachineForExecution`, `GetExecutionHistory`, `ListActivities`, `ListExecutions`, `ListMapRuns`, `ListStateMachineAliases`, `ListStateMachineVersions`, `ListStateMachines`, `ListTagsForResource` | at most 100 returned records/history events and at most 1 MiB payload. |
| Definition, version, alias and tag mutation adapter-added latency | +15 ms monthly p99 | `aws::1.0.0::sfn`: `CreateActivity`, `CreateStateMachine`, `CreateStateMachineAlias`, `DeleteActivity`, `DeleteStateMachine`, `DeleteStateMachineAlias`, `DeleteStateMachineVersion`, `PublishStateMachineVersion`, `TagResource`, `UntagResource`, `UpdateStateMachine`, `UpdateStateMachineAlias`, `ValidateStateMachineDefinition` | Definition at most 1 MiB and at most 100 states; one named resource. |
| Execution and task coordination adapter-added latency | +12 ms monthly p99 | `aws::1.0.0::sfn`: `RedriveExecution`, `SendTaskFailure`, `SendTaskHeartbeat`, `SendTaskSuccess`, `StartExecution`, `StopExecution`, `TestState`, `UpdateMapRun` | Payload at most 256 KiB; one execution/task token; customer task execution excluded. |
| Activity poll processing adapter-added latency | +5 ms monthly p99 | `aws::1.0.0::sfn`: `GetActivityTask` | Adapter processing before the poll and after task availability; intentional wait time is excluded and reported separately. |
| Bounded synchronous workflow processing adapter-added latency | +25 ms monthly p99 | `aws::1.0.0::sfn`: `StartSyncExecution` | Payload at most 256 KiB and at most 32 workflow transitions; customer-service execution and intentional waits excluded by observed spans. |
| Documented adapter behavior | Preserve the supported behavior documented for this adapter | `aws::1.0.0::sfn`: `DescribeActivity`, `DescribeExecution`, `DescribeMapRun`, `DescribeStateMachine`, `DescribeStateMachineAlias`, `DescribeStateMachineForExecution`, `GetExecutionHistory`, `ListActivities`, `ListExecutions`, `ListMapRuns`, `ListStateMachineAliases`, `ListStateMachineVersions`, `ListStateMachines`, `ListTagsForResource`, `CreateActivity`, `CreateStateMachine`, `CreateStateMachineAlias`, `DeleteActivity`, `DeleteStateMachine`, `DeleteStateMachineAlias`, `DeleteStateMachineVersion`, `PublishStateMachineVersion`, `TagResource`, `UntagResource`, `UpdateStateMachine`, `UpdateStateMachineAlias`, `ValidateStateMachineDefinition`, `RedriveExecution`, `SendTaskFailure`, `SendTaskHeartbeat`, `SendTaskSuccess`, `StartExecution`, `StopExecution`, `TestState`, `UpdateMapRun`, `GetActivityTask`, `StartSyncExecution` | Accepted transitions and task outcomes are durable and idempotent, retries follow the definition, aliases resolve consistently, and redrive never skips required history. Unsupported ASL or target integrations fail before execution rather than being silently ignored. |
| Endpoint reachability | 99.9% per calendar month | Adapter endpoint reachability | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider's service. |
| Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Adapter behavior across requests | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. |

**Adapter-added latency.** A + prefix marks time added by the adapter, not the total time your application waits. Total request time includes adapter processing, backend service time and network time. The backend provider's SLA applies independently. Only separately measured target-service wait may be subtracted, and only when your agreement permits it; internal metadata, coordination and retry processing still count. For one request, 12 ms of adapter processing plus 90 ms waiting for the backend means at least 102 ms total. This example does not add monthly p99 values.

**What Tensor9 covers.** These service levels cover the adapter between the origin API and target API. They do not replace the target provider's SLA.

**How latency is counted.** Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.

**Which terms apply.** Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.

#### What this adapter does

Control calls validate and durably record state-machine definitions, versions and aliases. Execution calls admit work, evaluate ASL transitions and coordinate activities or google::1.0.0::workflows. Time inside invoked customer services is separately observed; interpreter work, durable transition logging, retry decisions and response conversion remain covered.

#### How the latency targets were chosen

**Workflow and execution reads: +8 ms monthly p99 (adapter-added).** `DescribeActivity`, `DescribeExecution`, `DescribeMapRun`, `DescribeStateMachine`, `DescribeStateMachineAlias`, `DescribeStateMachineForExecution`, `GetExecutionHistory`, `ListActivities`, `ListExecutions`, `ListMapRuns`, `ListStateMachineAliases`, `ListStateMachineVersions`, `ListStateMachines`, `ListTagsForResource`. Bounded durable-log or definition-state response mapping.

**Definition, version, alias and tag mutation: +15 ms monthly p99 (adapter-added).** `CreateActivity`, `CreateStateMachine`, `CreateStateMachineAlias`, `DeleteActivity`, `DeleteStateMachine`, `DeleteStateMachineAlias`, `DeleteStateMachineVersion`, `PublishStateMachineVersion`, `TagResource`, `UntagResource`, `UpdateStateMachine`, `UpdateStateMachineAlias`, `ValidateStateMachineDefinition`. ASL validation and serialized durable metadata mutation.

**Execution and task coordination: +12 ms monthly p99 (adapter-added).** `RedriveExecution`, `SendTaskFailure`, `SendTaskHeartbeat`, `SendTaskSuccess`, `StartExecution`, `StopExecution`, `TestState`, `UpdateMapRun`. Durable transition admission and bounded workflow evaluation.

**Activity poll processing: +5 ms monthly p99 (adapter-added).** `GetActivityTask`. Authorization, bounded task lookup and response conversion around the documented long poll.

**Bounded synchronous workflow processing: +25 ms monthly p99 (adapter-added).** `StartSyncExecution`. Durable admission, bounded transition evaluation and final response conversion.

Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.

#### What counts toward latency

For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter's own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it.

For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request's adapter duration first, then the monthly p99. Do not subtract one service's p99 from another's. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.

#### Endpoint reachability and request failures

The endpoint-reachability target measures adapter health checks. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures remain Tensor9's responsibility even when the target is healthy.

Correctness and data-integrity requirements apply to every supported request. Endpoint reachability does not measure request correctness or grant an allowance for incorrect results.

#### Scaling and target-service capacity

Executions shard by execution identity; ordered transitions within one execution remain serialized. Qualification fixes definition size, history events, payload bytes, map concurrency, activity waiters and execution mix. Lists and histories are bounded pages, and a hot execution cannot monopolize unrelated workflows.

Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service's capacity with Tensor9's help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.

#### Data and behavior guarantees

Accepted transitions and task outcomes are durable and idempotent, retries follow the definition, aliases resolve consistently, and redrive never skips required history. Unsupported ASL or target integrations fail before execution rather than being silently ignored.

#### Example and diagnosis

StartExecution durably creates one execution and returns its stable ARN. A three-state workflow then records each transition; Lambda or cloud-workflow execution time is external, while ASL evaluation and log commits remain covered. GetExecutionHistory returns one bounded page from that durable sequence.

Use `tensor9 explain` and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider's latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.

### Step Functions to Temporal Cloud (Managed)

| SLA | Service level | What is covered | Conditions |
| - | - | - | - |
| Workflow and execution reads adapter-added latency | +8 ms monthly p99 | `aws::1.0.0::sfn`: `DescribeActivity`, `DescribeExecution`, `DescribeMapRun`, `DescribeStateMachine`, `DescribeStateMachineAlias`, `DescribeStateMachineForExecution`, `GetExecutionHistory`, `ListActivities`, `ListExecutions`, `ListMapRuns`, `ListStateMachineAliases`, `ListStateMachineVersions`, `ListStateMachines`, `ListTagsForResource` | at most 100 returned records/history events and at most 1 MiB payload. |
| Definition, version, alias and tag mutation adapter-added latency | +15 ms monthly p99 | `aws::1.0.0::sfn`: `CreateActivity`, `CreateStateMachine`, `CreateStateMachineAlias`, `DeleteActivity`, `DeleteStateMachine`, `DeleteStateMachineAlias`, `DeleteStateMachineVersion`, `PublishStateMachineVersion`, `TagResource`, `UntagResource`, `UpdateStateMachine`, `UpdateStateMachineAlias`, `ValidateStateMachineDefinition` | Definition at most 1 MiB and at most 100 states; one named resource. |
| Execution and task coordination adapter-added latency | +12 ms monthly p99 | `aws::1.0.0::sfn`: `RedriveExecution`, `SendTaskFailure`, `SendTaskHeartbeat`, `SendTaskSuccess`, `StartExecution`, `StopExecution`, `TestState`, `UpdateMapRun` | Payload at most 256 KiB; one execution/task token; customer task execution excluded. |
| Activity poll processing adapter-added latency | +5 ms monthly p99 | `aws::1.0.0::sfn`: `GetActivityTask` | Adapter processing before the poll and after task availability; intentional wait time is excluded and reported separately. |
| Bounded synchronous workflow processing adapter-added latency | +25 ms monthly p99 | `aws::1.0.0::sfn`: `StartSyncExecution` | Payload at most 256 KiB and at most 32 workflow transitions; customer-service execution and intentional waits excluded by observed spans. |
| Documented adapter behavior | Preserve the supported behavior documented for this adapter | `aws::1.0.0::sfn`: `DescribeActivity`, `DescribeExecution`, `DescribeMapRun`, `DescribeStateMachine`, `DescribeStateMachineAlias`, `DescribeStateMachineForExecution`, `GetExecutionHistory`, `ListActivities`, `ListExecutions`, `ListMapRuns`, `ListStateMachineAliases`, `ListStateMachineVersions`, `ListStateMachines`, `ListTagsForResource`, `CreateActivity`, `CreateStateMachine`, `CreateStateMachineAlias`, `DeleteActivity`, `DeleteStateMachine`, `DeleteStateMachineAlias`, `DeleteStateMachineVersion`, `PublishStateMachineVersion`, `TagResource`, `UntagResource`, `UpdateStateMachine`, `UpdateStateMachineAlias`, `ValidateStateMachineDefinition`, `RedriveExecution`, `SendTaskFailure`, `SendTaskHeartbeat`, `SendTaskSuccess`, `StartExecution`, `StopExecution`, `TestState`, `UpdateMapRun`, `GetActivityTask`, `StartSyncExecution` | Accepted transitions and task outcomes are durable and idempotent, retries follow the definition, aliases resolve consistently, and redrive never skips required history. Unsupported ASL or target integrations fail before execution rather than being silently ignored. |
| Endpoint reachability | 99.9% per calendar month | Adapter endpoint reachability | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider's service. |
| Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Adapter behavior across requests | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. |

**Adapter-added latency.** A + prefix marks time added by the adapter, not the total time your application waits. Total request time includes adapter processing, backend service time and network time. The backend provider's SLA applies independently. Only separately measured target-service wait may be subtracted, and only when your agreement permits it; internal metadata, coordination and retry processing still count. For one request, 12 ms of adapter processing plus 90 ms waiting for the backend means at least 102 ms total. This example does not add monthly p99 values.

**What Tensor9 covers.** These service levels cover the adapter between the origin API and target API. They do not replace the target provider's SLA.

**How latency is counted.** Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.

**Which terms apply.** Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.

#### What this adapter does

Control calls validate and durably record state-machine definitions, versions and aliases. Execution calls admit work, evaluate ASL transitions and coordinate activities or temporalio::1.0.0::managed. Time inside invoked customer services is separately observed; interpreter work, durable transition logging, retry decisions and response conversion remain covered.

#### How the latency targets were chosen

**Workflow and execution reads: +8 ms monthly p99 (adapter-added).** `DescribeActivity`, `DescribeExecution`, `DescribeMapRun`, `DescribeStateMachine`, `DescribeStateMachineAlias`, `DescribeStateMachineForExecution`, `GetExecutionHistory`, `ListActivities`, `ListExecutions`, `ListMapRuns`, `ListStateMachineAliases`, `ListStateMachineVersions`, `ListStateMachines`, `ListTagsForResource`. Bounded durable-log or definition-state response mapping.

**Definition, version, alias and tag mutation: +15 ms monthly p99 (adapter-added).** `CreateActivity`, `CreateStateMachine`, `CreateStateMachineAlias`, `DeleteActivity`, `DeleteStateMachine`, `DeleteStateMachineAlias`, `DeleteStateMachineVersion`, `PublishStateMachineVersion`, `TagResource`, `UntagResource`, `UpdateStateMachine`, `UpdateStateMachineAlias`, `ValidateStateMachineDefinition`. ASL validation and serialized durable metadata mutation.

**Execution and task coordination: +12 ms monthly p99 (adapter-added).** `RedriveExecution`, `SendTaskFailure`, `SendTaskHeartbeat`, `SendTaskSuccess`, `StartExecution`, `StopExecution`, `TestState`, `UpdateMapRun`. Durable transition admission and bounded workflow evaluation.

**Activity poll processing: +5 ms monthly p99 (adapter-added).** `GetActivityTask`. Authorization, bounded task lookup and response conversion around the documented long poll.

**Bounded synchronous workflow processing: +25 ms monthly p99 (adapter-added).** `StartSyncExecution`. Durable admission, bounded transition evaluation and final response conversion.

Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.

#### What counts toward latency

For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter's own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it.

For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request's adapter duration first, then the monthly p99. Do not subtract one service's p99 from another's. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.

#### Endpoint reachability and request failures

The endpoint-reachability target measures adapter health checks. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures remain Tensor9's responsibility even when the target is healthy.

Correctness and data-integrity requirements apply to every supported request. Endpoint reachability does not measure request correctness or grant an allowance for incorrect results.

#### Scaling and target-service capacity

Executions shard by execution identity; ordered transitions within one execution remain serialized. Qualification fixes definition size, history events, payload bytes, map concurrency, activity waiters and execution mix. Lists and histories are bounded pages, and a hot execution cannot monopolize unrelated workflows.

Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service's capacity with Tensor9's help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.

#### Data and behavior guarantees

Accepted transitions and task outcomes are durable and idempotent, retries follow the definition, aliases resolve consistently, and redrive never skips required history. Unsupported ASL or target integrations fail before execution rather than being silently ignored.

#### Example and diagnosis

StartExecution durably creates one execution and returns its stable ARN. A three-state workflow then records each transition; Lambda or cloud-workflow execution time is external, while ASL evaluation and log commits remain covered. GetExecutionHistory returns one bounded page from that durable sequence.

Use `tensor9 explain` and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider's latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.

### Step Functions to Temporal (Self-Hosted)

| SLA | Service level | What is covered | Conditions |
| - | - | - | - |
| Workflow and execution reads adapter-added latency | +8 ms monthly p99 | `aws::1.0.0::sfn`: `DescribeActivity`, `DescribeExecution`, `DescribeMapRun`, `DescribeStateMachine`, `DescribeStateMachineAlias`, `DescribeStateMachineForExecution`, `GetExecutionHistory`, `ListActivities`, `ListExecutions`, `ListMapRuns`, `ListStateMachineAliases`, `ListStateMachineVersions`, `ListStateMachines`, `ListTagsForResource` | at most 100 returned records/history events and at most 1 MiB payload. |
| Definition, version, alias and tag mutation adapter-added latency | +15 ms monthly p99 | `aws::1.0.0::sfn`: `CreateActivity`, `CreateStateMachine`, `CreateStateMachineAlias`, `DeleteActivity`, `DeleteStateMachine`, `DeleteStateMachineAlias`, `DeleteStateMachineVersion`, `PublishStateMachineVersion`, `TagResource`, `UntagResource`, `UpdateStateMachine`, `UpdateStateMachineAlias`, `ValidateStateMachineDefinition` | Definition at most 1 MiB and at most 100 states; one named resource. |
| Execution and task coordination adapter-added latency | +12 ms monthly p99 | `aws::1.0.0::sfn`: `RedriveExecution`, `SendTaskFailure`, `SendTaskHeartbeat`, `SendTaskSuccess`, `StartExecution`, `StopExecution`, `TestState`, `UpdateMapRun` | Payload at most 256 KiB; one execution/task token; customer task execution excluded. |
| Activity poll processing adapter-added latency | +5 ms monthly p99 | `aws::1.0.0::sfn`: `GetActivityTask` | Adapter processing before the poll and after task availability; intentional wait time is excluded and reported separately. |
| Bounded synchronous workflow processing adapter-added latency | +25 ms monthly p99 | `aws::1.0.0::sfn`: `StartSyncExecution` | Payload at most 256 KiB and at most 32 workflow transitions; customer-service execution and intentional waits excluded by observed spans. |
| Documented adapter behavior | Preserve the supported behavior documented for this adapter | `aws::1.0.0::sfn`: `DescribeActivity`, `DescribeExecution`, `DescribeMapRun`, `DescribeStateMachine`, `DescribeStateMachineAlias`, `DescribeStateMachineForExecution`, `GetExecutionHistory`, `ListActivities`, `ListExecutions`, `ListMapRuns`, `ListStateMachineAliases`, `ListStateMachineVersions`, `ListStateMachines`, `ListTagsForResource`, `CreateActivity`, `CreateStateMachine`, `CreateStateMachineAlias`, `DeleteActivity`, `DeleteStateMachine`, `DeleteStateMachineAlias`, `DeleteStateMachineVersion`, `PublishStateMachineVersion`, `TagResource`, `UntagResource`, `UpdateStateMachine`, `UpdateStateMachineAlias`, `ValidateStateMachineDefinition`, `RedriveExecution`, `SendTaskFailure`, `SendTaskHeartbeat`, `SendTaskSuccess`, `StartExecution`, `StopExecution`, `TestState`, `UpdateMapRun`, `GetActivityTask`, `StartSyncExecution` | Accepted transitions and task outcomes are durable and idempotent, retries follow the definition, aliases resolve consistently, and redrive never skips required history. Unsupported ASL or target integrations fail before execution rather than being silently ignored. |
| Endpoint reachability | 99.9% per calendar month | Adapter endpoint reachability | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider's service. |
| Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Adapter behavior across requests | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. |

**Adapter-added latency.** A + prefix marks time added by the adapter, not the total time your application waits. Total request time includes adapter processing, backend service time and network time. The backend provider's SLA applies independently. Only separately measured target-service wait may be subtracted, and only when your agreement permits it; internal metadata, coordination and retry processing still count. For one request, 12 ms of adapter processing plus 90 ms waiting for the backend means at least 102 ms total. This example does not add monthly p99 values.

**What Tensor9 covers.** These service levels cover the adapter between the origin API and target API. They do not replace the target provider's SLA.

**How latency is counted.** Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.

**Which terms apply.** Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.

#### What this adapter does

Control calls validate and durably record state-machine definitions, versions and aliases. Execution calls admit work, evaluate ASL transitions and coordinate activities or temporalio::1.0.0::self-hosted. Time inside invoked customer services is separately observed; interpreter work, durable transition logging, retry decisions and response conversion remain covered.

#### How the latency targets were chosen

**Workflow and execution reads: +8 ms monthly p99 (adapter-added).** `DescribeActivity`, `DescribeExecution`, `DescribeMapRun`, `DescribeStateMachine`, `DescribeStateMachineAlias`, `DescribeStateMachineForExecution`, `GetExecutionHistory`, `ListActivities`, `ListExecutions`, `ListMapRuns`, `ListStateMachineAliases`, `ListStateMachineVersions`, `ListStateMachines`, `ListTagsForResource`. Bounded durable-log or definition-state response mapping.

**Definition, version, alias and tag mutation: +15 ms monthly p99 (adapter-added).** `CreateActivity`, `CreateStateMachine`, `CreateStateMachineAlias`, `DeleteActivity`, `DeleteStateMachine`, `DeleteStateMachineAlias`, `DeleteStateMachineVersion`, `PublishStateMachineVersion`, `TagResource`, `UntagResource`, `UpdateStateMachine`, `UpdateStateMachineAlias`, `ValidateStateMachineDefinition`. ASL validation and serialized durable metadata mutation.

**Execution and task coordination: +12 ms monthly p99 (adapter-added).** `RedriveExecution`, `SendTaskFailure`, `SendTaskHeartbeat`, `SendTaskSuccess`, `StartExecution`, `StopExecution`, `TestState`, `UpdateMapRun`. Durable transition admission and bounded workflow evaluation.

**Activity poll processing: +5 ms monthly p99 (adapter-added).** `GetActivityTask`. Authorization, bounded task lookup and response conversion around the documented long poll.

**Bounded synchronous workflow processing: +25 ms monthly p99 (adapter-added).** `StartSyncExecution`. Durable admission, bounded transition evaluation and final response conversion.

Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.

#### What counts toward latency

For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter's own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it.

For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request's adapter duration first, then the monthly p99. Do not subtract one service's p99 from another's. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.

#### Endpoint reachability and request failures

The endpoint-reachability target measures adapter health checks. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures remain Tensor9's responsibility even when the target is healthy.

Correctness and data-integrity requirements apply to every supported request. Endpoint reachability does not measure request correctness or grant an allowance for incorrect results.

#### Scaling and target-service capacity

Executions shard by execution identity; ordered transitions within one execution remain serialized. Qualification fixes definition size, history events, payload bytes, map concurrency, activity waiters and execution mix. Lists and histories are bounded pages, and a hot execution cannot monopolize unrelated workflows.

Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service's capacity with Tensor9's help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.

#### Data and behavior guarantees

Accepted transitions and task outcomes are durable and idempotent, retries follow the definition, aliases resolve consistently, and redrive never skips required history. Unsupported ASL or target integrations fail before execution rather than being silently ignored.

#### Example and diagnosis

StartExecution durably creates one execution and returns its stable ARN. A three-state workflow then records each transition; Lambda or cloud-workflow execution time is external, while ASL evaluation and log commits remain covered. GetExecutionHistory returns one bounded page from that durable sequence.

Use `tensor9 explain` and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider's latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.

### Step Functions State Machine to Azure Durable Functions

| SLA | Service level | What is covered | Conditions |
| - | - | - | - |
| Workflow and execution reads adapter-added latency | +8 ms monthly p99 | `aws::1.0.0::sfn`: `DescribeStateMachine`, `DescribeStateMachineAlias`, `DescribeStateMachineForExecution`, `ListStateMachineAliases`, `ListStateMachineVersions`, `ListStateMachines`, `ListTagsForResource` | at most 100 returned records/history events and at most 1 MiB payload. |
| Definition, version, alias and tag mutation adapter-added latency | +15 ms monthly p99 | `aws::1.0.0::sfn`: `CreateStateMachine`, `CreateStateMachineAlias`, `DeleteStateMachine`, `DeleteStateMachineAlias`, `DeleteStateMachineVersion`, `PublishStateMachineVersion`, `TagResource`, `UntagResource`, `UpdateStateMachine`, `UpdateStateMachineAlias`, `ValidateStateMachineDefinition` | Definition at most 1 MiB and at most 100 states; one named resource. |
| Documented adapter behavior | Preserve the supported behavior documented for this adapter | `aws::1.0.0::sfn`: `DescribeStateMachine`, `DescribeStateMachineAlias`, `DescribeStateMachineForExecution`, `ListStateMachineAliases`, `ListStateMachineVersions`, `ListStateMachines`, `ListTagsForResource`, `CreateStateMachine`, `CreateStateMachineAlias`, `DeleteStateMachine`, `DeleteStateMachineAlias`, `DeleteStateMachineVersion`, `PublishStateMachineVersion`, `TagResource`, `UntagResource`, `UpdateStateMachine`, `UpdateStateMachineAlias`, `ValidateStateMachineDefinition` | Accepted transitions and task outcomes are durable and idempotent, retries follow the definition, aliases resolve consistently, and redrive never skips required history. Unsupported ASL or target integrations fail before execution rather than being silently ignored. |
| Endpoint reachability | 99.9% per calendar month | Adapter endpoint reachability | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider's service. |
| Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Adapter behavior across requests | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. |

**Adapter-added latency.** A + prefix marks time added by the adapter, not the total time your application waits. Total request time includes adapter processing, backend service time and network time. The backend provider's SLA applies independently. Only separately measured target-service wait may be subtracted, and only when your agreement permits it; internal metadata, coordination and retry processing still count. For one request, 12 ms of adapter processing plus 90 ms waiting for the backend means at least 102 ms total. This example does not add monthly p99 values.

**What Tensor9 covers.** These service levels cover the adapter between the origin API and target API. They do not replace the target provider's SLA.

**How latency is counted.** Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.

**Which terms apply.** Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.

#### What this adapter does

Control calls validate and durably record state-machine definitions, versions and aliases. Execution calls admit work, evaluate ASL transitions and coordinate activities or azure::1.0.0::durable-functions. Time inside invoked customer services is separately observed; interpreter work, durable transition logging, retry decisions and response conversion remain covered.

#### How the latency targets were chosen

**Workflow and execution reads: +8 ms monthly p99 (adapter-added).** `DescribeStateMachine`, `DescribeStateMachineAlias`, `DescribeStateMachineForExecution`, `ListStateMachineAliases`, `ListStateMachineVersions`, `ListStateMachines`, `ListTagsForResource`. Bounded durable-log or definition-state response mapping.

**Definition, version, alias and tag mutation: +15 ms monthly p99 (adapter-added).** `CreateStateMachine`, `CreateStateMachineAlias`, `DeleteStateMachine`, `DeleteStateMachineAlias`, `DeleteStateMachineVersion`, `PublishStateMachineVersion`, `TagResource`, `UntagResource`, `UpdateStateMachine`, `UpdateStateMachineAlias`, `ValidateStateMachineDefinition`. ASL validation and serialized durable metadata mutation.

Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.

#### What counts toward latency

For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter's own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it.

For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request's adapter duration first, then the monthly p99. Do not subtract one service's p99 from another's. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.

#### Endpoint reachability and request failures

The endpoint-reachability target measures adapter health checks. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures remain Tensor9's responsibility even when the target is healthy.

Correctness and data-integrity requirements apply to every supported request. Endpoint reachability does not measure request correctness or grant an allowance for incorrect results.

#### Scaling and target-service capacity

Executions shard by execution identity; ordered transitions within one execution remain serialized. Qualification fixes definition size, history events, payload bytes, map concurrency, activity waiters and execution mix. Lists and histories are bounded pages, and a hot execution cannot monopolize unrelated workflows.

Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service's capacity with Tensor9's help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.

#### Data and behavior guarantees

Accepted transitions and task outcomes are durable and idempotent, retries follow the definition, aliases resolve consistently, and redrive never skips required history. Unsupported ASL or target integrations fail before execution rather than being silently ignored.

#### Example and diagnosis

StartExecution durably creates one execution and returns its stable ARN. A three-state workflow then records each transition; Lambda or cloud-workflow execution time is external, while ASL evaluation and log commits remain covered. GetExecutionHistory returns one bounded page from that durable sequence.

Use `tensor9 explain` and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider's latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.

### Step Functions State Machine to Cloud Workflows

| SLA | Service level | What is covered | Conditions |
| - | - | - | - |
| Workflow and execution reads adapter-added latency | +8 ms monthly p99 | `aws::1.0.0::sfn`: `DescribeStateMachine`, `DescribeStateMachineAlias`, `ListStateMachineAliases`, `ListStateMachineVersions`, `ListStateMachines`, `ListTagsForResource` | at most 100 returned records/history events and at most 1 MiB payload. |
| Definition, version, alias and tag mutation adapter-added latency | +15 ms monthly p99 | `aws::1.0.0::sfn`: `CreateStateMachine`, `CreateStateMachineAlias`, `DeleteStateMachine`, `DeleteStateMachineAlias`, `DeleteStateMachineVersion`, `PublishStateMachineVersion`, `TagResource`, `UntagResource`, `UpdateStateMachine`, `UpdateStateMachineAlias`, `ValidateStateMachineDefinition` | Definition at most 1 MiB and at most 100 states; one named resource. |
| Documented adapter behavior | Preserve the supported behavior documented for this adapter | `aws::1.0.0::sfn`: `DescribeStateMachine`, `DescribeStateMachineAlias`, `ListStateMachineAliases`, `ListStateMachineVersions`, `ListStateMachines`, `ListTagsForResource`, `CreateStateMachine`, `CreateStateMachineAlias`, `DeleteStateMachine`, `DeleteStateMachineAlias`, `DeleteStateMachineVersion`, `PublishStateMachineVersion`, `TagResource`, `UntagResource`, `UpdateStateMachine`, `UpdateStateMachineAlias`, `ValidateStateMachineDefinition` | Accepted transitions and task outcomes are durable and idempotent, retries follow the definition, aliases resolve consistently, and redrive never skips required history. Unsupported ASL or target integrations fail before execution rather than being silently ignored. |
| Endpoint reachability | 99.9% per calendar month | Adapter endpoint reachability | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider's service. |
| Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Adapter behavior across requests | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. |

**Adapter-added latency.** A + prefix marks time added by the adapter, not the total time your application waits. Total request time includes adapter processing, backend service time and network time. The backend provider's SLA applies independently. Only separately measured target-service wait may be subtracted, and only when your agreement permits it; internal metadata, coordination and retry processing still count. For one request, 12 ms of adapter processing plus 90 ms waiting for the backend means at least 102 ms total. This example does not add monthly p99 values.

**What Tensor9 covers.** These service levels cover the adapter between the origin API and target API. They do not replace the target provider's SLA.

**How latency is counted.** Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.

**Which terms apply.** Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.

#### What this adapter does

Control calls validate and durably record state-machine definitions, versions and aliases. Execution calls admit work, evaluate ASL transitions and coordinate activities or google::1.0.0::workflows. Time inside invoked customer services is separately observed; interpreter work, durable transition logging, retry decisions and response conversion remain covered.

#### How the latency targets were chosen

**Workflow and execution reads: +8 ms monthly p99 (adapter-added).** `DescribeStateMachine`, `DescribeStateMachineAlias`, `ListStateMachineAliases`, `ListStateMachineVersions`, `ListStateMachines`, `ListTagsForResource`. Bounded durable-log or definition-state response mapping.

**Definition, version, alias and tag mutation: +15 ms monthly p99 (adapter-added).** `CreateStateMachine`, `CreateStateMachineAlias`, `DeleteStateMachine`, `DeleteStateMachineAlias`, `DeleteStateMachineVersion`, `PublishStateMachineVersion`, `TagResource`, `UntagResource`, `UpdateStateMachine`, `UpdateStateMachineAlias`, `ValidateStateMachineDefinition`. ASL validation and serialized durable metadata mutation.

Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.

#### What counts toward latency

For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter's own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it.

For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request's adapter duration first, then the monthly p99. Do not subtract one service's p99 from another's. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.

#### Endpoint reachability and request failures

The endpoint-reachability target measures adapter health checks. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures remain Tensor9's responsibility even when the target is healthy.

Correctness and data-integrity requirements apply to every supported request. Endpoint reachability does not measure request correctness or grant an allowance for incorrect results.

#### Scaling and target-service capacity

Executions shard by execution identity; ordered transitions within one execution remain serialized. Qualification fixes definition size, history events, payload bytes, map concurrency, activity waiters and execution mix. Lists and histories are bounded pages, and a hot execution cannot monopolize unrelated workflows.

Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service's capacity with Tensor9's help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.

#### Data and behavior guarantees

Accepted transitions and task outcomes are durable and idempotent, retries follow the definition, aliases resolve consistently, and redrive never skips required history. Unsupported ASL or target integrations fail before execution rather than being silently ignored.

#### Example and diagnosis

StartExecution durably creates one execution and returns its stable ARN. A three-state workflow then records each transition; Lambda or cloud-workflow execution time is external, while ASL evaluation and log commits remain covered. GetExecutionHistory returns one bounded page from that durable sequence.

Use `tensor9 explain` and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider's latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.

### Step Functions State Machine to Temporal Cloud (Managed)

| SLA | Service level | What is covered | Conditions |
| - | - | - | - |
| Workflow and execution reads adapter-added latency | +8 ms monthly p99 | `aws::1.0.0::sfn`: `DescribeStateMachine`, `DescribeStateMachineAlias`, `DescribeStateMachineForExecution`, `ListStateMachineAliases`, `ListStateMachineVersions`, `ListStateMachines`, `ListTagsForResource` | at most 100 returned records/history events and at most 1 MiB payload. |
| Definition, version, alias and tag mutation adapter-added latency | +15 ms monthly p99 | `aws::1.0.0::sfn`: `CreateStateMachine`, `CreateStateMachineAlias`, `DeleteStateMachine`, `DeleteStateMachineAlias`, `DeleteStateMachineVersion`, `PublishStateMachineVersion`, `TagResource`, `UntagResource`, `UpdateStateMachine`, `UpdateStateMachineAlias`, `ValidateStateMachineDefinition` | Definition at most 1 MiB and at most 100 states; one named resource. |
| Documented adapter behavior | Preserve the supported behavior documented for this adapter | `aws::1.0.0::sfn`: `DescribeStateMachine`, `DescribeStateMachineAlias`, `DescribeStateMachineForExecution`, `ListStateMachineAliases`, `ListStateMachineVersions`, `ListStateMachines`, `ListTagsForResource`, `CreateStateMachine`, `CreateStateMachineAlias`, `DeleteStateMachine`, `DeleteStateMachineAlias`, `DeleteStateMachineVersion`, `PublishStateMachineVersion`, `TagResource`, `UntagResource`, `UpdateStateMachine`, `UpdateStateMachineAlias`, `ValidateStateMachineDefinition` | Accepted transitions and task outcomes are durable and idempotent, retries follow the definition, aliases resolve consistently, and redrive never skips required history. Unsupported ASL or target integrations fail before execution rather than being silently ignored. |
| Endpoint reachability | 99.9% per calendar month | Adapter endpoint reachability | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider's service. |
| Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Adapter behavior across requests | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. |

**Adapter-added latency.** A + prefix marks time added by the adapter, not the total time your application waits. Total request time includes adapter processing, backend service time and network time. The backend provider's SLA applies independently. Only separately measured target-service wait may be subtracted, and only when your agreement permits it; internal metadata, coordination and retry processing still count. For one request, 12 ms of adapter processing plus 90 ms waiting for the backend means at least 102 ms total. This example does not add monthly p99 values.

**What Tensor9 covers.** These service levels cover the adapter between the origin API and target API. They do not replace the target provider's SLA.

**How latency is counted.** Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.

**Which terms apply.** Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.

#### What this adapter does

Control calls validate and durably record state-machine definitions, versions and aliases. Execution calls admit work, evaluate ASL transitions and coordinate activities or temporalio::1.0.0::managed. Time inside invoked customer services is separately observed; interpreter work, durable transition logging, retry decisions and response conversion remain covered.

#### How the latency targets were chosen

**Workflow and execution reads: +8 ms monthly p99 (adapter-added).** `DescribeStateMachine`, `DescribeStateMachineAlias`, `DescribeStateMachineForExecution`, `ListStateMachineAliases`, `ListStateMachineVersions`, `ListStateMachines`, `ListTagsForResource`. Bounded durable-log or definition-state response mapping.

**Definition, version, alias and tag mutation: +15 ms monthly p99 (adapter-added).** `CreateStateMachine`, `CreateStateMachineAlias`, `DeleteStateMachine`, `DeleteStateMachineAlias`, `DeleteStateMachineVersion`, `PublishStateMachineVersion`, `TagResource`, `UntagResource`, `UpdateStateMachine`, `UpdateStateMachineAlias`, `ValidateStateMachineDefinition`. ASL validation and serialized durable metadata mutation.

Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.

#### What counts toward latency

For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter's own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it.

For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request's adapter duration first, then the monthly p99. Do not subtract one service's p99 from another's. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.

#### Endpoint reachability and request failures

The endpoint-reachability target measures adapter health checks. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures remain Tensor9's responsibility even when the target is healthy.

Correctness and data-integrity requirements apply to every supported request. Endpoint reachability does not measure request correctness or grant an allowance for incorrect results.

#### Scaling and target-service capacity

Executions shard by execution identity; ordered transitions within one execution remain serialized. Qualification fixes definition size, history events, payload bytes, map concurrency, activity waiters and execution mix. Lists and histories are bounded pages, and a hot execution cannot monopolize unrelated workflows.

Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service's capacity with Tensor9's help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.

#### Data and behavior guarantees

Accepted transitions and task outcomes are durable and idempotent, retries follow the definition, aliases resolve consistently, and redrive never skips required history. Unsupported ASL or target integrations fail before execution rather than being silently ignored.

#### Example and diagnosis

StartExecution durably creates one execution and returns its stable ARN. A three-state workflow then records each transition; Lambda or cloud-workflow execution time is external, while ASL evaluation and log commits remain covered. GetExecutionHistory returns one bounded page from that durable sequence.

Use `tensor9 explain` and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider's latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.

### Step Functions State Machine to Temporal (Self-Hosted)

| SLA | Service level | What is covered | Conditions |
| - | - | - | - |
| Workflow and execution reads adapter-added latency | +8 ms monthly p99 | `aws::1.0.0::sfn`: `DescribeStateMachine`, `DescribeStateMachineAlias`, `DescribeStateMachineForExecution`, `ListStateMachineAliases`, `ListStateMachineVersions`, `ListStateMachines`, `ListTagsForResource` | at most 100 returned records/history events and at most 1 MiB payload. |
| Definition, version, alias and tag mutation adapter-added latency | +15 ms monthly p99 | `aws::1.0.0::sfn`: `CreateStateMachine`, `CreateStateMachineAlias`, `DeleteStateMachine`, `DeleteStateMachineAlias`, `DeleteStateMachineVersion`, `PublishStateMachineVersion`, `TagResource`, `UntagResource`, `UpdateStateMachine`, `UpdateStateMachineAlias`, `ValidateStateMachineDefinition` | Definition at most 1 MiB and at most 100 states; one named resource. |
| Documented adapter behavior | Preserve the supported behavior documented for this adapter | `aws::1.0.0::sfn`: `DescribeStateMachine`, `DescribeStateMachineAlias`, `DescribeStateMachineForExecution`, `ListStateMachineAliases`, `ListStateMachineVersions`, `ListStateMachines`, `ListTagsForResource`, `CreateStateMachine`, `CreateStateMachineAlias`, `DeleteStateMachine`, `DeleteStateMachineAlias`, `DeleteStateMachineVersion`, `PublishStateMachineVersion`, `TagResource`, `UntagResource`, `UpdateStateMachine`, `UpdateStateMachineAlias`, `ValidateStateMachineDefinition` | Accepted transitions and task outcomes are durable and idempotent, retries follow the definition, aliases resolve consistently, and redrive never skips required history. Unsupported ASL or target integrations fail before execution rather than being silently ignored. |
| Endpoint reachability | 99.9% per calendar month | Adapter endpoint reachability | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider's service. |
| Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Adapter behavior across requests | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. |

**Adapter-added latency.** A + prefix marks time added by the adapter, not the total time your application waits. Total request time includes adapter processing, backend service time and network time. The backend provider's SLA applies independently. Only separately measured target-service wait may be subtracted, and only when your agreement permits it; internal metadata, coordination and retry processing still count. For one request, 12 ms of adapter processing plus 90 ms waiting for the backend means at least 102 ms total. This example does not add monthly p99 values.

**What Tensor9 covers.** These service levels cover the adapter between the origin API and target API. They do not replace the target provider's SLA.

**How latency is counted.** Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.

**Which terms apply.** Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.

#### What this adapter does

Control calls validate and durably record state-machine definitions, versions and aliases. Execution calls admit work, evaluate ASL transitions and coordinate activities or temporalio::1.0.0::self-hosted. Time inside invoked customer services is separately observed; interpreter work, durable transition logging, retry decisions and response conversion remain covered.

#### How the latency targets were chosen

**Workflow and execution reads: +8 ms monthly p99 (adapter-added).** `DescribeStateMachine`, `DescribeStateMachineAlias`, `DescribeStateMachineForExecution`, `ListStateMachineAliases`, `ListStateMachineVersions`, `ListStateMachines`, `ListTagsForResource`. Bounded durable-log or definition-state response mapping.

**Definition, version, alias and tag mutation: +15 ms monthly p99 (adapter-added).** `CreateStateMachine`, `CreateStateMachineAlias`, `DeleteStateMachine`, `DeleteStateMachineAlias`, `DeleteStateMachineVersion`, `PublishStateMachineVersion`, `TagResource`, `UntagResource`, `UpdateStateMachine`, `UpdateStateMachineAlias`, `ValidateStateMachineDefinition`. ASL validation and serialized durable metadata mutation.

Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.

#### What counts toward latency

For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter's own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it.

For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request's adapter duration first, then the monthly p99. Do not subtract one service's p99 from another's. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.

#### Endpoint reachability and request failures

The endpoint-reachability target measures adapter health checks. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures remain Tensor9's responsibility even when the target is healthy.

Correctness and data-integrity requirements apply to every supported request. Endpoint reachability does not measure request correctness or grant an allowance for incorrect results.

#### Scaling and target-service capacity

Executions shard by execution identity; ordered transitions within one execution remain serialized. Qualification fixes definition size, history events, payload bytes, map concurrency, activity waiters and execution mix. Lists and histories are bounded pages, and a hot execution cannot monopolize unrelated workflows.

Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service's capacity with Tensor9's help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.

#### Data and behavior guarantees

Accepted transitions and task outcomes are durable and idempotent, retries follow the definition, aliases resolve consistently, and redrive never skips required history. Unsupported ASL or target integrations fail before execution rather than being silently ignored.

#### Example and diagnosis

StartExecution durably creates one execution and returns its stable ARN. A three-state workflow then records each transition; Lambda or cloud-workflow execution time is external, while ASL evaluation and log commits remain covered. GetExecutionHistory returns one bounded page from that durable sequence.

Use `tensor9 explain` and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider's latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.

## Install and run

The documentation and SLAs are public. Downloading and running the Cloud Adapter binary requires an entitled customer account. Set `T9_API_KEY` as described in [Install and Authenticate](https://docs.tensor9.com/cloud-adapter-early-access/getting-started/install-and-authenticate.md), then list the adapters your account may use with this origin:

```sh theme={null}
tensor9 adapt svc list \
  -origin aws::1.0.0::sfn
```

The result is limited to directed mappings for this origin that your account is entitled to use. Use a returned backend identifier when configuring the adapter or investigating a request.

Request binary access from [hello@tensor9.com](mailto:hello@tensor9.com) if your account does not yet include this direction.

## Existing data and credentials

Selecting a backend does not copy existing data, credentials or access policies. Plan and verify migration separately before changing an application's endpoint. Do not assume an identifier, credential or encrypted value from the origin service works unchanged on the target.

## Configure, tune and debug

Start with [setup](https://docs.tensor9.com/cloud-adapter-early-access/getting-started/overview.md) and [configuration](https://docs.tensor9.com/cloud-adapter-early-access/configuration/overview.md). Use [tuning](https://docs.tensor9.com/cloud-adapter-early-access/tuning/overview.md) to understand supported request tags, [debugging](https://docs.tensor9.com/cloud-adapter-early-access/debugging/overview.md) to investigate a request, and [High Fidelity Cloud Emulators](https://docs.tensor9.com/cloud-adapter-early-access/local-testing/overview.md) to validate a bounded reproduction.

For requests that go through an entitled service adapter, use [tensor9 explain](https://docs.tensor9.com/cloud-adapter-early-access/debugging/explain.md) and [x-t9-explain](https://docs.tensor9.com/cloud-adapter-early-access/debugging/response-headers.md) to inspect the selected mapping.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.