API gateway in Azure API Management

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. 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

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
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	❌	❌	✔️1
Multi-region deployment	Premium	❌	❌	✔️1
CA root certificates for certificate validation	✔️	✔️	❌	✔️3
CA root certificates for certificate validation	✔️	✔️	❌	✔️3
Managed domain certificates	Developer, Basic, Standard, Premium	❌	✔️	❌
TLS settings	✔️	✔️	✔️	✔️
HTTP/2 (Client-to-gateway)	✔️4	✔️4	❌	✔️
HTTP/2 (Gateway-to-backend)	❌	❌	❌	✔️
API threat detection with Defender for APIs	✔️	✔️	❌	❌

¹ Depends on how the gateway is deployed, but is the responsibility of the customer.
² Connectivity to the self-hosted gateway v2 configuration endpoint requires DNS resolution of the endpoint hostname.
³CA root certificates for self-hosted gateway are managed separately per gateway
⁴ Client protocol needs to be enabled.

Backend APIs

Feature support	Classic	V2	Consumption	Self-hosted
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 (preview)	❌	❌	❌	✔️
OData (preview)	✔️	✔️	✔️	✔️
Pass-through GraphQL	✔️	✔️	✔️	✔️
Azure OpenAI	✔️	✔️	✔️	✔️
Circuit breaker in backend (preview)	✔️	✔️	❌	✔️
Load-balanced backend pool (preview)	✔️	✔️	✔️	✔️

¹ 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
Dapr integration	❌	❌	❌	✔️
GraphQL resolvers and GraphQL validation	✔️	✔️	✔️	❌
Get authorization context	✔️	✔️	✔️	❌
Quota and rate limit	✔️	✔️2	✔️3	✔️4

¹ Configured policies that aren't supported by the self-hosted gateway are skipped during policy execution.
² The quota by key policy isn't available in the v2 tiers.
² The rate limit by key and quota by key policies aren't available in the Consumption tier.
³ 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
API analytics	✔️	✔️1	❌	❌
Application Insights	✔️	✔️	✔️	✔️
Logging through Event Hubs	✔️	✔️	✔️	✔️
Metrics in Azure Monitor	✔️	✔️	✔️	✔️
OpenTelemetry Collector	❌	❌	❌	✔️
Request logs in Azure Monitor and Log Analytics	✔️	✔️	❌	❌2
Local metrics and logs	❌	❌	❌	✔️
Request tracing	✔️	❌3	✔️	✔️

¹ The v2 tiers support Azure Monitor-based analytics.
² 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.
³ 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
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.

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