Pricing model for Azure Logic Apps
You can create and run automated integration workflows that can scale in the cloud when you use Azure Logic Apps. Here are the details about how billing and pricing work for Logic Apps.
Consumption pricing model
For new logic apps that run in the public or "global" Logic
Apps service, you pay only for what you use. These logic apps
use a consumption-based plan and pricing model. In your logic app
definition, each step is an action. Actions include the trigger,
any control flow steps, built-in actions, and connector calls.
Logic Apps meters all actions that run in your logic app.
For more information, see Logic Apps Pricing.
Fixed pricing model
For new logic apps that run inside an integration service environment (ISE), you pay a fixed monthly price for built-in actions and standard connectors. An ISE provides a way for you to create and run isolated logic apps that can access resources in an Azure virtual network.
Your ISE base unit has fixed capacity, so if you need more throughput, you can add more scale units, either during creation or afterwards. Your ISE includes one free Enterprise connector, which includes as many connections as you want. Usage for additional Enterprise connectors are charged based on the Enterprise consumption price.
Triggers are special actions that create a logic app instance when a specific event happens. Triggers act in different ways, which affect how the logic app is metered.
Polling trigger – This trigger continually checks an endpoint for messages that satisfy the criteria for creating a logic app instance and starting the workflow. Even when no logic app instance gets created, Logic Apps meters each polling request as an execution. To specify the polling interval, set up the trigger through the Logic App Designer.
To estimate more accurate consumption costs, consider the possible number of messages or events that might arrive on any given day, rather than base your calculations on only the polling interval. When an event or message meets the trigger criteria, many triggers immediately try to read any and all other waiting events or messages that meet the criteria. This behavior means that even when you select a longer polling interval, the trigger fires based on the number of waiting events or messages that qualify for starting workflows. Triggers that follow this behavior include Azure Service Bus and Azure Event Hub.
So, for example, suppose you set up trigger that checks an endpoint every day. When the trigger checks the endpoint and finds 15 events that meet the criteria, the trigger fires and runs the corresponding workflow 15 times. Logic Apps meters all the actions that those 15 workflows perform, including the trigger requests. To calculate your potential costs, try the Azure pricing calculator.
Webhook trigger – This trigger waits for a client to send a request to a specific endpoint. Each request sent to the webhook endpoint counts as an action execution. For example, the Request and HTTP Webhook trigger are both webhook triggers.
Recurrence trigger – This trigger creates a logic app instance based on the recurrence interval that you set up in the trigger. For example, you can set up a recurrence trigger that runs every three days or on a more complex schedule.
Logic Apps meters built-in actions as native actions. For example, built-in actions include calls over HTTP, calls from Azure Functions or API Management, and control flow steps such as loops and conditions
- each with their own action type. Actions that call connectors have the "ApiConnection" type. These connectors are classified as standard or enterprise connectors, which are metered based on their respective pricing. Enterprise connectors in Preview are charged as standard connectors.
Logic Apps meters all successfully and unsuccessfully run actions as action executions. Logic Apps doesn't meter these actions:
- Actions that get skipped due to unmet conditions
- Actions that don't run because the logic app stopped before finishing
Disabled logic apps aren't charged while disabled because they can't create new instances.
After you disable a logic app, any currently running instances might take some time before they completely stop.
For actions that run inside loops, Logic Apps counts each action per cycle in the loop. For example, suppose you have a "for each" loop that processes a list. Logic Apps meters an action in that loop by multiplying the number of list items with the number of actions in the loop, and adds the action that starts the loop. The calculation for a 10-item list is (10 * 1) + 1, which results in 11 action executions.
Integration Account usage
Consumption-based usage applies to integration accounts where you can explore, develop, and test the B2B/EDI and XML processing features in Logic Apps at no additional cost. You can have one integration account per region. Each integration account can store up to specific numbers of artifacts, which include trading partners, agreements, maps, schemas, assemblies, certificates, batch configurations, and so on.
Logic Apps also offers basic and standard integration accounts with supported Logic Apps SLA. You can use basic integration accounts when you just want message handling or act as a small business partner that has a trading partner relationship with a larger business entity. Standard integration accounts support more complex B2B relationships and increase the number of entities you can manage. For more information, see Azure pricing.
We'd love to hear your thoughts. Choose the type you'd like to provide:
Our feedback system is built on GitHub Issues. Read more on our blog.