Azure API Management

About Azure API Management

Azure API Management is Microsoft's managed platform for publishing, securing, transforming, observing and governing APIs across Azure, on-premises and other cloud environments. It combines managed API gateways, a management plane, developer experiences and optional hybrid gateway deployment so organizations can expose backend services through a controlled API layer without rebuilding every backend. API Management is best suited to teams running an API program that needs centralized policies, access controls, quotas, analytics, developer onboarding, workspace isolation or hybrid deployment. Buyers should choose the service tier from actual traffic, networking, availability and governance requirements because Consumption, classic and v2 tiers differ materially in capabilities, limits and billing.

What is Azure API Management used for?

Azure API Management sits between API consumers and backend services. Organizations use it to publish internal, partner and public APIs through a consistent gateway, apply authentication and authorization checks, limit traffic, transform requests and responses, cache selected responses, collect telemetry and manage how developers discover and consume APIs.

The backend does not have to run in Azure. Microsoft positions API Management as a hybrid and multicloud API platform, so teams can front APIs implemented in Azure, on-premises or in another cloud. This is useful when an organization wants one policy and management layer across a mixed estate. It is less valuable when a team only has one simple internal endpoint and does not need gateway policies, lifecycle governance or developer onboarding.

How do the gateway, management plane and developer portal work together?

The API gateway handles runtime requests. It receives calls from API consumers, applies configured policies and routing, forwards allowed requests to backends and returns responses. The management plane is where administrators import APIs, configure products, subscriptions, policies, diagnostics, identities and related settings.

The developer portal is a consumer-facing experience where developers can discover APIs, read documentation, request or obtain access and try APIs. Organizations should still define ownership for documentation quality, onboarding workflows and API lifecycle. A portal does not make an undocumented or unstable API easy to consume by itself.

Which API Management tiers should buyers evaluate?

Microsoft currently offers Consumption, classic dedicated tiers and newer v2 tiers. The v2 family includes Basic v2, Standard v2 and Premium v2. Microsoft positions Basic v2 for teams and projects, Standard v2 for organizational API programs that need production networking options, and Premium v2 for enterprise programs that need stronger isolation, availability-zone support and higher scale.

Classic tiers remain available and include Developer, Basic, Standard and Premium, while Consumption is a serverless option that scales automatically and bills by API operations. Developer is intended for evaluation and development rather than production. Buyers should compare feature support before migrating or standardizing because networking, multi-region deployment, managed certificates, self-hosted gateway support, caching and other capabilities differ by gateway architecture and tier.

What service limits changed in 2026?

Microsoft updated and aligned several API Management service limits across classic and v2 tiers in 2026. Current documented maximum API operation counts are 3,000 for Consumption and Developer, 10,000 for Basic and Basic v2, 50,000 for Standard and Standard v2, and 75,000 for Premium and Premium v2. Microsoft also documents product limits of 100 for Consumption and Developer, 200 for Basic and Basic v2, 500 for Standard and Standard v2, and 2,000 for Premium and Premium v2.

Subscription limits are currently 10,000 for Developer, 15,000 for Basic and Basic v2, 25,000 for Standard and Standard v2, and 75,000 for Premium and Premium v2. Microsoft states that API versions and revisions count toward API-related resource limits. These limits rolled out by tier between March 15 and May 15, 2026. Existing classic-tier services that were already above a new limit are grandfathered, with the enforced limit set above their observed usage when the change took effect. Buyers should therefore check both the documented tier limit and the actual quota on a long-running instance before planning a consolidation or migration.

What changed for trusted service connectivity in 2026?

Microsoft retired trusted service connectivity from the API Management gateway to supported Azure services on March 15, 2026. The affected gateway scenarios include access to Azure Storage, Key Vault, Key Vault Managed HSM, Service Bus, Event Hubs and Container Registry when the gateway depended on trusted-service access and managed identity. Microsoft states that gateway communication relying on this retired path can fail after the deadline.

Existing deployments should confirm that the gateway has normal network line-of-sight to affected backends and should not assume that enabling the target service's trusted-services option is sufficient for API Management gateway traffic. Microsoft directs affected customers to Azure Advisor and API Management diagnostics to identify dependencies. Control-plane scenarios such as some Key Vault certificate or named-value access and Storage backup and restore have separate behavior, so teams should review the exact dependency before changing firewall rules.

How do policies help secure and shape API traffic?

API Management policies let teams change gateway behavior without modifying every backend implementation. Common scenarios include validating tokens, setting or removing headers, rewriting URLs, limiting request rates, enforcing quotas, caching responses, transforming payloads and routing calls to different backends.

