Step Functions pricing: the 2026 break-even

AWS Step Functions pricing has two meters that never meet. Standard workflows bill per state transition. Express workflows bill per request plus duration times memory, the way Lambda does. AWS publishes both and never converts between them, so here is the conversion: one state transition costs the same as 23.995 seconds of Express duration at the minimum 64 MB billed memory. That single number decides the workflow type, and it has a hard edge. Past twelve counted states, Express runs into its own five-minute ceiling before Standard ever becomes the cheaper option.

How much does AWS Step Functions charge per state transition?

$0.000025 in US East (N. Virginia), with 4,000 free every month. The Step Functions pricing page states the meter plainly: "You are charged based on the number of state transitions required to execute your application." It defines the unit including retries: "Step Functions counts a state transition each time a step of your workflow is executed. You are charged for the total number of state transitions across all your state machines, including retries."

Example 1 on the same page describes a workflow with "four state transitions, determined by counting the nodes on the graph" and then lists those nodes as Start, two tasks, and End. Start and End are billable nodes. A one-task Standard workflow therefore counts three transitions by AWS's own method, which is $0.000075 an execution.

Retries are additive. "If you include retry error handling in any steps of your workflow, each retry will be charged as an additional state transition." A flaky downstream API does not just slow the workflow down, it multiplies the only meter Standard has.

How does Step Functions Express workflow pricing work?

Three components, and two of them are rounded up. The pricing page's Example 3 states "The price is $1.00 per million requests" and "The price is $0.00001667 per GB-second of duration". The rounding is where an Express bill is decided: "Duration is calculated from the time your workflow begins executing until it completes or otherwise terminates, rounded up to the nearest 100ms, and the amount of memory used in the execution of your workflow, billed in 64-MB chunks."

You do not choose the memory. AWS derives it: "Memory consumption is based on the size of a workflow definition, the use of map or parallel states, and the execution (payload) data size." The formula is published, in Examples 3 and 4: "Workflow memory utilized = 50 MB + state machine definition size + execution data size x Number of Parallel or Map Steps". The 50 MB base means almost every workflow lands in the first 64 MB chunk, which is why all three of AWS's Express examples bill at 64 MB.

The tiers only matter at scale: 1,000 GB-hours at 64 MB is 1.92 million thirty-second executions before the second tier starts.

When is a Step Functions Express workflow cheaper than a Standard workflow?

Whenever the execution runs for less than about 24 seconds per counted state. That is the conversion AWS does not print. At 64 MB billed memory, one second of Express duration costs $0.0000010419, so a $0.000025 state transition buys 23.995 seconds of it. Add the $0.000001 request charge and Express is cheaper while its duration stays under 23.995 times the state count, minus about a second.

Hypothetical arithmetic on AWS's published rates, at 64 MB billed memory and the first duration tier.

The Standard columns are flat because duration is not a Standard meter. A Standard workflow that sits in a Wait state for six days costs exactly what the same workflow costs in six milliseconds. Express charges for waiting; Standard does not, which is why polling and human-approval workflows belong on Standard regardless of the crossover.

Does the Express five-minute limit decide Step Functions pricing for you?

For anything past twelve counted states, yes. The workflow type documentation says Express workflows "can run for up to five minutes", and the Step Functions quotas page lists that maximum execution time as a hard quota that cannot be changed. At 13 states the crossover lands at 311 seconds. Express cannot legally run that long. So a 13-state workflow is cheaper on Express for every duration Express is capable of, and Standard never wins on price. It can only win on the features Express gives up.

The threshold moves with billed memory. At 128 MB one state transition buys 12 seconds and the threshold is 26 states; at 256 MB it is 51. Since AWS's formula starts at 50 MB and every AWS Express example bills 64 MB, 13 is the number most workflows meet. Crossing into the next chunk takes real payload volume: with a 10 KB definition and the "256 KiB of data as a UTF-8 encoded string" the quotas page allows per state, it takes 56 Inline Map iterations to reach 64.01 MB and double the duration charge.

Is the Step Functions free tier of 4,000 state transitions worth anything?

$0.10 a month, forever. The pricing page says "The Step Functions free tier includes 4,000 free state transitions per month" and, unusually, that it never runs out: "The Step Functions Free Tier does not automatically expire at the end of your 12 month AWS Free Tier term, and is available to both existing and new AWS customers indefinitely."

At $0.000025 each that allowance is worth ten cents a month, or $1.20 a year. In practice it covers 1,000 executions of a four-state workflow, or 444 of a nine-state one. There is no matching Express allowance anywhere on the pricing page: Express requests and duration are billed from the first execution, including, per the page, "tests from the console". Treat the free tier as a rounding artefact, not a budget. If the goal is catching a runaway state machine before the invoice does, that is a job for AWS Budgets and Cost Anomaly Detection, not for a $0.10 buffer.

Does a Step Functions workflow that calls Lambda pay both bills?

