AWS Step Functions vs Camunda: choosing a workflow engine

The short answer

Both orchestrate multi-step workflows with retries, branching and error handling. AWS Step Functions is a fully managed, serverless state-machine service for workflows that live inside AWS. Camunda is a BPMN process engine you can run anywhere, built for long-running business processes that business stakeholders also need to read — including human tasks and decision tables.

Rule of thumb: technical orchestration of AWS services → Step Functions. Business processes with people, audits and diagrams the business signs off on → Camunda.

How workflows are defined

Step Functions workflows are written in the Amazon States Language (JSON), with a visual editor in the console. Camunda workflows are BPMN 2.0 diagrams — an industry standard notation that business analysts, developers and auditors can all read — plus DMN for decision tables.

Here is a Step Functions task with retries and a fallback path:

"ChargeCard": {
  "Type": "Task",
  "Resource": "arn:aws:states:::lambda:invoke",
  "Parameters": { "FunctionName": "charge-card", "Payload.$": "$" },
  "Retry": [{
    "ErrorEquals": ["Lambda.TooManyRequestsException", "States.Timeout"],
    "IntervalSeconds": 2,
    "MaxAttempts": 5,
    "BackoffRate": 2.0
  }],
  "Catch": [{ "ErrorEquals": ["States.ALL"], "Next": "NotifyFailure" }],
  "Next": "ShipOrder"
}

In Camunda the same step is a service task in the diagram: retries are set on the task, a job worker does the work, and an error boundary event draws the fallback path where everyone can see it.

Integrations and where your code runs

• Step Functions calls AWS services directly — Lambda, ECS, SQS, SNS, DynamoDB and hundreds of others through its SDK integrations — with no glue code for many steps.
• Camunda hands work to job workers you write in Java or any other language, wherever they run, plus ready-made Connectors for common systems such as REST APIs and Kafka.

Human tasks

This is often the deciding factor. Camunda has user tasks built in, with Tasklist and forms for assigning, claiming and completing work. Step Functions supports waiting for people through the callback pattern (.waitForTaskToken): the workflow pauses until something sends the task token back — but the task list, assignment and UI are yours to build.

Error handling and long-running work

• Retries: both support retries with backoff — Retry blocks in Step Functions, task retries and backoff in Camunda.
• Business errors: Step Functions uses Catch to route to another state; Camunda uses BPMN error events, plus compensation to undo completed steps.
• Stuck work: a failed Step Functions execution ends and is inspected in the console; a Camunda instance stops at an incident that can be fixed and retried from where it stopped.
• Duration: Step Functions Standard workflows can run for up to a year, while Express workflows are for short, high-volume runs. Camunda process instances can stay open as long as the business process needs.

Operations, cost and lock-in

• Operations: Step Functions is serverless — nothing to run or patch. Camunda is available as SaaS or self-managed, where you operate the engine.
• Cost model: Step Functions Standard is billed per state transition and Express per request and duration, so chatty workflows with many small steps get expensive. Camunda is licensed (or self-hosted infrastructure), largely independent of step count.
• Portability: Step Functions is AWS-only. BPMN models and Camunda run on any cloud or on-premises.

Side-by-side comparison

Which one to choose

Choose Step Functions when the workflow is technical, everything lives in AWS, steps are mostly AWS service calls, and the developers who build it also own it.

Choose Camunda when people take part in the process, business stakeholders need to read and agree on it, decisions belong in DMN tables, you need to run outside AWS, or audits require a clear history of every instance.

Using both is common: Camunda orchestrates the business process, and individual technical steps — a data pipeline, a batch of AWS calls — run as Step Functions workflows behind a single task.