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

• How many times you call the connector

• Is it a premium vs standard connector

• Is it a built in connector vs a cloud connector

Things to think about

Logic App Standard vs Logic App Consumption

One of the interesting things about Logic App standard connectors is the costs appear differently to how they do for Logic App consumption.

In Logic App consumption, if you make a call to a cloud connector then the cost for the execution appears under the billing row for the Logic App.  You do not get a billing row for the connector.

In Logic App Standard you DO get a billing row for the connector.

The reason for this is that for Logic App Standard the billing is for the App Service Plan which is a per hour compute model hosting many workflows.  The connectors are a per click type cost model.  In order to be able to handle both cost models then the cost for the connector is now a separate billing row.

Built-In vs Cloud Connectors

In Logic App Standard you have build in connectors which run on the hosting node for the Logic App.  This is the same as the bindings for Azure Functions.  You do not explicitly pay for the execution for a built in connector.  You may pay a charge for the end service you connect to from the built in connector (eg Service Bus) but the built in connector should not have a charge on the Logic Apps side.

In order to maximize cost efficiency its beneficial to prefer built-in connectors over cloud connectors where possible however there are a limited number of built in connectors.

Shared or Separate Cloud Connectors

If you are using a connector from multiple different workflows and multiple different Logic Apps it can be challenging to get visibility of who is using the connector to what level.  You could use App Insights if you wanted to get a view from a performance perspective.

With Logic App Standard, there is no additional cost to having multiple cloud connectors pointing to the same resource in most cases (eg: Multiple dataverse connector instances) compared to having a single one.  Having multiple will make it easier to identify in your billing data who is spending what money.

Common Optimizations

Can I optimize my workflow

Sometimes you may be able to minimize the execution of cloud connectors in a workflow.  A good example would be if I receive a batch of 100,000 records per day and process the rows individually and then make 3 calls to dataverse via the connector for each record.  In this case I am making 300k dataverse connector calls per day.  If I am then able to remove records that have not changed since yesterday I may be able to significantly reduce the number of records I process which will reduce the number of connector calls.  In the scenario above if only 1000 records per day really change then I could reduce my calls to Dataverse to 3000.  Some quick maths shows:

• Before

  • Calls to dataverse connector = 300k

  • Cost for connector = 0.000172

  • Cost per day = 51.6

  • Cost per month = 1548

• After

  • Calls to dataverse connector = 300k

  • Cost for connector = 0.000172

  • Cost per day = 0.516

  • Cost per month = 15.48

In this scenario we have reduced the cost by over 1500 per month.

Remember this cost is ONLY for the connector and not for the rest of the Logic App or any other connectors

Can I use APIM rather than a connector

If you are using APIM in your architecture then it can be beneficial to use APIM as a proxy to some services.  Calls to the APIM from Logic Apps would be HTTP based running from the Logic App node so there is no connector cost in this scenario.  Its the same as the built-in connectors.

In the above scenario if I use APIM as a proxy to Dataverse I can get some of the benefits of a friendly connector if I build my API proxy nicely but I remove the connector cost.

In this case remember there is a cost for API Management but if you already have that in your architecture it may be beneficial.

Ways Turbo360 can help

Cost Data Visualization

In Turbo360 the key challenge we would help you address is the visibility of cost for the connectors.

In my tree view of costs, within my integration team I could create a node scoped to just look at the costs for microsoft.web/connections.  This will give you a way to holistically look at your connector costs across your platform.

I then create a graph like below where I am looking at the cost per month for my connectors.  In the case below you can see that I have an increase in connector costs once I deployed a new Logic App solution which was using cloud connectors.

Next we are looking at comparing the costs for connectors across a period of time.  When I do a cost review I can use the table below to view how much each connector cost this month vs last month.  I can then look for changes and which connectors may be used more than expected.

I can also do a graph comparing my costs by dimensions such as resource group. environment, etc.  This lets me look for pattern changes.

With the visualization of this cost data I am looking to understand how my Logic Apps are using the connectors and the impact on cost.  Maybe there are opportunities to optimize my workflows to use the connectors in a way that would reduce costs.

Monitoring

Next I can setup monitoring for my costs just for the Logic App connectors.  In this case I have a tree node looking at all of my connector costs so I have a budget monitor below which I have configured a daily budget for my overall costs for connectors.  If I hit the budget then I will get alerted.

I can also use the anomaly detection feature which will track my connector costs and if something changes in a significant way then I will get an alert to tell me.

Identify Unused Connections

The Turbo360 other recommendations feature will help you identify connections that you may no longer be using so you can clean them up.  This will reduce the amount of technical debt in your environment to lower your total cost of ownership.