Highlight
Azure Logic Apps store their state on storage accounts, and they require dedicated account, or do they?
Well… in general the docs don’t explicitly say that logic apps require dedicated storage account. But when you read the requirements, and check how they work, then you will realize they do.
Why?
Why? Why would you even consider sharing storage accounts?
I think it’s a valid question so let’s start there.
if you read my previous post on cost of logic apps with ‘effect of scale’, then you might see that major cost driver for large scale platform can be private endppoints for storage accounts. Every logic app requires a storage account. Every storage account requires private endpoint. Every private endpoint costs. You get the point…
So why? To potentially save a ton of money for your organization.
Should I worry?
If you your organization doesn’t use private endpoints, or does allow firewall exceptions then this issue doesn’t affect you can you can disregard this post. But if effect of scale might be an issue for you it’s worth noting.
How Logic App connects to storage
Currently (as of January 2025) the way Logic Apps standard connect to Storage Account is either using
- Storage Account Keys or
- RBAC with Storage Contributor & Data Contributor roles
Both of which give logic app full ownership over data and storage account containers
Logic app requires these permissions because the way they are implemented, logic app will dynamically create containers/files based on which connectors you use.
Below diagram illustrates the problem if you would want two logic apps to share a single storage.
In short? Since queues, tables and blob container names are mostly random, and some hardcoded. We will run into collisions, which might have bad effect for how your logic app runs, even resulting is loss of state.
Is there a solution? Personally some time ago I would say no, so this tip was mostly advisory. But there might be soon with SQL DB state storage. I’ve explained this here: SQL db can’t be shared, but….
What you can do?
- Ensure as few private endpoints are deployed to minimize the cost
- Consider moving to SQL DB for state once it leaves preview state
- Ask your org if firewall trusted services exceptions are allowed and remove private endpoints for state storages
Next Actions
Here are some recommendations from me on what you can check out next if you want to learn more
