- Article
APPLIES TO: All API Management tiers
This article provides information about the roles and features of the API Management gateway component and 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:
- API Management tiers
- Feature-based comparison of the Azure API Management tiers.
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 JWT tokens 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 applied in the service tier.
Managed and self-hosted
API Management offers both managed and self-hosted gateways:
Managed - The managed gateway is the default gateway component that is deployed in Azure for every API Management instance in every service tier. A standalone managed gateway can also be associated with a workspace in an API Management instance. With 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 is 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.
Important
Support for Azure API Management self-hosted gateway version 0 and version 1 container images is ending on 1 October 2023, along with its corresponding Configuration API v1. Use our migration guide to use self-hosted gateway v2.0.0 or higher with Configuration API v2. Learn more in our deprecation documentation
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 and Standard 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.
- For the current supported features of the self-hosted gateway, ensure that you have 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 | ❌ | ❌ | ✔️1,2 | ✔️ |
| Inbound private endpoints | Developer, Basic, Standard, Premium | ❌ | ❌ | ❌ | ❌ |
| Outbound virtual network integration | ❌ | Standard V2 | ❌ | ❌ | ✔️ |
| Availability zones | Premium | ✔️3 | ❌ | ✔️1 | ✔️3 |
| Multi-region deployment | Premium | ❌ | ❌ | ✔️1 | ❌ |
| CA root certificates for certificate validation | ✔️ | ✔️ | ❌ | ✔️4 | ❌ |
| Managed domain certificates | Developer, Basic, Standard, Premium | ❌ | ✔️ | ❌ | ❌ |
| TLS settings | ✔️ | ✔️ | ✔️ | ✔️ | ❌ |
| HTTP/2 (Client-to-gateway) | ✔️5 | ✔️5 | ❌ | ✔️ | ❌ |
| HTTP/2 (Gateway-to-backend) | ❌ | ❌ | ❌ | ✔️ | ❌ |
| 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 Two zones are enabled by default; not configurable.
4 CA root certificates for self-hosted gateway are managed separately per gateway
5 Client protocol needs to be enabled.
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 | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| Circuit breaker in backend | ✔️ | ✔️ | ❌ | ✔️ | ✔️ |
| Load-balanced backend pool | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
1 Synthetic GraphQL subscriptions (preview) aren't supported.
Policies
Managed and self-hosted gateways support all available policies in policy definitions with the following exceptions.
| Feature support | Classic | V2 | Consumption | Self-hosted1 | Workspace |
|---|---|---|---|---|---|
| Dapr integration | ❌ | ❌ | ❌ | ✔️ | ❌ |
| GraphQL resolvers and GraphQL validation | ✔️ | ✔️ | ✔️ | ❌ | ❌ |
| Get authorization context | ✔️ | ✔️ | ✔️ | ❌ | ❌ |
| Quota and rate limit | ✔️ | ✔️2 | ✔️3 | ✔️4 | ✔️ |
1 Configured policies that aren't supported by the self-hosted gateway are skipped during policy execution.
2 The quota by key policy isn't available in the v2 tiers.
3 The rate limit by key, quota by key, and Azure OpenAI token limit policies aren't available in the Consumption tier.
4 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 | ✔️ | ❌4 | ✔️ | ✔️ | ❌ |
1 The v2 tiers support Azure Monitor-based analytics.
2 Gateway uses Azure Application Insight's built-in memory buffer and does not 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.
4 Tracing is currently unavailable in the v2 tiers.
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 is affected by 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 is also dependent on the compute capacity (CPU and memory) of the host where it runs. Perform gateway load testing using anticipated production conditions to determine expected throughput accurately.
Managed gateway
For estimated maximum gateway throughput in the API Management service tiers, see API Management pricing.
Important
Throughput figures are presented for information only and must not be relied upon 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 not 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.
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.
Related content
Lear more about:
- API Management in a Hybrid and multicloud World
- Capacity metric for scaling decisions
- Observability capabilities in API Management
- GenAI gateway capabilities in API Management
