Last updated 4/3/2024 to include v2 Tiers features.
Authors: Faisal Mustafa, Ben Gimblett, Jose Moreno, Srini Padala, and Fernando Mejia.
There are different options when it comes to integrating your API Management with your Azure Virtual Network (VNet) which are important to understand. These options will depend on your network perimeter access requirements and the available tiers and features in Azure API Management.
This blog post aims to guide you through the different options available on both the classic tiers and v2 tiers of Azure API Management, to help you decide which choice works best for your requirements.
TL; DR
Decision tree describing how to choose the right Azure API Management tier based on networking scenarios.
Here is the relevant documentation to implement these tiers and features:
- Tiers
- Networking Features
Background
Before we jump into the options and differences it's worth taking a step back to understand more about how Azure Platform as a Service products (PaaS) work regarding networking. If you need a refresher and so we don't repeat ourselves here, we'd ask the reader to spend a few minutes over at Jose's excellent "Cloudtrooper blog" and his deep dive post on all things "PaaS networking". We'll use some of the same labels and terms in this post for consistency Taxonomy of Azure PaaS service access – Cloudtrooper.
What is API Management, what tiers are available and why does it matter in relation to networking?
The first thing to remember is that the API Management API Gateway is a Layer 7 (in OSI model terms) HTTP Proxy. Keeping this in mind helps a lot when you think about the networking options available through the different tiers. In simple terms:
An HTTP proxy terminates HTTP connections from any client going to a set of [backend] servers and establishes new HTTP connections to those servers. For most API Management Gateway use cases the resource would reside close to the [backend] servers its facades (usually in the same Azure region).
Diagram describing all the components included in Azure API Management, and the difference between inbound and outbound sections.
Why does this matter? When we talk about the available networking-options we talk about features which relate to the initial client connection to API Management(inbound) OR features relating to the connection from API Management to the API backends(outbound). From now on, we will call them inbound and outbound connections, and there are different options/features for each type.
Regarding Azure API Management tiers we will rely in the following categories:
- Consumption tier, the tier that exposes serverless properties.
- Classic tiers, this category refers to the Developer, Basic, Standard and Premium tiers.
- V2 tiers, this category refers to the Basic v2 and Standard v2.
Networking scenarios
Let's jump right in. To make it easier to navigate and for you to get the information you need to make the right decisions for your use case, lets summarize by the applicable use-cases, we'll list the tiers where the functionality is available and add any applicable notes.
I have no specific networking requirements and just want to keep things simple.
Supported tiers: Consumption, Classic tiers, and V2 tiers.
Of course, there's more to implementing a workload with API Management than just networking features and still a lot of choice when it comes to an API Management tier that fits your workload and scale requirements. But if you are ok with having inbound and outbound connections going through the Azure Backbone or Public Internet, any tier of Azure API Management can help you with this scenario. Of course, we recommend securing your endpoints using Authentication/Authorization mechanisms like subscription keys, certificates, and Oauth2/OIDC.
Diagram describing what tiers of Azure API Management allow public access for inbound and outbound.
I have a requirement to connect privately to API Management for one or more of my Client Applications
Option 1: Consider deploying a Private Endpoint into API Management.
Supported tiers: Classic tiers.
“Private endpoints allow you to access services privately within your virtual network, avoiding exposure over the public internet.” (Thanks Microsoft co-pilot).
Deploying a Private Endpoint for inbound connectivity is a good option to support secure client connections into API Management. Remember, in this context the Private Endpoint you deploy for API Management creates an alternative network path into your API MANAGEMENT service instance; it's about facilitating inbound communication (the client connecting to API Management), and it is "one way only" meaning it doesn't help for scenarios where you also want to connect privately to your backends.
Diagram describing what tiers of Azure API Management allow public access and private endpoint for inbound.
Note: Whilst it's supported to use Private Endpoints in the Premium or Developer tiers - the service must not have been added to a Virtual Network (VNET). This makes private endpoints and the "VNET Injection" capability supported by Premium and Developer mutually exclusive. The Basic and Standard tiers can't be added to a Virtual Network.
Option 2: Consider adding your API Management to your VNet.
Supported tiers: Developer tier and Premium tier.
Developer and Premium are the only tiers where you can deploy the service into your virtual network - what we sometimes refer to as "VNet injection" - and allows you to set the inbound as public or private.
Diagram describing what tiers of Azure API Management allow private access for both inbound and outbound.
As far as the Developer Tier is concerned, this is NOT meant for production use and no workloads showed be deployed on this Developer Tier.
The API backends I want to reach from API Management are private.
Supported tiers: Developer tier, Premium tier, and Standard v2 tier.
For the classic tiers Developer and Premium, as we mentioned before you can deploy the service into your virtual network. This could be in “internal” (private) or external mode.
Diagram describing what tiers of Azure API Management allow private access for both inbound and outbound.
For the v2 tiers, Standard v2, allows you to rely on a feature called “VNet Integration” (please not the difference between VNet Integration and VNet injection) which allows API Management to "see" into your network and access services through a private IP in the connected Virtual Network, or in peered / connected network(s).
Diagram describing what tiers of Azure API Management allow private access for outbound using VNet integration.
I need to connect to API Management privately as well as reach private backends with no public access.
Supported tiers: Developer tier and Premium tier.
Add API Management Premium or Developer to your Virtual Network. The best practice would be to set the mode to "internal" - meaning inbound connectivity is via a private IP, via an internal load balancer.
Diagram describing what tiers of Azure API Management allow private access for both inbound and outbound.
This allows you to keep all API's private/internal but offers the option of later placing a Reverse Proxy in front of API Management (for example Azure Application Gateway) ....
A last word about IP Addresses...
It's something that relates to networking and is oft asked, so it would be remiss of us not to add a few lines summarizing the behavior and NAT (network address translation) for the different deployment modes:
Inbound
- By default, inbound is via a public IP address assigned to the service.
- This changes if you opt into using a Private Endpoint (for any of the tiers supporting this feature). Always remember to explicitly turn off the public ingress if you deploy a private endpoint instead and no longer require it.
- This also changes if you deploy the Premium (or Developer) tier, added to your Virtual Network (“VNet-injected”), and set the mode to "internal". In this mode, although a public IP is still deployed for control plane traffic, all data plane traffic will go through the private IP (Internal load balancer endpoint) which is provided in this mode.
Outbound
- By default, outbound traffic is via the public IP(s) assigned to the service.
- This changes for Premium (or Developer) tiers when the service is added to your Virtual Network (irrespective of the inbound mode being public or private). In this case
- For internal traffic leaving API Management - for example API Management reaching to a backend service hosted on a downstream VM within the network - there is no SNAT (source network address translation). If the next hop is an NVA (network virtual appliance/firewall) any rules for the source should use the subnet prefix, not individually mapped IPs.
- External bound traffic breaking out (non RFC1918) is SNAT to the single-tenant (dedicated) public IP assigned. This includes traffic to other PaaS services via a public endpoint (although you should note the traffic in this instance stays on the Azure backbone).
- For Standard V2 using “VNet integration”
- NAT for internal traffic is the same.
- External bound traffic breaking out is SNAT to one of the hosting stamps shared public IPs. If you want control over the outbound IP, use an Azure NAT Gateway on the subnet or route via an NVA (network virtual appliance, or firewall). Same note as above applies for PaaS-to-PaaS traffic via Public IPs.
Note for v2 tiers: API MANAGEMENT control plane and its own dependency traffic is not seen on the customers network, which is an enhancement from the GA tiers, and simplifies scenarios requiring force-tunnelling / firewall integration.
