You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This article provides information about the roles and features of the API Management *gateway* component and compares the gateways you can deploy.
19
+
This article describes the roles and features of the API Management *gateway* component. It also compares the gateways you can deploy.
20
20
21
21
Related information:
22
22
@@ -34,21 +34,21 @@ The API Management *gateway* (also called *data plane* or *runtime*) is the serv
34
34
35
35
36
36
> [!NOTE]
37
-
> 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.
37
+
> 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.
38
38
39
39
40
-
## Managed and self-hosted
40
+
## Managed and self-hosted gateways
41
41
42
42
API Management offers both managed and self-hosted gateways:
43
43
44
-
***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](workspaces-overview.md) in an API Management instance. With the managed gateway, all API traffic flows through Azure regardless of where backends implementing the APIs are hosted.
44
+
***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](workspaces-overview.md) 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.
45
45
46
46
> [!NOTE]
47
47
> 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](#feature-comparison-managed-versus-self-hosted-gateways).
48
48
>
49
49
50
50
51
-
***Self-hosted** - The [self-hosted gateway](self-hosted-gateway-overview.md) 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.
51
+
***Self-hosted** - The [self-hosted gateway](self-hosted-gateway-overview.md) 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.
52
52
53
53
* The self-hosted gateway is [packaged](self-hosted-gateway-overview.md#packaging) as a Linux-based Docker container and is commonly deployed to Kubernetes, including to [Azure Kubernetes Service](how-to-deploy-self-hosted-gateway-azure-kubernetes-service.md) and [Azure Arc-enabled Kubernetes](how-to-deploy-self-hosted-gateway-azure-arc.md).
54
54
@@ -66,7 +66,7 @@ The following tables compare features available in the following API Management
66
66
67
67
> [!NOTE]
68
68
> * Some features of managed and self-hosted gateways are supported only in certain [service tiers](api-management-features.md) or with certain [deployment environments](self-hosted-gateway-overview.md#packaging) for self-hosted gateways.
69
-
> *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](self-hosted-gateway-overview.md#container-images).
69
+
> *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](self-hosted-gateway-overview.md#container-images).
70
70
> * See also self-hosted gateway [limitations](self-hosted-gateway-overview.md#limitations).
71
71
72
72
### Infrastructure
@@ -90,7 +90,7 @@ The following tables compare features available in the following API Management
90
90
91
91
<sup>1</sup> Depends on how the gateway is deployed, but is the responsibility of the customer.<br/>
92
92
<sup>2</sup> Connectivity to the self-hosted gateway v2 [configuration endpoint](self-hosted-gateway-overview.md#fqdn-dependencies) requires DNS resolution of the endpoint hostname.<br/>
93
-
<sup>3</sup> CA root certificates for self-hosted gateway are managed separately per gateway<br/>
93
+
<sup>3</sup> CA root certificates for self-hosted gateway are managed separately per gateway.<br/>
94
94
<sup>4</sup> Client protocol needs to be enabled.<br/>
95
95
<sup>5</sup> Configure using the [forward-request](forward-request-policy.md) policy.<br/>
96
96
<sup>6</sup> Configure CA certificate details for backend certificate authentication in [backend](backends.md) settings.
@@ -154,7 +154,7 @@ For details about monitoring options, see [Observability in Azure API Management
<sup>1</sup> The v2 tiers support Azure Monitor-based analytics.<br/>
157
-
<sup>2</sup> Gateway uses [Azure Application Insight's built-in memory buffer](/azure/azure-monitor/app/telemetry-channels#built-in-telemetry-channels) and does not provide delivery guarantees.<br/>
157
+
<sup>2</sup> Gateway uses [Azure Application Insight's built-in memory buffer](/azure/azure-monitor/app/telemetry-channels#built-in-telemetry-channels) and doesn't provide delivery guarantees.<br/>
158
158
<sup>3</sup> The self-hosted gateway currently doesn't send resource logs (diagnostic logs) to Azure Monitor. Optionally [send metrics](how-to-configure-cloud-metrics-logs.md) to Azure Monitor, or [configure and persist logs locally](how-to-configure-local-metrics-logs.md) where the self-hosted gateway is deployed.<br/>
159
159
160
160
### Authentication and authorization
@@ -169,17 +169,17 @@ Managed and self-hosted gateways support all available [API authentication and a
169
169
## Gateway throughput and scaling
170
170
171
171
> [!IMPORTANT]
172
-
> 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.
172
+
> 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.
173
173
174
174
### Managed gateway
175
175
176
176
For estimated maximum gateway throughput in the API Management service tiers, see [API Management pricing](https://azure.microsoft.com/pricing/details/api-management/).
177
177
178
178
> [!IMPORTANT]
179
-
> Throughput figures are presented for information only and must not be relied upon for capacity and budget planning. See [API Management pricing](https://azure.microsoft.com/pricing/details/api-management/) for details.
179
+
> Use the throughput figures for information only. Don't rely on them for capacity and budget planning. See [API Management pricing](https://azure.microsoft.com/pricing/details/api-management/) for details.
180
180
181
181
***Classic tiers**
182
-
* Scale gateway capacity by adding and removing scale [units](upgrade-and-scale.md), or upgrade the service tier. (Scaling not available in the Developer tier.)
182
+
* Scale gateway capacity by adding and removing scale [units](upgrade-and-scale.md), or upgrade the service tier. (Scaling isn't available in the Developer tier.)
183
183
* In the Basic, Standard, and Premium tiers, optionally configure [Azure Monitor autoscale](api-management-howto-autoscale.md).
184
184
* In the Premium tier, optionally add and distribute gateway capacity across multiple [regions](api-management-howto-deploy-multi-region.md).
185
185
@@ -198,6 +198,19 @@ For estimated maximum gateway throughput in the API Management service tiers, se
198
198
199
199
Scale capacity by adding and removing scale [units](upgrade-and-scale.md) in the workspace gateway.
200
200
201
+
## Gateway health check endpoint
202
+
203
+
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.
204
+
205
+
A request to the endpoint returns a `200 OK` HTTP response when the gateway is healthy; failures indicate networking or gateway issues.
206
+
207
+
* Azure uses this endpoint internally for continuous SLA monitoring and gateway health validation.
208
+
* Customers can integrate requests to this endpoint into their own monitoring tools and probes.
209
+
* The endpoint is available for managed gateways (including regional gateways in multi-region deployments), self-hosted gateways, and workspace gateways.
210
+
211
+
> [!TIP]
212
+
> When you [integrate Azure Application Insights](api-management-howto-app-insights.md) 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.
Copy file name to clipboardExpand all lines: articles/app-service/manage-automatic-scaling.md
+35-17Lines changed: 35 additions & 17 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,32 +4,50 @@ description: Learn how to scale automatically in Azure App Service with no confi
4
4
author: msangapu-msft
5
5
ms.author: msangapu
6
6
ms.topic: how-to
7
-
ms.date: 04/18/2025
7
+
ms.date: 01/09/2026
8
8
ms.custom: devx-track-azurecli
9
-
10
9
ms.service: azure-app-service
11
10
---
12
11
13
12
# Automatic scaling in Azure App Service
14
13
15
-
> [!NOTE]
16
-
> Automatic scaling is available for all app types: Windows and Linux (deploy as code and container). Automatic scaling isn't supported for deployment slot traffic.
17
-
>
14
+
> [!NOTE]
15
+
> Automatic scaling is available for all app types: Windows and Linux (deploy as code or container).
16
+
> Automatic scaling isn't supported for deployment slot traffic.
17
+
18
+
Automatic scaling is a scale-out option that automatically handles scaling decisions for your web apps and App Service plans. It's different from [Azure autoscale](/azure/azure-monitor/autoscale/autoscale-overview), which lets you define scaling rules based on metrics and schedules.
19
+
20
+
With automatic scaling, you can adjust scaling settings to improve performance and reduce cold-start delays. The platform prewarms instances to act as a buffer, ensuring smooth scaling transitions. You're billed per second for every instance, including prewarmed instances.
18
21
19
-
Automatic scaling is a scale-out option that automatically handles scaling decisions for your web apps and App Service plans. It's different from **[Azure autoscale](/azure/azure-monitor/autoscale/autoscale-overview)**, which lets you define scaling rules based on schedules and resources.
22
+
## Before you begin
20
23
21
-
With automatic scaling, you can adjust scaling settings to improve your app's performance and avoid cold start issues. The platform prewarms instances to act as a buffer when scaling out, ensuring smooth performance transitions. You're charged per second for every instance, including prewarmed instances.
24
+
Automatic scaling in App Service is different from autoscale.
25
+
Use automatic scaling when you want App Service to handle scaling automatically based on HTTP traffic, without creating rules or schedules.
22
26
23
-
The following table compares scale-out and scale-in options available on App Service:
27
+
**Automatic scaling (this article):**
28
+
- Scales automatically based on incoming HTTP traffic
29
+
- Configured per app
30
+
- Supports Always ready, per-app limits, Maximum burst, and prewarmed instances
24
31
25
-
||**Manual**|**Autoscale**|**Automatic scaling**|
26
-
| --- | --- | --- | --- |
27
-
| Available pricing tiers | Basic and up | Standard and up | Premium V2 (P1V2, P2V2, and P3V2) pricing tiers. Premium V3 (P0V3, P1V3, P2V3, P3V3, P1MV3, P2MV3, P3MV3, P4MV3, and P5MV3) pricing tiers.|
28
-
|Rule-based scaling |No |Yes |No, the platform manages the scale-out and scale-in based on HTTP traffic. |
29
-
|Schedule-based scaling |No |Yes |No |
30
-
|Always-ready instances | No, your web app runs on the number of manually scaled instances. | No, your web app runs on other instances available during the scale-out operation, based on the threshold defined for autoscale rules. | Yes (minimum 1) |
| Available tiers | Basic and up | Standard and up | Premium v2 and Premium v3 |
45
+
| Rule-based scaling | No | Yes | No (traffic-based) |
46
+
| Schedule-based scaling | No | Yes | No |
47
+
| Always-ready instances | No | No | Yes (minimum 1) |
48
+
| Prewarmed instances | No | No | Yes (default 1) |
49
+
| Per-app maximum | No | No | Yes |
50
+
| ARR affinity behavior | On by default | On unless manually disabled |[Should be disabled manually](#arr-affinity)|
33
51
34
52
## How automatic scaling works
35
53
@@ -175,7 +193,7 @@ If your web app returns a 5xx status, these endpoint pings might result in inter
175
193
### How do I track the number of scaled-out instances during the automatic scaling event?
176
194
177
195
The `AutomaticScalingInstanceCount` metric reports the number of virtual machines on which the app is running, including the prewarmed instance if it's deployed. This metric can also be used to track the maximum number of instances your web app scaled out during an automatic scaling event. This metric is available only for the apps that have **Automatic Scaling** enabled.
178
-
196
+
<aname='arr-affinity'></a>
179
197
### How does ARR Affinity affect automatic scaling?
Copy file name to clipboardExpand all lines: articles/application-gateway/custom-error.md
+1Lines changed: 1 addition & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -34,6 +34,7 @@ The custom error pages are supported for the following response codes:
34
34
| 504 | Gateway timeout |
35
35
36
36
> [!Note]
37
+
> If you are hosting custom error pages in Azure Blob Storage, the storage account must be accessible directly from the internet (public access) so that Application Gateway can fetch the pages. Custom error pages cannot be served from a CDN endpoint in front of the storage account — Application Gateway does not currently support fetching error pages from CDN URLs. If you are using a CDN with your storage account, make sure the Application Gateway can access the storage account directly, not only through the CDN.
37
38
> - API version 2022-09-01 or later should be used to configure error pages for all available response codes.
38
39
> - Response code 404 (Page not found) is currently unsupported.
39
40
> - The custom error pages are displayed for response codes generated by Application Gateway. If an error originates from the backend server, it is passed along unmodified to the client.
0 commit comments