API gateway in Azure API Management
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 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. 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 Consumption tier gateway currently lacks some capabilities of the dedicated gateway. 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. 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.
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 table compares features available in the managed gateway versus the features in the self-hosted gateway. Differences are also shown between the managed gateway for dedicated service tiers (Developer, Basic, Standard, Premium) and for the Consumption tier.
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 | Managed (Dedicated) | Managed (Consumption) | Self-hosted |
|---|---|---|---|
| Custom domains | ✔️ | ✔️ | ✔️ |
| Built-in cache | ✔️ | ❌ | ❌ |
| External Redis-compatible cache | ✔️ | ✔️ | ✔️ |
| Virtual network injection | Developer, Premium | ❌ | ✔️1,2 |
| Private endpoints | ✔️ | ❌ | ❌ |
| Multi-region deployment | Premium | ❌ | ✔️1 |
| CA root certificates for certificate validation | ✔️ | ❌ | ✔️3 |
| Managed domain certificates | ✔️ | ✔️ | ❌ |
| TLS settings | ✔️ | ✔️ | ✔️ |
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.
3CA root certificates for self-hosted gateway are managed separately per gateway
4 Client protocol needs to be enabled.
Backend APIs
| API | Managed (Dedicated) | Managed (Consumption) | Self-hosted |
|---|---|---|---|
| OpenAPI specification | ✔️ | ✔️ | ✔️ |
| WSDL specification | ✔️ | ✔️ | ✔️ |
| WADL specification | ✔️ | ✔️ | ✔️ |
| Logic App | ✔️ | ✔️ | ✔️ |
| App Service | ✔️ | ✔️ | ✔️ |
| Function App | ✔️ | ✔️ | ✔️ |
| Service Fabric | Developer, Premium | ❌ | ❌ |
| Pass-through GraphQL | ✔️ | ✔️ | ✔️ |
| Synthetic GraphQL | ✔️ | ✔️1 | ✔️1 |
| Pass-through WebSocket | ✔️ | ❌ | ✔️ |
| Pass-through gRPC | ❌ | ❌ | ✔️ |
| 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.
| Policy | Managed (Dedicated) | Managed (Consumption) | Self-hosted1 |
|---|---|---|---|
| Dapr integration | ❌ | ❌ | ✔️ |
| GraphQL resolvers and GraphQL validation | ✔️ | ✔️ | ❌ |
| Get authorization context | ✔️ | ✔️ | ❌ |
| 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 and quota by key 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 | Managed (Dedicated) | Managed (Consumption) | Self-hosted |
|---|---|---|---|
| API analytics | ✔️ | ❌ | ❌ |
| Application Insights | ✔️ | ✔️ | ✔️ |
| Logging through Event Hubs | ✔️ | ✔️ | ✔️ |
| Metrics in Azure Monitor | ✔️ | ✔️ | ✔️ |
| OpenTelemetry Collector | ❌ | ❌ | ✔️ |
| Request logs in Azure Monitor and Log Analytics | ✔️ | ❌ | ❌1 |
| Local metrics and logs | ❌ | ❌ | ✔️ |
| Request tracing | ✔️ | ✔️ | ✔️ |
1 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.
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.
Dedicated service tiers
- Scale gateway capacity by adding and removing scale units, or upgrade the service tier. (Scaling not available in the Developer tier.)
- In the Standard and Premium tiers, optionally configure Azure Monitor autoscale.
- In the Premium tier, optionally add and distribute gateway capacity across multiple regions.
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.
Related content
- Learn more about API Management in a Hybrid and multicloud World
- Learn more about using the capacity metric for scaling decisions
- Learn about observability capabilities in API Management