In this article we will look at options for Logic App Standard and how they affect the cost aspects of your solution.

Factors Affecting Cost

• Which plan do you pick

• How do you position apps to plans

• Cost of dependencies

• Stateless vs Stateful workflows

Things to think about

WS-* or ASE

When deploying Logic App Standard you will have a plan to host the solution on.  This plan could be one of the following:

• App Service Hosted on an ASE

• App Service with a WS1, WS2 or WS3 plan

These 2 different types of plan have different characteristics which will affect cost.  The ASE is a more typical fixed node cost per hour similar to a virtual machine.  The WS-* plans are more aligned to a Premium Function plan where you can easily dynamically scale up and down.

At scale you may even have different types of workload within your Logic Apps where some would lend better to having an ASE and some would be better with a WS3.  Take time to consider your plan usage and if you are better off with one vs the other.

Sharing plans with non Logic App components

When you deploy your Logic App Standard on an ASE, this ASE plan can also be used for hosting Azure Functions.  You may decide that it is better to have a single plan shared by both functions and logic apps to reduce costs.

Splitting Logic Apps across multiple plans

When you begin setting up plans for Logic Apps you need to decide which Logic App Standard resources will live on which plan.  One of the pitfalls you can fall into would be to put all of your apps on a single plan then when you start reaching the capacity limits of your plan you begin to look at scaling it up or out.

In some cases scaling will be absolutely fine but in other cases this may not be effective and you might be better off creating a 2nd plan and splitting your Logic Apps across multiple plans.

In this area you need to understand the profile and use of each app and decide how best to host them.

Logging

Logging is one of the unexpected costs for Logic App Standard.  You might be logging lots of data to app insights which could have a high cost with low value.  The host.json file can help you tune what you want to be logged.

Use of code within a workflow

One of the interesting patterns with a workflow is the use of custom code in the workflow.  It can be beneficial to use some custom code either via an expression or inline function which can reduce the amount of actions which are required in the workflow.  Reducing the number of actions will lower the resource requirements for your hosting and can at scale reduce costs.

Common Optimizations

This section covers some of the most common cost optimizations you might implement.

Burst Scaling

One of the best features of the WS-* plans is that they can burst out and back in as a response to load.  This is a great way to deal with a temporary spike and you would pay an increase in cost for the period of the increased load and then your app would scale back down.

One thing to consider with burst scaling is that there may be times where you prefer to implement a throttling pattern as an alternative.  If we consider the scenario that we have a WS-3 plan which is running 24 hours per day with 1 node.  Most of the time we are doing very little work but then we have a burst of load.  My WS-3 plan burst scales to 20 nodes for 1 hour to process the big burst of load and then scales back in to the normal 1 node.  This means that for today I will have paid for :

• 24 hours at 1 node

• And 20 hours for the additional burst processing

If I did not have a requirement to process these messages quickly I could have just left the Logic App at 1 node and allowed it 21 hours to process the messages.  The difference in cost here would have been:

While that is probably a simplified example, the point id like to make is to let your requirements drive the necessity to increase the cost.

Storage Transactions

Logic App Standard will heavily use 1 or more Azure Storage accounts.  The nature of the runtime and triggers and run history and persistence points will perform a lot of transactions on your storage account and Azure storage will charge you based on the storage and transactions use.

For smaller workflows and less frequently used workflows this is probably not that noticeable, but for high volume workflows or workflows with large messages within them these transactions against the storage account can mount up.  Remember one of the most common cost accumulators on your Azure spend is a very large number of ting individually costing transactions.

With this in mind there may be some scenarios where you want consider design patterns that remove duplicate data or process loops in specific ways.

With storage costs usually being quite cheap this may not be one of the first cost areas you look at but do keep an eye on your storage usage.

Stateful vs Stateless

Stateful and Stateless workflows are processed differently under the hood in terms of how the instance interacts with the runtime and storage.

Stateful workflows interact with storage heavily in order to do mass parallel async processing where as stateless workflows are not persisting to storage on each stage.

The interesting thing in this area is that its a trade-off between throughput and latency.  If you have a high volume of messages but require low latency then you will need to scale out where as it you are using stateful workflows then the async nature may better align to throttling patterns which will allow you to control load for the best balance of cost and performance.

There are many other design considerations which will factor into this decision but be aware that cost can be affected here.

App Insights

In addition to the storage dependency, your Logic App will also have a dependency on App Insights.  A Logic App processing a lot of messages is also going to process a lot of telemetry to App Insights.  This will appear on your Azure bill as Azure Monitor logging costs.

The function runtime used by Logic Apps will produce messages for messages processed and triggers.  Its likely you may get 2 log messages per action in the workflow.

You will probably find that 85%+ of the messages logged to App Insights will never be used.

There are a lot of tuning knobs available with the host.json file within your solution.  Its best to configure this service appropriately based on the right balance of logging needs and cost.

Ways Turbo360 can help

Automated Scaling of the Plan

Many resources will have a dynamic usage pattern.  A great example is Logic App Standard in non production where out of hours it is not tested heavily compared to during the day.  Here I can add it to a schedule and the plan will be resized based on the scheduled on and off hours as shown below.

I then just add the resource to the schedule and choose the appropriate size for up and down configurations.  In this case I make the plan an I3V2 when up and an I1V2 when down.  This saves me nearly $800 per month.

Right Size

With Turbo360 right sizing you will get guidance on any recommendations to right size your app service plans for Logic App Standard.  Often customers might oversize the app service plan and then never review it because it is just working and users are happy.

Make sure you review your plan and check for any opportunities to downgrade.

Reservation

Many teams miss that there are reservation opportunities available for App Service Plans.  Below you can see that there are reservations available for my App Service Plan hosted on an ASE.  This can give me a discount which gives some good savings.

Useful Resources

This deep dive video talks about logic app standard vs consumption which has lots of useful info

This video discusses defender costs for storage that can affect logic apps

Recommended Reading

Below are some articles from other sources which we would recommend checking out

• Target Based Scaling

• Saved Costs on Logic Apps Standard