authentication standards is not policy enforcement. I have seen both confused with security —
and watched the audit trail conversation happen six months later, in the wrong room.
The Problem a Gateway Solves That Teams Cannot
On a platform with multiple teams building services and multiple consumer groups calling
them — portal users, a co-delivery partner, external integrations — the authentication
question surfaces early and gets answered the wrong way. Each service team addresses it
independently. JWT validation is implemented here, API key check there, custom HMAC
somewhere else. The implementations are individually defensible. Collectively they are
ungovernable.
When a security team asks “show me every external call made to service X in the last
72 hours,” the answer is: open four dashboards, correlate four log formats, write a join
query. That is not a security posture. That is security theatre with extra steps.
What APIM Actually Enforces
Azure API Management’s value is not routing. It is the policy layer that executes
before a request reaches a service. The key policies in production environments:
- JWT validation at the gateway. Every request carries an Entra ID token.
APIM validates the signature, audience, and expiry before routing. Services on the
private network receive pre-authenticated requests and do not implement their own auth.
No drift. No inconsistency. - Rate limiting per subscription. An integration partner with a
misconfigured retry loop cannot flood backend pods. The limit is applied at APIM before
the request touches AKS. Consumer isolation is enforced, not assumed. - Transformation across versions. When a backend service changes its
response schema, APIM applies an outbound transformation policy. v1 consumers keep
working. The API surface is stable while the implementation evolves behind it. - Request/response logging to Log Analytics. Every call, with identity,
latency, and status code, lands in one workspace. The security team’s 72-hour query
becomes a two-line KQL.
Azure API Management is the only ingress point for all external and partner API calls. No service is reachable externally except through the gateway. APIM authenticates, rate-limits, transforms, and logs. Services trust the private network, not individual callers.
What We Did Not Use APIM For
Internal service-to-service calls within the AKS cluster stay off the gateway. Routing
a service-mesh call through an external gateway adds latency for no security benefit when
both services share the same network boundary and use workload identity. The trust boundary
is between the public internet and the private network — not between pods in the same
namespace.
Application Gateway sits in front of APIM and handles DDoS protection and WAF rule
evaluation. They are not interchangeable. Application Gateway understands HTTP at the
network layer. APIM understands HTTP at the API semantic layer. Both have a role. Replacing
one with the other loses something real.
What APIM does not fix: a service that is designed to accept any caller without validating the APIM-forwarded identity header. If a service is exposed to the internal network and trusts all requests from it, a compromised internal component has full access. Zero Trust means verifying even internal callers — APIM makes that possible; it does not enforce it automatically.
The Conversation That Changed
The developer portal changed a relationship, not just a workflow. An IBM co-delivery
team that previously waited for endpoint documentation in email was suddenly self-sufficient.
They discovered APIs, read the OpenAPI spec, generated a subscription key, and ran their
first successful test call — without raising a request to the platform team.
That shift in dynamic is worth more than the licence cost. Documentation that lives in
a portal gets used. Documentation sent in email gets buried. An API that can be tested
interactively before a single line of integration code is written is an API that gets
integrated correctly the first time.