The road around the desk
Parts D and F configured API Management (APIM) to authenticate, limit, and log requests. Those APIM checks apply only to requests that pass through APIM. Imagine a catalog API whose backend app also accepts calls at a public address. A caller who finds that address may bypass APIM's checks. The backend might have its own authentication, but you must verify it; the gateway's policy cannot protect a path it never sees.
Ask two questions separately: Who can reach the gateway? And who can reach the backend? A private gateway does not automatically make the backend private. A private backend does not automatically close the gateway's public endpoint. The controls below solve different parts of that design:
- VNet injection
- Placing APIM in an Azure virtual network (VNet), a private network you control. Classic Developer and Premium tiers offer external and internal modes. Premium v2 has a separate injection model.1
- External vs internal
- In classic injection, external mode keeps a public gateway endpoint while reaching private backends. Internal mode gives the gateway a private VNet address. Network peers may still reach it unless you restrict them.
- Private endpoint
- A private IP for a specific service. A private endpoint on APIM handles inbound calls to its gateway; a separate private endpoint on the backend lets APIM reach that backend privately. Neither one disables that service's public access by itself.
- 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
- Two ways to publish a controlled entry point. Application Gateway can forward to classic internal APIM from a connected VNet. Front Door requires a supported private origin connection, such as Private Link in eligible v2 configurations or a correctly configured Application Gateway origin.2
Before any tier or VNet choice
Draw three boxes: caller, gateway, backend. Draw an arrow for each leg: caller to gateway, gateway to backend.
Beside each arrow write who can use it today: anyone on the internet, only your network, or only the gateway.
Now draw the third arrow nobody intended: caller straight to backend. Is it possible in your design? If yes, the gateway's policies do not apply to it.
Check your drawing
The fix in §1 closes the third arrow first: the backend accepts traffic only from the gateway. Which tier and VNet model you then need (§2 to §4) depends on where the two legs have to run, so choose it after this drawing.
VNet injection — external and internal
With classic virtual network injection, APIM runs in a subnet of your VNet. From there, it can call an API backend with private network connectivity: for example, an App Service reached through its own private endpoint, or an on-premises API reached across VPN or ExpressRoute. Configure routing and DNS so the backend name resolves to the private address. Classic injection is available in the Developer and Premium tiers. Its two modes differ in how callers reach APIM:
External mode keeps a public gateway endpoint while allowing private backend access. Use it when direct public access to APIM is intentional. Internal mode makes the gateway, developer portal, and management endpoints reachable through the VNet rather than directly from the public internet. It suits a private API or a gateway published through a separate, deliberately configured front end. Private-network reachability remains; use network rules and authentication to control it.
A desk you can walk around is a decoration.
Do not use one tier's instructions for another. Standard v2 and Premium v2 support outbound VNet integration for reaching private backends. Premium v2 also has its own VNet injection model for private gateway and backend connectivity. An inbound private endpoint on APIM is another distinct option: it provides a private route to the gateway, not a route from APIM to the backend. Check the current tier, region, DNS, and supported combinations before choosing a design.1
Play it through
Three minutes. Find both side doors around the WAF, close the first by moving the gateway inside the network, then close the second by taking the backend off the internet entirely. It plays on its own and stops when it needs your hands.
This part carries no live lab. The game models a classic Developer/Premium APIM instance in internal mode, an Application Gateway in a connected VNet, and a backend with its own private endpoint and public access disabled. The APIM instance does not need an additional inbound private endpoint in this design. Provisioning and validating all three services would be costly for a short exercise; Class 14 covers the underlying private-connectivity steps. Use the game to practice identifying which public path each change closes.
Private endpoints, and fronting APIM with a WAF
A private endpoint on APIM gives clients a private route to its gateway through Azure Private Link. On supported configurations, you can then disable APIM public network access. That private endpoint does not help APIM reach private backends. Conversely, a private endpoint on a backend gives APIM a private route to that service, provided APIM has outbound network connectivity and DNS resolves the backend name correctly. Disable the backend's public access separately. The same phrase, “private endpoint,” means different traffic directions depending on which resource owns it.3
For a public API that should have one controlled public entry, Figure 1 uses an internet-facing Application Gateway with WAF forwarding to classic internal APIM. Application Gateway needs network and DNS reachability to APIM. The backend needs its own private connection and public access disabled. Azure Front Door is a separate global-front option, but it needs a supported private connection to its origin; do not replace the Application Gateway box with Front Door without designing that connection. Neither front end inspects calls that originate inside the private network, so test those paths and require backend authentication too.2
The self-hosted gateway — when the backend can't move
Some APIs live in a data centre or another cloud, and their callers are nearby. Sending every API call through Azure and back can add latency and cost, and it may conflict with a locality requirement. A self-hosted gateway is a containerized APIM gateway you run near such a backend. A local caller can then reach the local gateway and backend without routing that API request through the Azure-managed gateway. Its policies and configuration are managed from an Azure APIM instance. This feature is available in the Developer and Premium tiers; check whether each caller and dependency truly stays local before making a data-residency claim.
The self-hosted gateway makes outbound connections to required Azure endpoints on port 443 for configuration, health reports, and optional telemetry; those dependencies need working DNS and reachability. During a temporary Azure connection loss, a running gateway can continue with its cached configuration but receives no updates or telemetry delivery. A stopped gateway needs a configured persistent backup to start while disconnected. Backend, identity, and other policy dependencies can still fail independently. Test those conditions before calling the local service resilient.4
A gateway with no front door, and one that travels
In this fictional case, a reviewer reaches Campux's catalog App Service directly at its public endpoint, bypassing APIM's rate limit. Campux gives the backend a private endpoint, configures DNS so APIM reaches that address, and separately disables public access on the App Service. Classic internal APIM sits behind an internet-facing Application Gateway with WAF. The team verifies that the old direct public requests fail and that intended calls pass through the WAF and APIM. They also review which other private-network clients can reach either service and keep backend authentication enabled.
For the warehouse API, Campux runs a self-hosted gateway near the stock server. In-store tills call that local gateway, avoiding an Azure round trip for each stock lookup. Campux still needs outbound Azure connectivity for updates and telemetry. During a temporary outage, a running gateway can use cached configuration; the team tests that the stock server and any required identity service remain reachable, and enables persistent configuration backup if restart during an outage is required.
Prove the paths
Network design determines which requests can reach APIM and its backend. To verify it, test a call through the intended public front, a direct public call to APIM, a direct public call to the backend, and access from relevant private networks. Confirm DNS, network rules, and backend authentication as well as endpoints. A self-hosted gateway is a separate answer when API traffic should stay near a remote backend. Part H covers how to change and observe the API after these paths are in place.
The backend nobody knew was public
In this fictional review, a tester calls the catalog backend's public endpoint without passing through APIM and avoids its rate limit. You configure private backend access and DNS, disable the backend's public access, and put classic internal APIM behind Application Gateway with WAF. Re-run calls through the intended path and directly from the internet to both services. Then test from allowed private networks: internal mode does not make APIM inaccessible to every other VNet client. Document which paths are allowed and ensure the backend enforces its own authentication.
Continue with a supplied build
Follow the same fictional catalogue through this track. The supplied contract and worked checks let you practise without an Azure estate; the optional import/mock path makes real gateway requests. Each step states what it proves and what it does not.
Examination
Four drills, then two situations. The situations have no marking scheme — write your answer before you reveal the reasoning, or the exercise is worthless. Nothing is stored; this is between you and the page.
B — use classic internal mode. It places the gateway, portal, and management endpoints behind VNet connectivity. A keeps a public gateway endpoint. C names a tier that does not offer classic injection. D confuses a different feature with a mode: an inbound private endpoint can give a supported APIM configuration private gateway access, but it does not convert external injection to internal, and classic injected APIM cannot add that inbound private endpoint. Figure 1 uses Application Gateway to publish the intended public path.
B — run the gateway near the backend. Local callers can reach the warehouse gateway and stock server without sending each API request through Azure. The gateway still needs outbound Azure connectivity for configuration and reporting. During a temporary disconnect, a running gateway can use cached configuration; test its other dependencies separately. A sends calls to Azure before returning to the warehouse. C gives no private route to an arbitrary on-premises server. D adds another management plane instead of a local gateway managed from the existing APIM instance.
Options two, four, and five are correct. A private endpoint on APIM handles inbound gateway traffic. Classic external/internal injection is a Developer/Premium feature. A running self-hosted gateway can keep using cached configuration during a temporary Azure connection loss, although it receives no updates and cannot report telemetry then; a stopped instance needs persistent backup to start disconnected. The first option is false because classic internal mode puts the portal behind private connectivity too. The third is false because APIM's inbound private endpoint does not provide outbound backend connectivity.
# private api platform — network design
1. APIM deployed in internal VNet mode:
no public endpoint on the gateway.
2. Backend has a private endpoint reachable
by APIM through private DNS.
3. Backend also keeps public access enabled
as a fallback, "just in case."
4. Application Gateway with WAF is the one
public front; forwards to internal APIM.
Line three leaves a public bypass. A caller could reach the backend without passing through APIM or its WAF. The backend may still authenticate callers, but APIM's policies would not apply. Keep the private endpoint in line two, disable the backend's public access, and verify that APIM resolves and reaches the private address. Internal mode in line one closes APIM's direct public gateway route; Application Gateway with WAF in line four provides the intended public entry. Finally, test private-network paths and backend authentication separately.
Identify the resource first. The proposed private endpoint belongs to APIM, so it handles inbound calls to the gateway. On supported configurations, disable APIM public access after creating it. That does not give APIM a private route to the backend.
Inspect the backend separately. Give APIM supported outbound VNet connectivity, configure the backend's own private connection and DNS, and disable the backend's public access. Adding either private endpoint alone does not disable a public endpoint.
Test the intended design. For classic internal APIM, an Application Gateway with WAF can publish the public route. Other tier combinations need their own supported origin design. Test direct public calls to APIM and the backend, then check which private-network callers can still reach them. Keep backend authentication because private network location alone is not an identity check.
Lead with the principle: one control plane, gateways where the backends live. "I keep a single Azure APIM instance as the place I author policies, issue subscriptions, and read analytics — one control plane — and I put the data plane wherever the backend actually is. That is the whole reason the self-hosted gateway exists, and it is what keeps this from becoming three products to operate." Saying that first shows you are designing a system, not stacking features.
Map each location. In Azure, choose supported VNet connectivity so APIM can reach each private backend. Configure backend private endpoints and DNS where appropriate, then disable public access separately. In another cloud and the data centre, a self-hosted gateway near each backend can serve local callers without routing each API call through Azure. It needs outbound connectivity to required Azure endpoints on port 443 for updates and reporting. A running gateway can use cached configuration during a temporary disconnect, but you must test its backend and identity dependencies.
Close by being precise about tiers, because the question demanded it. "Both the classic external/internal VNet injection and the self-hosted gateway are Developer and Premium tier features — so a design that leans on either lives on Premium in production, with Developer for non-prod. If someone wants this on a cheaper tier, that is the constraint that has to give, and I would rather say so up front than discover it at deployment." Naming the tier gate without being asked twice is the detail that separates someone who has built this from someone who has only read the marketing page.
Five things worth carrying out of this part
- APIM policies apply only to calls through APIM. Test direct public paths to the gateway and backend, then test private-network paths and backend authentication.
- Classic VNet injection puts APIM in your VNet. External permits direct public access; internal uses private VNet access. Classic injection supports Developer / Premium; Premium v2 has a separate injection model.
- A private endpoint on APIM handles inbound gateway access. A separate private endpoint on a backend can make that backend reachable privately. Disable each resource's public access separately; classic injected APIM cannot combine with an inbound APIM private endpoint.
- One public-entry design is Application Gateway with WAF → classic internal APIM → private backend. Front Door requires its own supported private-origin design. Neither front end automatically controls internal callers.
- A self-hosted gateway runs near remote APIs and needs outbound access to Azure. A running instance can use cached configuration during a temporary Azure disconnect; test restart and policy dependencies. It is a Developer / Premium feature.
- Microsoft documents classic Developer/Premium injection and Premium v2 injection separately. Check the current networking matrix for tier and region support before deployment. ↩
- Microsoft's classic internal APIM with Application Gateway guide documents Figure 1's front end. For Front Door, follow the supported Private Link and origin configurations; Front Door cannot simply reach an arbitrary internal VNet address. See also Front Door vs Application Gateway. ↩
- Microsoft's APIM private endpoint guidance says the endpoint is inbound to the gateway, public access must be disabled separately, and classic VNet-injected instances cannot add this inbound Private Link connection. A backend's private endpoint is a separate resource. ↩
- Microsoft's self-hosted gateway overview distinguishes a running gateway's in-memory configuration from restarting during disconnection, which requires persistent configuration backup. ↩
Trace caller-to-gateway and gateway-to-backend access, and choose a supported API Management networking model.
Play the lesson above to stamp this class.