Peter in the Azure sky

Last year I wrote a post where I illustrated that the costs of the Azure Logic Apps could in some cases may get far too high, especially if the trigger was based on scheduled polling intervals (you can read it here if you are interested). In it I illustrated that even for a single integration scenario using Logic Apps could be a costly integration component compared to other Azure and on premise solutions at the time. I also claimed that you would get punished for making the Logic Apps well-structured with many steps (read actions) compared to just having one big step that did all your logic (in for example code). I was also convinced that Microsoft would adjust the pricing to make it more fair going ahead.

This post will re-evaluate those theories and see what has happened during the last year with the Logic App pricing. Are there still things you need to be carefull of in 2018 regarding Azure Logic App usage and point out some alternate solution if there are any.

What is still the same and recap from old post?

The chargeable unit of the Logic App is still the action executions. The simplest way of describing this is any step that is run in the logic app. It is important to understand that:

• triggering a Logic app to look for messages in an empty service bus queue or database will still count as an executable action.
• Any step (send SMS,  call to azure function, database lookup etc) in the logic app that is actually run is also counted

What is not charged:

• any (non-polling) action that is not run due to that for example the queue was empty or there was a condition that prevented the action from being run will not count

As a consequence you could claim that you are still “punished” for the number of steps you have in your Logic Apps and how often you poll a queue as a Logic App with 20 steps will cost you more that a Logic App with 2 steps.

Pricing 2017 vs 2018

Pricing 2017

If we look at the pricing of Logic Apps in 2017 the action execution was a non-linear step pricing equation. The more actions you executed would lower the cost. For low usage you paid a higher price per execution and if you executed a lot of steps the cost would decrease in steps.

Actions executed/month	List Price (as of 2017-Feb-16 North Europe)
First 250 000 actions	€0,0007/action
250 000–1 million actions	€0,0003/action
1 million –50 million actions	€0,00013/action
50 million –100 million actions	€0,00008/action
100 million + actions	€0,000046/action

Pricing 2018

Pricing 2018 is not all that simple to compare. Because there are now different types of actions/connectors and executing them does not cost the same amount of money.

Instead they are divided into four tiers:

• Built-in connectors: Such as calling HTTP endpoints, calling Azure Functions, and Azure API Management operations as well as data manipulating actions. These actions will count as a normal action execution.
• Standard Connectors: Here lies a majority of the connectors to services such as Azure Service Bus, Office 365, Dynamics and SQL server
• Enterprise Connectors: Such as SAP connector and MQ connector.
• Integration Account Connectors: Which you get when you set up an integration account (see here)

So depending on if your action is a built-in connector or if you access an SQL database if will cost a different sum for the action.

Actions executed/month	List Price (as of 2018-March-17 North Europe)
Action executions	€0.000022/action
Standard Connector	€0.000106/action
Enterprise Connector	€0.000844/action

You can also see that the cost is completely linear and you wont be granted a discount anymore for higher payloads.

My interpretation of this is that for a database call you would be changed both for action execution and the standard connector  (i.e. 0.000022 + 0.000106 in the example above). I’ll try to get that confirmed by Microsoft.

Price Development 2017 to 2018

It is like I stated above difficult to compare the prices but I will try to anyway.

The below table shows the cost for single action execution under certain condition

Action/ Connector Type	Actions executed /month	2017 List Price* (North Europe)	2018 List Price** (North Europe)	2017 to 2018 Diff	2018 compared to 2017
Built-in action	First 250 000	€0.0007 /action	€0.000022 /action	-€0.000678 /action	~3% of 2017 price
Standard Connector	First 250 000	€0.0007 /action	€0.000128 /action	-€0.000572 /action	~18% of 2017 price
Built-in action	250 000-1 000 000	€0.0003 /action	€0.000022 /action	-€0.000278 /action	~7% of 2017 price
Standard Connector	250 000-1 000 000	€0.0003 /action	€0.000128 /action	-€0,000172 /action	~43% of 2017 price
Built-in action	1 million –50 million	€0.00013 /action	€0.000022 /action	-€0,000108 /action	~17% of 2017 price
Standard Connector	1 million –50 million	€0.00013 /action	€0.000128 /action	-€0,000002 /action	~98% of 2017 price
Built-in action	50 million –100 million	€0.00008 /action	€0.000022 /action	-€0.000058 /action	~27% of 2017 price
Standard Connector	50 million –100 million	€0.00008 /action	€0.000128 /action	+0,000048 /action	~160% of 2017 price
Built-in action	100 million+	€0.000046 /action	€0.000022 /action	-€0,000024 /action	~48% of 2017 price
Standard Connector	100 million+	€0.000046 /action	€0.000128 /action	+0,000082 /action	~278% of 2017 price

 Conclusion Price Development 2017 to 2018

As I predicted last year Microsoft has significantly lowered the cost for action executions for the low usage to medium usage scenario. For Logic Apps that are triggered extremely often, includes many standard connectors or Enterprise connectors you may, however unlikely, have a slightly more expensive setup. But for most scenarios the costs are significantly lower in March 2018 compared to February 2017. The actual savings are depending on what type of actions/connectors are used.

A quick comparison. In the below graphics I have two different data series for 2018. One assuming that 50% of your actions are using standard connectors and one assuming 25 % of the action executions are using standard connectors (***). But your Logic App may of course differ a lot from this scenario.

