Step Functions - Tensor9

Preview On this page

Coverage by target cloud
How the backends compare
- Max adaptation
On Google Cloud
- Via Cloud Workflows
On Google Cloud, Azure, OCI, and Private Kubernetes
- Via Temporal (Self-Hosted)
- Via Temporal Cloud (Managed)
On Azure
- Via Azure Durable Functions
State-machine administration
Costs
Service level agreements
Debug this service

Coverage by target cloud

Target cloud	Available
Google Cloud	✓
Azure	✓
OCI	✓
Private Kubernetes	✓

How the backends compare

Each row compares a capability of Step Functions with its adaptation on each backend. A dash means this row is not stated for that backend.

Max adaptation

Capability	Step Functions	Google Cloud · Cloud Workflows	Google Cloud, Azure, OCI, and Private Kubernetes · Temporal (Self-Hosted)	Google Cloud, Azure, OCI, and Private Kubernetes · Temporal Cloud (Managed)	Azure · Azure Durable Functions
Execution engine · what runs the state machine	the Step Functions service interprets the Amazon States Language definition	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	-	-	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
Execution state · where progress is checkpointed	held by the service	held by Cloud Workflows per execution; the adapter keeps the execution’s identity, input and outcome	-	-	checkpointed in a task hub in an Azure Storage account; an execution survives a restart of the function app or of the adapter
Long-running executions · Wait states and timeouts	up to one year; a Wait state holds no compute	up to one year, the Workflows ceiling; a Wait is the engine’s own sleep	-	-	up to one year; a Wait is a durable timer held in the task hub
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 by the adapter and completion resumes the workflow through its callback	-	-	a queue the adapter serves; the token is minted and checked by the adapter, and workers reach the adapter’s endpoint
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	-	-	-
Service integrations · what a Task state can call	AWS services through optimized and SDK integrations	the services adapted on the same appliance, through their own mappings; a Resource the appliance does not serve is refused at CreateStateMachine	-	-	the services adapted on the same appliance, through their own mappings; a Resource the appliance does not serve is refused at CreateStateMachine
Logs and traces · where execution logs go	CloudWatch Logs and X-Ray	Cloud Logging captures execution and step logs; X-Ray tracing is not reproduced	-	-	the appliance’s logging; X-Ray tracing is not reproduced
API coverage	full	partial	partial	partial	partial
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	-
Versions and aliases · immutable versions, weighted routing	native	-	-	-	adapter records; an execution pins the version it was routed to

On Google Cloud

Via Cloud Workflows

Capability	Area	Support	Required tier	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 appliance (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 appliance 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 appliance, including .sync and .waitForTaskToken, nested executions and Task.Credentials role overrides; a Resource naming a service the appliance 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 appliance 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 appliance; 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 appliance’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 appliance. 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 appliance 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 appliance. A Resource naming a service the appliance 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 BYOC scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. How Tensor9 estimates costs 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.

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): 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). 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).
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
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, 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): 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). 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).
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, Workflows pricing.

On Google Cloud, Azure, OCI, and Private Kubernetes

Via Temporal (Self-Hosted)

Capability	Area	Support	Required tier	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 and Web UI.

Example monthly charges

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.

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); 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): 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). 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); a Persistent Disk volume holds up to 64 TiB (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
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

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, Compute Engine general-purpose machine pricing, Disk and image pricing, 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

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); 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): 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). 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); a Persistent Disk volume holds up to 64 TiB (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, Compute Engine general-purpose machine pricing, Disk and image pricing, Network pricing.

Via Temporal Cloud (Managed)

Capability	Area	Support	Required tier	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, worker architecture and Web UI documentation.

Example monthly charges

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.

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

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): 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). 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).
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
Temporal 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, Temporal 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

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): 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). 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).
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, Temporal Cloud pricing.

On Azure

Via Azure Durable Functions

Capability	Area	Support	Required tier	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 appliance (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 appliance’s logging, since CloudWatch Logs is a service the appliance 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 appliance, including the .sync and .waitForTaskToken patterns, nested executions and Task.Credentials role overrides; a Resource naming a service the appliance 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 appliance 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 appliance: 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 appliance’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 appliance. 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 appliance’s logging, since CloudWatch Logs is a service the appliance 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 appliance. A Task state reaches the services adapted on the same appliance. A Resource naming a service the appliance 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 appliance’s durable store. Both are in the target environment.

Example monthly charges

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.

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

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): 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). 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).
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
Azure Retail Prices API: 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, Azure Retail Prices API. 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

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): 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). 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).
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, Azure Retail Prices API.

State-machine administration

The state-machine API manages definitions, versions, aliases and configuration. The backend-specific sections below describe these administration operations alongside the execution behavior documented above.