Yesterday I wrote a post describing a “disaster” occurred to a customer working with Azure Functions and sharing the same storage account across different function apps.
After this post, a natural question (that also someone of you raised on socials as comment to that post) is: and what about Azure Logic Apps? So, this post is a “follow-up” of the previous one (I will not be too long here).
Like in Azure Functions, storage accounts are fundamental to Azure Logic Apps operations, handling everything from session state management to action histories and run information. More in details:
- Consumption Logic Apps store outputs of actions in the default storage account associated with the Integration Service Environment (ISE), or in a specified storage account. This includes input/output data for actions, which can grow substantially depending on your workflow volume and data payload sizes.
- Standard Logic Apps use storage accounts for similar purposes but with different architectural implications. Standard Logic Apps run in an App Service Plan and have more explicit control over storage configuration and scaling.
Azure Storage Accounts have well-defined limits:
- 20,000 requests per second for a single storage account.
- Maximum ingress/egress bandwidth varies by storage account type.
- Queue-based operations have their own throughput limitations.
Sharing the same storage account across different Azure Logic Apps instances can cause serious problems and personally I think that the main issues that you will have if you do that are the following:
Problem 1: scaling and reliability.
When multiple Logic Apps instances (potentially hundreds of concurrent executions if you have heavy workloads) share a single storage account, you’re multiplying the request volume against these limits. Each action’s input/output persistence, each state management operation, and each queue polling activity counts toward these limits.
Consumption Logic Apps can scale automatically and rapidly. A single trigger-based Logic App can generate lots of parallel executions in minutes. When all these executions persist their state and action outputs to the same storage account, you will create a wondeful source of throttling. And in practice (your real-world experience as end user), this means the following:
- You will start receiving HTTP 429 (Too Many Requests) responses from storage.
- You will start experiencing increased action latencies.
- You will start experiencing cascading failures across dependent workflows (if you have some).
- Generally speaking, you will have unpredictable performance during peak loads.
Standard Logic Apps offer more architectural control, but the core problem related to a shared storage remains. While you get better observability and more predictable scaling with Logic Apps Standard, sharing a storage account across multiple Standard Logic Apps (especially if they’re processing high volumes) creates the same bottleneck risk.
The difference is that Standard Logic Apps typically run in App Service Plans with defined scale-out boundaries, making the problem more predictable but still present.
Standard Logic Apps using managed connectors (like the Business Central one) still rely on storage for connection state and authentication tokens and using a shared storage account will lead to an increased contention for this critical part of the infrastructure.
Stateful workflows in single-tenant Azure Logic Apps (Logic Apps Standard) use:
- Azure Table Storage for persistent data storage during runtime.
- Azure Blob Storage for maintaining workflow run histories.
- Azure Queue Storage for scheduling purposes.
Each of these contributes to the load on your storage account.
Problem 2: contention issues on storage.
Storage account sharing across Azure Logic Apps instances introduces also contention issues.
Logic Apps use table storage for session state with specific row key patterns. When multiple apps simultaneously update session state for the same entity, you risk conflicts and inconsistent state management.
If multiple Logic Apps instances are reading from the same storage queues (Logic Apps uses queues for messaging and handling state across actions), you’ll experience message processing contention and a big decrease on response time.
Let’see problems in action
To show you some of these problems in a real-world scenario, I’ve created 2 Azure Logic Apps Standard (named LogicAppSharedStorage1 and LogicAppSharedStorage2) that shares the same storage account:
On both the Azure Logic Apps Standard instances I’ve created a stateful workflow like the following:
This workflow starts from an Http request where we pass a JSON like the following:
{
"iterations": 50
}
The workflow initialize some variables, then for every number of iteration specified in the incoming request, it increments a variable, then updates an array and wait for a delay (some ms). This workflow’s loop executes many times, creating many state updates, with heavy state reads/writes to the system storage account.
After that, I’ve created a Powershell script to execute the two workflows with some concurrencies. The “light load” test was the following:
- 20 iterations (loop parameter)
- 1 parallel request
- 3 total requests sent to both workflows
Result was the following:
We have an average response time of 1355 ms.
If we inspect the storage account metrics in Application Insights, we can see the load on the shared storage account (transactions and latency):
Now let’s execute the following “heavy load test”:
- 1000 iterations (loop parameter)
- 30 parallel requests
- 100 total requests sent to both workflows
Result now is the following:
As you can see, now the average response time is increased to 3097 ms, with some big spikes (around 12 seconds).
If we inspect again the Application Insights metrics of the shared storage account, this is what we have now. The number of transactions and latency on the shared storage is increased a lot:
The shared storage creates contention and throttling, decreasing performances of your workflows.
Conclusion.
In Azure Logic Apps sharing a stirage account between apps is possible, but not recommended unless you’re confident the account can handle the load. Personally, like for Azure Functions (see here), also for Azure Logic Apps I recommend the following:
PLEASE NEVER DO THAT!
If you want to be safe, the simplest, reliable and most effective solution is using one storage account per Logic App. This provides:
- Complete isolation of storage and no limits on scalability.
- Predictable performance.
- No locking and resource contentions on storage.
Stefano Demiliani 