AWS Step Functions vs Temporal

AWS Step Functions vs Temporal: which fits your workflows

Step Functions fits when your workflows are mostly coordination between AWS services, when you want AWS to run the orchestration layer, and when your team is comfortable describing flows as JSON state machines in Amazon States Language. Its integrations with Lambda, ECS, DynamoDB, SQS and other AWS services are the main reason to stay. Self-hosted Temporal fits when workflows are better written as ordinary code, when logic must run outside AWS or across several clouds, and when your organization wants direct control over the runtime, its upgrades and its data. Cost pressure alone rarely settles the question, because a self-hosted cluster has operating costs that a per-transition bill does not show.

Four factors should drive the decision. The first is run length: confirm how long your longest workflows live, because long-running processes with human waits, retries over days or large fan-outs change both the execution model and the history you must keep. The second is required AWS service integrations: list every service task and callback pattern in your current state machines, since each one needs an equivalent in Temporal activities or a custom worker. The third is who will operate the cluster: a Temporal deployment needs a persistence database, a visibility store such as Elasticsearch or OpenSearch, upgrades and on-call coverage, and you should name the team that owns those before you commit. The fourth is data location: confirm where workflow payloads and history will be stored, and whether your rules require them to stay inside a specific network or country.

Before deciding, ask a vendor or your own platform team to confirm the operational details for your target version. Check the supported persistence and visibility combinations in Temporal's documentation, confirm how the self-hosted security defaults apply to your deployment, and run a small proof of concept on one representative workflow that includes a long wait, a retry policy and one AWS service call. The result gives you concrete run length, history size and operating effort to compare with your Step Functions bill and with Temporal's own pricing page, which describes its managed service.

Which scenarios favor Step Functions and which favor Temporal

This table maps six common conditions to the platform that usually fits better, with the reason tied to that condition. Read each row as a question about your own environment: if the condition holds for most of your workflows, the matching column is the likely starting point.

Scenario	Better fit	Why the condition matters
AWS-only orchestration with many direct service integrations	Step Functions	Step Functions calls many AWS services directly from state machine definitions, with no worker code to write or host. Temporal would need activities that wrap those SDK calls and workers you run yourself.
Team already fluent in Amazon States Language	Step Functions	Existing JSON definitions, IAM roles and CloudWatch habits carry over without retraining. Moving to Temporal means rewriting each state as code and learning its replay model.
Workflows must run on-premises or across clouds	Temporal	Self-hosted Temporal runs in your data center or any cloud, with its server and persistence under your control. Step Functions runs only in AWS, so its use outside AWS is limited.
Long-running business processes with human waits	Temporal	Workflow code can wait on signals, timers and approvals for long periods while keeping state durable. Confirm the retention settings and history limits that apply to your expected wait times before committing.
Teams that prefer writing workflow code with unit tests	Temporal	Workflows are ordinary code in supported SDK languages, so logic can be unit tested and reviewed in the same pull requests as the rest of the service. Step Functions logic is mainly declarative JSON with limited local testing.
No platform team to run a database-backed cluster	Step Functions	Step Functions is operated by AWS, so no database, visibility store or server upgrades fall to your team. Self-hosting Temporal means owning persistence, visibility, upgrades and on-call, so ask whether that capacity exists before choosing it.

How the programming model changes durability and versioning

The main difference is where the workflow logic lives. A Step Functions workflow is a declarative state machine written in Amazon States Language, a JSON document that names states, transitions, retries and service integrations, and AWS runs it as a managed service. A Temporal workflow is ordinary code in a supported language, and its activities are ordinary functions that call external systems. Temporal records every decision the workflow makes as an event history and replays that history to rebuild local state after a worker crash, so a run can wait on a timer, a signal or a long external task and resume where it stopped. Step Functions gives a comparable guarantee through its own execution model, but the state it keeps is the state machine's data passed between states, not the program's variables. Before planning, confirm the current Step Functions quotas for execution duration, history size and payload limits, and the retention window for execution history, in the AWS documentation, since this page does not cover those figures.

