Merge pull request #256586 from MJyot/v1-migration

V1 migration

Author: v-ccolin

articles/application-gateway/application-gateway-autoscaling-zone-redundant.md

@@ -5,7 +5,7 @@ services: application-gateway
 author: greg-lindsay
 ms.service: application-gateway
 ms.topic: conceptual
-ms.date: 03/01/2022
+ms.date: 11/02/2023
 ms.author: greglin
 ms.custom: fasttrack-edit, references_regions
 ---
@@ -14,22 +14,23 @@ ms.custom: fasttrack-edit, references_regions
 
 Application Gateway and WAF can be configured to scale in two modes:
 
-- **Autoscaling** - With autoscaling enabled, the Application Gateway and WAF v2 SKUs scale out or in 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 10 if not specified.
-- **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.
+- **Autoscaling** - With autoscaling enabled, the Application Gateway and WAF v2 SKUs scale out or in 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 are only 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 10 if not specified.
+- **Manual** - You can also choose Manual mode where the gateway doesn'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.
 
 ## Autoscaling and High Availability
 
-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.
+Azure Application Gateways are always deployed in a highly available fashion. The service is made up of multiple instances that are created as configured if autoscaling is disabled, or required by the application load if autoscaling is enabled. 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 transparently creates a new instance.
 
-Even if you configure autoscaling with zero minimum instances the service will still be highly available, which is always included with the fixed price.
+Even if you configure autoscaling with zero minimum instances the service is still highly available, which is always included with the fixed price.
 
-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.
+However, creating a new instance can take 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 have at least two instances in your Azure Application Gateway under normal circumstances. So if one of them had a problem the other tries to handle the traffic while a new instance is being created. An Azure Application Gateway instance can support around 10 Capacity Units. Depending on how much traffic you typically have, you might want to configure your minimum instance autoscaling setting to a value higher than two.
 
-For scale-in events, Application Gateway will drain existing connections for 5 minutes on the instance that is subject for removal. After 5 minutes, existing connections will be closed and the instance removed. Any new connections during or after the 5 minute scale-in time will be established to other existing instances on the same gateway.
+For scale-in events, Application Gateway drains existing connections for 5 minutes on the instance that is subject for removal. After 5 minutes, existing connections are closed and the instance removed. Any new connections during or after the 5 minute scale-in time is established to other existing instances on the same gateway.
 
 
 ## Next steps
 
+- Learn how to [Schedule autoscaling for Application Gateway](application-gateway-externally-managed-scheduled-autoscaling.md)
 - Learn more about [Application Gateway v2](overview-v2.md)
 - [Create an autoscaling, zone redundant application gateway with a reserved virtual IP address using Azure PowerShell](tutorial-autoscale-ps.md)
 

articles/application-gateway/application-gateway-externally-managed-scheduled-autoscaling.md

@@ -0,0 +1,84 @@
+---
+
+title: Externally managed scheduled autoscaling for Application Gateway v2
+description: This article introduces the Azure Application Standard_v2 and WAF_v2 SKU scheduled autoscaling feature.
+services: application-gateway
+author: greg-lindsay
+ms.service: application-gateway
+ms.topic: how-to
+ms.date: 10/30/2023
+ms.author: greglin
+
+---
+# Schedule autoscaling for Application Gateway v2
+
+## Overview
+
+For those experiencing predictable daily traffic patterns and who have a reliable estimate of the required capacity for Application Gateway, the option to preschedule the minimum capacity to better align with traffic demands might be of interest. 
+
+While autoscaling is commonly utilized, it’s important to note that Application Gateway doesn't currently support prescheduled capacity adjustments natively.
+
+The goal is to use Azure Automation to create a schedule for running runbooks that adjust the minimum autoscaling capacity of Application Gateway to meet traffic demands.
+
+## Set up scheduled autoscaling 
+
+To implement scheduled autoscaling:
+1.	Create an Azure Automation account resource in the same tenant as the Application Gateway. 
+2.	Note the system assigned managed identity of the Azure Automation account.
+3.	Create PowerShell runbooks for increasing and decreasing min autoscaling capacity for the Application Gateway resource.
+4.	Create the schedules during which the runbooks need to be implemented.
+5.	Associate the runbooks with their respective schedules.
+6.	Associate the system assigned managed identity noted in step 2 with the Application Gateway resource.
+
+## Configure automation
+
+Suppose the requirement is to increase the min count to 4 during business hours and to decrease the min count to 2 during non business hours. 
+
+Two runbooks are created: 
+- IncreaseMin - Sets the min count of the autoscaling configuration to 4 
+- DecreaseMin - Sets the min count of the autoscaling configuration to 2 
+
+Use the following PowerShell runbook to adjust capacity:
+
+  ```Azure PowerShell
+# Get the context of the managed identity 
+$context = (Connect-AzAccount -Identity).Context 
+# Import the Az module 
+Import-Module Az 
+# Adjust the min count of your Application Gateway 
+$gw = Get-AzApplicationGateway -Name “<AppGwName>” -ResourceGroupName “<ResourceGroupName>”
+$gw = Set-AzApplicationGatewayAutoscaleConfiguration -ApplicationGateway $gw -MinCapacity <NumberOfRequiredInstances>
+$gw = Set-AzApplicationGateway -ApplicationGateway $gw 
+```
+
+Next, create the following two schedules:
+
+- WeekdayMorning – Run the IncreaseMin runbook from Mon-Fri at 5:00AM PST 
+- WeekdayEvening – Run the DecreaseMin runbook from Mon-Fri at 9:00PM PST 
+
+## FAQs
+
+- What is the SLA for timely job executions?  
+
+  Azure Automation has a SLA of 99.9% for a timely start of jobs.  
+
+- What happens if jobs are interrupted during execution?
+   
+    - If the job already sends the request to AppGW before getting interrupted, then the request goes through.  
+    - If the job gets interrupted before sending the request to Application Gateway, then it will be one of the scenarios described in next section.  
+
+- What happens if job tasks don’t occur? 
+
+   | Absent job |	Impact  | 
+   | --- | --- |  
+   |IncreaseMin |	Falls back on native autoscaling. Next run of DecreaseMin should be no-op as the count doesn’t need to be adjusted. | 
+   |DecreaseMin |	Additional cost to the customer for the (unintended) capacity that is provisioned for those hours. Next run of IncreaseMin should be no-op because the count doesn’t need to be adjusted. | 
+  
+> [!NOTE]
+> Send email to [email protected] if you have questions or need help to set up managed and scheduled autoscale for your deployments. 
+
+## Next steps
+
+* Learn more about [Scaling Application Gateway v2 and WAF v2](application-gateway-autoscaling-zone-redundant.md)
+* Learn more about [Monitoring Azure Automation runbooks with metric alerts](../automation/automation-alert-metric.md)
+* Learn more about [Azure Automation](../automation/overview.md) 

articles/application-gateway/toc.yml

@@ -257,8 +257,6 @@
       items:
         - name: Azure portal
           href: rewrite-url-portal.md
-  - name: Configure App Service
-    href: configure-web-app.md
   - name: Configure custom probes
     items:
       - name: Portal
@@ -267,6 +265,10 @@
         href: application-gateway-create-probe-classic-ps.md
       - name: Resource Manager PowerShell
         href: application-gateway-create-probe-ps.md
+  - name: Configure App Service
+    href: configure-web-app.md
+  - name: Schedule autoscaling
+    href: application-gateway-externally-managed-scheduled-autoscaling.md
   - name: Troubleshoot
     items:
       - name: ILB with an App Service Environment