BPMN VS AWS Step Function


I have been hearing a lot about AWS Step function and I am kind of convinced that AWS step function can replace Camunda . Can someone point me to the difference between AWS step function and what Camunda does ? I know BPMN contains lot more feature than Step function but my general feeling is that AWS is continuously improving Step function and it might very soon be there . Any good pointer will be helpful ?

Camunda VS Spring Data flow

Hi Bhupendra.

AWS Step Functions and Camunda are indeed competition for some use cases.

I am currently comparing language features, but doesn’t have anything to publish yet. But in general BPMN is much more powerful at the moment - and you are missing a lot like timers (step functions is reduced for waiting with timeout), compensation or scoping (subprocesses). Of course step functions can eventually implement these concepts, but keep in mind that this also means: reinventing them. What I personally like about BPMN is that it is an ISO standard, so a lot of important players in the industry agreed on it and it is well discussed - so you can be sure important concepts are tackled and got right. I know that standards overall don’t have the best reputation at the moment, but I am convinced that they are very useful given a wide adoption like BPMN. A lot of people know it, so it is basically about proprietary vs. standard flow languages.

Another important aspect is visualization. With Camunda you get BPMN models, which are considerably known around the globe by various stakeholders. You can model your flows graphically, but you are not forced to do it by the way, you can also define your flow in Java DSL or YAML. In this case you still have a BPMN visualization (auto-layout). BPMN models enable a BizDevOps mindset as these models can be read by business people as well as developers as well as in operations. This is not so much the case with Step Function visualizations.

Talking about operations: Have a look at Camunda Cockpit and compare this to the AWS tooling, which I think speaks for itself.

Technically a big difference is that Step Functions are cloud only. You simply cannot run them locally or on premise. This might be OK for some, but limits the general applicability. And if you are doing cloud things, Step Functions support AWS stuff better than other (understandable). With Camunda you can also orchestrate e.g. Lambdas, but in the same way as other services (e.g. Azure Functions). It needs some custom glue code (nothing out-of-the-box yet), but is very flexible.

So personally I think it depends on your use case very much - and both tools can be a good fit. Not hard to guess my preferred default :slight_smile:

Let me know if you have feedback or concrete questions!


PS: Might be also interesting for you to have a look at http://zeebe.io/ - architectural wise it is even closer to Step Functions than Camunda BPM - but if you do not have the requirements for a huge load or to run without RDMS Camunda BPM is the better choice at the moment because of its maturity.


Thanks for that amazing feedback . Every point you mention is what I feel as well being a Camunda/BPMN developer for last few months . My specific question was do we have a comparison of feature set that makes Camunda more attractive than AWS step function along with some nice use cases that can be done in Camunda easily but cannot be done in Step function or not as easy to do in Step function ?

Just to give you a little more feedback we are moving towards AWS as a company and my team has been heavily invested in building Camunda workflow but after attending few AWS session , it seems like we can do most of the stuff with AWS step function as well without worrying about deployment or other stuff that comes with Camunda (Just FYI as this session are attended by my boss as well there has been question about why Camunda?) . I want to be proven wrong regarding step function as I love camunda and I hope someone can do that for me with some nice concrete examples (as I am not an expert in Camunda)


I plan to make a more serious comparison later this month (hopefully) or early next year. For the moment I can give you a very prominent example: Compensation, which is about business transactions or also often referred to the Saga Pattern. Think of this simple payment example:

Assume that both services are not transactional, e.g. because they are Lambdas or REST. If the credit card fails you have to roll back the business transactions and compensate any money you deducted from the customer credit. BPMN can do this out-of-the-box, step function not at all (as far as I know). so you would have to model compensation logic “manually”, which might be easy in this case, but we often see much more complicated flows with more complicated compensations, where you have to duplicate basically all happy path flow logic into various compensation moments.

And as an additional remark: To make a fair comparison you would need to compare Step Functions against a Camunda cloud service - which is not yet there. But we will eventually have this. I cannot yet commit on any timeline, but don’t expect it too far away :slight_smile: As soon as this is there, the comparison makes much more sense and is easier to do. I see the argument of easier operations. Not that it is hard to operate Camunda on AWS, a lot of customers are doing it, but it needs low level ECS or Kubernetes instead of just having the engine as a service.

Personally I still believe that the operational features in Cockpit (EE version) alone make a decision pretty easy for serious use cases. But of course that’s my personal opinionated view.

Hope that helps bit?



Doesn’t AWS Step functions provide “Catch” which can be used for such “recovery” or “compensation” steps?


Step Functions does indeed have a “catch” and this allows to catch errors and define an action what to do next. This can be used to implement compensation logic. However, the compensation logic cannot be distinguished from happy path logic any more, it is much more cumbersome to design complex logic and it is much harder to write and read. From my perspective this matters a lot - I wrote about this in https://blog.bernd-ruecker.com/bizdevops-the-true-value-proposition-of-workflow-engines-f342509ba8bb.


@BerndRuecker , We are evaluating using AWS Step functions v/s Camunda.

Can you provide me some kind of performance comparison for the same. I am looking for scale parameters like

  1. Maximum number of parallel execution of workflows
  2. Maximum number of state transitions per second
  3. Maximum size of data that can be passed across tasks etc.

(of course with the assumption of some hardware and for a single node)

Thanks in advance


Can you send me a private mail (bernd.ruecker@camunda.com)? I would have some counter questions and it probably needs some more info to give you better ideas.


Haven’t received anything yet - can you please try to send it again and ping me here (to make sure it did not go into SPAM)? Thanks.