Introduction

A key consideration when deploying Azure API Management Standard v2 or Premium v2 is that outbound networking behavior differs from the classic tiers. This applies both when customers manually rebuild an existing solution on one of these tiers and when they create a new deployment based on assumptions formed from classic-tier behavior.

In classic tiers, dedicated outbound IP addresses are available and are commonly used by backend services for source-IP allowlisting. With Standard v2 and Premium v2, customers should instead design outbound connectivity explicitly when a predictable public source IP is required. This article applies only to Standard v2 with virtual network integration and Premium v2 with either virtual network integration or virtual network injection.

The Challenge

Many backend systems still validate the source IP address of incoming traffic. Common examples include:

• Partner APIs
• Payment providers
• Legacy applications
• On-premises systems
• Third-party SaaS platforms

When designing a new APIM v2 service, or manually rebuilding a solution previously hosted on a classic tier, backend teams often ask:

“Which IP address should we allowlist?”

Unlike a classic-tier design that relies on the service’s dedicated outbound IP addresses, an APIM v2 service may require an explicit egress pattern. Virtual network integration combined with Azure NAT Gateway can provide a predictable public source IP for outbound traffic that traverses the integrated subnet.

Architecture

Before: Classic APIM

The backend allowlist contains the outbound public IP address associated with the APIM instance.

After: APIM v2 Service with NAT Gateway

The backend allowlist contains the public IP address assigned to the NAT Gateway. APIM outbound traffic uses the virtual network integration path, and the NAT Gateway provides the predictable public source IP for internet-bound connections from the associated subnet.

Configuration Steps

Prerequisite - Create an APIM v2 Service

The portal walkthrough in this article uses a Standard v2 instance configured for outbound virtual network integration.

As shown in the service overview, the dedicated public IP address information available in the classic tiers is not displayed for this APIM v2 instance.

 

Step 1 - Create a Virtual Network

Create or select the virtual network that will be used for APIM outbound virtual network integration.

 

Step 2 - Create a Dedicated APIM Subnet

Create a subnet dedicated to the APIM v2 instance. The integration subnet must meet the documented requirements for outbound virtual network integration.

Reference: Integrate an API Management instance with a virtual network for outbound connectivity

 

Subnet delegation depends on the APIM v2 tier:

• Standard v2: Delegate the subnet to Microsoft.Web/serverFarms for outbound virtual network integration.

• Premium v2: Delegate the subnet to Microsoft.ApiManagement/service, whether using virtual network integration or virtual network injection.

 

Step 3 - Associate a Network Security Group

Associate a Network Security Group (NSG) with the APIM integration subnet. Configure the required rules according to the documented APIM networking dependencies, while also applying the outbound controls required by your environment.

Reference: APIM outbound virtual network integration requirements

Step 4 - Configure APIM Virtual Network Integration

In the Azure portal, open the API Management instance and navigate to Networking > Virtual network integration. Select the virtual network and dedicated subnet, and then save the configuration.

 

 

Virtual network integration can also be configured when creating the APIM instance.

References: Outbound virtual network integration | API Management v2 service tiers overview

Test the Current Outbound IP

This example uses a second APIM instance as the backend, although any backend service that records the request source IP can be used.

Before NAT Gateway is configured, the backend can observe different Azure source IP addresses. The Azure IP Ranges and Service Tags - Public Cloud file is available from the Microsoft Download Center: Download Azure IP Ranges and Service Tags – Public Cloud from Official Microsoft Download Center

 

Step 5 - Create a NAT Gateway

Create an Azure NAT Gateway and associate it with one or more Standard public IP addresses or a public IP prefix. The assigned public IP becomes the predictable source address used for applicable outbound connections through the integrated subnet.

For this example, the NAT Gateway uses a Standard public IP address resource.

 

Step 6 - Associate the NAT Gateway with the APIM Subnet

Open the NAT Gateway configuration and associate it with the APIM integration subnet.

 

After the association is applied, validate that the effective network configuration matches the intended routing, NSG, and outbound connectivity design.

Step 7 - Validate

Send a test request through APIM to an endpoint that returns the caller’s public IP address, or inspect the destination backend logs. Confirm that the observed source IP matches the public IP assigned to the NAT Gateway.

 

 

As expected, the source IP address observed by the backend now matches the NAT Gateway public IP address.

When to Use This Pattern

This pattern is useful when:

• Backend teams require source-IP allowlisting.
• Third-party vendors support only IP-based network controls.
• Legacy integrations cannot be changed quickly.
• A manual rebuild of a solution previously hosted on an APIM classic tier must preserve predictable outbound addressing.

Recommendations

A predictable source IP can simplify firewall integration, but it should not replace strong service-to-service authentication. Where supported, combine or replace IP-based controls with mechanisms such as:

• Mutual TLS (mTLS)
• OAuth 2.0
• Client certificates
• Managed identity
• Private endpoints and Private Link

Treat IP allowlisting as an additional network control rather than the primary authentication mechanism. Also validate capacity, resiliency, routing, DNS, NSG rules, and dependency access for the complete solution before production deployment.

Conclusion

APIM v2 services use a different outbound networking model from the classic tiers. For new deployments or manually rebuilt solutions, outbound virtual network integration combined with Azure NAT Gateway can provide a predictable public source IP for applicable outbound traffic and simplify integration with backend firewall rules.