Versioning of running work is where the two models diverge most. A Step Functions state machine can be updated, and you can start new executions against a specific revision, but the definition you control is the whole JSON document, and the team has to decide how in-flight executions are handled while they finish. In Temporal, a running workflow is bound to the code that started it, so code changes must stay compatible with histories already recorded. Engineers use patching APIs or worker versioning to branch on the version a run was started with. Plan a review step for every change to a workflow function, and inventory which workflow types have long-lived executions, because those are the ones that carry old branches for the longest time. Confirm the exact behavior of your Temporal SDK and server version against the official documentation before you rely on it.

Capability comparison from the supplied Temporal facts

This table sets AWS Step Functions beside self-hosted Temporal across licensing, hosting, persistence, access control, encryption and portability. Step Functions cells describe capabilities in general terms, so confirm current specifics in AWS documentation before relying on them. The main takeaway is that Temporal's security and storage choices are yours to make and operate, while Step Functions' controls come bundled with the AWS account model.

Capability	AWS Step Functions	Self-hosted Temporal
Licensing	Proprietary AWS managed service, billed through AWS usage charges	Server licensed under the MIT license, per its GitHub repository
Hosting model	Runs only inside AWS regions as a managed service	Runs on hosts you operate, with services kept off the public internet
Deployment options	Managed by AWS, with definitions deployed through AWS tooling	Docker Compose, Go binaries, Helm charts on Kubernetes, or a custom Go build
Persistence and visibility stores	Managed by AWS, with no database for you to size or patch	Cassandra, PostgreSQL, MySQL or SQLite for development; Elasticsearch or OpenSearch recommended for visibility at scale
Authentication and authorization	Governed by AWS IAM roles and policies attached to the state machine	Default noopAuthorizer allows all requests until you configure an Authorizer and ClaimMapper
Encryption in transit	Handled by AWS service endpoints, confirm TLS options in AWS documentation	mTLS with separate settings for internode and frontend traffic
Web UI single sign-on	Console access follows your AWS identity configuration, confirm with AWS documentation	OIDC single sign-on for the Web UI
Payload encryption	Confirm encryption options for state data and KMS use in AWS documentation	Payload encryption through custom codecs and a codec server
Managed service option	Native; AWS operates the service	Temporal Cloud is a separate paid managed offering from Temporal Technologies
Portability beyond AWS	Tied to AWS APIs and Amazon States Language execution	Runs on any infrastructure you control, including your own data center or other clouds

What data control and hosting mean for a regulated buyer

Moving from Step Functions to Temporal changes who holds workflow state, who can call the API, and where the evidence for an assessment comes from. The cards below cover the decisions a regulated buyer should settle before comparing features, and they name the checks to run in your own environment.

Where workflow state and payloads live

Step Functions keeps execution history and state in AWS-managed storage in the region you choose. Self-hosted Temporal writes workflow history and payloads to a persistence database you operate, such as PostgreSQL, MySQL or Cassandra, plus an optional visibility store. Confirm which regions, accounts and database hosts will hold event history, how long history is retained, and whether payload encryption through a custom codec is required before any sensitive data enters a workflow.

Choosing a hosting model

There are three realistic models: Step Functions as an AWS-managed service, self-hosted Temporal in your own cloud account or data center, and Temporal Cloud as a managed Temporal service run by Temporal Technologies. Each model moves operational duties to a different party. Document who patches the server, who holds the database backups and who answers for availability before choosing one, because the answer decides which controls you must evidence yourself.

Identity and access defaults

If no Authorizer is configured, self-hosted Temporal allows every API request with no authentication or access control. This is the noopAuthorizer default. Before production, configure an Authorizer plugin and a ClaimMapper that maps JWT or certificate claims to namespace roles, and enable OIDC single sign-on for the Web UI. Step Functions relies on IAM policies for access, so this control has to be designed from scratch on the Temporal side.

