Do you have strict security requirements for your workflows? Azure Logic Apps is the solution.

Low-code workflows for integrations between systems are a quite common scenario in many projects, from small to enterprise companies. And (I repeat myself again) when talking about this scenario, we have two main platforms: Power Automate and Azure Logic Apps.

Both platforms can be used in enteprise scenarios, despite some important differences that, at least in my opinion, make Azure Logic Apps always the best choice when you have workflows in a large organization.

The first aspect that usually drives the choice is performance and scalability. Azure Logic Apps (Standard) is designed and built for high performance and scalable automation, which makes the platform ideal for large-scale workflows. The advantages are:

• High throughput.
• Dedicated compute resources.
• Elastic scaling.
• Optimized workflow execution with lower latency and faster response times.

Bu there’s another aspect that in many scenario can be a driver for the workflow’s platform choice: business continuity and security. These are two aspects that sometimes are not initially considered, but then when you have to do with auditors, not satisfying them can be a problem.

Compared to Power Automate, Azure Logic Apps provides:

• Geo-redundacy and multi-region deployment for your workflows (that can guarantee availability even during regional outages).
• Automated workflows backups.
• High availability.

But security is probably the aspect where Azure Logic Apps is a must when you have strict security requirements to satisfy. With Azure Logic Apps, you can

• Restrict access to your worklfow by IP address: https://demiliani.com/2024/09/10/azure-logic-apps-workflows-restrict-access-by-ip-ranges/
• Restrict access to your workflow by Azure Service Tag: https://demiliani.com/2024/10/15/restrict-azure-logic-appss-workflows-access-only-to-dynamics-365-business-central/
• Create VNET integration and inbound traffic filtering through private endpoints.

Regarding these last two points, here is a brief explanation on how to activate those settings.

If you select your Azure Logic Apps (Standard) instance, under Security and then Networking you have the following settings:

• Private endpoints
• Virtual Network Integration

To add the Azure Logic Apps in an existing Virtual Network, select Virtual Network Integration and then specify the Virtual Network and the subnet:

Setting up virtual network integration affects only outbound traffic. For securing inbound traffic, you need to create a private endpoint. Select Private endpoints and then Add (Express or Advanced):

Here I’ve selected Advanced. Give it a name for the private endpoint and select a region and a name for the network interface:

Then select the target resource (it’s automatically selected as your Logic Apps):

And then select the Virtual Network and the subnet:

Then click Create and the private endpoint will be configured.

When you activate VNET integration and private endpoint, public network access to your Azure Logic Apps should bve disabled (otherwise you will see a warning like in my image above when creating the private endpoint).

All those settings ensure that Azure Logic Apps (Standard) conforms to the most strict security requirements (writing this post expecially if you have requirements coming from auditors). Together with built-in logging and auditing capabilities (you can use audit trails to track changes and ensure compliance with security standards) and fine role-based access control (or RBAC, that in Azure Logic Apps works at the resource level where you assign role-based access to a specific resource, so that if the workflow creator leaves, you don’t lose access to their workflows) you can satisfy every security needs for the enterprise market.

Original Post https://demiliani.com/2025/02/06/do-you-have-strict-security-requirements-for-your-workflows-azure-logic-apps-is-the-solution/