AWS Step Functions cost vs self-hosted Temporal: where the break-even sits
Step Functions cost grows with usage, while self-hosted Temporal cost is mostly fixed infrastructure plus skilled staff time and on-call. So the break-even depends on your transition or request volume, how long workflows run, and what an engineer costs in your organization. Start by pulling your current Step Functions bill for the last 12 months and splitting it into Standard charges, which are billed per state transition, and Express charges, which are billed per request and by duration. Take the list rates from AWS's pricing page for your region and tier, because no Step Functions price is set out here and rates change. Then model your monthly transition or request counts against those rates.
For the self-hosted side, the only price reference this page relies on is Temporal Cloud's pay-as-you-go pricing, which starts at 50 US dollars per million actions, with active storage at 0.042 dollars per GB-hour and retained storage at 0.00105 dollars per GB-hour, according to the Temporal Cloud pricing page. That figure is a managed-service benchmark, not the cost of running the open-source server. Your self-hosted cost is made of separate components: compute for the Temporal Server services, a persistence database (Cassandra, PostgreSQL or MySQL, per the supported versions), an Elasticsearch or OpenSearch cluster for advanced visibility, backups, monitoring, and the engineering time to upgrade and operate all of it. Ask vendors and your own platform team to quote each line, and confirm the Temporal persistence and visibility versions you plan to run.
Most of the uncertainty sits in staff time and on-call, which often outweighs infrastructure. Count the engineers who will own upgrades, since Temporal recommends moving one minor version at a time and running schema upgrades before server upgrades when release notes require them. Add the cost of securing the cluster, because self-hosted Temporal uses a noopAuthorizer by default, and that default allows every API request. Break-even moves toward self-hosting when transition volume is high and steady, when you already run the databases and search clusters, and when the team has Go or Java skills to operate code-based workflows. It moves back toward Step Functions when volume is low and the team is small. Run a two-week trial of both costs, including incident time, before you commit.
Which cost components move the comparison
This table sets each cost component of Step Functions against the matching self-hosted Temporal component, and marks whether it is paid once or recurs. Read the commercial column for what AWS bills by usage and the self-hosted column for what your team pays for in staff, infrastructure and operations. The main takeaway is that most of the Temporal cost is recurring people and infrastructure time, and the only priced Temporal comparison supplied is Temporal Cloud.
| Cost component | Commercial side (Step Functions) | Self-hosted side (Temporal) | One-time or recurring |
|---|---|---|---|
| Standard transitions | Billed per state transition, so cost follows how many steps your state machines run | No per-transition fee; cost shifts to the cluster and database that absorb the same load | Recurring, scales with volume |
| Express requests and duration | Billed per request and by duration, which suits high-volume short workflows | Covered by server compute and persistence sizing, driven by throughput and history size | Recurring, scales with throughput |
| Temporal server compute | Not applicable; AWS runs the service | Frontend, history, matching and worker services on hosts or Kubernetes pods that you provision and scale | Recurring infrastructure |
| Persistence database | Not applicable; state is held inside the AWS service | Supported backends include Cassandra, PostgreSQL and MySQL; you size, back up and patch the database | Recurring, plus one-time setup |
| Elasticsearch or OpenSearch visibility | Execution history is visible in the console within the service's own retention | Advanced visibility needs a separate search cluster, which is a second system to run and size | Recurring infrastructure |
| Upgrades | AWS applies service changes; your effort is limited to state machine updates | Server upgrades one minor version at a time, with schema changes first where release notes require them | Recurring, per release cycle |
| Engineering time | Mostly definition work in Amazon States Language and IAM | Workflow code, activity code, testing and cluster work, which is the largest one-time cost in most migrations | One-time build, then recurring maintenance |
| On-call | Handled by AWS for the service; your team owns application failures | Your team owns cluster health, database failover and visibility store health, so on-call scope widens | Recurring |
| Security hardening | Covered by AWS shared responsibility and IAM policies you already run | No authorization by default; you must configure mTLS, authorization, network isolation and payload encryption | One-time setup, then recurring review |
What moves the cost of each side
Step Functions bills by what your workflows do, while a self-hosted Temporal cluster bills by what you run and who runs it. The drivers below move one side or the other, and most of them affect both, so model them together before comparing totals.
Execution volume and transitions
Step Functions Standard bills per state transition, so every retry, Choice branch and Map iteration adds to the bill. Express bills per request and duration instead. On the Temporal side, volume mainly drives database write load, worker capacity and the size of the persistence tier, not a per-action fee. Ask your team to count transitions per execution from a typical month, then model the same workload as Temporal history events and worker throughput. Illustrative: a workflow with many retries costs more per run on Standard than a single-pass workflow, even if both finish the same business task.
Average history length per workflow
Temporal stores every event in a workflow's history, and long histories grow persistence storage, slow replay and increase the work each worker does when it resumes a workflow. Step Functions also charges more for longer state machines, so history length affects both sides in different ways. Measure the median and the tail of history length for your longest processes. Long-running processes that loop many times are where Temporal teams usually need Continue-As-New patterns or periodic restarts to keep histories bounded.
Retention window
Step Functions keeps execution history for a limited period, and most teams that move off it must export history before it expires. Self-hosted Temporal retention is set per namespace and is paid for in database storage and backups that you operate. Longer retention raises storage on your persistence database and any visibility index, and it also raises backup and restore time. Ask which records auditors or incident responders need, for how long, and whether that data should live in the workflow store or in your own archive.
Visibility query load
Visibility is how operators search and list workflow executions. Temporal's advanced visibility needs a separate store, and the docs recommend Elasticsearch or OpenSearch for anything beyond a few workflow executions. That index adds nodes, memory, disk and tuning work that Step Functions does not require from you. Frequent dashboards, customer-facing status queries or compliance searches increase this load. Confirm which query patterns you need before sizing the index, and check which visibility backend your target version supports.
Namespaces and environments
Each Temporal namespace is an isolation unit with its own retention and access settings, and every environment you add (development, test, staging, production, regulated sub-units) multiplies the services, databases and monitoring you run. Step Functions scopes state machines by account and Region, so teams often underestimate what separate Temporal namespaces and clusters cost to operate. Decide early whether you need one shared cluster with several namespaces or separate clusters per environment, and price the second option with its own persistence and on-call coverage.
Availability targets and on-call
A self-hosted cluster needs redundant frontend, history, matching and worker services, a highly available persistence database and tested backups. Temporal Cloud publishes an SLA of 99.9%, or 99.99% with high availability, and Step Functions runs on AWS infrastructure you already pay for. Your cost is the engineering and on-call time needed to reach the availability you commit to internally. Ask what uptime you have promised to business owners, who will be paged for a stuck workflow at night, and what a failover test costs in staff hours.
In-house Temporal skills
Temporal workflows are written as code, and operating the cluster requires people who understand its persistence, upgrades and security settings. Upgrades must move one minor version at a time, and schema changes must run before server upgrades when release notes require them. Teams without this experience usually pay for training, consulting or a retainer, while teams already running Go or Java services may absorb the work. Compare the cost of hiring or training two or three engineers against the Step Functions spend you expect to avoid, and ask any implementation partner to state the skills and hours in writing.
What a self-hosted Temporal cluster actually requires
A self-hosted Temporal cluster is more than one binary. The Temporal Server runs as a set of services that you can deploy with Docker Compose, with Go binaries, or with Helm charts that place each service in its own Kubernetes pod. Your team chooses the deployment method, and that choice decides who maintains the upgrade path, the monitoring and the scaling. Check that the Helm chart version matches the server image: the deployment documentation states that chart versions below 0.73.1 do not work with server images 1.30 and later. Plan for the Temporal Server itself to be upgraded one minor version at a time, which is recurring engineering work rather than a one-time install. The Temporal self-hosted deployment guide covers the supported layouts.
The second part is a persistence database. Temporal is tested on Cassandra, PostgreSQL 13 to 16 and MySQL, and SQLite is only for development and testing. The database is usually the largest standing cost after engineering time, because you pay for its compute, storage, backups, high availability and patching, either as a managed service or as a platform team's responsibility. Advanced visibility is a separate line. Elasticsearch 7 or 8, or OpenSearch 2 or later from Temporal Server 1.30.1, is recommended for anything beyond a few workflow executions, so you should budget a search cluster of its own with its own storage growth, index management and on-call coverage. Ask your team to confirm which visibility store the chosen server version supports before sizing either system.
Finally, treat the network layout as a control, not a default. The deployment documentation says Temporal services should run on hosts that are not reachable from the public internet, with access restricted to trusted internal networks. If no Authorizer is configured, the server uses a no-op authorizer that allows every API request. Before go-live, confirm that mTLS, the ClaimMapper, the Authorizer and OIDC single sign-on for the Web UI are configured through the Temporal self-hosted security guide. Each of these settings adds design and testing time, which belongs in your effort estimate alongside the database and visibility lines.
How to build the comparison with your own numbers
This sequence turns your current Step Functions bill into a comparable model for a self-hosted Temporal cluster, so the break-even point reflects your own volume, staffing and growth rather than a generic estimate.
Export execution and transition volumes
Pull monthly execution counts for each state machine from CloudWatch metrics and the AWS billing report, separating Standard and Express workflows because they are billed differently. Your cloud or finance team does this, and the output is a table of executions per month by state machine and workflow type, with the billed usage lines matched to each row. Confirm the exact billing dimensions with AWS pricing documentation for your region before you rely on the figures.
Measure transitions and requests per workflow
Sample recent executions in the Step Functions console or from execution history to count average state transitions per Standard execution, and average request count and duration for Express executions. Map the Map and Parallel states to their real fan-out, because iterations multiply transitions. The output is a per-workflow average that you multiply by the volumes from the previous step, and you should note which workflows have outliers that skew the mean.
Size the Temporal cluster for the same load
Translate the throughput into a Temporal sizing exercise with your platform engineers: frontend and history service capacity, worker counts for the activities that replace Lambda or service integrations, and the Kubernetes or Docker Compose footprint that the chosen deployment method needs. Confirm current sizing guidance and supported server versions in Temporal's deployment and upgrade documentation. The output is a node and pod plan with an estimated compute cost per month from your cloud provider's price list.
Size the persistence database and visibility store
Choose the supported persistence backend (Cassandra, PostgreSQL or MySQL, per the persistence docs) and estimate storage from your retained history volume and retention period. Add the advanced visibility store, which Temporal recommends as Elasticsearch or OpenSearch for anything beyond a few workflow executions, and price it as a separate managed or self-run service. Confirm supported versions in Temporal's visibility documentation. The output is a monthly line for database, backups, and search storage, plus the replica and backup policy you intend to run.
Price staff time and on-call for your team
Estimate the engineering hours for initial build, migration of workflow code, upgrades (Temporal recommends moving one minor version at a time), security hardening such as mTLS, authorization and network isolation, and ongoing on-call. Use your team's loaded hourly cost from HR or finance, not a market average. The output is a one-time migration cost and a recurring operations cost per month, and you should state which hours are funded by existing headcount and which require new hires or an external retainer.
Add licensing and support lines
List the lines that apply to your choice: the Temporal server is MIT licensed, so the software itself carries no license fee, but you still pay for infrastructure, staff and any support contract. If you compare against Temporal Cloud, take the pay-as-you-go rates from Temporal's pricing page and apply them to your action count. The output is a side-by-side table with self-hosted cost components and the managed service quote on the same volume.
Run a volume growth sensitivity check
Model the total cost at your current volume and at two or three higher growth levels that your product roadmap supports, because Step Functions costs scale with transitions while a Temporal cluster scales in steps. Mark the volume where the self-hosted total falls below the AWS total, including the one-time migration cost spread over your planning horizon. The output is a break-even chart by volume, and it should be reviewed by finance and the platform team together.
Request quotes for the same volume
Ask Temporal Cloud for a quote for the same action volume, retention and availability target, and ask AWS to confirm the Step Functions pricing for the same executions and transitions in writing. Ask any implementation partner for a fixed-scope quote based on your written requirements. The output is three reference points that you can compare against your self-hosted model, and the step is complete when every line in the model traces to a quote, a bill or a named internal estimate.
Questions buyers ask before comparing cost
Is Temporal cheaper than Step Functions at low volume?
Usually not once you count the whole system. Step Functions Standard is billed per state transition, so a low-volume workflow has a small metered bill and no servers to run. A self-hosted Temporal cluster needs a server deployment, a persistence database and, for production visibility, Elasticsearch or OpenSearch, and those components cost money and staff time even when traffic is light. The Temporal server itself is MIT licensed, so the software is free to use, but the infrastructure and people around it are not. Ask your team to compare the fixed monthly cost of the cluster against the metered Step Functions bill at your real transition counts.
How much engineering time does self-hosting Temporal take?
The honest answer depends on your deployment method, your availability targets and how many teams share the cluster, so no fixed figure applies here. Work that recurs includes deploying the server through Docker Compose, Go binaries or Helm charts, sizing and operating the persistence database, keeping visibility storage healthy, configuring mTLS, authorization and OIDC single sign-on, and rotating credentials. Ask your platform team to estimate these tasks in hours per month and to name who carries the on-call rotation for the cluster.
Can our team run self-hosted Temporal without outside help?
A team with Kubernetes, database and security skills can run it, but the question is whether they have the capacity and the knowledge to do it safely. Temporal's self-hosted security documentation notes that without a configured Authorizer, the default noopAuthorizer allows every API request with no authentication, so hardening is a required first step, not an optional one. Many organizations bring in an implementation partner for the initial build, hardening and runbooks, then keep the platform in-house. DeployOpen plans, implements, hardens, backs up, documents and supports self-hosted platforms inside your own infrastructure, with a fixed scope agreed in writing before work starts, and ongoing support available as a retainer.
What drives the break-even point between Step Functions and self-hosted Temporal?
The break-even depends on the volume of transitions or actions, the length and count of your workflows, your uptime requirements and the fully loaded cost of the people who run the cluster. Step Functions cost grows with each state transition, while a self-hosted cluster costs mostly in fixed infrastructure and staff, so higher volume tends to favor self-hosting. Factor in visibility storage, since Temporal recommends Elasticsearch or OpenSearch for anything beyond a few workflow executions. Build a model with your own transition counts, retention needs and on-call load, and check the result with your AWS account team and your Temporal vendor or partner.
How do Temporal upgrades affect the operating budget?
Upgrades add recurring work, so include them in the operating budget. Temporal's upgrade guidance says to move one minor version at a time, to the latest patch of the current minor first, because backward compatibility is guaranteed only between successive minor versions. Schema upgrades must run before server upgrades when release notes call for them. The Helm chart version also matters, since chart versions below 0.73.1 do not work with server images 1.30 and later. Plan time for a test environment, a staged rollout and a rollback path each cycle, and confirm the upgrade cadence with your team before you commit to a support model.
Is Temporal Cloud a middle option between the two?
Yes, Temporal Cloud is a managed option that moves server operations to Temporal Technologies while you keep the Temporal programming model. Its published pay-as-you-go pricing starts at 50 US dollars per million actions, with active storage at 0.042 dollars per GB-hour and retained storage at 0.00105 dollars per GB-hour, according to Temporal's pricing page, and it lists a 99.9% SLA or 99.99% with high availability. Compare those metered charges with your self-hosted run cost, and ask Temporal directly whether current rates, regional hosting and data residency terms match your requirements, since pricing and terms can change.
What should we ask for in a quote for self-hosting Temporal?
Ask for a written scope that names each deliverable: deployment method, persistence and visibility design, security configuration, backup and restore testing, upgrade procedure, documentation and handover. Ask which items are one-time, such as the initial build and hardening, and which recur, such as support, upgrades and continuous testing. Request the assumptions behind any timeline, including the number of environments, the compliance evidence you need and who on your side approves changes. DeployOpen does not publish a price list, and a quote follows from the written scope.
What a migration adds to the one-time cost
A move from Step Functions to Temporal adds a one-time migration cost that sits on top of the recurring figures. The work has four parts: exporting the existing state machines, translating their states into workflow and activity code, running both systems side by side during cutover, and retiring the Step Functions resources afterward. Each part consumes engineering time, and the people doing it are usually the same platform engineers who also run the Temporal cluster. Ask whether that capacity is already committed to other work before you treat the migration as an add-on.
The export step is the most predictable. Each Amazon States Language definition has to be retrieved, along with the IAM roles, service integrations and any KMS-encrypted definitions it depends on. The translation step is where effort concentrates. Task, Choice, Wait, Parallel and Map states each become code, and callback patterns must be redesigned around Temporal signals. Count the state machines, the distinct service integrations and the callback patterns in your inventory first, because those three numbers drive most of the translation effort. The Temporal self-hosted deployment guide is the reference for the target environment, not a migration plan.
Parallel running is the cost teams most often underestimate. For the cutover period, both the Step Functions workloads and the Temporal cluster must be operated, monitored and staffed, and in-flight executions must either finish on Step Functions or be drained deliberately. Decide the cutover method per workflow before the first deployment, and confirm how long executions in your environment typically run, since that sets how long the old system must stay alive. For detailed sequencing, see the sibling pages on migrating from AWS Step Functions to Temporal and on exporting state machines from AWS Step Functions.
How DeployOpen scopes a fixed-price Temporal implementation
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a move off AWS Step Functions, that means we start from a written scope that compares your current per-transition and per-request bill with the components of a self-hosted Temporal cluster, so the cost case is checked before anything is built.
How we scope
- We inventory your state machines, execution volumes, run lengths and integrations before estimating anything
- We separate Standard and Express workloads, since their billing and history behavior differ
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts
How we build
- We size the Temporal server, persistence database and visibility store as separate components in your environment
- We configure mTLS, a ClaimMapper, an Authorizer and OIDC single sign-on instead of relying on the default open API
- We test workflow retries, timeouts and failover against your existing error handling before cutover
How we hand over
- You receive architecture records, runbooks for upgrades in one minor version at a time, and backup procedures
- We document the cost model so your finance and platform teams can track each component after handover
- We run parallel execution with your Step Functions workflows so both can be compared during cutover
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work ends
- Retainers can cover Temporal server patch and minor upgrades, schema changes and persistence maintenance
- Ask any implementation partner to confirm on-call coverage, response expectations and who owns each component