Network exposure of Temporal services

Temporal's deployment guidance says services should run on hosts that the public internet cannot reach, with network access limited to trusted internal networks. Step Functions is reached through AWS public API endpoints protected by IAM. With self-hosted Temporal, the frontend, internode traffic and database connections need explicit network segmentation, and mTLS should be set up separately for internode and frontend traffic. Ask your network team to confirm ingress rules before any worker or client connects.

Compliance evidence and DeployOpen's role

Assessments need evidence that access, logging, change and backup controls work as described. DeployOpen plans, implements and documents these controls in your environment and prepares the evidence an assessor will ask for. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments, so confirm early which framework and evidence format your auditor expects.

What drives the cost of each option

AWS Step Functions bills for usage, so spend follows the work the workflows do. Standard workflows are billed per state transition, while Express workflows are billed per request and by duration. Either way, cost rises with the number of steps in each workflow and with the number of executions. There is no server to size or patch, and no cluster to operate, so the bill is mostly a function of volume and design.

Per-transition billing: Each state a Standard execution enters adds to the count, so long workflows with many Choice, Map or retry steps cost more than short ones.
Per-request and duration billing: Express workflows charge for requests and for the time they run, which makes high-volume, short executions a different calculation from Standard.
Adjacent AWS charges: Lambda, API Gateway, DynamoDB, CloudWatch Logs and data transfer are billed separately and often grow with the state machine.
Region and model: Rates vary by AWS region and by the workflow type you choose, so the same design can cost different amounts in different places.

Pull current AWS pricing for your region and workflow type, then model your transition and request counts against a realistic sample of executions.

What moving from Step Functions to Temporal involves

The sequence turns Amazon States Language state machines into versioned Temporal workflow code, proves the new runtime in non-production, and retires the old machines only after both systems have run side by side. Each step ends with a check you can review before the next one starts.

