Before deploying APIM myself, I did some research on how to create a similar setup, where most of our backend services (azure functions, app services etc.) live inside a virtual network. Note that we are still using the developer SKU for API Management, it has almost the same features as the premium SKU (source). For our use case, developer tier has enough bandwidth and the premium SKU is pretty darn expensive. The developer tier is not backed by a Microsoft SLA, so be careful using this in production environments. Below, I'll start with a short summary and describe the scenario's at the end.
Summary
I hope this overview highlights some of our concerns, which may help you to decide the best fit for your scenario. In the end, we choose scenario two, which provides the necessary security we needed. It reduces the attack surface because all backends are private. The main reason is that we wanted to use consumption plan logic apps. Standard logic apps are expensive and not really user-friendly in terms of deployment. With an additional Front Door in place, it also enables us to easily move to solution three at a later point in time. Since you don’t have to move around with custom domains and certificates when putting APIM private, Front Door still remains your main entry point.
1) Scenario one
- APIM without vnet integration (public)
- Azure Function with Vnet integration
- Azure SQL and Storage with private endpoints
Pros: In this scenario your are able to choose APIM standard or basic sku. These are a lot cheaper than the premium sku.
Cons: The Azure function is exposed to the public internet, so be careful and protect it with AAD authentication. When you would deploy multiple azure functions like this, it increases the attack surface.
2) Scenario two
- APIM with vnet integration (external mode)
- Azure Function with private endpoint
- Azure SQL and Storage with private endpoints
Pros: Setup is not that difficult if you follow the APIM vnet documentation (source). May be useful if you want to expose your APIs to external parties as well. Everything behind APIM resides securly within a virtual network.
Cons: Only developer and premium tiers are available for this setup. APIM is reachable over the public internet, so make sure you put in the necessary policies that always checks the JWT. You could even put in a policy that check's the IP address, basically a poor man's firewall solution.
1) Scenario three
- APIM with vnet integration (internal mode)
- Azure function with private endpoint
- Azure SQL and Storage with private endpoints
- Optional: Application gateway with or without Front Door to safely expose certain routes to the outside world.
Pros: Most secure solution, since everything is shielded from the public internet. I would call this the preferred enterprise setup. If needed, you could even extend this setup with an application gateway with or without Front Door to control who has access to certain API’s from outside the virtual network.
Cons: This is the most extensive setup, meaning that it takes a lot more time to deploy. You have to take into account all the necessary routes, NSGs, private DNS entries, etc. Advisable to be familiar with azure policies as well to do some of this automatically.
Note: APIM is going to support private endpoints as well in the near future, which is a bit confusing. I would say the two vnet modes are already comparable to how you would use vnet integration and private endpoints for azure functions and app services.