You see that for both these scenarios – the cost are lower. Even the 50% standard connector example will be cheaper up to about 200 000 000 action executions. But what the above diagram fails to show is how much the costs have been reduced for the low to medium usage Logic App. So I will present one more diagram.

From the above graph you can see that for a logic app with 250 000 action executions (using equal amount of built-in and standard connectors) will be €18 now compared to €175 just a year ago.

The graphs show a very interesting reduction in cost, could it be that my recommendations and warnings from last years post are now invalid?

Lets try the same scenarios as I used last year to validate it….

Rerun of scenarios from previous post

Basic Scenario, we poll a service bus queue. This will use a standard connector to access the service bus.

Standard connector action execution cost: (i.e. action execution €0.000022 + standard connector €0.000106) = €0.000128

Scenario 1: For the basic scenario above where I will look for messages each 15th second but will never receive any messages in a service bus queue – this will equate to 172 800 executions/month.

2018: 172 800 * €0.000128 = €22/month. This is a great reduction compared to last year.

(2017: 172 800 *  €0,0007 = € 121/month.  That is a fairly high amount for nothing.)

Scenario 2: If we tweak the first scenario a little bit. Why should we check for messages this often if we don’t expect to get any messages? So if we would change the polling interval to every tenth minute the cost would be: (6 times per hour * 24 hours * 30 days) = 4 320 Actions

2018: 4 300 * €0.000128 = € 0.55. A ridiculously low sum.

(2017: 4 320 * €,0007 = €3 which is a really low figure even for nothing.)

Scenario 3: we design a logic app that

• will receive 100 000 messages on a service bus per month,
• they must be processed as soon as possible,
• it will parse the message from JSON body to a JSON schemed message,
• save it to a database with action set to ‘start’,
• fetch some information from a web service using parameters from the SB message,
• depending if the value is above a certain value  it should (that will occur half of the executions on average)
  • will email the manager and
  • send a SMS message
• update the previous row in the database with action set to ‘done’

Queue polling: Every 10 seconds (6 times per minute * 60 minutes * 24 Hours * 30 Days) = 259 200 Actions all using standard connector.

Actions for single message: Parse Json + initial save to the database, call web service, 0.5 emails, 0.5 SMS, Update database) = 5 Actions on average per message.

Assume that only web service call and JSON parse are built-in connectors (in reality you could, if desired, solve this scenario with fewer standard connectors using other technologies). But anyway, in this scenario, of the 5 actions, two are built-in and three are standard connectors.

Cost	Calculation	Actions
Polling actions	Every 10 seconds (6 times per minute * 60 minutes * 24 Hours * 30 Days)	259 200 Actions using standard connctor
Actions for single msg	Parse Json + initial save to the database, call web service, 0.5 emails, 0.5 SMS, Update database) = 5 Actions on average per message. 2 Built-in and 3 using standard connectors
Built-in actions for messages total	100 000 messages * 2 actions (row above)	200 000 Built-in Actions
Standard connector actions for messages total	100 000 messages * 3 actions (row above)	300 000 Standard connector actions

2018: Polling: 259 200 * 0,000128 = €33. Built-in Action executions: 200 000 * €0.000022 = €4. Standard connector actions: 300 000 * €0.000128 = €38. This summarizes to €75/month and €900 for a year.

(2017: This adds up in 759 200 actions/month and a total sum of: (250 000 actions * €0,0007/action) + (509 200 actions * €0,0003/action) = €175 + €152 = € 327 /month for a single integration. Looked on a yearly basis € 3 924 this integration alone.)

Conclusions

Logic Apps are less likely to bust the bank for your scenario in 2018 compared to 2017. Your main factor to watch out for is nowadays if you have several Logic Apps with many actions (where you utilize many non-built-in connectors) or if your Logic App is set up with frequent execution or polling.

It is clear that other integration options may still be a cheaper option in some scenarios.

The more steps you have the more it will cost. However if most of these are built-in you likely need not worry. And as Azure functions today are counted as built-in you could use these to a high extent and avoid standard connectors. Note that in Scenario 3, the most costly version, you could see if you could get away cheaper by having replacing the email step with a Azure Function with SendGrid binding as well as having Twilio binding function for SMSes. Azure functions are however not free either and you have to take Azure function cost into account also and compare it to the standard connector cost before selecting one or the other.

You could reduce polling costs by using other techniques and triggering the Logic App from an external source like a webjob, function or similar and only calling the logic app when it should actually run.

Another alternative for your integrations may be utilizing the Azure Event Grid which in some scenarios may be cheaper and can fulfill some of your integration needs. It also works nicely with functions and Logic Apps.

You could also go more traditional and use webjobs to have a more static cost, a Web Job (unless auto-scale) may have some issues processing timely but costs will be predictable to a larger extent than Logic Apps, functions and Event Grid. Logic Apps can’t reuse processing capacity between Logic Apps like you can with Web Jobs by having multiple in the same app service plan. Each Logic App will be charged individually and many integrations with Logic apps will generate costs separately and combined the cost could still become high.

The main conclusions are however:

• Logic Apps are much more price worthy now in 2018 than 2017. It is a suitable integration solution in many more scenarios now than just a year ago.
• You must however do your own math still to see if your Logic App(s) will be the most efficient performance and cost for your needs.