Azure API Management in front of your APIs: the sane baseline config

TL;DR: Put APIM between clients and your backends for keys, rate limits, and a stable facade. The baseline: products, subscriptions, rate-limit policies, and a real hostname with cert, not the default azure-api.net URL in prod. Send gateway logs to Log Analytics; alert on backend 5xx rate and throttled requests. Verify: a throttled test key gets 429 while others pass; old API revision still serves during a backend rollout.

The fix

TL;DR: Put APIM between clients and your backends for keys, rate limits, and a stable facade. The baseline: products, subscriptions, rate-limit policies, and a real hostname with cert, not the default azure-api.net URL in prod. Send gateway logs to Log Analytics; alert on backend 5xx rate and throttled requests. Verify: a throttled test key gets 429 while others pass; old API revision still serves during a backend rollout.

The fix

1. SKU. Consumption for low/zero traffic (pay per call), Standard+ for VNet support. Developer SKU for non-prod only (no SLA).
2. Products + subscriptions. One product per audience (internal, partners, public). Subscription keys per consumer; revoke per consumer without touching others.

3. Policies at the product level:

   • rate-limit-by-key / quota-by-key: per-subscription throttles so one consumer cannot starve the rest.
   • validate-jwt at the API level for user-facing APIs; subscription key alone is not user auth.
   • set-backend-service so the public API shape is decoupled from backend URLs.
4. Custom domain + cert. Key Vault-stored cert, hostname bound. The azure-api.net URL is fine for dev, not for customers.
5. Observability. Send gateway logs to Log Analytics; alert on backend 5xx rate and throttled requests.
6. Revisions, not edits. New backend version = new API revision; keep the old revision live until consumers migrate.

Traps:

• Rate limit at the API level only: one noisy consumer eats the shared budget. Per-subscription keys exist for this.
• Caching responses that should not be cached: APIM response caching is off by default; when you enable it, scope by subscription key or users see each other's data.
• Forgetting the developer portal: internal consumers need docs; publish the portal or answer the same questions forever.

Verify: a throttled test key gets 429 while others pass; old API revision still serves during a backend rollout.

When to use this

• This covers exactly what the title says: Azure API Management in front of your APIs.
• You are setting this up for the first time, or auditing an existing setup.
• You want the key gotchas in one place before you start.

When not to use this

• You are doing a different workflow with Azure; these steps are specific to the title above.
• You need the full reference docs; this is the short path, not the manual.

Proactive workflow skill. APIM policy and product pattern verified against current API Management docs. Evidence: https://learn.microsoft.com/en-us/azure/api-management/api-management-key-concepts