What drives Logic App cost?

Welcome to our video of Logic Apps, where we dive into the factors influencing their costs and performance. In this session, Andrew Rivers breaks down the essentials of Logic App Standard, explaining the importance of hosting plans and compute resources. Whether you’re evaluating different hosting plans, calculating necessary compute, or looking for strategies to optimize your Logic Apps, this guide provides valuable insights into managing costs while maintaining performance. Follow along as we also discuss practical tips for enhancing efficiency with stateful and stateless configurations. Join us to unlock the potential of your Logic Apps with expert advice and actionable strategies.

Perhaps the question I’m asked the most is what drives the cost of Logic Apps? So I’m just going to give you a really quick overview of what’s driving that. Because ultimately when we host Logic Apps, and here I’m talking about Logic App Standard, they sit on a hosting plan. And a hosting plan ultimately is just a computer, and you’re paying for the compute. Now, the different types of plans, you’ve got the WS one, WS two, WS three.

But ultimately all they’re doing is setting different levels of CPU. So the higher the plan, the more CPUs you have. And the costs pretty much scale linearly with that. So again, it comes down to how much CPU, how much compute. That’s what the cost is.

Now what’s the magic number for how much compute you have to buy? And the answer appears to be 80. So we’ll provide a link for this. But ultimately it seems like if you are running Logic Apps and you’re running stateful Logic Apps, you can do approximately 80 actions per second.

Follow the link, check it out. Now that means that you’ve got something then that you can optimize against. Because if you know how many Logic App executions you need a second, how many actions are in each Logic App, you can then work out how much compute you need and hence how much that’s going to cost you. And then if that’s a problem, you can then start to look at some strategies for making that better. So the first thing is, do you need all your actions?

So what we see a lot of the time is, for example, variable assignments. Do you need variables or do you need parameters? Because variable assignment is another action, and you’ve just used another one for very little gain. So do you need all your actions, another one, batching or set-based operations. It’s an action to do stuff on a single unit.

It’s an action to do something as a batch or as a set. So can you do things in set-based operations? Instead of… Well, I’ve got it last, but avoid looping because if you’ve got 100 things to loop through and each one of those has a whole ton of bits of work, it’s really painful, really expensive. If you can do that, all the set-based operations, the savings are massive.

And finally, stateful versus stateless. The stateful Logic Apps, one of the reasons why they take this amount of compute is because they’re designed to be operationally bulletproof, which means that every time you do an action, the result of that is written back to storage, which is great from a recoverability and operational point of view, but from a computing and resource point of view, it’s quite expensive. So if you find that some steps can be done in sequence, but they don’t all have to be saved back to disk, you can actually make those stateless. And that can save you an awful lot as well, because one stateless Logic App effectively is one action. Whereas if you’ve got a stateful Logic App, you’ve got a whole load you have to write back all the time. So there are just some quick thoughts.

The number 80—follow the link. Talk to me.

Chat to us about your Integration journey

Get in touch

Share this post