I currently have the following setup in Azure:
- An Azure API Management API that maps to
- an Azure Function App with multiple functions that accept data and store it in
- an Azure Storage Account.
- A private (no public access) Azure SQL database.
Now I want to add a few more API endpoints and Azure functions that provide access to some data from the SQL database. I am now facing the problem that my Function App and API Management are public and therefore cannot connect to resources within my VNet (i.e. the database).
Is there a way to have functions connect to the private database without making the functions private, too? And if I have to make the functions private I would also have to make the API Management private, right? Which would make the whole API unavailable from the internet.
The plans for API Management and Function App that support VNet integration are way more powerful and expensive. I don’t need so much power, just the VNet integration.
Does anyone know how to solve this issue?
2
Answers
You can achieve this with a VPN Gateway
This means the VPN Gateway provides a public IP to your VPN!
So the public Azure Functions can access the VPN resources.
Tutorial: Create and manage a VPN gateway using the Azure portal
A better approach is, to use the internal mode of API Management:
Connect to a virtual network in internal mode using Azure API Management
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
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
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
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.