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

Factors affecting Cost

• How many action executions do you have

• Inefficient processing of data/messages

Things to think about

Should I use Logic App Standard?

One of the common questions is if you should use Logic App Standard or Consumption.  This is bigger than a cost driven question but there are cost angles to the decision.  Consumption Logic Apps are costed purely based on usage and have cost per action execution.  This means that for some solutions they can be extremely cheap.  The problem is for other solutions they can be expensive.  Logic App Standard is priced based on the node per hour model.  This means for Logic App Standard you will pay when there are no workflows running but you will pay a more reliable amount.

There is no right answer on this point, its really about understanding your expected usage and deciding which is best.

Diagnostics Settings

In Logic App Consumption you may choose to turn on diagnostics settings so that you get a lot of log data going to a Log Analytics workspace.  You will get multiple log entries for each action in the workflow.

The question is if you need to have diagnostics on all of the time of just when you need it.

Polling Triggers

In Logic Apps you will pay a tiny charge per trigger.  If you are using a polling trigger that checks too regularly you can build up a cost even when you havent processed any messages.  We have seen cases where you can spend in the region of $10 per month for a workflow polling Service Bus when there are no messages.  You should think about how you want to tune those triggers to poll at the right frequency.

Loops

When you have a loop in Logic Apps you will be processing a number of actions for each row in the loop.  If you can de-duplicate your batch of items and remove duplicate or redundant rows from the batch to ensure you only process the data that is required then you can minimize the cost of the workflow run.

Can you reduce complexity

Sometimes, with Logic App Consumption, you can over-engineer the workflow, making it very complex with loops and conditions to achieve functionality that could be achieved with a simple line of code.  Combining Logic Apps and Functions can give you an option to make a simple function call and do some stuff in custom code.  I have seen cases where 5 lines of code can remove significant numbers of Logic App actions.  When you pay per action, if there are lots of runs this can be a noticeable cost saving.

Common Optimizations

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

Leveraging an Azure Function to help your Logic App

There are design patterns where you might find you can put a little code in an Azure Function which can be called by your Logic App as a helper which can take a lot of actions calls out from the Logic App.  The function is charged per execution rather than per action so it can be more cost efficient to do some work in a function then return the data back to the Logic App.

Choose appropriate polling intervals

For Logic Apps that poll data sources or systems to get data, you should pick an appropriate polling interval.  If you are checking every second for data rather than every 15 mins then you will have a significant cost difference.

Minimize processing of unnecessary data

Sometimes, you might get a batch of data that contains a lot of records that are unchanged.  If you can use a map or function to remove redundant records from the data before you start looping over the batch then you can save a lot of unnecessary work which is a direct contribution to cost.

Gotchas

Watch for misconfigured triggers

We had a scenario once where a misconfigured Logic App trigger was pointing to a service bus queue with incorrect configuration, and because the connection could not be successfully made, the Logic App would aggressively try to reconnect to the service bus.  This resulted in a cost spike in that Logic App because of the aggressive attempts to reconnect.  This resulted in a Logic App that was expected to cost $10 per month, costing $82 for a few days, even though it never processed a message.

Below in the image you can see the triggers failed counter showing aggressive retrying.

We were able to catch this through cost monitoring and look into why that Logic App was costing so much and we would then fix the configuration error and the problem went away.  This had not been identified as an issue as the Logic App had not begun being used yet, it was just deployed in advance ready for testing the next week.

Ways Turbo360 can help

Schedule Enable and Disable workflow

You can enable and disable logic app consumption on a schedule to maximize the workload optimization.  For example in non prod you could disable it out of hours so that they stop polling for messages.

In one case we have seen customers who had many logic apps across many environments all polling service bus.  Using Turbo360 to automate their state the customer was able to save over $100 per month.  Below is the schedule they added.

You now just tick each Logic App you want added to the schedule.

Visualize Cost

There are a number of ways you could visualize cost for Logic Apps, first you could create a tree node for the integration team and view all of your integration costs in one place.  You can break things down by environments etc with sub-nodes on the tree.

One thing you might do is create graphs that focus just on your Logic App Consumption resources to check where you're spending money across your entire environment.  We often find customers have a small number of Logic Apps which may be consuming most of the cost.  This approach will make them easy to find.

If you wanted to take an interface based approach to visualizing cost you could create nodes on the tree view for different interfaces.  This could be done manually or if you have a good tagging strategy we can automate this for you.

Monitor Cost

If you have a tree node looking at your integration team (or more granularly looking at just Logic Apps) you can setup budget monitoring for these resources so you are aware of increases in cost.  This is very useful for resources like Logic App Consumption where the cost is consumption based.

If you have also setup tree view nodes for individual interfaces you could use budget monitoring or anomaly detection to identify issues for individual interfaces.

Useful Resources

Circuit Breaker Pattern to prevent cost spikes

This blog on Azure cost circuit breaker post describes a pattern for a circuit breaker if there is a cost spike.

Compare Logic App Versions

This video does a deep dive on logic app standard vs consumption, which provides info on comparing the 2 technologies and covers some cost angles.

Remove duplicate and wasteful processing