Networking — where the desk sits on the wire

Everything in this track so far has assumed the caller comes through the front desk. Parts D and F built a very good desk — it authenticates, limits, and logs every request. None of it matters if there is a second door. By default APIM has a public IP and so, very often, does the backend behind it, which means a caller who learns the backend's address can skip the desk entirely: no key checked, no token validated, no rate limit, no log. The gateway becomes a suggestion. This is the failure that networking exists to close, and it is the one auditors reach for first, because it turns every control you built into theatre.

So the whole of this part answers one question in three settings: how do you make the gateway the only road to the backend? Sometimes that means the backend sits in a private network APIM can reach but the internet cannot. Sometimes it means clients themselves must arrive privately. And sometimes the backend will never leave your own building, and the gateway has to go to it. The vocabulary is small; the tier rules are where people get caught out, so learn them with the concept:

VNet injection

Deploying the whole APIM instance into a subnet of your virtual network, so it can reach private backends. Two modes — external and internal. A classic Developer / Premium capability.¹

External vs internal

External: the gateway keeps a public endpoint but can also reach VNet resources. Internal: the gateway has no public endpoint — it is reachable only from inside the network.

Private endpoint

A private IP in your VNet for inbound client connections to APIM over Azure Private Link. Inbound only — it secures the road clients take in, not the road APIM takes out.

Self-hosted gateway

A containerised copy of the gateway you run yourself — on-premises or in another cloud — managed from your Azure instance. For backends that will never move to Azure. Developer / Premium.

Application Gateway / Front Door

A WAF-bearing front you put in front of an internal-mode APIM, so the public takes the internet-facing appliance and the gateway stays private behind it.

The heaviest tool is virtual network injection: you deploy the entire APIM instance into a subnet of your VNet, and from there it can reach backends that have no public address at all — a database behind a private endpoint, an app service locked to the VNet, a server on-premises across a VPN or ExpressRoute. This is a classic Developer and Premium tier capability, and stating that tier gate correctly is the single most common thing candidates get wrong in an interview. It comes in two modes, and the difference is entirely about the front:

External mode keeps a public endpoint on the gateway — the internet can still call APIM directly — while giving it a foot inside the VNet to reach private backends. Use it when you want a public API whose backends happen to be private. Internal mode removes the public endpoint entirely: the gateway, the developer portal, and the management plane are reachable only from inside the network. Nothing on the internet can call it. That is the mode for an API that should never face the public directly — an internal platform, or one that will only ever be fronted by something else.

A desk you can walk around is a decoration.

One newer wrinkle worth knowing so you are not caught flat: the v2 tiers (Standard v2, Premium v2) added a separate, lighter model called VNet integration for outbound connectivity to private backends, keeping the gateway's inbound endpoint public. It is a different feature from classic injection, not a rename, and conflating the two is a common slip. For this class, hold the classic external/internal injection model as your default mental picture — it is what "VNet mode" almost always means — and know that a lighter outbound-only option exists on the v2 tiers.

Injection is about the road APIM takes out to backends. A private endpoint is about the road clients take in. It gives your APIM instance a private IP inside your VNet via Azure Private Link, so a client on the network reaches the gateway without ever touching a public address — and you can then disable public network access entirely, so the only way to the gateway is the private one. The detail that catches people: a private endpoint on APIM is inbound only. It secures how clients connect to the gateway; it does nothing for how the gateway connects to its backends. Inbound private endpoint and outbound reachability are two separate problems, solved by two separate features, and an interviewer will happily watch you conflate them.

The most common production shape combines internal mode with a public front. You put APIM in internal mode — no public endpoint — and place an internet-facing Application Gateway (or Azure Front Door) in front of it. The public reaches the WAF-bearing appliance; the appliance forwards to the private gateway; the gateway alone reaches the backend. You get a web application firewall inspecting traffic before it ever reaches APIM, a public entry point you can harden and scale independently, and an API gateway that has no direct exposure to the internet at all. Front Door adds global anycast and CDN-style edge presence for a geographically spread audience; Application Gateway is the regional, in-VNet choice. This is the pattern Figure 1 draws, and it is worth being able to sketch on a whiteboard in four boxes.²

Every option so far assumes the backend can be reached from Azure. Some cannot — a mainframe in a data centre that will never be migrated, a service in another cloud, a system a regulator says must stay in a particular building. Routing those calls up to Azure and back down is slow, sometimes non-compliant, and occasionally billed by the gigabyte. The self-hosted gateway answers this by inverting the geometry: it is a containerised copy of the gateway — a Linux Docker image you run on Docker, Kubernetes, or Azure Arc, on-premises or in another cloud — that you deploy beside the backend. API traffic then flows directly from caller to local gateway to local backend, never leaving the building, while the gateway is still managed, configured, and observed from your single Azure APIM instance. It is a Developer and Premium feature.

Two facts about it earn their keep. First, connectivity: the self-hosted gateway needs only outbound connectivity to Azure on port 443 — it reaches out to a configuration endpoint to pull policy updates every few seconds and to send heartbeats and telemetry (to Azure Monitor and Application Insights). You never open an inbound hole from Azure into your data centre; the container phones home. Second, resilience: it is designed to fail static. If the link to Azure drops, a running gateway keeps serving traffic from its in-memory (or backed-up) configuration, and reconnects and catches up when Azure returns. A network blip in your Azure region does not stop your on-premises API. It is the answer to "single point of management, many places the APIs actually live."

Networking is where the gateway stops being advice and becomes architecture. A desk you can walk around is a decoration; a desk that is the sole path to the backend is a control. You now have the three moves that guarantee it: injection so APIM can reach private backends, internal mode plus a WAF-bearing front so clients cannot reach the gateway's backend directly, and the self-hosted gateway for the servers that will never come to the cloud — each with a tier gate worth stating precisely, because the wrong tier is the wrong answer. What is left is the thing every change to a public contract needs: a way to alter the API without breaking the strangers who depend on it, and the instruments to see who is calling what. That is Part H.