1. APIM Role in Architecture

APIM implements the facade pattern — a single, consistent entry point that hides the complexity of multiple backend services. This decouples frontend consumers from backend implementation details and centralises cross-cutting concerns.

Cross-Cutting Concerns Handled by APIM

• Authentication & authorization — validate tokens before traffic reaches backends
• Rate limiting & throttling — protect backends from burst traffic
• Caching — reduce backend load for read-heavy APIs
• Request/response transformation — reshape payloads without changing backends
• Logging & analytics — unified telemetry across all APIs
• Versioning & deprecation — expose stable contracts while evolving backends

2. APIM Tiers — Decision Matrix

Choosing the right tier is a cost-vs-capability trade-off that appears frequently on AZ-305.

3. APIM Architecture

Every APIM instance comprises three logical components:

• Gateway (data plane) — proxies API calls, enforces policies, routes to backends. This is the performance-critical path.
• Management plane — Azure Resource Manager APIs + Azure portal experience for configuring APIs, products, policies, users.
• Developer portal — auto-generated, customisable documentation site where API consumers discover, test, and subscribe to APIs.

Policy Pipeline

Policies execute at four stages of a request lifecycle:

1. Inbound — runs before the request reaches the backend (auth, rate-limit, transform)
2. Backend — runs just before forwarding (set backend URL, client cert)
3. Outbound — runs after backend response (transform, cache-store, headers)
4. On-error — runs if any stage throws an exception

<policies>
    <inbound>
        <rate-limit calls="100" renewal-period="60" />
        <validate-jwt header-name="Authorization" ...>
    </inbound>
    <backend>
        <forward-request />
    </backend>
    <outbound>
        <cache-store duration="300" />
    </outbound>
    <on-error>
        <set-body>@("Error: " + context.LastError.Message)</set-body>
    </on-error>
</policies>

4. Key Policies

5. Backend Abstraction: Versioning & Revisions

Versioning Strategies

Revisions vs Versions

• Revision — non-breaking changes (bug fix, add optional field). Consumers don't notice. You can test a revision before making it current. Think: git branch before merge.
• Version — breaking changes (removed field, new auth model). Consumers choose which version to call. Think: v1 vs v2 coexisting.

6. Security Patterns

OAuth 2.0 Flow Through APIM

Security Layers

7. Networking: VNet Modes & Self-Hosted Gateway

VNet Integration Modes (Premium Only)

Self-Hosted Gateway

A containerised gateway you deploy on-premises, in other clouds, or at the edge. It connects back to the APIM management plane for configuration sync.

• Runs as a Docker container or Kubernetes deployment
• Enables hybrid/multi-cloud API governance with a single control plane
• Policies and API definitions sync from the Azure-hosted management plane
• Available on Developer and Premium tiers

8. Multi-Region Deployment

Premium tier supports deploying additional gateway units to multiple Azure regions, providing:

• Lower latency — clients route to the nearest gateway via Traffic Manager / Front Door
• Higher availability — if one region fails, traffic shifts to healthy regions (99.99% SLA)
• Compliance — keep data processing in-region where required

How It Works

1. Primary region hosts the management plane (one region always "primary")
2. Additional regions host gateway units only
3. Configuration syncs automatically from primary to all regions
4. Each region can have its own backend pool (use set-backend-service policy with expressions to route by region)

9. Real-World: Banking API Platform

10. Knowledge Check