|
1 | 1 | --- |
2 | | -title: Autoscaling and Zone-redundant Application Gateway v2 |
3 | | -description: This article introduces the Azure Application Standard_v2 and WAF_v2 SKU, which includes Autoscaling and Zone-redundant features. |
| 2 | +title: Scaling and Zone-redundant Application Gateway v2 |
| 3 | +description: This article introduces the Azure Application Standard_v2 and WAF_v2 SKU Autoscaling and Zone-redundant features. |
4 | 4 | services: application-gateway |
5 | 5 | author: vhorne |
6 | 6 | ms.service: application-gateway |
7 | 7 | ms.topic: conceptual |
8 | | -ms.date: 12/17/2021 |
| 8 | +ms.date: 01/18/2022 |
9 | 9 | ms.author: victorh |
10 | 10 | ms.custom: fasttrack-edit, references_regions |
11 | 11 | --- |
12 | 12 |
|
13 | | -# Autoscaling and Zone-redundant Application Gateway v2 |
14 | | - |
15 | | -Application Gateway is available under a Standard_v2 SKU. Web Application Firewall (WAF) is available under a WAF_v2 SKU. The v2 SKU offers performance enhancements and adds support for critical new features like autoscaling, zone redundancy, and support for static VIPs. Existing features under the Standard and WAF SKU continue to be supported in the new v2 SKU, with a few exceptions listed in [comparison](#differences-from-v1-sku) section. |
16 | | - |
17 | | -The new v2 SKU includes the following enhancements: |
18 | | - |
19 | | -- **Autoscaling**: Application Gateway or WAF deployments under the autoscaling SKU can scale out or in based on changing traffic load patterns. Autoscaling also removes the requirement to choose a deployment size or instance count during provisioning. This SKU offers true elasticity. In the Standard_v2 and WAF_v2 SKU, Application Gateway can operate both in fixed capacity (autoscaling disabled) and in autoscaling enabled mode. Fixed capacity mode is useful for scenarios with consistent and predictable workloads. Autoscaling mode is beneficial in applications that see variance in application traffic. |
20 | | -- **Zone redundancy**: An Application Gateway or WAF deployment can span multiple Availability Zones, removing the need to provision separate Application Gateway instances in each zone with a Traffic Manager. You can choose a single zone or multiple zones where Application Gateway instances are deployed, which makes it more resilient to zone failure. The backend pool for applications can be similarly distributed across availability zones. |
21 | | - |
22 | | - Zone redundancy is available only where Azure Zones are available. In other regions, all other features are supported. For more information, see [Regions and Availability Zones in Azure](../availability-zones/az-overview.md) |
23 | | -- **Static VIP**: Application Gateway v2 SKU supports the static VIP type exclusively. This ensures that the VIP associated with the application gateway doesn't change for the lifecycle of the deployment, even after a restart. There isn't a static VIP in v1, so you must use the application gateway URL instead of the IP address for domain name routing to App Services via the application gateway. |
24 | | -- **Header Rewrite**: Application Gateway allows you to add, remove, or update HTTP request and response headers with v2 SKU. For more information, see [Rewrite HTTP headers with Application Gateway](./rewrite-http-headers-url.md) |
25 | | -- **Key Vault Integration**: Application Gateway v2 supports integration with Key Vault for server certificates that are attached to HTTPS enabled listeners. For more information, see [TLS termination with Key Vault certificates](key-vault-certs.md). |
26 | | -- **Azure Kubernetes Service Ingress Controller**: The Application Gateway v2 Ingress Controller allows the Azure Application Gateway to be used as the ingress for an Azure Kubernetes Service (AKS) known as AKS Cluster. For more information, see [What is Application Gateway Ingress Controller?](ingress-controller-overview.md). |
27 | | -- **Performance enhancements**: The v2 SKU offers up to 5X better TLS offload performance as compared to the Standard/WAF SKU. |
28 | | -- **Faster deployment and update time** The v2 SKU provides faster deployment and update time as compared to Standard/WAF SKU. This also includes WAF configuration changes. |
29 | | - |
30 | | - |
31 | | - |
32 | | -## Supported regions |
33 | | - |
34 | | -The Standard_v2 and WAF_v2 SKU is available in the following regions: North Central US, South Central US, West US, West US 2, East US, East US 2, Central US, North Europe, West Europe, Southeast Asia, France Central, UK West, Japan East, Japan West, Australia East, Australia Southeast, Brazil South, Canada Central, Canada East, East Asia, Korea Central, Korea South, UK South, Central India, West India, South India,Jio India West,Norway East,Switzerland North,UAE North,South Arica North,Germany West Central. |
35 | | - |
36 | | -## Pricing |
37 | | - |
38 | | -With the v2 SKU, the pricing model is driven by consumption and is no longer attached to instance counts or sizes. The v2 SKU pricing has two components: |
39 | | - |
40 | | -- **Fixed price** - This is hourly (or partial hour) price to provision a Standard_v2 or WAF_v2 Gateway. Please note that 0 additional minimum instances still ensures high availability of the service which is always included with fixed price. |
41 | | -- **Capacity Unit price** - This is a consumption-based cost that is charged in addition to the fixed cost. Capacity unit charge is also computed hourly or partial hourly. There are three dimensions to capacity unit - compute unit, persistent connections, and throughput. Compute unit is a measure of processor capacity consumed. Factors affecting compute unit are TLS connections/sec, URL Rewrite computations, and WAF rule processing. Persistent connection is a measure of established TCP connections to the application gateway in a given billing interval. Throughput is average Megabits/sec processed by the system in a given billing interval. The billing is done at a Capacity Unit level for anything above the reserved instance count. |
42 | | - |
43 | | -Each capacity unit is composed of at most: 1 compute unit, 2500 persistent connections, and 2.22-Mbps throughput. |
44 | | - |
45 | | -To learn more, see [Understanding pricing](understanding-pricing.md). |
46 | | - |
47 | | -## Scaling Application Gateway and WAF v2 |
| 13 | +# Scaling Application Gateway v2 and WAF v2 |
48 | 14 |
|
49 | 15 | Application Gateway and WAF can be configured to scale in two modes: |
50 | 16 |
|
51 | | -- **Autoscaling** - With autoscaling enabled, the Application Gateway and WAF v2 SKUs scale up or down based on application traffic requirements. This mode offers better elasticity to your application and eliminates the need to guess the application gateway size or instance count. This mode also allows you to save cost by not requiring the gateway to run at peak provisioned capacity for anticipated maximum traffic load. You must specify a minimum and optionally maximum instance count. Minimum capacity ensures that Application Gateway and WAF v2 don't fall below the minimum instance count specified, even in the absence of traffic. Each instance is roughly equivalent to 10 additional reserved Capacity Units. Zero signifies no reserved capacity and is purely autoscaling in nature. You can also optionally specify a maximum instance count, which ensures that the Application Gateway doesn't scale beyond the specified number of instances. You will only be billed for the amount of traffic served by the Gateway. The instance counts can range from 0 to 125. The default value for maximum instance count is 20 if not specified. |
52 | | -- **Manual** - You can alternatively choose Manual mode where the gateway won't autoscale. In this mode, if there is more traffic than what Application Gateway or WAF can handle, it could result in traffic loss. With manual mode, specifying instance count is mandatory. Instance count can vary from 1 to 125 instances. |
| 17 | +- **Autoscaling** - With autoscaling enabled, the Application Gateway and WAF v2 SKUs scale up or down based on application traffic requirements. This mode offers better elasticity to your application and eliminates the need to guess the application gateway size or instance count. This mode also allows you to save cost by not requiring the gateway to run at peak-provisioned capacity for expected maximum traffic load. You must specify a minimum and optionally maximum instance count. Minimum capacity ensures that Application Gateway and WAF v2 don't fall below the minimum instance count specified, even without traffic. Each instance is roughly equivalent to 10 more reserved Capacity Units. Zero signifies no reserved capacity and is purely autoscaling in nature. You can also optionally specify a maximum instance count, which ensures that the Application Gateway doesn't scale beyond the specified number of instances. You'll only be billed for the amount of traffic served by the Gateway. The instance counts can range from 0 to 125. The default value for maximum instance count is 20 if not specified. |
| 18 | +- **Manual** - You can also choose Manual mode where the gateway won't autoscale. In this mode, if there's more traffic than what Application Gateway or WAF can handle, it could result in traffic loss. With manual mode, specifying instance count is mandatory. Instance count can vary from 1 to 125 instances. |
53 | 19 |
|
54 | 20 | ## Autoscaling and High Availability |
55 | 21 |
|
56 | | -Azure Application Gateways are always deployed in a highly available fashion. The service is made out of multiple instances that are created as configured (if autoscaling is disabled) or required by the application load (if autoscaling is enabled). Note that from the user's perspective you do not necessarily have visibility into the individual instances, but just into the Application Gateway service as a whole. If a certain instance has a problem and stops being functional, Azure Application Gateway will transparently create a new instance. |
57 | | - |
58 | | -Please note that even if you configure autoscaling with zero minimum instances the service will still be highly available, which is always included with the fixed price. |
59 | | - |
60 | | -However, creating a new instance can take some time (around six or seven minutes). Hence, if you do not want to cope with this downtime you can configure a minimum instance count of 2, ideally with Availability Zone support. This way you will have at least two instances inside of your Azure Application Gateway under normal circumstances, so if one of them had a problem the other will try to cope with the traffic, during the time a new instance is being created. Note that an Azure Application Gateway instance can support around 10 Capacity Units, so depending on how much traffic you typically have you might want to configure your minimum instance autoscaling setting to a value higher than 2. |
61 | | - |
62 | | -## Feature comparison between v1 SKU and v2 SKU |
| 22 | +Azure Application Gateways are always deployed in a highly available fashion. The service is made out of multiple instances that are created as configured (if autoscaling is disabled) or required by the application load (if autoscaling is enabled). Note that from the user's perspective you don't necessarily have visibility into the individual instances, but just into the Application Gateway service as a whole. If a certain instance has a problem and stops being functional, Azure Application Gateway will transparently create a new instance. |
63 | 23 |
|
64 | | -The following table compares the features available with each SKU. |
| 24 | +Even if you configure autoscaling with zero minimum instances the service will still be highly available, which is always included with the fixed price. |
65 | 25 |
|
66 | | -| Feature | v1 SKU | v2 SKU | |
67 | | -| ------------------------------------------------- | -------- | -------- | |
68 | | -| Autoscaling | | ✓ | |
69 | | -| Zone redundancy | | ✓ | |
70 | | -| Static VIP | | ✓ | |
71 | | -| Azure Kubernetes Service (AKS) Ingress controller | | ✓ | |
72 | | -| Azure Key Vault integration | | ✓ | |
73 | | -| Rewrite HTTP(S) headers | | ✓ | |
74 | | -| URL-based routing | ✓ | ✓ | |
75 | | -| Multiple-site hosting | ✓ | ✓ | |
76 | | -| Traffic redirection | ✓ | ✓ | |
77 | | -| Web Application Firewall (WAF) | ✓ | ✓ | |
78 | | -| WAF custom rules | | ✓ | |
79 | | -| WAF policy associations | | ✓ | |
80 | | -| Transport Layer Security (TLS)/Secure Sockets Layer (SSL) termination | ✓ | ✓ | |
81 | | -| End-to-end TLS encryption | ✓ | ✓ | |
82 | | -| Session affinity | ✓ | ✓ | |
83 | | -| Custom error pages | ✓ | ✓ | |
84 | | -| WebSocket support | ✓ | ✓ | |
85 | | -| HTTP/2 support | ✓ | ✓ | |
86 | | -| Connection draining | ✓ | ✓ | |
| 26 | +However, creating a new instance can take some time (around six or seven minutes). If you don't want to have this downtime, you can configure a minimum instance count of two, ideally with Availability Zone support. This way you'll have at least two instances in your Azure Application Gateway under normal circumstances. So if one of them had a problem the other will try to handle the traffic while a new instance is being created. An Azure Application Gateway instance can support around 10 Capacity Units, so depending on how much traffic you typically have you might want to configure your minimum instance autoscaling setting to a value higher than two. |
87 | 27 |
|
88 | | -> [!NOTE] |
89 | | -> The autoscaling v2 SKU now supports [default health probes](application-gateway-probe-overview.md#default-health-probe) to automatically monitor the health of all resources in its back-end pool and highlight those backend members that are considered unhealthy. The default health probe is automatically configured for backends that don't have any custom probe configuration. To learn more, see [health probes in application gateway](application-gateway-probe-overview.md). |
90 | 28 |
|
91 | | -## Differences from v1 SKU |
92 | | - |
93 | | -This section describes features and limitations of the v2 SKU that differ from the v1 SKU. |
94 | | - |
95 | | -|Difference|Details| |
96 | | -|--|--| |
97 | | -|Authentication certificate|Not supported.<br>For more information, see [Overview of end to end TLS with Application Gateway](ssl-overview.md#end-to-end-tls-with-the-v2-sku).| |
98 | | -|Mixing Standard_v2 and Standard Application Gateway on the same subnet|Not supported| |
99 | | -|User-Defined Route (UDR) on Application Gateway subnet|Supported (specific scenarios). In preview.<br> For more information about supported scenarios, see [Application Gateway configuration overview](configuration-infrastructure.md#supported-user-defined-routes).| |
100 | | -|NSG for Inbound port range| - 65200 to 65535 for Standard_v2 SKU<br>- 65503 to 65534 for Standard SKU.<br>For more information, see the [FAQ](application-gateway-faq.yml#are-network-security-groups-supported-on-the-application-gateway-subnet).| |
101 | | -|Performance logs in Azure diagnostics|Not supported.<br>Azure metrics should be used.| |
102 | | -|Billing|Billing scheduled to start on July 1, 2019.| |
103 | | -|FIPS mode|These are currently not supported.| |
104 | | -|ILB only mode|This is currently not supported. Public and ILB mode together is supported.| |
105 | | -|Net watcher integration|Not supported.| |
106 | | -|Microsoft Defender for Cloud integration|Not yet available. |
107 | | - |
108 | | -## Migrate from v1 to v2 |
109 | | - |
110 | | -An Azure PowerShell script is available in the PowerShell gallery to help you migrate from your v1 Application Gateway/WAF to the v2 Autoscaling SKU. This script helps you copy the configuration from your v1 gateway. Traffic migration is still your responsibility. For more information, see [Migrate Azure Application Gateway from v1 to v2](migrate-v1-v2.md). |
111 | 29 |
|
112 | 30 | ## Next steps |
113 | 31 |
|
114 | | -- [Quickstart: Direct web traffic with Azure Application Gateway - Azure portal](quick-create-portal.md) |
| 32 | +- Learn more about [Application Gateway v2](overview-v2.md) |
115 | 33 | - [Create an autoscaling, zone redundant application gateway with a reserved virtual IP address using Azure PowerShell](tutorial-autoscale-ps.md) |
116 | | -- Learn more about [Application Gateway](overview.md). |
117 | | -- Learn more about [Azure Firewall](../firewall/overview.md). |
| 34 | + |
0 commit comments