Inventory state machines and service integrations
Export every state machine definition, its IAM role, its service integrations (Lambda, DynamoDB, SQS, SNS, ECS and others) and its triggers, then record which external systems each workflow calls and which ones use callback or task token patterns. The owning platform team usually does this with the application owners, because undocumented integrations surface here. The step is done when you have a migration inventory that lists every state machine, its integrations, its callers and its data retention needs. Confirm the export method with your AWS account team and your own change control process before you start.
Choose the first workflows to move
Rank the inventory by business risk, dependency count and how many callers depend on each workflow, then select one or two low-risk, well-understood workflows as the pilot. Avoid starting with workflows that depend on long-running callbacks or that touch regulated data without a tested rollback path. The output is a written list of pilot workflows with owners, acceptance criteria and a rollback plan agreed by the people who run them in production.
Stand up a non-production Temporal cluster
Deploy a non-production Temporal Server using one of the supported methods (Docker Compose, Go binaries, Helm charts on Kubernetes or a custom Go build) with a supported persistence database. Temporal's persistence documentation lists tested versions of Cassandra, PostgreSQL and MySQL, and states that SQLite is meant only for development and testing. Decide on advanced visibility early, since Elasticsearch or OpenSearch is recommended once you run more than a few workflow executions. Keep the Temporal services on hosts not reachable from the public internet. The step is done when a test workflow runs end to end, the Web UI is reachable only from your trusted network, and the persistence and visibility stores are backed up.
Secure the cluster before any workload runs
Configure an Authorizer, since a self-hosted Temporal with no Authorizer uses a default that allows every API request without authentication or access control. Enable mTLS for internode and frontend traffic, map identity claims to namespace roles through the ClaimMapper, connect OIDC single sign-on for the Web UI, and decide whether payloads need encryption through a custom codec and codec server. Your security team should review these settings against your own policies. The step is done when unauthenticated API calls are rejected in a test and each namespace has documented roles.
Rewrite state logic as workflow and activity code
Translate each pilot state machine into a Temporal workflow written in your chosen SDK language. Task states become activities (the code that calls external systems and can be retried), while Choice states become ordinary conditionals, Wait states become durable timers, and Parallel and Map states become concurrent work inside the workflow. Retry and timeout policies from the state definitions must be re-declared explicitly. Application engineers should write unit tests with Temporal's test framework and replay histories from the test environment. The step is done when the pilot workflows pass their acceptance tests and replay cleanly, which confirms that future code changes will not break in-flight executions.
Replace callbacks with signals and handle external events
Where a Step Functions workflow waits for an external system through a callback or task token, replace that wait with a Temporal signal that the external system or a service sends to the running workflow, and keep a timeout so a lost message does not stall the execution. Document each signal name, payload shape and sender. The step is done when every callback in the pilot workflows has a tested signal path, including the timeout behavior when the signal never arrives.
Run both systems side by side during cutover
Route new work to Temporal for the pilot workflows while existing state machines finish their in-flight executions on Step Functions. Compare outputs, error rates and retry behavior between the two, and keep the ability to switch callers back. Operations staff should be on call with runbooks for Temporal's services and persistence store, since this is the first period the team runs the cluster under real load. The step is done when the agreed acceptance criteria hold for the pilot workflows over the monitoring window you set and the team has rehearsed rollback.
Retire state machines and keep the upgrade discipline
Disable the migrated state machines only after no in-flight executions remain and no caller still targets them, then archive their definitions and execution history under your retention policy. Keep the Temporal deployment on a documented upgrade path. Upgrade one minor version at a time, moving to the latest patch of the current minor first, since backward compatibility is guaranteed only between two successive minor versions. Run schema upgrades before server upgrades when release notes call for them, and pin Helm chart versions because chart versions below 0.73.1 do not work with server images 1.30 and later. Check the current release at the time of your upgrade against Temporal's GitHub releases. At the time this page was written, Temporal Server v1.32.1 was published on October 8, 2026, and patch releases v1.31.4 and v1.30.8 followed on October 12, 2026, so treat those as the current state to verify, not a target to assume. The step is done when the old machines are archived and the upgrade runbook has been tested on a non-production cluster.

Questions buyers ask before choosing Temporal

How much does moving from Step Functions to Temporal cost?

The move has two cost types: one-time work to rewrite and test state machines as code, and recurring cost to run Temporal. Step Functions is billed per state transition (Standard) or per request and duration (Express), so the recurring bill falls as the platform cost rises. Temporal's own costs come from servers, a persistence database, an Elasticsearch or OpenSearch visibility store if you need it, and engineering and on-call time. Temporal Cloud pricing, which the vendor publishes as starting at 50 US dollars per million actions, is a useful comparison point for the managed option. Ask any provider for a fixed-scope quote that lists each state machine, integration and environment, plus what happens to the Step Functions bill during cutover.

How long does a Step Functions to Temporal migration take?

The duration depends mainly on the number of state machines, how many AWS service integrations each one calls, and how much callback and wait logic must be redesigned as signals and timers. A team with a handful of simple Task and Choice flows faces a different job than one with many Parallel and Map states that call Lambda, SQS and DynamoDB. Running both systems side by side during cutover adds time but reduces risk. Ask for a written inventory of state machines, a per-workflow complexity assessment, and a timeline tied to deliverables before work starts. Any duration you are given should be traceable to that inventory.

Can our team migrate Step Functions to Temporal without outside help?

Yes, many teams do it internally, but the work requires skills beyond JSON editing. Engineers must learn Temporal's programming model, handle determinism rules in workflow code, design retries and timeouts, and build test harnesses for long-running executions. The Amazon States Language definitions must be exported and mapped to code, and IAM roles and service integrations must be captured. A fixed-scope engagement can cover planning, translation, testing and cutover support, while your team keeps ownership. Compare the cost of pulling engineers off product work against a written scope with clear deliverables.

