Single-tenant versus multi-tenant and integration service environment for Azure Logic Apps
Azure Logic Apps is a cloud-based platform for creating and running automated logic app workflows that integrate your apps, data, services, and systems. With this platform, you can quickly develop highly scalable integration solutions for your enterprise and business-to-business (B2B) scenarios. To create a logic app, you use either the Logic App (Consumption) resource type or the Logic App (Standard) resource type. The Consumption resource type runs in the multi-tenant Azure Logic Apps or integration service environment, while the Standard resource type runs in single-tenant Azure Logic Apps environment.
Before you choose which resource type to use, review this article to learn how the resources types and service environments compare to each other. You can then decide which type is best to use, based on your scenario's needs, solution requirements, and the environment where you want to deploy, host, and run your workflows.
If you're new to Azure Logic Apps, review the following documentation:
Resource types and environments
To create logic app workflows, you choose the Logic App resource type based on your scenario, solution requirements, the capabilities that you want, and the environment where you want to run your workflows.
The following table briefly summarizes differences between the Logic App (Standard) resource type and the Logic App (Consumption) resource type. You'll also learn how the single-tenant environment compares to the multi-tenant and integration service environment (ISE) for deploying, hosting, and running your logic app workflows.
|Resource type||Benefits||Resource sharing and usage||Pricing and billing model||Limits management|
|Logic App (Consumption)
Host environment: Multi-tenant Azure Logic Apps
|- Easiest to get started
- Fully managed
|A single logic app can have only one workflow.
Logic apps created by customers across multiple tenants share the same processing (compute), storage, network, and so on.
|Consumption (pay-per-execution)||Azure Logic Apps manages the default values for these limits, but you can change some of these values, if that option exists for a specific limit.|
|Logic App (Standard)
Note: If your scenario requires containers, create single-tenant based logic apps using Azure Arc enabled Logic Apps. For more information, review What is Azure Arc enabled Logic Apps?
|- Run most anywhere that Azure Functions can run using the single-tenant Azure Logic Apps runtime. Deployment slots are currently not supported.
- More built-in connectors for higher throughput and lower costs at scale
- More control and fine-tuning capability around runtime and performance settings
- Integrated support for virtual networks and private endpoints.
- Create your own built-in connectors.
|A single logic app can have multiple stateful and stateless workflows.
Workflows in a single logic app and tenant share the same processing (compute), storage, network, and so on.
|Standard, based on a hosting plan with a selected pricing tier||You can change the default values for many limits, based on your scenario's needs.
Important: Some limits have hard upper maximums. In Visual Studio Code, the changes you make to the default limit values in your logic app project configuration files won't appear in the designer experience. For more information, see Edit app and environment settings for logic apps in single-tenant Azure Logic Apps.
|Logic App (Consumption)
|- Enterprise scale for large workloads
- 20+ ISE-specific connectors that connect directly to virtual networks
- Predictable pricing with included usage and customer-controlled scaling
|A single logic app can have only one workflow.
Logic apps in the same environment share the same processing (compute), storage, network, and so on.
|ISE (fixed)||Azure Logic Apps manages the default values for these limits, but you can change some of these values, if that option exists for a specific limit.|
Logic App (Standard) resource
The Logic App (Standard) resource type is powered by the redesigned single-tenant Azure Logic Apps runtime. This runtime uses the Azure Functions extensibility model and is hosted as an extension on the Azure Functions runtime. This design provides portability, flexibility, and more performance for your logic app workflows plus other capabilities and benefits inherited from the Azure Functions platform and Azure App Service ecosystem.
For example, you can run single-tenant based logic apps and their workflows anywhere that Azure function apps and their functions can run. The Standard resource type introduces a resource structure that can host multiple workflows, similar to how an Azure function app can host multiple functions. With a 1-to-many mapping, workflows in the same logic app and tenant share compute and processing resources, providing better performance due to their proximity. This structure differs from the Logic App (Consumption) resource where you have a 1-to-1 mapping between a logic app resource and a workflow.
To learn more about portability, flexibility, and performance improvements, continue with the following sections. Or, for more information about the single-tenant Azure Logic Apps runtime and Azure Functions extensibility, review the following documentation:
- Azure Logic Apps Running Anywhere - Runtime Deep Dive
- Introduction to Azure Functions
- Azure Functions triggers and bindings
Portability and flexibility
When you create logic apps using the Logic App (Standard) resource type, you can run your workflows anywhere that you can run Azure function apps and their functions, not just in the single-tenant service environment.
For example, when you use Visual Studio Code with the Azure Logic Apps (Standard) extension, you can locally develop, build, and run your workflows in your development environment without having to deploy to Azure. If your scenario requires containers, create single-tenant based logic apps using Azure Arc-enabled Logic Apps. For more information, review What is Azure Arc enabled Logic Apps?
These capabilities provide major improvements and substantial benefits compared to the multi-tenant model, which requires you to develop against an existing running resource in Azure. Also, the multi-tenant model for automating Logic App (Consumption) resource deployment is completely based on Azure Resource Manager templates (ARM templates), which combine and handle resource provisioning for both apps and infrastructure.
With the Logic App (Standard) resource type, deployment becomes easier because you can separate app deployment from infrastructure deployment. You can package the single-tenant Azure Logic Apps runtime and workflows together as part of your logic app. You can use generic steps or tasks that build, assemble, and zip your logic app resources into ready-to-deploy artifacts. To deploy your infrastructure, you can still use ARM templates to separately provision those resources along with other processes and pipelines that you use for those purposes.
To deploy your app, copy the artifacts to the host environment and then start your apps to run your workflows. Or, integrate your artifacts into deployment pipelines using the tools and processes that you already know and use. That way, you can deploy using your own chosen tools, no matter the technology stack that you use for development.
By using standard build and deploy options, you can focus on app development separately from infrastructure deployment. As a result, you get a more generic project model where you can apply many similar or the same deployment options that you use for a generic app. You also benefit from a more consistent experience for building deployment pipelines around your app projects and for running the required tests and validations before publishing to production.
Using the Logic App (Standard) resource type, you can create and run multiple workflows in the same single logic app and tenant. With this 1-to-many mapping, these workflows share resources, such as compute, processing, storage, and network, providing better performance due to their proximity.
The Logic App (Standard) resource type and single-tenant Azure Logic Apps runtime provide another significant improvement by making the more popular managed connectors available as built-in operations. For example, you can use built-in operations for Azure Service Bus, Azure Event Hubs, SQL, and others. Meanwhile, the managed connector versions are still available and continue to work.
When you use the new built-in operations, you create connections called built-in connections or service provider connections. Their managed connection counterparts are called API connections, which are created and run separately as Azure resources that you also have to then deploy by using ARM templates. Built-in operations and their connections run locally in the same process that runs your workflows. Both are hosted on the single-tenant Azure Logic Apps runtime. As a result, built-in operations and their connections provide better performance due to proximity with your workflows. This design also works well with deployment pipelines because the service provider connections are packaged into the same build artifact.
Create, build, and deploy options
To create a logic app based on the environment that you want, you have multiple options, for example:
|Option||Resources and tools||More information|
|Azure portal||Logic App (Standard) resource type||Create integration workflows for single-tenant Logic Apps - Azure portal|
|Visual Studio Code||Azure Logic Apps (Standard) extension||Create integration workflows for single-tenant Logic Apps - Visual Studio Code|
|Azure CLI||Logic Apps Azure CLI extension||Not yet available|
|Option||Resources and tools||More information|
|Azure portal||Logic App (Consumption) resource type||Quickstart: Create integration workflows in multi-tenant Azure Logic Apps - Azure portal|
|Visual Studio Code||Azure Logic Apps (Consumption) extension||Quickstart: Create integration workflows in multi-tenant Azure Logic Apps - Visual Studio Code|
|Azure CLI||Logic Apps Azure CLI extension||- Quickstart: Create and manage integration workflows in multi-tenant Azure Logic Apps - Azure CLI
- az logic
|Azure Resource Manager||Create a logic app ARM template||Quickstart: Create and deploy integration workflows in multi-tenant Azure Logic Apps - ARM template|
|Azure PowerShell||Az.LogicApp module||Get started with Azure PowerShell|
|Azure REST API||Azure Logic Apps REST API||Get started with Azure REST API reference|
Integration service environment
|Option||Resources and tools||More information|
|Azure portal||Logic App (Consumption) resource type with an existing ISE resource||Same as Quickstart: Create integration workflows in multi-tenant Azure Logic Apps - Azure portal, but select an ISE, not a multi-tenant region.|
Although your development experiences differ based on whether you create Consumption or Standard logic app resources, you can find and access all your deployed logic apps under your Azure subscription.
For example, in the Azure portal, the Logic apps page shows both Consumption and Standard logic app resource types. In Visual Studio Code, deployed logic apps appear under your Azure subscription, but they are grouped by the extension that you used, namely Azure: Logic Apps (Consumption) and Azure: Logic Apps (Standard).
Stateful and stateless workflows
With the Logic App (Standard) resource type, you can create these workflow types within the same logic app:
Create a stateful workflow when you need to keep, review, or reference data from previous events. These workflows save and transfer all the inputs and outputs for each action and their states to external storage, which makes reviewing the run details and history possible after each run finishes. Stateful workflows provide high resiliency if outages happen. After services and systems are restored, you can reconstruct interrupted runs from the saved state and rerun the workflows to completion. Stateful workflows can continue running for much longer than stateless workflows.
By default, stateful workflows in both multi-tenant and single-tenant Azure Logic Apps run asynchronously. All HTTP-based actions follow the standard asynchronous operation pattern. This pattern specifies that after an HTTP action calls or sends a request to an endpoint, service, system, or API, the receiver immediately returns a "202 ACCEPTED" response. This code confirms that the receiver accepted the request but hasn't finished processing. The response can include a
locationheader that specifies the URI and a refresh ID that the caller can use to poll or check the status for the asynchronous request until the receiver stops processing and returns a "200 OK" success response or other non-202 response. However, the caller doesn't have to wait for the request to finish processing and can continue to run the next action. For more information, see Asynchronous microservice integration enforces microservice autonomy.
Create a stateless workflow when you don't need to keep, review, or reference data from previous events in external storage after each run finishes for later review. These workflows save all the inputs and outputs for each action and their states in memory only, not in external storage. As a result, stateless workflows have shorter runs that are typically less than 5 minutes, faster performance with quicker response times, higher throughput, and reduced running costs because the run details and history aren't saved in external storage. However, if outages happen, interrupted runs aren't automatically restored, so the caller needs to manually resubmit interrupted runs.
A stateless workflow provides the best performance when handling data or content, such as a file, that doesn't exceed 64 KB in total size. Larger content sizes, such as multiple large attachments, might significantly slow your workflow's performance or even cause your workflow to crash due to out-of-memory exceptions. If your workflow might have to handle larger content sizes, use a stateful workflow instead.
Stateless workflows only run synchronously, so they don't use the standard asynchronous operation pattern used by stateful workflows. Instead, all HTTP-based actions that return a "202 ACCEPTED" response proceed to the next step in the workflow execution. If the response includes a
locationheader, a stateless workflow won't poll the specified URI to check the status. To follow the standard asynchronous operation pattern, use a stateful workflow instead.
For easier debugging, you can enable run history for a stateless workflow, which has some impact on performance, and then disable the run history when you're done. For more information, see Create single-tenant based workflows in Visual Studio Code or Create single-tenant based workflows in the Azure portal.
Stateless workflows currently support only actions for managed connectors, which are deployed in Azure, and not triggers. To start your workflow, select either the built-in Request, Event Hubs, or Service Bus trigger. These triggers run natively in the Azure Logic Apps runtime. For more information about limited, unavailable, or unsupported triggers, actions, and connectors, see Changed, limited, unavailable, or unsupported capabilities.
Nested behavior differences between stateful and stateless workflows
You can make a workflow callable from other workflows that exist in the same Logic App (Standard) resource by using the Request trigger, HTTP Webhook trigger, or managed connector triggers that have the ApiConnectionWebhook type and can receive HTTPS requests.
Here are the behavior patterns that nested workflows can follow after a parent workflow calls a child workflow:
Asynchronous polling pattern
The parent doesn't wait for a response to their initial call, but continually checks the child's run history until the child finishes running. By default, stateful workflows follow this pattern, which is ideal for long-running child workflows that might exceed request timeout limits.
Synchronous pattern ("fire and forget")
The child acknowledges the call by immediately returning a
202 ACCEPTEDresponse, and the parent continues to the next action without waiting for the results from the child. Instead, the parent receives the results when the child finishes running. Child stateful workflows that don't include a Response action always follow the synchronous pattern. For child stateful workflows, the run history is available for you to review.
To enable this behavior, in the workflow's JSON definition, set the
DisableAsyncPattern. For more information, see Trigger and action types - Operation options.
Trigger and wait
For a child stateless workflow, the parent waits for a response that returns the results from the child. This pattern works similar to using the built-in HTTP trigger or action to call a child workflow. Child stateless workflows that don't include a Response action immediately return a
202 ACCEPTEDresponse, but the parent waits for the child to finish before continuing to the next action. These behaviors apply only to child stateless workflows.
This table specifies the child workflow's behavior based on whether the parent and child are stateful, stateless, or are mixed workflow types:
|Parent workflow||Child workflow||Child behavior|
|Stateful||Stateful||Asynchronous or synchronous with
|Stateful||Stateless||Trigger and wait|
|Stateless||Stateless||Trigger and wait|
Other single-tenant model capabilities
The single-tenant model and Logic App (Standard) resource type include many current and new capabilities, for example:
Create logic apps and their workflows from 400+ managed connectors for Software-as-a-Service (SaaS) and Platform-as-a-Service (PaaS) apps and services plus connectors for on-premises systems.
More managed connectors are now available as built-in operations and run similarly to other built-in operations, such as Azure Functions. Built-in operations run natively on the single-tenant Azure Logic Apps runtime. For example, new built-in operations include Azure Service Bus, Azure Event Hubs, SQL Server, MQ, DB2, and IBM Host File.
For the built-in SQL Server version, only the Execute Query action can directly connect to Azure virtual networks without using the on-premises data gateway.
You can create your own built-in connectors for any service that you need by using the single-tenant Azure Logic Apps extensibility framework. Similarly to built-in operations such as Azure Service Bus and SQL Server but unlike custom managed connectors, which aren't currently supported, custom built-in connectors provide higher throughput, low latency, and local connectivity because they run in the same process as the single-tenant runtime.
The authoring capability is currently available only in Visual Studio Code, but isn't enabled by default. To create these connectors, switch your project from extension bundle-based (Node.js) to NuGet package-based (.NET). For more information, see Azure Logic Apps Running Anywhere - Built-in connector extensibility.
You can use the following actions for Liquid Operations and XML Operations without an integration account. These operations include the following actions:
XML: Transform XML and XML Validation
Liquid: Transform JSON To JSON, Transform JSON To TEXT, Transform XML To JSON, and Transform XML To Text
To use these actions in single-tenant Azure Logic Apps (Standard), you need to have Liquid maps, XML maps, or XML schemas. You can upload these artifacts in the Azure portal from your logic app's resource menu, under Artifacts, which includes the Schemas and Maps sections. Or, you can add these artifacts to your Visual Studio Code project's Artifacts folder using the respective Maps and Schemas folders. You can then use these artifacts across multiple workflows within the same logic app resource.
Logic App (Standard) resources can run anywhere because Azure Logic Apps generates Shared Access Signature (SAS) connection strings that these logic apps can use for sending requests to the cloud connection runtime endpoint. Azure Logic Apps service saves these connection strings with other application settings so that you can easily store these values in Azure Key Vault when you deploy in Azure.
By default, the Logic App (Standard) resource type has the system-assigned managed identity automatically enabled to authenticate connections at run time. This identity differs from the authentication credentials or connection string that you use when you create a connection. If you disable this identity, connections won't work at run time. To view this setting, on your logic app's menu, under Settings, select Identity.
The user-assigned managed identity is currently unavailable on the Logic App (Standard) resource type.
You can locally run, test, and debug your logic apps and their workflows in the Visual Studio Code development environment.
Before you run and test your logic app, you can make debugging easier by adding and using breakpoints inside the workflow.json file for a workflow. However, breakpoints are supported only for actions at this time, not triggers. For more information, see Create single-tenant based workflows in Visual Studio Code.
Directly publish or deploy logic apps and their workflows from Visual Studio Code to various hosting environments such as Azure and Azure Arc enabled Logic Apps.
Enable diagnostics logging and tracing capabilities for your logic app by using Application Insights when supported by your Azure subscription and logic app settings.
Access networking capabilities, such as connect and integrate privately with Azure virtual networks, similar to Azure Functions when you create and deploy your logic apps using the Azure Functions Premium plan. For more information, review the following documentation:
Regenerate access keys for managed connections used by individual workflows in a Logic App (Standard) resource. For this task, follow the same steps for the Logic Apps (Consumption) resource but at the individual workflow level, not the logic app resource level.
Changed, limited, unavailable, or unsupported capabilities
For the Logic App (Standard) resource, these capabilities have changed, or they are currently limited, unavailable, or unsupported:
Triggers and actions: Built-in triggers and actions run natively in Azure Logic Apps, while managed connectors are hosted and run in Azure. Some built-in triggers and actions are unavailable, such as Sliding Window, Batch, Azure App Services, and Azure API Management. To start a stateful or stateless workflow, use the built-in Recurrence, Request, HTTP, HTTP Webhook, Event Hubs, or Service Bus trigger. In the designer, built-in triggers and actions appear under the Built-in tab.
For stateful workflows, managed connector triggers and actions appear under the Azure tab, except for the unavailable operations listed below. For stateless workflows, the Azure tab doesn't appear when you want to select a trigger. You can select only managed connector actions, not triggers. Although you can enable Azure-hosted managed connectors for stateless workflows, the designer doesn't show any managed connector triggers for you to add.
To run locally in Visual Studio Code, webhook-based triggers and actions require additional setup. For more information, see Create single-tenant based workflows in Visual Studio Code.
These triggers and actions have either changed or are currently limited, unsupported, or unavailable:
On-premises data gateway triggers are unavailable, but gateway actions are available.
The built-in action, Azure Functions - Choose an Azure function is now Azure Function Operations - Call an Azure function. This action currently works only for functions that are created from the HTTP Trigger template.
In the Azure portal, you can select an HTTP trigger function that you can access by creating a connection through the user experience. If you inspect the function action's JSON definition in code view or the workflow.json file using Visual Studio Code, the action refers to the function by using a
connectionNamereference. This version abstracts the function's information as a connection, which you can find in your logic app project's connections.json file, which is available after you create a connection in Visual Studio Code.
In the single-tenant model, the function action supports only query string authentication. Azure Logic Apps gets the default key from the function when making the connection, stores that key in your app's settings, and uses the key for authentication when calling the function.
As in the multi-tenant model, if you renew this key, for example, through the Azure Functions experience in the portal, the function action no longer works due to the invalid key. To fix this problem, you need to recreate the connection to the function that you want to call or update your app's settings with the new key.
The built-in action, Azure Logic Apps - Choose a Logic App workflow is now Workflow Operations - Invoke a workflow in this workflow app.
Some triggers and actions for integration accounts are unavailable, for example, the Flat File actions, AS2 (V2) actions, and RosettaNet actions.
Custom managed connectors currently aren't currently supported. However, you can create custom built-in operations when you use Visual Studio Code. For more information, review Create single-tenant based workflows using Visual Studio Code.
Authentication: The following authentication types are currently unavailable for the Logic App (Standard) resource type:
Azure Active Directory Open Authentication (Azure AD OAuth) for inbound calls to request-based triggers, such as the Request trigger and HTTP Webhook trigger.
User-assigned managed identity. Currently, only the system-assigned managed identity is available and automatically enabled.
XML transformation: Support for referencing assemblies from maps is currently unavailable. Also, only XSLT 1.0 is currently supported.
Breakpoint debugging in Visual Studio Code: Although you can add and use breakpoints inside the workflow.json file for a workflow, breakpoints are supported only for actions at this time, not triggers. For more information, see Create single-tenant based workflows in Visual Studio Code.
Trigger history and run history: For the Logic App (Standard) resource type, trigger history and run history in the Azure portal appears at the workflow level, not the logic app level. For more information, review Create single-tenant based workflows using the Azure portal.
Zoom control: The zoom control is currently unavailable on the designer.
Deployment targets: You can't deploy the Logic App (Standard) resource type to an integration service environment (ISE) nor to Azure deployment slots.
Azure API Management: You currently can't import the Logic App (Standard) resource type into Azure API Management. However, you can import the Logic App (Consumption) resource type.
Strict network and firewall traffic permissions
If your environment has strict network requirements or firewalls that limit traffic, you have to allow access for any trigger or action connections in your logic app workflows. To find the fully qualified domain names (FQDNs) for these connections, review the corresponding sections in these topics:
- Firewall permissions for single tenant logic apps - Visual Studio Code
- Firewall permissions for single tenant logic apps - Azure portal
- Create single-tenant based workflows in the Azure portal
- Create single-tenant based workflows in Visual Studio Code
We'd also like to hear about your experiences with single-tenant Azure Logic Apps!