**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.