Azure API Management Private Endpoints: Take Your Gateway Off the Public Internet

If your API Management instance only ever serves internal consumers — other Azure workloads, on-premises systems over ExpressRoute, partner networks over VPN — keeping its gateway on a public IP is exposure you don't need. Private endpoint support lets you give APIM a private IP inside your own virtual network, so the public hostname resolves to an address that simply isn't routable from the internet. This post walks through how the pieces fit, a worked setup, and the limitations worth knowing before you commit.

What a private endpoint actually changes

A private endpoint is a network interface with a private IP, placed in a subnet you choose, that maps to your APIM instance. Once it exists and DNS is wired up, clients inside the VNet (or in networks connected to it) resolve <apim-name>.azure-api.net to that private IP instead of the public one. The hostname stays the same, so client configuration doesn't change — only the resolution does.

Two things this does not do automatically:

• It doesn't block the public path. You must separately set publicNetworkAccess to Disabled if you want the public endpoint to refuse traffic. Note that disabling it blocks traffic but doesn't delete the underlying public IP — it just stops answering.
• It doesn't make outbound calls private. APIM's calls to your backends still leave over its normal egress path unless you design for that separately (for example, with VNet integration or internal mode, which is a different feature from private endpoints).

SKU and subnet prerequisites

Private endpoints for APIM are supported on the Premium and Developer SKUs only. Basic and Standard can't use them — if cost pushes you toward those tiers, a public endpoint with IP filtering is your fallback.

You also need:

• A subnet in your VNet for the endpoint's network interface. It can be shared with other private endpoints.
• A Private DNS zone (azure-api.net) linked to the VNet, so the hostname resolves to the private IP. If you let the portal create the endpoint, it can register the DNS record for you; doing it by CLI means wiring the zone yourself.
• Optionally, NSG rules on the subnet to restrict which source addresses can reach the endpoint.

Worked example: create the endpoint and lock down public access

Run these with Azure CLI from a workstation or Cloud Shell, as a principal with Contributor (or equivalent) on the APIM instance, the VNet, and the Private DNS zone. Replace the placeholders.

# Variables\nAPIM_NAME=my-apim\nRG=rg-apim\nVNET_RG=rg-network\nVNET=vnet-hub\nSUBNET=snet-private-endpoints\n\n# 1. Create the private endpoint\naz network private-endpoint create \\\n  --name pe-$APIM_NAME \\\n  --resource-group $VNET_RG \\\n  --vnet-name $VNET --subnet $SUBNET \\\n  --private-connection-resource-id \\\n    $(az apim show -n $APIM_NAME -g $RG --query id -o tsv) \\\n  --group-id Gateway \\\n  --connection-name ${APIM_NAME}-conn\n\n# 2. Approve the connection (if it isn't auto-approved)\naz apim private-endpoint-connection approve \\\n  --service-name $APIM_NAME -g $RG \\\n  --name ${APIM_NAME}-conn\n\n# 3. Disable public network access\naz apim update -n $APIM_NAME -g $RG \\\n  --set publicNetworkAccess=Disabled

If you create the endpoint without the portal's DNS integration, create a Private DNS zone named azure-api.net, link it to your VNet, and add A records for the gateway hostname pointing at the endpoint's private IP. A missing zone link is the most common cause of \"it doesn't resolve\" failures.

Verifying it works

From a VM in the same VNet:

nslookup my-apim.azure-api.net

The answer should be the private endpoint's IP (a 10.x/172.16-31.x/192.168.x address from your subnet), not a public one. Then call an API operation and confirm a 200 response. In the portal, under the APIM instance's Networking → Private endpoint connections, the connection should show Approved with the private IP listed.

For the negative check: from a machine outside the VNet with no VPN/ExpressRoute path, the same call should now time out or be refused once publicNetworkAccess is disabled. If it still succeeds, public access is still on.

Limitations and trade-offs

• Consumers outside the VNet need a path in. On-premises callers need ExpressRoute or a site-to-site VPN; other Azure VNets need peering. The private endpoint doesn't create connectivity, it just terminates it.
• DNS is the fragile part. On-premises resolvers must forward azure-api.net queries to a resolver that can see your Private DNS zone (commonly via DNS private resolver or conditional forwarders). Test resolution from every network segment that will call the API.
• Outbound is unchanged. If your backends are also private, plan APIM's egress separately — private endpoints only cover inbound.
• SKU cost. Premium is a significant price step. Developer SKU works for non-production validation of the whole design before you pay for Premium.

Closing

The practical sequence: confirm your SKU, create the endpoint, get DNS resolution right from a test VM, verify traffic flows, and only then disable public network access — in that order, so a DNS mistake doesn't lock you out. If you're evaluating this for production, rehearse it end to end on a Developer-SKU instance first; the networking behavior is identical and the cost of a wrong turn is near zero.