Merge pull request #224305 from JackStromberg/patch-100

Private AppGW feature public preview

Author: v-regandowner

articles/application-gateway/application-gateway-faq.yml

@@ -276,11 +276,13 @@ sections:
 
       - question: How do I use Application Gateway V2 with only private frontend IP address?
         answer: |
-          Application Gateway V2 currently doesn't support only private IP mode. It supports the following combinations
+          Application Gateway V2 currently supports private IP frontend configuration only (no public IP) via public preview.  More information can be found [here](application-gateway-private-deployment.md).
+          
+          For current general availability support, Application Gateway V2 supports the following combinations
           * Private IP and Public IP
           * Public IP only
           
-          But if you'd like to use Application Gateway V2 with only private IP, you can follow the process below:
+          To restrict traffic only to private IP addresses with current functionality, you can follow the process below:
           1. Create an Application Gateway with both public and private frontend IP address
           2. Don't create any listeners for the public frontend IP address. Application Gateway won't listen to any traffic on the public IP address if no listeners are created for it.
           3. Create and attach a [Network Security Group](../virtual-network/network-security-groups-overview.md) for the Application Gateway subnet with the following configuration in the order of priority:

articles/application-gateway/application-gateway-private-deployment.md

@@ -14,12 +14,12 @@ ms.custom: devx-track-azurepowershell
 
 Azure Application Gateway by default monitors the health of all resources in its backend pool and automatically removes any resource considered unhealthy from the pool. Application Gateway continues to monitor the unhealthy instances and adds them back to the healthy backend pool once they become available and respond to health probes. By default, Application gateway sends the health probes with the same port that is defined in the backend HTTP settings. A custom probe port can be configured using a custom health probe.
 
-The source IP address that Application Gateway uses for health probes will depend on the backend pool:
+The source IP address that Application Gateway uses for health probes depend on the backend pool:
 
 - If the server address in the backend pool is a public endpoint, then the source address is the application gateway's frontend public IP address.
 - If the server address in the backend pool is a private endpoint, then the source IP address is from the application gateway subnet's private IP address space.
 
-![application gateway probe example][1]
+:::image type="content" source="media/application-gateway-probe-overview/appgatewayprobe.png" alt-text="Diagram showing Application Gateway initiating health probes to individual backend targets within a backend pool":::
 
 In addition to using default health probe monitoring, you can also customize the health probe to suit your application's requirements. In this article, both default and custom health probes are covered.
 
@@ -29,7 +29,7 @@ In addition to using default health probe monitoring, you can also customize the
 
 An application gateway automatically configures a default health probe when you don't set up any custom probe configuration. The monitoring behavior works by making an HTTP GET request to the IP addresses or FQDN configured in the backend pool. For default probes if the backend http settings are configured for HTTPS, the probe uses HTTPS to test health of the backend servers.
 
