1. What and Why

One sentence: Azure API Management is a managed, regional (optionally multi-region) API gateway and governance layer that terminates client calls to your HTTP APIs, applies a declarative policy pipeline to each one, and forwards it to a backend — while separately controlling who may call what, on what terms, and publishing that to them in a developer portal.

The problem before it existed

Picture an organisation with a dozen HTTP APIs. Some are on App Service, two are Functions, one is a SOAP service on a VM that predates everyone in the room, and one lives on-premises behind a VPN. Three teams built them, in three languages, over five years.

Now a partner wants access to four of them. That request generates the same work in four places: issue them a credential, check that credential on every request, stop them exceeding a fair share, log what they did for the invoice, hide the internal error details from them, tell them what the API looks like, and give them a way to rotate the credential when it leaks. Each team implements this slightly differently. Now security mandates that all external traffic must present an Entra-issued token. That's four more pull requests, four more test suites, and four different interpretations of what "validate the token" means.

The analogy: a gateway is the reception desk of a building. Without one, every office fits its own lock, prints its own visitor badges, and keeps its own sign-in sheet — and when the fire policy changes, you renegotiate with every office. With a reception desk, visitors are identified once, issued a badge once, logged once, and directed to the right floor. The offices behind it can then be simple. Crucially, reception doesn't make the offices do anything different; it changes who gets to reach them and on what terms.

That's the shift APIM makes: cross-cutting concerns move out of N backends into one declarative pipeline. A rate limit becomes four lines of XML at one scope instead of a middleware in four codebases. And because that pipeline is an ARM resource, it's reviewable in a pull request.

The second, less-advertised problem it kills is presentation. Backends are shaped by their implementation history: inconsistent paths, a SOAP envelope, an internal ID leaking into a response, a header nobody should see, an error body with a stack trace. APIM lets you publish the API you wish you had in front of the API you actually have. That facade is not free — it's translation logic that has to be maintained — but it decouples "what consumers depend on" from "what the backend team can change," which is often the whole point.

Where it sits

APIM is in Azure's integration category, but it belongs at the boundary of an architecture: in front of compute, behind a global entry point. A complete, common topology reads left to right as

client → Front Door (WAF, global anycast, caching) → API Management (auth, quota, transform, route) → backend (App Service / Functions / Container Apps / AKS / on-prem)

with Key Vault supplying certificates and secrets, Entra ID issuing the tokens APIM validates, and Application Insights collecting what happened.

The overlaps that cause the most confusion, separated:

Confused with	What it actually does	Use it instead when
Azure Front Door	Global anycast entry, CDN caching, WAF, path/host routing across regions	You need global routing, edge caching, or OWASP WAF and have no API-level governance needs. Note it is usually deployed with APIM, not instead of it
Application Gateway	Regional layer-7 load balancer with WAF and TLS termination	You need WAF in one region — typically as the public front for an internal-mode APIM
Azure API Center	A catalogue/inventory of APIs across gateways, with metadata, versions and compliance	You need to know what APIs exist; it never sees traffic
AKS ingress / service mesh	In-cluster north-south routing and east-west mTLS	Traffic never leaves the cluster, or the consumers are other services rather than people and partners
Azure Functions HTTP keys	Per-function shared secrets and basic CORS	You have exactly one API and one consumer
Logic Apps	Workflow orchestration across connectors	The problem is "call six systems in order," not "expose one endpoint safely"

The single-line rule of thumb: if the question is where should this request go, the answer is a load balancer or Front Door. If the question is is this caller allowed to make this request, how many more may they make, and what should the request and response look like on the way through, the answer is API Management.

The AWS analogue, and where it breaks

Amazon API Gateway. The shape transfers: managed front door, per-operation configuration, keys with usage plans, throttling, transformation, custom domains, and a swagger/OpenAPI import path.

Where it breaks — and each of these has bitten someone:

1. Billing model. API Gateway is per-request. APIM (except Consumption) is a provisioned resource billed per unit-hour, running 24/7 whether or not anyone calls it. Budget it like a VM, not like Lambda.
2. Resource granularity. One API Gateway REST API is one resource with its own ARN and resource policy. In APIM, the service is the resource; APIs live inside it. There is no per-API resource policy, so per-team delegation means workspaces (Premium) or multiple instances.
3. No stages. dev/prod stages have no APIM analogue. Revisions are for iterating on one API safely; versions are for breaking changes exposed at different URLs. Environments are normally separate APIM instances.
4. Policies are a genuine pipeline, in XML. Far more capable than mapping templates — control flow, C# expressions, caching, JWT validation, retries, backend selection — and correspondingly more to learn.
5. No built-in WAF. Pair with Front Door or Application Gateway.
6. A developer portal is included, which AWS simply doesn't have.
7. Provisioning is slow on classic tiers — tens of minutes, not seconds ⚠️ verify current figures. This changes how you build pipelines.
8. VPC Link ≈ VNet integration, but APIM's version comes in two flavours — external (public IP, VNet-reachable backends) and internal (no public endpoint at all, private IP only) — and the internal mode is the one enterprises standardise on. Classic internal mode is Premium/Developer only; the v2 tiers reshape this ⚠️ verify current per-tier networking support.

When NOT to use it

The honest anti-patterns, in rough order of how often they're regretted:

• One small API. The gateway costs more than the thing it fronts. If you genuinely have one API, ship it with its own auth and revisit when there are three.
• As a WAF. APIM will validate a JWT, a schema, a size, and a header. It will not stop SQL injection patterns or a botnet. Different layer, different product.
• As a CDN or file server. Capacity units are expensive per gigabyte compared with Blob Storage plus Front Door. Hand out a SAS URL instead of proxying a 200 MB download.
• Between every internal microservice. A shared regional gateway in the middle of an east-west call graph is a shared failure domain, a shared throttle, and an extra hop. Boundary only.
• To fix API design. Rewriting a bad contract in policy XML creates a translation layer that must be maintained forever by whoever least wants to. Sometimes correct as a migration step; rarely correct as a destination.
• As your only authorisation. Anything with network access to the backend bypasses the gateway entirely. Isolate backends at the network layer and keep token validation in the backend for anything that matters. Defence in depth exists because a gateway is a policy, not a wall.
• Developer tier in production. It has every feature and no SLA — a single-instance service Microsoft may restart for maintenance without warning. It is a genuinely good tier for building against, and a genuinely bad one to page someone about at 3 a.m.
• Consumption tier for anything with network requirements. No VNet, no developer portal, no built-in cache, cold starts, stricter payload limits ⚠️ verify the current limitation list. It is excellent for a low-volume, internet-facing, stateless facade and unsuitable for most enterprise designs.

What you should be able to say after this page

• What a gateway is for — cross-cutting concerns and consumer governance in one place.
• Why Front Door and APIM are usually deployed together rather than chosen between.
• The three ways the API Gateway analogy misleads: billing, resource granularity, stages.
• Two anti-patterns you'd push back on in a design review.

---

Next: Core Concepts →

← Back to the Azure API Management overview