Policies are powerful but can also become a hidden application layer. Large policy chains can be difficult to test and troubleshoot, and domain logic placed in the gateway can become tightly coupled to one platform. Teams should keep policies focused on cross-cutting API concerns such as security, traffic control and mediation while leaving core business behavior in the backend where it can be versioned and tested with the application.

How do managed, workspace and self-hosted gateways differ?

Every API Management instance includes a Microsoft-managed gateway. With that gateway, API traffic flows through Azure even if the backend is hosted elsewhere. API Management also supports managed workspace gateways in selected scenarios and self-hosted gateways in selected classic tiers.

Microsoft currently documents a limit of 30 workspaces per workspace gateway in supported v2 scenarios, while Premium classic supports up to 100 self-hosted gateways. Workspaces have important constraints: they cannot be associated with a self-hosted gateway, do not support credential manager, do not support synthetic GraphQL APIs, do not support MCP servers, and currently support only internal cache rather than external cache. Request metrics are also aggregated at the service level rather than split by workspace. Buyers using workspaces should treat them as a governance and isolation feature with their own capability boundaries, not as a transparent copy of the root service.

How does Azure API Management pricing work?

Azure API Management does not have one fixed monthly price. Consumption uses operation-based billing and scales automatically. Classic and v2 dedicated tiers charge for provisioned gateway capacity and tier-specific usage. Microsoft's current v2 pricing table includes 10 million monthly API requests with Basic v2, 50 million with Standard v2 and unlimited API requests in the published Premium v2 tier table. The same pricing page lists built-in cache sizes of 250 MB for Basic v2, 1 GB for Standard v2 and 5 GB for Premium v2.

Pricing was checked on September 4, 2026. Buyers should estimate gateway capacity, request volume, networking, cache use, workspace gateways, monitoring and related Azure services rather than comparing only the base tier price. Microsoft also lists an AI Gateway tier with pricing still marked as coming soon, so buyers should not assume a public production price until Microsoft publishes one for the required region and offer.

What networking and availability choices matter?

Networking support differs by tier and gateway architecture. Microsoft's current gateway comparison shows Standard v2 and Premium v2 support outbound virtual network integration, while Premium v2 also supports virtual network injection. Inbound private endpoint support is available in Standard v2 and Premium v2, while multi-region deployment remains a classic Premium capability rather than a general v2 feature.

Microsoft currently lists a 99.95 percent SLA for Basic v2 and Standard v2 and 99.99 percent for qualifying Premium v2 deployments with at least one unit deployed across two or more availability zones or regions. The pricing page also states that v2 gateway custom domains are limited to 20 per instance before a support request is needed. Buyers should verify the deployment architecture that qualifies for the SLA rather than treating the tier name alone as a resilience guarantee.

What analytics change is coming in March 2027?

Microsoft plans to retire the legacy built-in API analytics dashboard and reports in classic Developer, Basic, Standard and Premium tiers on March 15, 2027. The recommended replacement is Azure Monitor-based API analytics backed by a Log Analytics workspace receiving API Management gateway logs.

Organizations still depending on the classic dashboard should migrate reporting and operational workflows before the retirement date. This matters beyond the portal view: teams may need to update runbooks, saved reporting procedures, access roles and Log Analytics retention or cost assumptions. Microsoft currently recommends the Azure Monitor-based dashboard for API analytics.

What are the main limitations and tradeoffs?

API Management adds a control point to the API path, which is useful for governance but also introduces another service that must be designed, monitored and paid for. Poorly written policies can add latency or create difficult failures. Tier selection can be complex because the platform spans Consumption, classic and v2 architectures with different feature sets and resource ceilings.

Gateway feature parity is not universal. v2 gateways do not support every capability available in classic Premium, and workspace gateways have their own restrictions. Teams planning a migration should compare the exact protocols, networking, certificates, caching, monitoring, multi-region, developer-experience and resource-limit requirements they use today rather than assuming a newer tier is a drop-in replacement.

Who should choose something else?

Teams that only need basic reverse proxying or ingress for a small application may not need the cost and governance surface of a full API management platform. Kubernetes-heavy teams whose primary requirement is cluster-local ingress or service-to-service traffic should compare Kubernetes-native gateway or service-mesh options. Organizations that want only an API inventory and governance catalog, without runtime gateway mediation, should evaluate Azure API Center rather than assuming API Management is required.

Azure API Management is strongest for organizations with multiple APIs, multiple consumer groups or hybrid environments that need centralized gateway policies, developer onboarding, analytics and lifecycle control. Buyers should choose it when API management is an organizational capability, not just when one application needs an endpoint.