Step Functions

Preview On this page

• Coverage by target cloud
• How the targets 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

​

Coverage by target cloud

​

How the targets compare

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

​

Max adaptation

​

On Google Cloud

​

Via Cloud Workflows

​

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.

​

On Google Cloud, Azure, OCI, and Private Kubernetes

​

Via Temporal (Self-Hosted)

​

How Step Functions runs on self-hosted Temporal

Your application calls the Step Functions API in the target environment. A Tensor9 service adapter stores state-machine definitions, revisions, versions and aliases. For a Standard execution, a Tensor9-maintained worker reads the selected Amazon States Language definition and interprets it as a Temporal workflow. The same worker runs many definitions; your team does not maintain generated application code. The Temporal service and its persistence database run in the selected deployment environment. Workers use its task queues, durable timers and execution history to resume after a worker restart. The adapter retains the AWS execution ARN and translates execution status and history back into Step Functions responses. An Express execution uses the adapter’s separate, short-lived execution path.

​

Tasks, callbacks and an approval example

A Task Resource identifies an AWS integration, not a Temporal workflow type. The adapter resolves the requested operation through the service mappings available in the deployment and checks the execution role before dispatch. Temporal activities perform external calls; the interpreter controls ASL Retry and Catch so a native retry does not silently create another business attempt. AWS Activities remain a separate queue served through GetActivityTask. Consider an order awaiting approval through .waitForTaskToken. The adapter associates the token with the active task attempt while the Temporal workflow waits. An authorized SendTaskSuccess or SendTaskFailure call records that attempt’s result and wakes the workflow. A transport acknowledgment alone does not complete the task. A .sync task instead observes the submitted job until its terminal result. Parallel branches and Map items use child workflows. The interpreter retains item order, concurrency limits and the distinction between an item retry and a retry of the containing Map. Continue-as-new and worker upgrades preserve the public execution identity and the definition revision.

​

Debugging and worker upgrades

Temporal Web UI is the operator interface for Standard workflow execution. Its history, pending activities and timers help distinguish a stuck external call from an execution waiting for a callback. It does not reproduce the AWS console’s ASL graph or highlighted state path. GetExecutionHistory supplies the Step Functions view of a Standard execution; access to decoded payloads requires separate authorization. Tensor9 maintains the interpreter and compatible worker versions. Running executions keep their program and evaluator versions during an upgrade. Your deployment operator maintains Temporal service availability, database backups and restoration procedures. Retaining a Helm release without protecting the persistence database is insufficient for recovery.

​

Limitations

Where Step Functions and self-hosted Temporal differ

• Service integrations depend on the deployment. A Task can call only an operation and invocation pattern supplied by its service mapping. A Glue or SageMaker ARN does not become executable merely because Temporal can schedule an activity.
• External effects retain their own retry rules. Workflow replay does not make a remote, non-idempotent operation safe to submit twice. The integration’s recovery and cancellation behavior applies to work already accepted by that service.
• Capacity comes from the installed cluster. Worker capacity, persistence throughput and Temporal history limits constrain concurrency. ASL MaxConcurrency is an upper bound, not a throughput reservation.
• AWS console and telemetry endpoints change. Use Temporal Web UI and deployment logs. X-Ray tracing is rejected when enabled, and configured logs do not go to AWS CloudWatch Logs.
• Express has a different execution model. It has no Standard execution-history API and cannot use Activities, Distributed Map, .sync or .waitForTaskToken.

​

Other considerations

• Cutover. Deploy definitions, versions and aliases through the Step Functions API. Existing AWS executions and callbacks finish against AWS; their running state and history are not imported.
• Operations. The deployment operator owns the Temporal cluster, persistence, backups, network access and service upgrades. Tensor9 maintains the adapter and interpreter workers. Infrastructure and operating 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; namespace naming alone is not authorization.
• Changing engines. A backend change applies to new executions. Retain the old workers, credentials and callback routes until their executions and retention obligations finish.

Temporal documents the self-hosted service and Web UI.

​

Via Temporal Cloud (Managed)

​

How Step Functions uses Temporal Cloud

Your application keeps using the Step Functions API in the target environment. A Tensor9 service adapter stores definitions, revisions, versions and aliases, then starts Standard executions in a Temporal Cloud namespace owned by the customer. Tensor9-maintained interpreter workers run beside the adapter in the deployment environment and evaluate the original Amazon States Language definition. Temporal operates the workflow service and stores execution history in the namespace’s selected region. The workers execute the orchestration code and service calls. Temporal Cloud does not host these workers. An Express execution follows the adapter’s separate, short-lived execution path.

​

Connecting the namespace

Connect an existing customer-owned namespace using its full namespace ID, endpoint and an authorized credential. The initial connection uses mutual TLS. Namespace creation, billing and account administration remain with the customer; deploying or removing the adapter does not create or delete that namespace. The workers need network access to Temporal Cloud and to the service adapters used by Tasks. An application on Azure, GCP, Kubernetes or OCI can use the namespace independently of where its managed history is stored. Select the namespace region and connectivity to meet the deployment’s residency requirements. This option requires access to the managed service and does not serve 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. ASL Retry and Catch determine the business attempts; the integration adapter resolves ambiguous service responses under its own idempotency rules. For an approval task using .waitForTaskToken, an authorized callback reaches the Step Functions adapter in the deployment environment. The adapter records completion for the exact active attempt and delivers it to the workflow in Temporal Cloud. The caller receives success only after the task disposition is durable. An engine notification alone is insufficient. If a worker restarts during the wait, a compatible worker resumes from Temporal’s history. The execution keeps its AWS identity, selected definition and worker version. Moving the deployment to a different engine affects subsequent starts and does not move this active approval.

​

Limitations

Where Step Functions and Temporal Cloud differ

• Managed history leaves the deployment environment. Temporal Cloud stores workflow history and any encoded payloads in the selected namespace region. Payload encryption does not move that storage into the local cluster; avoid secrets in searchable metadata.
• The namespace does not provide AWS integrations. A Task Resource must resolve to a supported service operation and invocation pattern in the deployment. .sync and callback behavior depend on that integration.
• Service capacity and worker capacity both matter. Namespace limits, history size, worker slots and downstream service limits affect throughput. Selecting Temporal Cloud does not reserve concurrency for every Map item.
• Debugging uses Temporal’s interface. Temporal Web UI exposes workflow history and pending work rather than the AWS console’s visual ASL graph. Payload decoding requires authorized access. Logs use the deployment’s logging destination; X-Ray tracing is rejected when enabled.
• Express restrictions remain. Express executions 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 still runs in the deployment environment.
• Retention and encryption. Set namespace retention together with the adapter’s history and redrive retention requirements. Configure the worker payload codec and key access when using customer-managed encryption. Web UI access and permission to decode payloads are separate controls.
• Cutover. Deploy definitions, versions and aliases through the adapter. Existing AWS executions finish there; active executions, outstanding tokens and historical runs are not imported into Temporal Cloud.
• Connection lifecycle. Rotate namespace credentials while retaining access for existing executions. An adapter removal releases its connection and owned workers, leaving the customer’s namespace and unrelated workflows intact.

See Temporal’s namespace and region configuration, worker architecture and Web UI documentation.

​

On Azure

​

Via Azure Durable Functions

​

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.

Service Catalog.