Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
APPLIES TO: All API Management tiers
This article describes the roles and features of the API Management gateway component. It also compares the gateways you can deploy.
Related information:
For an overview of API Management scenarios, components, and concepts, see What is Azure API Management?
For more information about the API Management service tiers and features, see:
Role of the gateway
The API Management gateway (also called data plane or runtime) is the service component that's responsible for proxying API requests, applying policies, and collecting telemetry.
Specifically, the gateway:
- Acts as a facade to backend services by accepting API calls and routing them to appropriate backends
- Verifies API keys and other credentials such as JWTs and certificates presented with requests
- Enforces usage quotas and rate limits
- Optionally transforms requests and responses as specified in policy statements
- If configured, caches responses to improve response latency and minimize the load on backend services
- Emits logs, metrics, and traces for monitoring, reporting, and troubleshooting
Note
All requests to the API Management gateway, including those rejected by policy configurations, count toward configured rate limits, quotas, and billing limits if the service tier applies them.
Managed and self-hosted gateways
API Management offers both managed and self-hosted gateways:
Managed - The managed gateway is the default gateway component that Azure deploys for every API Management instance in every service tier. You can also associate a standalone managed gateway with a workspace in an API Management instance in select service tiers. By using the managed gateway, all API traffic flows through Azure regardless of where backends implementing the APIs are hosted.
Note
Because of differences in the underlying service architecture, the gateways provided in the different API Management service tiers have some differences in capabilities. For details, see the section Feature comparison: Managed versus self-hosted gateways.
Self-hosted - The self-hosted gateway is an optional, containerized version of the default managed gateway that's available in select service tiers. It's useful for hybrid and multicloud scenarios where there's a requirement to run the gateways off of Azure in the same environments where API backends are hosted. The self-hosted gateway enables customers with hybrid IT infrastructure to manage APIs hosted on-premises and across clouds from a single API Management service in Azure.
The self-hosted gateway is packaged as a Linux-based Docker container and is commonly deployed to Kubernetes, including to Azure Kubernetes Service and Azure Arc-enabled Kubernetes.
Each self-hosted gateway is associated with a Gateway resource in a cloud-based API Management instance from which it receives configuration updates and communicates status.
Feature comparison: Managed versus self-hosted gateways
The following tables compare features available in the following API Management gateways:
- Classic - the managed gateway available in the Developer, Basic, Standard, and Premium service tiers (formerly grouped as dedicated tiers)
- V2 - the managed gateway available in the Basic v2, Standard v2, and Premium v2 tiers
- Consumption - the managed gateway available in the Consumption tier
- Self-hosted - the optional self-hosted gateway available in select service tiers
- Workspace - the managed gateway available in a workspace in select service tiers
Note
- Some features of managed and self-hosted gateways are supported only in certain service tiers or with certain deployment environments for self-hosted gateways.
- To see the current supported features of the self-hosted gateway, make sure you upgraded to the latest major version of the self-hosted gateway container image.
- See also self-hosted gateway limitations.
Infrastructure
| Feature support | Classic | V2 | Consumption | Self-hosted | Workspace |
|---|---|---|---|---|---|
| Custom domains | ✔️ | ✔️ | ✔️ | ✔️ | ❌ |
| Built-in cache | ✔️ | ✔️ | ❌ | ❌ | ✔️ |
| External Redis-compatible cache | ✔️ | ✔️ | ✔️ | ✔️ | ❌ |
| Virtual network injection | Developer, Premium | Premium v2 | ❌ | ✔️1,2 | ✔️ |
| Inbound private endpoints | ✔️ | Standard v2, Premium v2 | ❌ | ❌ | ❌ |
| Outbound virtual network integration | ❌ | Standard v2, Premium v2 | ❌ | ❌ | ✔️ |
| Availability zones | Premium | Premium v2 | ❌ | ✔️1 | ❌ |
| Multi-region deployment | Premium | ❌ | ❌ | ✔️1 | ❌ |
| CA root certificates for certificate validation | ✔️ | ✔️6 | ❌ | ✔️3 | ❌ |
| Managed domain certificates | ✔️ | ❌ | ✔️ | ❌ | ❌ |
| TLS settings | ✔️ | ✔️ | ✔️ | ✔️ | ❌ |
| HTTP/2 (Client-to-gateway) | ✔️4 | ✔️4 | ❌ | ✔️ | ❌ |
| HTTP/2 (Gateway-to-backend) | ❌ | ✔️5 | ❌ | ✔️5 | ❌ |
| API threat detection with Defender for APIs | ✔️ | ✔️ | ❌ | ❌ | ❌ |
1 Depends on how the gateway is deployed, but is the responsibility of the customer.
2 Connectivity to the self-hosted gateway v2 configuration endpoint requires DNS resolution of the endpoint hostname.
3 CA root certificates for self-hosted gateway are managed separately per gateway.
4 Client protocol needs to be enabled.
5 Configure using the forward-request policy.
6 Configure CA certificate details for backend certificate authentication in backend settings.
Backend APIs
| Feature support | Classic | V2 | Consumption | Self-hosted | Workspace |
|---|---|---|---|---|---|
| OpenAPI specification | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| WSDL specification | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| WADL specification | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| Logic App | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| App Service | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| Function App | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| Container App | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| Service Fabric | Developer, Premium | ❌ | ❌ | ❌ | ❌ |
| Pass-through GraphQL | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| Synthetic GraphQL | ✔️ | ✔️ | ✔️1 | ✔️1 | ❌ |
| Pass-through WebSocket | ✔️ | ✔️ | ❌ | ✔️ | ✔️ |
| Pass-through gRPC | ❌ | ❌ | ❌ | ✔️ | ❌ |
| OData | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| Azure OpenAI in Microsoft Foundry models and LLMs | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| Pass-through MCP server | ✔️ | ✔️ | ❌ | ✔️ | ❌ |
| Export REST API as MCP server | ✔️ | ✔️ | ❌ | ✔️ | ❌ |
| A2A agent | ❌ | ✔️ | ❌ | ❌ | ❌ |
| Circuit breaker in backend | ✔️ | ✔️ | ❌ | ✔️ | ✔️ |
| Load-balanced backend pool | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
Policies
Managed and self-hosted gateways support all available policies in policy definitions with the following exceptions. See the policy reference for details about each policy.
| Feature support | Classic | V2 | Consumption | Self-hosted1 | Workspace |
|---|---|---|---|---|---|
| Dapr integration | ❌ | ❌ | ❌ | ✔️ | ❌ |
| Service Bus integration (preview) | ✔️ | ❌ | ❌ | ❌ | ❌ |
| GraphQL resolvers and GraphQL validation | ✔️ | ✔️ | ✔️ | ❌ | ❌ |
| Get authorization context | ✔️ | ✔️ | ✔️ | ❌ | ❌ |
| Authenticate with managed identity | ✔️ | ✔️ | ✔️ | ✔️ | ❌ |
| Azure OpenAI and LLM semantic caching | ✔️ | ✔️ | ✔️ | ❌ | ❌ |
| Quota and rate limit | ✔️ | ✔️ | ✔️2 | ✔️3 | ✔️ |
1 Configured policies that aren't supported by the self-hosted gateway are skipped during policy execution.
2 The rate limit by key, quota by key, and AI token limit policies aren't available in the Consumption tier.
3 Rate limit counts in a self-hosted gateway can be configured to synchronize locally (among gateway instances across cluster nodes), for example, through Helm chart deployment for Kubernetes or using the Azure portal deployment templates. However, rate limit counts don't synchronize with other gateway resources configured in the API Management instance, including the managed gateway in the cloud. Learn more
Monitoring
For details about monitoring options, see Observability in Azure API Management.
| Feature support | Classic | V2 | Consumption | Self-hosted | Workspace |
|---|---|---|---|---|---|
| API analytics | ✔️ | ✔️1 | ❌ | ❌ | ❌ |
| Application Insights | ✔️ | ✔️ | ✔️ | ✔️2 | ✔️ |
| Logging through Event Hubs | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| Metrics in Azure Monitor | ✔️ | ✔️ | ✔️ | ✔️ | ❌ |
| OpenTelemetry Collector | ❌ | ❌ | ❌ | ✔️ | ❌ |
| Request logs in Azure Monitor and Log Analytics | ✔️ | ✔️ | ❌ | ❌3 | ❌ |
| Local metrics and logs | ❌ | ❌ | ❌ | ✔️ | ❌ |
| Request tracing | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
1 The v2 tiers support Azure Monitor-based analytics.
2 Gateway uses Azure Application Insight's built-in memory buffer and doesn't provide delivery guarantees.
3 The self-hosted gateway currently doesn't send resource logs (diagnostic logs) to Azure Monitor. Optionally send metrics to Azure Monitor, or configure and persist logs locally where the self-hosted gateway is deployed.
Authentication and authorization
Managed and self-hosted gateways support all available API authentication and authorization options with the following exceptions.
| Feature support | Classic | V2 | Consumption | Self-hosted | Workspace |
|---|---|---|---|---|---|
| Credential manager | ✔️ | ✔️ | ✔️ | ❌ | ❌ |
Gateway throughput and scaling
Important
Throughput depends on many factors, including the number and rate of concurrent client connections, the kind and number of configured policies, payload sizes, backend API performance, and other factors. Self-hosted gateway throughput also depends on the compute capacity (CPU and memory) of the host where it runs. To accurately determine expected throughput, perform gateway load testing by using anticipated production conditions.
Managed gateway
For estimated maximum gateway throughput in the API Management service tiers, see API Management pricing.
Important
Use the throughput figures for information only. Don't rely on them for capacity and budget planning. See API Management pricing for details.
Classic tiers
- Scale gateway capacity by adding and removing scale units, or upgrade the service tier. (Scaling isn't available in the Developer tier.)
- In the Basic, Standard, and Premium tiers, optionally configure Azure Monitor autoscale.
- In the Premium tier, optionally add and distribute gateway capacity across multiple regions.
v2 tiers
- Scale gateway capacity by adding and removing scale units, or upgrade the service tier.
- Optionally configure Azure Monitor autoscale.
Consumption tier
- API Management instances in the Consumption tier scale automatically based on the traffic.
Self-hosted gateway
- In environments such as Kubernetes, add multiple gateway replicas to handle expected usage.
- Optionally configure autoscaling to meet traffic demands.
Workspace gateway
Scale capacity by adding and removing scale units in the workspace gateway.
Gateway health check endpoint
In all tiers except the Consumption tier, Azure API Management provides a built-in gateway health check endpoint at path /status-0123456789abcdef. Reach this endpoint to help confirm that the API gateway is available and functioning correctly. It doesn't test backend APIs, only the gateway itself.
A request to the endpoint returns a 200 OK HTTP response when the gateway is healthy; failures indicate networking or gateway issues.
- Azure uses this endpoint internally for continuous SLA monitoring and gateway health validation.
- Customers can integrate requests to this endpoint into their own monitoring tools and probes.
- The endpoint is available for managed gateways (including regional gateways in multi-region deployments), self-hosted gateways, and workspace gateways.
Tip
When you integrate Azure Application Insights with API Management, you can optionally enable availability monitoring of the gateway. This setting regularly polls the gateway health check endpoint and reports results on the Availability tab in Application Insights.
Related content
Learn more about:
- API Management in a Hybrid and multicloud World
- Capacity metric for scaling decisions
- Observability capabilities in API Management
- AI gateway capabilities in API Management