Network resource requirements for API Management injection into a virtual network
Availability
Important
This feature is available in the Premium and Developer tiers of API Management.
The following are virtual network resource requirements for API Management injection into a virtual network. Some requirements differ depending on the version (stv2 or stv1) of the compute platform hosting your API Management instance.
- An Azure Resource Manager virtual network is required.
- The subnet used to connect to the API Management instance might contain other Azure resource types.
- The subnet used to connect to the API Management instance shouldn't have any delegations enabled. The Delegate subnet to a service setting for the subnet should be set to None.
- A network security group attached to the subnet above. A network security group (NSG) is required to explicitly allow inbound connectivity, because the load balancer used internally by API Management is secure by default and rejects all inbound traffic.
- Depending on whether you inject your API Management instance into a virtual network in external mode or internal mode, you may provide a Standard SKU public IPv4 address in addition to specifying a virtual network and subnet.
- The API Management service, virtual network and subnet, and public IP address resource (if provided) must be in the same region and subscription.
- For multi-region API Management deployments, configure virtual network resources separately for each location.
Subnet size
The minimum size of the subnet in which API Management can be deployed is /29, which provides three usable IP addresses. Each extra scale unit of API Management requires two more IP addresses. The minimum size requirement is based on the following considerations:
Azure reserves five IP addresses within each subnet that can't be used. The first and last IP addresses of the subnets are reserved for protocol conformance. Three more addresses are used for Azure services. For more information, see Are there any restrictions on using IP addresses within these subnets?.
In addition to the IP addresses used by the Azure virtual network infrastructure, each API Management instance in the subnet uses:
- Two IP addresses per unit of Basic, Standard, or Premium SKU, or
- One IP address for the Developer SKU.
When deploying into an internal virtual network, the instance requires an extra IP address for the internal load balancer.
Examples
/29 subnet: 8 possible IP addresses - 5 reserved Azure IP addresses - 2 API Management IP addresses for one instance - 1 IP address for internal load balancer, if used in internal mode = 0 remaining IP addresses left for scale-out units.
/28 subnet: 16 possible IP addresses - 5 reserved Azure IP addresses - 2 API Management IP addresses for one instance - 1 IP address for internal load balancer, if used in internal mode = 8 remaining IP addresses left for four scale-out units (2 IP addresses/scale-out unit) for a total of five units.
/27 subnet: 32 possible IP addresses - 5 reserved Azure IP addresses - 2 API Management IP addresses for one instance - 1 IP address for internal load balancer, if used in internal mode = 24 remaining IP addresses left for 12 scale-out units (2 IP addresses/scale-out unit) for a total of 13 units.
/26 subnet: 64 possible IP addresses - 5 reserved Azure IP addresses - 2 API Management IP addresses for one instance - 1 IP address for internal load balancer, if used in internal mode = 56 remaining IP addresses left for 28 scale-out units (2 IP addresses/scale-out unit) for a total of 29 units.
/25 subnet: 128 possible IP addresses - 5 reserved Azure IP addresses - 2 API Management IP addresses for one instance - 1 IP address for internal load balancer, if used in internal mode = 120 remaining IP addresses left for 60 scale-out units (2 IP addresses/scale-out unit) for a total of 61 units. This is a large, theoretical number of scale-out units.
Note
It is currently possible to scale the Premium SKU to 31 units. If you foresee demand approaching this limit, consider the /26 subnet or /25 subnet.
Important
The private IP addresses of internal load balancer and API Management units are assigned dynamically. Therefore, it is impossible to anticipate the private IP of the API Management instance prior to its deployment. Additionally, changing to a different subnet and then returning might cause a change in the private IP address.
Routing
See the Routing guidance when deploying your API Management instance into an external virtual network or internal virtual network.
Learn more about the IP addresses of API Management.
DNS
In external mode, the virtual network enables Azure-provided name resolution by default for your API Management endpoints and other Azure resources. It doesn't provide name resolution for on-premises resources. Optionally, configure your own DNS solution.
In internal mode, you must provide your own DNS solution to ensure name resolution for API Management endpoints and other required Azure resources. We recommend configuring an Azure private DNS zone.
For more information, see the DNS guidance when deploying your API Management instance into an external virtual network or internal virtual network.
Related information:
Important
If you plan to use a custom DNS solution for the VNet, set it up before deploying an API Management service into it. Otherwise, you'll need to update the API Management service each time you change the DNS server(s) by running the Apply Network Configuration Operation, or by selecting Apply network configuration in the service instance's network configuration window in the Azure portal.
Limitations
Some virtual network limitations differ depending on the version (stv2 or stv1) of the compute platform hosting your API Management instance.
- A subnet containing API Management instances can't be moved across subscriptions.
- For multi-region API Management deployments configured in internal virtual network mode, users own the routing and are responsible for managing the load balancing across multiple regions.
- To import an API to API Management from an OpenAPI specification, the specification URL must be hosted at a publicly accessible internet address.