This chapter covers Azure API Management (APIM), a critical service for designing, publishing, securing, and governing APIs at scale. For the AZ-305 exam, this topic falls under Objective 4.4 (Design an API Management strategy) and appears in roughly 5-8% of questions. You must understand APIM's components, policies, security options, and how it integrates with other Azure services to design a robust API gateway solution. We will cover everything from the core architecture to advanced governance patterns.
Jump to a section
Imagine a large corporation with thousands of employees, each with a different role and location. The mailroom is the single point of entry for all external postal mail. When a package arrives, the mailroom clerk checks the address, verifies the sender against a trusted list, logs the package, and then routes it to the correct internal department. If the package is from an unknown sender, the clerk may inspect it, reject it, or forward it for security review. The mailroom also enforces corporate policies: no personal packages over 10 pounds, no hazardous materials. It can transform packages by repackaging them into internal envelopes, add tracking labels, and cache frequently received items for faster delivery. Incoming mail is also transformed: external letters are scanned and converted to internal digital memos. Outgoing mail from employees goes through the same mailroom, which checks addresses, adds postage, and logs all outbound packages. This mailroom is the API Management service: it sits between external consumers (senders) and internal backend APIs (departments). It authenticates, authorizes, rate-limits, transforms requests/responses, caches responses, logs all traffic, and enforces governance policies—just like the corporate mailroom handles, secures, and optimizes mail flow.
What is Azure API Management and Why Does It Exist?
Azure API Management (APIM) is a fully managed service that enables organizations to publish, secure, transform, maintain, and monitor APIs. It acts as a facade or gateway between API consumers (developers, partners, internal apps) and backend services. The primary reasons for using APIM include: - Security: Protect backend APIs from unauthorized access, DDoS attacks, and injection threats. - Governance: Enforce usage quotas, rate limits, and access policies. - Transformation: Convert between protocols (e.g., SOAP to REST), modify request/response formats, and aggregate multiple APIs. - Monitoring: Gain insights into API usage, latency, errors, and trends. - Developer Experience: Provide a developer portal for API discovery, documentation, and key management.
How APIM Works Internally
APIM operates as a reverse proxy that intercepts all API calls. Each request passes through a pipeline of policies configured at different scopes: - Global: Applies to all APIs in the service. - Product: Applies to a product (a grouping of APIs). - API: Applies to a specific API. - Operation: Applies to a single operation (e.g., GET /users).
The pipeline has two phases: inbound (request processing before hitting backend) and outbound (response processing before returning to client). Policies are XML-based and can include conditional logic, variable manipulation, and external calls.
Key Components
API Gateway: The endpoint that accepts API calls. Each APIM instance has a gateway URL (e.g., https://myapim.azure-api.net). It handles all runtime traffic.
Management Plane: Azure portal, REST API, PowerShell, CLI, or ARM templates for configuration.
Developer Portal: A customizable website where developers can browse APIs, read documentation, test endpoints, and subscribe to products.
Products: A way to package APIs for different audiences. Each product has a set of APIs, a display name, description, and subscription approval requirements (open, requires approval, or admin-only).
Subscriptions: A subscription key is a unique key that identifies a consumer. It can be at the product scope (most common) or API scope. Keys can be regenerated, and there are primary/secondary keys for zero-downtime rotation.
Policies: XML-based rules that execute in the gateway pipeline. Examples: set header, validate JWT, rate limit, cache response, convert XML to JSON.
Backend: The actual API service behind APIM. Configured with URL, credentials, and TLS settings.
Named Values: Key-value pairs for secrets or configuration (e.g., connection strings, API keys) that can be referenced in policies.
Default Values and Timers
Rate Limit Policy: calls (max number of calls) and renewal-period (in seconds, default 60).
Quota Policy: calls (max calls per time window) and renewal-period (seconds, default 86400 for daily).
Cache-Response: duration in seconds (default 300).
Subscription Key Header: Default header name is Ocp-Apim-Subscription-Key.
Developer Portal: Default URL is https://<service-name>.developer.azure-api.net.
Configuration and Verification Commands
To create an APIM instance using Azure CLI:
az apim create --name myapim --resource-group myRG --publisher-email admin@contoso.com --publisher-name Contoso --sku Developer --location eastusTo apply a policy using CLI:
az apim api policy set --service-name myapim --api-id myapi --policy-format xml --policy @policy.xmlTo get metrics:
az monitor metrics list --resource /subscriptions/.../service/myapim --metric RequestsInteraction with Related Technologies
Azure AD: APIM can validate JWT tokens issued by Azure AD. Use the validate-jwt policy to check token signature, issuer, and roles.
Azure Functions: APIM can proxy requests to serverless functions, providing a consistent API facade.
Event Grid: APIM can publish events to Event Grid for asynchronous processing (e.g., logging, analytics).
Application Insights: APIM can send telemetry to Application Insights for deep monitoring. Enable via the azure-monitor logger.
Azure Front Door: Used for global load balancing and WAF protection in front of APIM.
Azure Key Vault: Store and reference secrets (e.g., SSL certificates, backend credentials) via named values with Key Vault references.
Advanced Governance Patterns
Multi-tier Rate Limiting: Apply rate limits at global, product, and API levels to protect backend.
IP Filtering: Use ip-filter policy to allow or deny specific IP ranges.
CORS: Use cors policy to enable cross-origin requests from specific origins.
Backend Circuit Breaker: APIM does not have native circuit breaker, but you can implement using retry policy with exponential backoff and limit-concurrency to throttle.
API Versioning: Use URL path, query string, or header-based versioning. Combine with API revisions for non-breaking changes.
Security Considerations
TLS: APIM supports TLS 1.2 by default. Older versions can be disabled.
Certificate Validation: APIM can validate client certificates (mutual TLS) using validate-client-cert policy.
OAuth2/OpenID Connect: Use validate-jwt policy with Azure AD or any OpenID provider.
Managed Identity: APIM can authenticate to backends using a system-assigned or user-assigned managed identity, avoiding secrets.
Performance and Scaling
APIM offers four tiers: - Developer: For dev/test, no SLA, limited scale. - Basic: For production with low traffic, 1 unit, SLA 99.9%. - Standard: For production with moderate traffic, auto-scale up to 10 units, SLA 99.95%. - Premium: For enterprise, multi-region, VNet injection, auto-scale up to 10 units, SLA 99.99%.
Capacity is measured in units. Each unit handles a certain number of requests per second (RPS) depending on the tier and operation complexity. Typical baseline: Standard unit can handle ~1,000 RPS for simple pass-through.
Monitoring and Alerts
Use Azure Monitor to track: - Requests: Total API calls. - Duration: Average latency. - Errors: 4xx and 5xx status codes. - Capacity: Percentage of gateway capacity used.
Set alerts for high error rate or capacity nearing 90%.
Disaster Recovery
For Premium tier, deploy APIM in multiple regions with traffic routing via Azure Traffic Manager or Front Door. Each region has its own gateway endpoint. Use the same APIM service name but different regional gateways. Backup and restore the APIM configuration using ARM templates.
Create APIM Instance
In the Azure portal, navigate to Create a resource > API Management. Fill in subscription, resource group, region, organization name, admin email, pricing tier (Developer, Basic, Standard, Premium). Pricing tier determines SLA, features (VNet support, multi-region), and capacity. For production, use at least Standard. Enable Application Insights for monitoring. Deployment takes 20-40 minutes. After creation, note the gateway URL and developer portal URL.
Configure Backend API
In the APIM instance, go to APIs > Add API. You can import from Azure services (Function App, Logic App, Web App), OpenAPI/Swagger spec, WSDL, or create a blank API. Define the backend URL (e.g., https://myapp.azurewebsites.net). Set the API URL suffix (e.g., /api/v1). Configure authentication: Basic, Client Certificate, or Managed Identity. Test the connection by sending a request from the Test tab.
Define Products and Subscriptions
Create a product (Products > Add) to group APIs. Set product name, description, and subscription required (yes). Choose subscription approval: Open (auto-approve), Requires approval (admin must approve), or Admin-only (only admins can subscribe). Add APIs to the product. Developers subscribe to the product via the developer portal or by contacting admin. Each subscription generates a primary and secondary key.
Apply Policies for Governance
Navigate to APIs > All APIs > Design > Policies. Add inbound policies: rate-limit-by-key (throttle calls per key), set-header (add headers), validate-jwt (verify tokens). Add outbound policies: set-body (transform response), cache-response (cache responses). Use XML policy snippets. Test the policy by sending requests that exceed the rate limit—expect 429 Too Many Requests.
Enable Developer Portal
In the APIM portal, go to Developer portal > Portal settings. Customize the portal's look and feel using the built-in editor or export/import content. Publish the portal to make it accessible. Developers sign up, browse APIs, read documentation, and subscribe to products. You can also enable OAuth2 for portal sign-in. The portal URL is https://<service-name>.developer.azure-api.net.
Enterprise Scenario 1: Retail API Ecosystem
A large retailer exposes inventory, pricing, and order APIs to third-party sellers. They use APIM Standard tier with 3 units. The challenge: different sellers have different rate limits (e.g., premium sellers get 1000 req/min, basic get 100 req/min). Solution: Use products for each tier. The product 'Premium' has a rate-limit policy of 1000 per minute, 'Basic' has 100. Subscription keys identify the seller. The backend is an Azure App Service behind a VNet. APIM is injected into the VNet (Premium tier) for private connectivity. They also use OAuth2 with Azure AD for seller authentication. Monitoring: Application Insights tracks latency; they alert if p99 latency exceeds 500ms. Common misconfiguration: forgetting to set the 'renewal-period' in rate-limit policy, causing the limit to reset unexpectedly (default 60 seconds, not 60 minutes). They learned to explicitly set renewal-period to 60 for per-minute limits.
Enterprise Scenario 2: Legacy SOAP to REST Migration
A financial institution has a legacy SOAP service for account lookups. They want to expose it as a modern RESTful API. APIM's SOAP-to-REST policy transforms the request. The backend is a SOAP service with WSDL. In APIM, they import the WSDL and define REST operations that map to SOAP actions. The policy 'convert-soap-to-rest' handles the transformation. They also add a 'validate-xml' policy to ensure incoming SOAP requests are well-formed. Problem: The SOAP service requires client certificates for authentication. They use APIM's 'validate-client-cert' policy to check the thumbprint. They also cache responses to reduce load on the legacy system (cache duration 60 seconds). Performance: The legacy system can handle 50 req/s; APIM rate-limits to 40 req/s to avoid overload. They monitor backend health using health probes and route to a secondary legacy service if primary fails.
Enterprise Scenario 3: Multi-region High Availability
A SaaS company with global customers uses APIM Premium tier in two regions (East US and West Europe). They use Azure Front Door to route traffic to the nearest APIM gateway. Each APIM instance points to the same backend (a multi-region Azure SQL Database). They set up APIM policies to cache responses per region (e.g., Europe cache includes EU-specific data). Disaster recovery: If a region fails, Front Door routes all traffic to the healthy region. They also backup APIM configuration using ARM templates to Azure DevOps. Common issue: Rate limits are per gateway instance, so a user hitting both regions could exceed the intended global limit. Solution: Use Azure Redis Cache to synchronize rate-limit counters across regions (custom policy). They also use named values with Key Vault references for database connection strings, rotating secrets monthly.
What AZ-305 Tests on API Management
Objective 4.4: Design an API Management strategy. Sub-objectives include:
Choose between APIM tiers (Developer, Basic, Standard, Premium) based on requirements for SLA, VNet, multi-region, and scale.
Design API security: authentication (subscription keys, OAuth2, JWT, client certificates), authorization (Azure AD roles, custom claims).
Design API governance: rate limiting, quotas, throttling, caching, IP filtering.
Design API versioning and revisions: URL path vs. query vs. header versioning; revision lifecycle.
Integrate with Azure services: Functions, Logic Apps, Event Grid, Key Vault, Application Insights.
Design for high availability: multi-region Premium, Front Door, Traffic Manager.
Common Wrong Answers and Traps
Choosing Basic tier for production with VNet integration: Basic does not support VNet injection. Candidates often pick Basic because it has an SLA, but VNet requires Premium.
Using subscription key as the only authentication method for sensitive APIs: Subscription keys are not secure for authentication; they are for identification and rate limiting. Always combine with OAuth2/JWT for sensitive APIs.
Confusing API revisions with API versions: Revisions are for non-breaking changes (you can roll back). Versions are for breaking changes (different URL paths). The exam tests that revisions are isolated with a revision number.
Thinking rate limiting is applied per API by default: Rate limiting must be explicitly configured in policies. Without a policy, there is no rate limit.
Selecting Developer tier for production: Developer tier has no SLA and limited capacity. It is for dev/test only.
Specific Numbers and Terms
SLA: Developer (0%), Basic (99.9%), Standard (99.95%), Premium (99.99%).
Default subscription key header: Ocp-Apim-Subscription-Key.
Capacity unit: Basic/Standard/Premium up to 10 units.
Rate limit policy: calls and renewal-period (seconds).
Cache duration default: 300 seconds.
Premium tier supports: VNet injection, multi-region deployment, Azure AD integration.
Edge Cases
Self-hosted gateway: For on-premises or other clouds, use self-hosted gateway (containers) with Premium tier. The exam may ask when to use self-hosted vs. managed.
API Management in VNet: Only Premium tier supports VNet injection. The gateway can be internal (private IP only) or external (public and private).
Multiple gateways: Premium tier can have multiple regional gateways, but each has its own rate-limit counter unless using a shared cache.
How to Eliminate Wrong Answers
If the question mentions VNet, SLA above 99.9%, or multi-region, eliminate all tiers except Premium.
If it mentions developer portal, subscription keys, or rate limiting, any tier can work, but check SLA requirements.
For security, if the question says 'authenticate users', subscription keys are not enough; look for OAuth2/JWT.
For caching, remember that APIM caches responses only if the cache-response policy is applied and the backend returns Cache-Control headers.
APIM acts as a reverse proxy that intercepts all API calls and applies policies (rate limiting, transformation, security).
Only Premium tier supports VNet injection, multi-region, and self-hosted gateways.
Subscription keys identify consumers but do not authenticate; always use OAuth2/JWT for security.
Rate limiting and quotas must be explicitly configured via XML policies; default is no throttling.
API revisions are for non-breaking changes; breaking changes require a new version (URL path, query, or header).
APIM integrates with Azure AD, Key Vault, Application Insights, Event Grid, and Functions.
Cache responses using the 'cache-response' policy with a duration; default is 300 seconds.
For high availability, use Premium tier with multiple regions and Front Door or Traffic Manager.
Named values can reference Key Vault secrets for secure configuration management.
The Developer tier has no SLA and is for dev/test only.
These come up on the exam all the time. Here's how to tell them apart.
Azure API Management (APIM)
Purpose-built for API governance: policies, rate limiting, quotas, transformation.
Built-in developer portal for API discovery and subscription management.
Supports OAuth2, JWT, client certificates, IP filtering natively.
Single service for both North-South and East-West API traffic (with VNet).
Pricing tiers from Developer to Premium, with SLA up to 99.99%.
Azure Front Door + Application Gateway
General-purpose load balancing and WAF; no API-specific policies.
No developer portal; requires separate solution for API documentation.
WAF can filter malicious traffic, but no built-in JWT validation or rate limiting at API level.
Best for global load balancing and DDoS protection at network layer.
Combined cost may be lower for simple scenarios, but lacks API management features.
Mistake
API Management can only be used for REST APIs.
Correct
APIM supports REST, SOAP (via WSDL import), WebSocket, and GraphQL (in preview). You can import SOAP services and expose them as RESTful APIs using the SOAP-to-REST policy.
Mistake
Subscription keys are a secure way to authenticate API consumers.
Correct
Subscription keys are not secure; they are easily extracted from client code. They are meant for identification and rate limiting, not authentication. Always use OAuth2 or JWT for real security.
Mistake
Rate limiting is applied automatically to all APIs in APIM.
Correct
Rate limiting must be explicitly configured via policies. Without a rate-limit policy, there is no throttling, and consumers can call APIs unlimitedly.
Mistake
You can use any APIM tier for VNet integration.
Correct
Only the Premium tier supports VNet injection. Basic, Standard, and Developer tiers do not allow deploying the gateway inside a VNet.
Mistake
API revisions allow you to change the API signature (breaking changes).
Correct
Revisions are for non-breaking changes (e.g., bug fixes, minor enhancements). Breaking changes require a new API version (e.g., /api/v2). Revisions can be rolled back easily.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Yes, you can configure a product to not require a subscription key. However, this is not recommended for production because you lose the ability to identify and throttle individual consumers. To disable subscription key requirement, set the product's 'subscriptionRequired' property to false. Note that you still need some form of authentication (e.g., OAuth2) to secure the API.
You cannot directly change the tier of an APIM instance. Instead, create a new APIM instance in the desired tier (Standard), configure it identically (export ARM template from old, import to new), then update DNS/CNAME to point to the new gateway URL. This approach minimizes downtime. Alternatively, use the Premium tier's self-hosted gateway to run a separate instance during migration.
API revisions are for non-breaking changes (e.g., bug fixes, minor enhancements). They are isolated and can be rolled back. Each revision has a number (e.g., v1, v2). API versions are for breaking changes (e.g., new parameters, changed response format). Versions are exposed via a version identifier (URL path, query string, or header). Multiple versions can coexist (e.g., /api/v1 and /api/v2).
By default, caching is local to each gateway instance. For multi-region Premium deployments, you can use an external Azure Redis Cache to synchronize the cache across regions. Configure the 'cache-lookup' and 'cache-response' policies to use the external cache. This ensures consistent caching behavior globally.
Use the 'ip-filter' policy in the inbound section. You can specify a list of allowed IP addresses or ranges (CIDR). Requests from IPs not in the list will be rejected with a 403 Forbidden. Example: <ip-filter action="allow"><address-range from="10.0.0.1" to="10.0.0.10" /></ip-filter>
The self-hosted gateway is a containerized version of the APIM gateway that you can deploy on-premises or in other clouds. It is available only with the Premium tier. Use it when you have backend APIs that are not in Azure, need low-latency access, or must comply with data residency requirements. It connects back to the APIM management plane for configuration.
Each subscription has a primary and secondary key. Update your clients to use the secondary key, then regenerate the primary key. Then update clients to use the new primary key, and regenerate the secondary key. This zero-downtime rotation works because the old key remains valid until the client switches.
You've just covered API Management Design and Governance — now see how well it sticks with free AZ-305 practice questions. Full explanations included, no account needed.
Done with this chapter?