API Gateway Azure: Options, Setup, and When to Skip It

When people search "api gateway azure" they're usually looking for one of two things: Azure API Management (APIM), Microsoft's dedicated API gateway product, or Azure Application Gateway, a load balancer that can act as a reverse proxy in front of APIs. These are not the same service, and picking the wrong one wastes weeks.

The short answer: if you need API-specific features — rate limiting per key, request/response transformation, developer portals, subscription keys, policy-based auth — use Azure API Management. If you just need Layer 7 load balancing, SSL termination, and path-based routing without API-lifecycle features, Application Gateway (or Azure Front Door) is enough and cheaper. This article covers both, how to set them up, and when a self-hosted gateway is overkill compared to a managed API layer.

Azure API Management vs Application Gateway

Azure API Management is a full API gateway: it fronts your backend services, applies policies (rate limiting, JWT validation, caching, transformation), and gives you a developer portal where consumers can get API keys. It's built for exposing APIs to external or internal developers as products.

Application Gateway is infrastructure-layer routing. It terminates TLS, does URL-based routing, and can run a Web Application Firewall (WAF), but it has no concept of API products, subscriptions, or per-consumer quotas. Teams often put Application Gateway in front of APIM for network-level protection, with APIM handling the API logic behind it.

If your question is "how do I put a gateway in front of my APIs on Azure," APIM is almost always the right layer. Application Gateway is for infrastructure teams solving TLS and routing problems, not API governance problems.

Setting Up Azure API Management (Basic Flow)

1. Create an APIM instance — choose a tier (Consumption, Developer, Basic, Standard, Premium). Consumption is serverless and billed per call; Premium supports multi-region and VNET integration.
2. Import or define your API — either import an OpenAPI spec, a Function App, or define endpoints manually.
3. Attach policies — XML-based policy documents applied at the inbound, backend, or outbound stage. Common examples:

<inbound>
  <rate-limit calls="100" renewal-period="60" />
  <validate-jwt header-name="Authorization">
    <openid-config url="https://login.microsoftonline.com/{tenant}/v2.0/.well-known/openid-configuration" />
  </validate-jwt>
</inbound>

1. Publish a product — bundle one or more APIs into a "product" with subscription keys, then let developers request access through the portal.

This works well, but it's infrastructure you now own: you're responsible for policy XML, backend health, quota enforcement, and portal maintenance. For a handful of internal microservices that's fine. For exposing a single third-party API to your own app, it's often more machinery than the problem needs.

When You Don't Need a Full Gateway

A common Azure scenario: a team wants to expose an LLM (say, Claude via a Claude Code / Claude Max seat, or another model) to their product as an internal API, with per-app keys and usage tracking. Standing up APIM for this means building the auth policies, streaming pass-through, and usage logging yourself — none of which APIM gives you out of the box for LLM-specific concerns like token usage or tool-call metadata.

This is where a purpose-built layer like SubToAPI fits instead of a general API gateway. It turns an existing Claude subscription into a proper HTTPS API — issuing scoped sub_live_... keys per application, handling streaming and tool use, and reporting usage per key — without you configuring rate-limit policies or JWT validation rules in a gateway product. You get the API-key-per-consumer pattern APIM is built for, but scoped specifically to Claude access instead of generic backend routing.

A minimal request looks like this:

curl https://api.subtoapi.app/v1/messages \
  -H "Authorization: Bearer $SUBTOAPI_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-sonnet-4-5",
    "max_tokens": 1024,
    "messages": [{"role": "user", "content": "Summarize this Azure incident report."}]
  }'

If your actual need is "give my apps individual keys to call an AI model with usage tracking," that's a narrower, cheaper problem than deploying and maintaining APIM. See /docs/quickstart for the full setup, /docs/messages for the request format, and /docs/streaming if you need token-by-token output. Pricing starts with a free trial and Solo at €9 — see /pricing.

Choosing Based on What You're Actually Fronting

• Multiple internal microservices, need policy governance and a dev portal → Azure API Management.
• Just need TLS termination and path routing, no API lifecycle features → Application Gateway or Front Door.
• Exposing a third-party AI model to internal apps with per-app keys and usage reporting → a purpose-built API layer like SubToAPI is faster to stand up than configuring APIM policies for something it wasn't designed for.
• High-throughput public API with SLAs and versioning → APIM Premium tier, likely with Application Gateway or Front Door in front for WAF and global routing.

The mistake to avoid is defaulting to "put APIM in front of everything." It's a strong product for API governance at scale, but every API you route through it is now dependent on policy XML you maintain, quota configuration you tune, and a portal you keep patched. For narrower, single-purpose integrations — especially AI API access — a managed layer built for that specific job usually gets you to production faster.

Questions

Is Azure API Management the same as an API gateway? Yes — APIM is Microsoft's managed API gateway product. It handles routing, authentication, rate limiting, and developer access to your APIs, distinct from Application Gateway, which is a Layer 7 load balancer.

Do I need Application Gateway if I already use APIM? Not necessarily. Many teams add it for TLS termination and WAF protection at the network edge before traffic reaches APIM, but APIM alone is sufficient for most single-region API workloads.

What's a lighter alternative to APIM for exposing an AI model as an API? A purpose-built service like SubToAPI gives you per-application API keys, streaming, and usage metadata for Claude access without deploying and maintaining a general-purpose gateway — see /docs to get started.