Introduction
A very common discussion to have with enterprises around Azure API Management (“APIM”) is the aspect of network integration. At the end of the day, the response to that is very simple… Only the developer & premium SKU allow VNET integration. The integration is achieved by doing “injection”, which means that the service is “dedicated” to you and “the machines” are placed directly in your VNET. Azure APIM does not leverage private link (yet?)… Which then opens the next discussion, as the premium SKU is about 3,42 Euro per hour, where the basic SKU floats at about 20 Eurocent per hour. At this point, for most organizations, the cost impact will take priority over the most optimal design. Where today’s post will take a look at the various options at hand.
Update (March 2022)
Since the initial post, the ability to leverage private endpoints have been made available ; https://docs.microsoft.com/en-us/azure/api-management/private-endpoint. This concept will probably be more interesting to you than the approaches mentioned in this post!
Flavors / Tiers
When taking a look at the pricing info, you will notice there are multiple flavors you can choose from ;
- The consumption tier is the one where you are charged for the amount of calls you make. It is an awesome model in terms of linking your business outcome to the cost model at hand. The downside is, that is does not offer a developer portal or any typical enterprise features (like VNET integration or a self-hosted gateway).
- The basic and standard tiers are economic tiers at both about 45 and 130 Euros per month. They do include a developer portal.
- The developer and premium tiers are the ones typically picked by enterprises due to their VNET integration, HA/DR options (for Premium) and the self-hosted gateway.
Cost optimization for Non-Production environments
A common pattern in enterprises is to have have a “DTAP“-street for your applications. Here the general advice is to leverage premium in production; due to the SLA, scalability & HA/DR-options. Where you can optimize costs by leveraging the developer tier for the non-production environments. As from a functional perspective, the developer and premium tier are very close to each other. Where you can still opt to go for a premium tier (as opposed to a developer tier) in case you need one of the aspects only delivered in premium.
APIM Components
Azure APIM has three components ;
- Admin portal ; This is the Azure portal (actually the Azure Resource Provider), where you do the administration of the APIM service.
- Developer portal ; This is where the developers can discover and subscribe to the published API services.
- Gateway ; This is the component to which the consumers make the actual calls, which will do the processing and sending the requests to the backend.
In terms of network connectivity, it is key to know that there is a difference between these components. For today, the focus will be around the gateway…
Self-Hosted Gateways
Aside from a managed cloud gateway, you can also opt to deploy your self-hosted gateway. From a networking point-of-view, you then decide how it is integrated in the network. Where it will of course still need to connectivity towards the management plane to get the needed deployment configuration.
Network Injection vs Public
In essence, only the developer and premium tier will offer VNET integration. All other tiers, you should consider them being exposed “on the internet”. In reality, the traffic between an APIM and Azure services will remain on the backbone. Though the service is exposed to the public internet nevertheless. On the VNET integration side, the service is being “injected” into your VNET. Which means that the gateway will get IP addresses from the subnet it has been deployed into. Here you can then have the option to ONLY leverage the private IPs, or have the combination of being public exposed and route to the backend via the internal network.
Network Integration Options
In order to help you make a well informed decision, let us look at some architecture patterns and the impact they have ;
- Private VNET Integration
- With hybrid connectivity
In this scenario, the APIM is injected into the VNET and no public IP is exposed. The APIM can be reached via the VNET, and even in a hybrid mode via VPN/ExpressRoute. The advantage here is the full network isolation, where it does require the developer/premium tier to achieve this.
- With a Web Application Firewall (“WAF”)
In this scenario, the APIM is injected into the VNET and no public IP is exposed via the APIM. The Web Application Firewall will expose the APIM to the outside world. Where the APIM will then reroute the requests via the VNET to the backends. Of course, this scenario can also be combined with the previous one to route the traffic via the VPN/ExpressRoute. Just like that scenario, this requires the developer/premium tier to achieve.
- With hybrid connectivity
- Public VNET Integration
It is possible to expose the APIM to both the internet (“public endpoint”) and have it injected into the VNET. By leveraging this pattern, the incoming requests will land on the APIM, and then routed to the backend via the VNET. Outgoing calls will go directly to the outside world. Just like with the previous patterns, this one also requires the developer/premium tier, and can also be combined in a hybrid way of course!
- Public deployed
- All components public
The next patterns shows that all components are deployed on the public side. As mentioned, the traffic will flow over the Microsoft back-bone. Though the endpoints are still publicly exposed. Therefor, we can harden the situation by adding authentication to the flow. From the APIM to the Functions, we can inject authentication into the backend calls to validate that the calls are not coming from an untrusted source. We can even harden the network flow between the two components by restricting the allowed IPs on the Functions side. We can do the same flow between Functions and Azure SQL. Where we can even leverage the managed identity (MSI) in terms of authentication towards the backend data store. Where we can again restrict the IP addresses between Functions and Azure SQL. The advantage of this flow, is that it works on all tiers! The downside of the flow, is that the network is not fully isolated.
- Only APIM Public
In this pattern, we put the APIM outside of the VNET, and have the services exposed via a Web Application Firewall (“WAF”). In addition, we add authentication between the APIM and the WAF by injecting a client certificate in the backend communication to the WAF. And by adding a network ACL to the WAF, allowing only the traffic from the APIM. The clear advantage this scenario has over the previous one, is that the backend is isolated. The only attack vector here are the exposed endpoints on the WAF, where the hardening between APIM and WAF need to mitigate this risk. Next to the advantage of the backend isolation, this scenario can also be used with any tier!
- All components public
Closing Thoughts
I hope today’s post helped you to get some inspiration on architectures that can help you reduce cost or/and harden specific scenarios! Here I am aware that organizations quickly hit the premium/developer tier in regards to the network integration. Where I fully understand the grievance around this, it might bring comfort to know patterns exist to optimize the cost. And that this is a fully managed service… As I have seen many organizations attempting to set up their own setup, to quickly learn that there is no glory to be gained in that move. As successfully running a scalable APIM solution yourself is not for the faint of heart, and requires quite some energy. Energy that I can imagine is better spent elsewhere, where your organization gets more benefits from your time. Though at the end of the day, everyone’s mileage will vary!
Karim Vaes 