-For example: You configure your application gateway to use backend servers A, B, and C to receive HTTP network traffic on port 80. The default health monitoring tests the three servers every 30 seconds for a healthy HTTP response with a 30 second timeout for each request. A healthy HTTP response has a [status code](https://msdn.microsoft.com/library/aa287675.aspx) between 200 and 399. In this case, the HTTP GET request for the health probe will look like `http://127.0.0.1/`.
+For example: You configure your application gateway to use backend servers A, B, and C to receive HTTP network traffic on port 80. The default health monitoring tests the three servers every 30 seconds for a healthy HTTP response with a 30-second-timeout for each request. A healthy HTTP response has a [status code](https://msdn.microsoft.com/library/aa287675.aspx) between 200 and 399. In this case, the HTTP GET request for the health probe looks like `http://127.0.0.1/`.
 
 If the default probe check fails for server A, the application gateway stops forwarding requests to this server. The default probe still continues to check for server A every 30 seconds. When server A responds successfully to one request from a default health probe, application gateway starts forwarding the requests to the server again.
 
@@ -61,10 +61,10 @@ The following table provides definitions for the properties of a custom health p
 | Probe property | Description |
 | --- | --- |
 | Name |Name of the probe. This name is used to identify and refer to the probe in backend HTTP settings. |
-| Protocol |Protocol used to send the probe. This has to match with the protocol defined in the backend HTTP settings it is associated to|
-| Host |Host name to send the probe with. In v1 SKU, this value will be used only for the host header of the probe request. In v2 SKU, it will be used both as host header as well as SNI |
+| Protocol |Protocol used to send the probe. This has to match with the protocol defined in the backend HTTP settings it's associated to|
+| Host |Host name to send the probe with. In v1 SKU, this value is used only for the host header of the probe request. In v2 SKU, it is used both as host header and SNI |
 | Path |Relative path of the probe. A valid path starts with '/' |
-| Port |If defined, this is used as the destination port. Otherwise, it uses the same port as the HTTP settings that it is associated to. This property is only available in the v2 SKU
+| Port |If defined, this is used as the destination port. Otherwise, it uses the same port as the HTTP settings that it's associated to. This property is only available in the v2 SKU
 | Interval |Probe interval in seconds. This value is the time interval between two consecutive probes |
 | Time-out |Probe time-out in seconds. If a valid response isn't received within this time-out period, the probe is marked as failed  |
 | Unhealthy threshold |Probe retry count. The backend server is marked down after the consecutive probe failure count reaches the unhealthy threshold |
@@ -90,6 +90,10 @@ Once the match criteria is specified, it can be attached to probe configuration
 
 ## NSG considerations
 
+Fine grain control over the Application Gateway subnet via NSG rules is possible in public preview. More details can be found [here](application-gateway-private-deployment.md#network-security-group-control).
+
+With current functionality there are some restrictions:
+
 You must allow incoming Internet traffic on TCP ports 65503-65534 for the Application Gateway v1 SKU, and TCP ports 65200-65535 for the v2 SKU with the destination subnet as **Any** and source as **GatewayManager** service tag. This port range is required for Azure infrastructure communication.
 
 Additionally, outbound Internet connectivity can't be blocked, and inbound traffic coming from the **AzureLoadBalancer** tag must be allowed.

articles/application-gateway/application-gateway-probe-overview.md

@@ -15,15 +15,16 @@ You can configure the application gateway to have a public IP address, a private
 
 ## Public and private IP address support
 
-Application Gateway V2 currently doesn't support only private IP mode. It supports the following combinations:
+Application Gateway V2 currently supports the following combinations:
 
 * Private IP address and public IP address
 * Public IP address only
+* [Private IP address only (preview)](application-gateway-private-deployment.md)
 
 For more information, see [Frequently asked questions about Application Gateway](application-gateway-faq.yml#how-do-i-use-application-gateway-v2-with-only-private-frontend-ip-address).
 
 
-A public IP address isn't required for an internal endpoint that's not exposed to the Internet. That's known as an *internal load-balancer* (ILB) endpoint or private frontend IP. An application gateway ILB is useful for internal line-of-business applications that aren't exposed to the Internet. It's also useful for services and tiers in a multi-tier application within a security boundary that aren't exposed to the Internet but that require round-robin load distribution, session stickiness, or TLS termination.
+A public IP address isn't required for an internal endpoint that's not exposed to the Internet. A private frontend configuration is useful for internal line-of-business applications that aren't exposed to the Internet. It's also useful for services and tiers in a multi-tier application within a security boundary that aren't exposed to the Internet but that require round-robin load distribution, session stickiness, or TLS termination.
 
 Only one public IP address and one private IP address is supported. You choose the frontend IP when you create the application gateway.
 

articles/application-gateway/configuration-frontend-ip.md

@@ -71,7 +71,11 @@ By visiting Azure Advisor for your account, you can verify if your subscription
 
 ## Network security groups
 
-Network security groups (NSGs) are supported on Application Gateway. But there are some restrictions:
+Network security groups (NSGs) are supported on Application Gateway.
+
+Fine grain control over the Application Gateway subnet via NSG rules is possible in public preview. More details can be found [here](application-gateway-private-deployment.md#network-security-group-control).
+
+With current functionality there are some restrictions:
 
 - You must allow incoming Internet traffic on TCP ports 65503-65534 for the Application Gateway v1 SKU, and TCP ports 65200-65535 for the v2 SKU with the destination subnet as **Any** and source as **GatewayManager** service tag. This port range is required for Azure infrastructure communication. These ports are protected (locked down) by Azure certificates. External entities, including the customers of those gateways, can't communicate on these endpoints.
 
@@ -97,6 +101,10 @@ For this scenario, use NSGs on the Application Gateway subnet. Put the following
 
 ## Supported user-defined routes 
 
+Fine grain control over the Application Gateway subnet via Route Table rules is possible in public preview. More details can be found [here](application-gateway-private-deployment.md#route-table-control).
+
+With current functionality there are some restrictions: 
+
 > [!IMPORTANT]
 > Using UDRs on the Application Gateway subnet might cause the health status in the [backend health view](./application-gateway-diagnostics.md#backend-health) to appear as **Unknown**. It also might cause generation of Application Gateway logs and metrics to fail. We recommend that you don't use UDRs on the Application Gateway subnet so that you can view the backend health, logs, and metrics.
 
@@ -151,3 +159,4 @@ For this scenario, use NSGs on the Application Gateway subnet. Put the following
 ## Next steps
 
 - [Learn about frontend IP address configuration](configuration-frontend-ip.md).
+- [Learn about private Application Gateway deployment](application-gateway-private-deployment.md).