Pricing model for Azure Logic Apps
Azure Logic Apps helps you create and run automated integration workflows that can scale in the cloud. This article describes how billing and pricing work for Azure Logic Apps. For pricing rates, see Logic Apps Pricing.
Consumption pricing model
For new logic apps that run in the public or "global" Azure 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, each step is an action, and Azure Logic Apps meters all the actions that run in your logic app.
For example, actions include:
- Triggers, which are special actions. All logic apps require a trigger as the first step.
- "Built-in" or native actions such as HTTP, calls to Azure Functions and API Management, and so on
- Calls to managed connectors such as Outlook 365, Dropbox, and so on
- Control flow steps, such as loops, conditional statements, and so on
Standard connectors are charged at the Standard connector price. Generally available Enterprise connectors are charged at the Enterprise connector price, while public preview Enterprise connectors are charged at the Standard connector price.
Fixed pricing model
An integration service environment (ISE) provides an isolated way for you to create and run logic apps that can access resources in an Azure virtual network. For new logic apps that run inside an ISE, you pay a fixed monthly price for these capabilities:
Built-in triggers and actions
Within an ISE, built-in triggers and actions display the Core label and run in the same ISE as your logic apps.
Standard and Enterprise connectors that display the ISE label run in the same ISE as your logic apps. Connectors that don't display the ISE label run in the global Logic Apps service. Fixed monthly pricing also applies to connectors that run in the global service when you use them with logic apps that run in an ISE.
Premium SKU: A single Standard tier integration account
Developer SKU: A single Free tier integration account
Each ISE SKU is limited to 5 total integration accounts. For an additional cost, you can have more integration accounts, based on your ISE SKU:
Premium SKU: Up to four more Standard accounts. No Free or Basic accounts.
Developer SKU: Either up to 4 more Standard accounts, or up to 5 total Standard accounts. No Basic accounts.
If you choose the Premium ISE SKU, the base unit has fixed capacity. If you need more throughput, you can add more scale units, either during creation or afterwards. The Developer ISE SKU doesn't have the capability to add more scale units. Logic apps that run in an ISE don't incur data retention costs.
For pricing rates, see Logic Apps pricing.
Azure Logic Apps connectors help your logic app access apps, services, and systems in the cloud or on premises by providing triggers, actions, or both. Connectors are classified as either Standard or Enterprise. For an overview about these connectors, see Connectors for Azure Logic Apps. If no prebuilt connectors are available for the REST APIs that you want to use in your logic apps, you can create custom connectors, which are just wrappers around those REST APIs. Custom connectors are billed as Standard connectors. The following sections provide more information about how billing for triggers and actions work.
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. Here are the various kinds of triggers that exist in Azure Logic Apps:
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.
Azure Logic Apps meters "built-in" actions, such as HTTP, as native actions. For example, built-in actions include HTTP calls, calls from Azure Functions or API Management, and control flow steps such as conditions, loops, and switch statements. Each action has their own action type. For example, 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.
Azure Logic Apps meters all successful and unsuccessful actions as executions. However, 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
For actions that run inside loops, Azure Logic Apps counts each action for each 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. So, the calculation for a 10-item list is (10 * 1) + 1, which results in 11 action executions.
Disabled logic apps
Disabled logic apps aren't charged because they can't create new instances while they're disabled. After you disable a logic app, any currently running instances might take some time before they completely stop.
A fixed pricing model applies to integration accounts where you can explore, develop, and test the B2B and EDI and XML processing features in Azure Logic Apps at no additional cost. Each Azure subscription can have up to a specific limit of integration accounts. Each integration account can store up to specific limit of artifacts, which include trading partners, agreements, maps, schemas, assemblies, certificates, batch configurations, and so on.
Azure Logic Apps offers Free, Basic, and Standard integration accounts. The Basic and Standard tiers are supported by the Logic Apps service-level agreement (SLA), while the Free tier is not supported by an SLA and has limits on throughput and usage. Except for Free tier integration accounts, you can have more than one integration account in each Azure region. For pricing rates, see Logic Apps pricing.
If you have an integration service environment (ISE), either Premium or Developer, your ISE can have 5 total integration accounts. To learn how the fixed pricing model works for an ISE, see the previous Fixed pricing model section in this topic. For pricing rates, see Logic Apps pricing.
To choose between a Free, Basic, or Standard integration account, review these use case descriptions:
Free: For when you want to try exploratory scenarios, not production scenarios
Basic: For when you want only message handling or to act as a small business partner that has a trading partner relationship with a larger business entity
Standard: For when you have more complex B2B relationships and increased numbers of entities that you must manage
Except for logic apps that run in an integration service environment (ISE), all the inputs and outputs that are stored in your logic app's run history get billed based on a logic app's run retention period. Logic apps that run in an ISE don't incur data retention costs. For pricing rates, see Logic Apps pricing.
To help you monitor your logic app's storage consumption, you can:
- View the number of storage units in GB that your logic app uses monthly.
- View the sizes for a specific action's inputs and outputs in your logic app's run history.
View logic app storage consumption
In the Azure portal, find and open your logic app.
From your logic app's menu, under Monitoring, select Metrics.
In the right-hand pane, under Chart Title, from the Metric list, select Billing Usage for Storage Consumption Executions.
This metric gives you the number of storage consumption units in GB per month that are getting billed.
View action input and output sizes
In the Azure portal, find and open your logic app.
On your logic app's menu, select Overview.
In the right-hand pane, under Runs history, select the run that has the inputs and outputs you want to check.
Under Logic app run, choose Run Details.
In the Logic app run details pane, in the actions table, which lists each action's status and duration, select the action you want to view.
In the Logic app action pane, find the sizes for that action's inputs and outputs appear respectively under Inputs link and Outputs link.