What skills and on-call capacity does a self-hosted Temporal cluster need?

Operating Temporal requires people who can manage the server, its persistence database, a visibility store and the Kubernetes or Docker deployment. Temporal supports Cassandra, PostgreSQL and MySQL for persistence, and Elasticsearch, OpenSearch or SQL databases for visibility, so you must choose and run one of these stack combinations. Upgrades should move one minor version at a time, with schema upgrades before server upgrades when release notes require them. Plan for on-call rotation, backup and restore testing, and capacity monitoring. Ask any provider to name the people, runbooks and monitoring they will leave behind.

Can Temporal run on-premises and across multiple clouds?

Yes. Self-hosted Temporal can run on Docker Compose, Go binaries, Helm charts on Kubernetes, or a custom Go build that imports the server package, so it is not tied to AWS. The deployment documentation says Temporal services should run on hosts not reachable from the public internet, with access limited to trusted internal networks. Your persistence and visibility databases, network paths to AWS services that remain in use, and certificate management will shape the design. Confirm the target infrastructure, supported database versions and network routes against the current Temporal documentation before committing.

How does Temporal handle long-running waits and workflow versioning?

Temporal workflows are ordinary code, so waits are expressed as timers and external events as signals, instead of Step Functions Wait states and callback task tokens. A workflow can sleep for days or longer while its state is persisted, and the history records every step. Versioning is handled in code, using patching or versioned workflow types so that running executions finish on their original logic while new ones use updated code. Engineers should confirm how retention settings apply to completed history and how their team will test version changes before deployment.

When is Temporal Cloud worth comparing with self-hosting?

Temporal Cloud is worth comparing when you want the orchestration engine without operating its database, server upgrades and visibility store. The vendor's pricing page lists pay-as-you-go pricing, 99.9% and 99.99% with high availability SLAs, and SAML SSO. Self-hosting is the better fit when data residency rules, network isolation or the need to keep the runtime inside your own infrastructure outweigh the operations load. Compare total cost including your own engineering and on-call time, and confirm current SLA terms directly with the vendor.

What should we ask a consultant for in a fixed-scope quote?

Ask for a written scope listing the state machines in the migration, the AWS integrations each one uses, the environments covered, and the testing approach, including how long-running executions are validated. Request explicit deliverables such as translated workflow code, a deployment of Temporal in your infrastructure, hardening against the self-hosted security guidance, backup procedures, documentation and runbooks. Also ask how cutover will run side by side with Step Functions, what handover support is included, and whether ongoing support or upgrades are offered as a separate retainer. DeployOpen does not publish a price list, so a quote follows from this written scope.

How DeployOpen helps you evaluate, implement or migrate

DeployOpen plans, implements, hardens, backs up and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For AWS Step Functions vs Temporal, we start with your workflows and runtime constraints, then decide with you whether self-hosted Temporal fits, and what it would take to run it.

How we scope

Inventory which state machines, run lengths and AWS service integrations your workflows depend on today.
Define which Temporal deployment method, persistence database and visibility store fit your environment.
Agree deliverables, timelines and responsibilities in writing before any work starts, as a fixed-scope engagement.

How we build

Stand up a self-hosted Temporal cluster in your infrastructure, with services kept off the public internet.
Configure mTLS, an Authorizer, a ClaimMapper and OIDC single sign-on for the Web UI before any workflow runs.
Test workflow durability, retries, timeouts and versioning against representative state machines from your inventory.

How we hand over

Document the architecture, deployment steps, access model, upgrade procedure and payload encryption choices for your team.
Provide runbooks for upgrades, schema changes and backups, following the one-minor-version-at-a-time upgrade path.
Deliver the cutover plan and evidence for running Step Functions and Temporal side by side during migration.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover.
Re-test the cluster after each Temporal server upgrade, including schema changes and access controls.
Prepare systems, controls and evidence for compliance assessments; independent auditors issue any attestations.

AWS Step Functions vs Temporal