Highlight
Did you know azure connectors are still paid in logic app standard?
Intro
When people move to logic app standard sometimes they fall into a trap of simplification. This is a common issue that I see people make. Networking is similar to what I explained in the cost related blog post.
When you read Azure Logic App standard documentation or blog posts, they often mention that the biggest benefit of logic app standard is that your code is executed on your azure app service.
Which is of coruse true, but the simplification here is that this is only true if you use in-app connectors. Azure connectors are still the same as consumption ones. Many forget that when they export their consumption logic app into a import it into a standard one, their connectors don’t automatically change to in-app ones. So, they might be hit by networking issues if their move is related to new firewall/private network setup.
This is because logic apps standard work in a ‘hybrid’ model. Not to mistake it in hybrid model with cloud and on-prem. In App connectors are executed on Logic App standard app service plan, and are making requests to services from that app service. Azure connectors still call Microsoft’s infra and are executing requests from their infra. Hence hybrid.
Networking wise, in-app means they act like private connections when VNet Integration is enabled on Azure App Service, while Azure connectors are public traffic connections, with a small asterisk, but more on that in options section.
Below diagram presents this a bit clearler than just text.
Options that you have depend on your org security profile
Here are secure connectivity options for both connector types, check with your org which are allowed
- Managed Azure Connectors
- Public traffic - no Firewall must be present on target service
- Regional IP whitelistign - Azure connectors use finite list of IPs from Azure, so you can whitelist these IPs on your firewall. Note that this means all Microsoft App Service customers from particular region. Not just your azure environment.
- Service endpoints - A way better security than previous two options, especially if you add service endpoint policies for service like storage accounts
- Azure Trusted Services - If your service uses managed identity, then your service can be let through the firewall, as it’s considered a trusted connection (yet another benefit of managed identities)
- In-App Connectors
- All of above, but obviously the biggest win here are Private Endpoints which is Today’s leading way to securing Azure network
Summary
That’s it. Now you can design your solutions with networking in mind based on your organization’s security policies.
Next Actions
Here are some recommendations from me on what you can check out next if you want to learn more
