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

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.

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