Yes, and on AWS's own Example 2 the orchestration costs more than the work. The pricing page is explicit that "You may incur additional charges if the operation of your application workflow utilizes other AWS services or transfers data." Example 2 prices a nine-state image-processing workflow at 100,000 executions a month: $22.40 of state transitions, which we reproduce exactly, driving five Lambda functions whose memory and duration it tabulates.

AWS states "The total cost of the five AWS Lambda functions in this example would be $97.62." We cannot reproduce that. Those five functions consume 5.85 GB-seconds per execution, or 585,000 GB-seconds a month, plus 500,000 invocations. The Lambda pricing page says "The monthly compute price is $0.0000166667 per GB-s and the free tier provides 400,000 GB-s" and "The monthly request price is $0.20 per one million requests and the free tier provides 1 million requests per month." Ignoring both free tiers, that is $9.75 of compute and $0.10 of requests: $9.85. The $97.62 figure is reproducible at exactly ten times Lambda's published per-GB-second rate, and at no other rate we could find.

The conclusion flips. AWS's page reads as though orchestration is a fifth of the cost of the work. At Lambda's published rates, orchestrating five functions costs 2.3 times the functions themselves. For short Lambda tasks the state machine is the expense, so the cheapest fix is usually fewer, larger states. The same per-invocation arithmetic drives what Lambda cold starts actually cost.

What does a Step Functions Distributed Map cost per iteration?

One state transition each, charged to the parent Standard workflow. The pricing page's Example 5 says so in passing: "Distributed Map costs one state transition per iteration". It then prices a million S3 objects at 1,000,005 state transitions, $24.90, alongside a million Express child executions costing $32.25. The orchestration is 43.6% of that bill.

Inline mode bills differently, and the same example says why: "there is no state transition for starting each iteration when you use an Inline Map." Inline is not free, because the states inside each iteration still transition, but the per-iteration start is. The trade is in the Inline Map documentation and the Step Functions FAQ, which puts the ceiling at "concurrency of 40 parallel branches and execution history limits of 25,000 events or approximately 6,500 state transitions in a workflow". The Distributed Map documentation buys past that by giving each iteration its own history: "Each child workflow execution has its own, separate execution history from that of the parent workflow."

Distributed Map is the expensive mode by design, and the FAQ names the lever inside it: "You can also choose whether each iteration is performed by a Standard Workflow, which is idempotent, or Express Workflow, which is a higher speed and lower cost, but not idempotent." Batching iterations cuts the meter directly, as the pricing page notes. Fan-out built on queues instead has its own arithmetic, in how Amazon SQS pricing works.

What does logging Step Functions Express workflows to CloudWatch Logs cost?

It is billed at the vended logs rate, and for chatty workflows it can rival the Express charge itself. The Step Functions logging guide makes it compulsory in practice: "Unlike Standard Workflows, Express Workflows don't record execution history in AWS Step Functions. To see execution history and results for an Express Workflow, you must configure logging to Amazon CloudWatch Logs." It adds that "you will be billed at the vended logs rate", and that Express state machines created in the console are logged by default.

Example 3 on the CloudWatch pricing page gives the rate as "0 to 10TB @$0.50 per GB = 10 * 1,024 * $0.50 = $5,120.00", plus archival at $0.03 per GB. Take a five-second Express workflow at a million executions a month: $6.21 of Step Functions charges. At $0.53 per GB delivered and stored, 12.3 KB of log events per execution costs the same again. Log level ALL on a workflow with a dozen states clears that easily. The mechanics of a CloudWatch Logs bill apply unchanged here.

Trimming the log level is the lever; the same guide tabulates which events survive at ERROR and FATAL. It also warns that the logs are not a system of record: "Amazon CloudWatch Logs are delivered on a best-effort basis. The completeness and timeliness of log entries are not guaranteed." If the history has to be reliable, AWS recommends writing it to a datastore yourself, which adds a third bill. A DynamoDB table sized for that pattern is priced in on-demand versus provisioned DynamoDB capacity.

Can you change a Step Functions state machine from Standard to Express?

No. The workflow type documentation states it under a heading of its own: "Workflow type is immutable". Switching means creating a second state machine and repointing every caller, so the arithmetic above is worth doing before the first deploy rather than after the first invoice.

Three documented differences override price anyway. Standard workflows are "long-running (up to one year), durable, and auditable" and follow an exactly-once model. Asynchronous Express executions are at-least-once, "so an execution could potentially run more than once", which rules them out for anything non-idempotent such as taking a payment. And Express does not support the Job-run or Callback service integration patterns, so a workflow that waits on a task token cannot be Express at any price.

The documented escape hatch is to use both. The FAQ suggests "running Express Workflows as a child workflow of Standard Workflows", putting the long, exactly-once outer shell on Standard and the high-volume inner steps on Express. Synchronous Express executions behave differently again, per the synchronous execution guide, and the API Gateway in front of them carries its own per-request meter, compared in REST versus HTTP API pricing.

One last detail, offered without a resolution: Example 5's summary bullet reports "520.33 GB-hour duration" while the working immediately below it computes 520.83 GB-hours and prices that. The $31.25 AWS states matches 520.83, so the bullet is the typo. Recompute a vendor's example before quoting it.