In this article, I will discuss on Azure Logic Apps pricing. We will break down the mechanics of both plans, explore the hidden cost drivers, look at the financial break-even points, and establish a framework to help you optimize every single dollar of your cloud integration budget.
Table of Contents
- Azure Logic Apps Pricing
- Final Recommendations.
Azure Logic Apps Pricing
The Core Concept
Before looking at the exact monetary figures, you must understand that Microsoft divides Azure Logic Apps into two distinct architectural tiers. When you spin up a new Logic App resource in the Azure Portal, this is the very first fork in the road.
- The Consumption Plan (Multi-Tenant / Pay-Per-Execution): This is a purely serverless, consumption-driven model. You do not pay anything if your workflow is sitting idle. Instead, Azure tracks every single individual step (action) your workflow takes and bills you fractions of a cent per execution.
- The Standard Plan (Single-Tenant / Compute-Based Hosting): Built on top of the containerized Azure Functions extensibility runtime, this model charges you a fixed hourly rate for dedicated compute resources (vCPU and memory), much like a traditional virtual machine or App Service Plan. Within that allocated compute, you can run as many built-in operations as you want for free.
Let’s dissect exactly how the meters run for each of these options.
Deep Dive: The Consumption Plan Pricing Breakdown
The Consumption plan is the classic serverless offering. It is highly appealing for lightweight workloads or unpredictable traffic patterns because your baseline infrastructure cost is exactly $0. However, “serverless” does not mean “free.”
In the Consumption model, Azure bills you based on three distinct elements: Actions, Triggers, and Connectors.
Built-in Actions and Triggers
Every card in your visual designer canvas is an operation. Whether it is a condition (If/Else), a loop (For Each), an initialization of a variable, or an HTTP request card, it is counted as a built-in action.
- The Meter: Azure charges a flat fee of $0.000025 per execution for built-in actions and triggers.
- The Catch with Triggers: If you configure a polling trigger to check an external folder every 30 seconds, that trigger executes 2,880 times a day. Even if it finds absolutely zero files to process, you are billed for those execution attempts.
Managed Connectors (Standard vs. Enterprise)
When your workflow leaves the native Azure ecosystem to talk to external systems or enterprise software, it uses Managed Connectors. Microsoft splits these into two pricing tiers:
- Standard Connectors: These include everyday integrations like Office 365, SharePoint, Azure Blob Storage, Salesforce, and Google Sheets. They cost $0.000125 per call.
- Enterprise Connectors: These are heavy-duty, highly specialized corporate integrations, such as SAP, IBM MQ, Oracle Database, and B2B EDI features. They cost a significantly higher $0.001 per call.
Data Retention Costs
The Consumption plan stores your execution history automatically so you can audit past failures. Azure charges a storage fee of $0.12 per GB per month for retaining this metadata beyond the default limits.
Here is a quick-reference table summarizing the multi-tenant Consumption plan rates (based on typical East US region pricing):
| Metered Operation Type | Description / Examples | Price Per Execution / Call |
| Built-in Action / Trigger | Loops, Conditions, Variables, HTTP requests | $0.000025 |
| Standard Connector | Office 365, SharePoint, SQL Server, Slack | $0.000125 |
| Enterprise Connector | SAP, IBM MQ, B2B EDI, Oracle | $0.001000 |
| Data Retention | Storing execution run history metadata | $0.12 per GB / month |
Deep Dive: The Standard Plan Pricing Breakdown
If you are designing integrations for a mid-market or enterprise-level organization, the Standard plan is likely where you will land. Instead of billing you fractions of a cent for every loop iteration, Microsoft charges a predictable fee based on a Workflow Service Plan.
Dedicated Compute Tiers
When you provision a Standard Logic App, you select a dedicated compute size. You pay for this compute continuous-time, whether it runs one workflow or ten thousand. The standard tiers are structured as follows:
- WS1 Plan: 1 vCPU, 3.5 GB Memory (~$140 to $145 per month)
- WS2 Plan: 2 vCPUs, 7 GB Memory (~$280 to $290 per month)
- WS3 Plan: 4 vCPUs, 14 GB Memory (~$560 to $580 per month)
The Massive Financial Loophole: Free Built-in Operations
Here is the most critical difference: In the Standard Plan, all built-in actions, loops, variables, and built-in triggers are 100% free and unlimited.
Because the runtime executes locally within your dedicated vCPU and memory allocation, you are no longer penalized for processing a file with a loop containing 50,000 rows. A workflow that would cost thousands of dollars on the Consumption plan due to high loop iteration counts will cost you exactly nothing extra on a WS1 compute tier.
Managed Connectors in Standard Tiers
Do not assume everything is covered under the flat monthly compute rate. If your Standard Logic App leverages Managed Connectors (the cloud-hosted connectors managed by Microsoft), those are still routed outside your local runtime and are billed at the exact same per-call rates as the Consumption plan:
- Standard Managed Connector: $0.000125 per call
- Enterprise Managed Connector: $0.001 per call
Note: If you use the built-in versions of these connectors (such as the native built-in SQL, Azure Service Bus, or HTTP operations), they run locally on your compute tier and incur no extra per-call charges.
The Hidden Cost Multiplier: Integration Accounts
If your business relies heavily on supply chain automation, corporate logistics, or electronic data interchange (EDI), you will inevitably come across Integration Accounts. This is a separate Azure resource used to store XML schemas, X12/EDIFACT maps, and trading partner agreements.
For Consumption-based workflows, adding an Integration Account introduces a massive, fixed monthly baseline cost that completely disrupts the serverless “pay-only-for-what-you-use” model.
| Integration Account Tier | Ideal Use Case | Approximate Cost per Hour | Approximate Cost per Month |
| Basic Tier | Light XML parsing, limited schemas and maps | $0.42 / hour | ~$300 / month |
| Standard Tier | Full-scale corporate B2B trading environments | $1.37 / hour | ~$1,000 / month |
The Standard Plan Advantage for B2B
One major financial advantage of the Standard Plan that many architects overlook is its native support for schemas and maps. On the Standard Plan, you can upload your XML schemas and liquid maps directly into the workflow app assembly without buying an external Integration Account, instantly wiping out a $300 to $1,000 monthly hidden fee.
The Break-Even Analysis: When to Switch from Consumption to Standard
Choosing between these two models should not be a matter of guesswork. It is a mathematical equation based on volume.
Let us look at the economic break-even point. A standard WS1 plan costs roughly $145 per month for base compute. If we look strictly at built-in actions on the Consumption plan ($0.000025 per action), we can calculate the exact pivot point:
$$\text{Break-even point} = \frac{\$145}{\$0.000025} = 5,800,000 \text{ actions per month}$$
This translates to roughly 193,333 individual action executions per day.
- If your collective workflows execute fewer than 5.8 million steps per month, the Consumption plan is highly cost-effective.
- If your collective workflows execute more than 5.8 million steps per month, the Standard plan immediately becomes cheaper, and its cost advantage increases alongside your data volume.
Strategic Cost Optimization Framework
To keep your Azure integration spend highly optimized, I recommend implementing the following structural guidelines across your engineering organization:
- Avoid Tight Polling Windows on Consumption: If a workflow only needs to process data once a day, do not set a polling trigger to run every 10 seconds. You will generate hundreds of thousands of empty, billable trigger executions. Use push-based webhooks or EventGrid triggers instead.
- Consolidate Workflows in Standard Plans: The Standard Plan allows you to host multiple distinct workflows within a single compute instance. If you have 10 high-volume workflows, do not create 10 separate Standard Logic Apps. House them inside a single Standard app resource to fully saturate your allocated WS1 or WS2 vCPUs.
- Leverage Stateless Workflows: When using the Standard plan, you can mark workflows as Stateless. Stateless workflows do not write execution data to external storage tables, which vastly improves performance and removes the minor costs associated with Azure Storage transaction I/O.
- Clean Up Arrays Before Looping: If you must loop through data on a Consumption plan, filter your arrays using the built-in “Filter Array” data operation card before passing them into a
For Eachloop. Cutting a 1,000-item array down to 50 relevant items before looping will save you 950 billable loop executions.
Final Recommendations.
If you are a startup launching a pilot program or building minor automated alerts that fire a few dozen times a day, run the Consumption plan. It will cost you pennies, and you will never have to worry about paying for idle resources.
However, if you are architecting a mission-critical enterprise middleware layer, handling heavy batch data processing, or requiring tight network isolation inside a private corporate VNet, deploy the Standard plan. By decoupling your financial liability from execution counts, you gain total budget predictability, enhanced compute performance, and a clear architectural path toward long-term cloud scalability.
You may also like the following articles:

I am Rajkishore, and I am a Microsoft Certified IT Consultant. I have over 14 years of experience in Microsoft Azure and AWS, with good experience in Azure Functions, Storage, Virtual Machines, Logic Apps, PowerShell Commands, CLI Commands, Machine Learning, AI, Azure Cognitive Services, DevOps, etc. Not only that, I do have good real-time experience in designing and developing cloud-native data integrations on Azure or AWS, etc. I hope you will learn from these practical Azure tutorials. Read more.
