Frequently asked questions about Application Gateway

Azure Application Gateway provides an application delivery controller as a service. It offers various layer 7 load-balancing capabilities for your applications. This service is highly available, scalable, and fully managed by Azure.

Application Gateway supports autoscaling, TLS offloading, and end-to-end TLS, a web application firewall (WAF), cookie-based session affinity, URL path-based routing, multisite hosting, and other features. For a full list of supported features, see Introduction to Application Gateway.

Application Gateway is a layer 7 load balancer, which means it works only with web traffic (HTTP, HTTPS, WebSocket, and HTTP/2). It supports capabilities such as TLS termination, cookie-based session affinity, and round robin for load-balancing traffic. Load Balancer load-balances traffic at layer 4 (TCP or UDP).

Application Gateway supports HTTP, HTTPS, HTTP/2, and WebSocket.

See HTTP/2 support.

See Supported backend resources.

Application Gateway v1 (Standard and WAF) is available in all regions of global Azure. It's also available in Microsoft Azure operated by 21Vianet.

For Application Gateway v2 (Standard_v2 and WAF_v2) availability, see Supported regions for Application Gateway v2.

Application Gateway is a dedicated deployment in your virtual network.

Redirection is supported. See Application Gateway redirect overview.

See the order of listener processing.

If you're using a public IP address as an endpoint, you find the IP and DNS information on the public IP address resource. Or you can find it in the Azure portal, on the overview page for the application gateway. If you're using internal IP addresses, find the information on the overview page. For the v1 SKU, gateways created after May 1, 2023, won't have a default DNS name automatically associated with the public IP resource. For the v2 SKU, open the public IP resource and select Configuration. The DNS name label (optional) field is available to configure the DNS name.

Keep-Alive timeout governs how long the application gateway waits for a client to send another HTTP request on a persistent connection before reusing it or closing it. TCP idle timeout governs how long a TCP connection is kept open if there's no activity.

The Keep-Alive timeout in the Application Gateway v1 SKU is 120 seconds and in the v2 SKU it's 75 seconds. For private IP addresses, the value is nonconfigurable with a TCP idle timeout of 5 minutes. The TCP idle timeout is a 4-minute default on the frontend virtual IP (VIP) of both v1 and v2 SKU of Application Gateway. You can configure the TCP idle timeout value on v1 and v2 Application Gateway instances to be anywhere between 4 minutes and 30 minutes. For both v1 and v2 Application Gateway instances, you need to go to the public IP of the application gateway and change the TCP idle timeout under the Configuration pane of the public IP in the portal. You can set the TCP idle timeout value of the public IP through PowerShell by running the following commands:

$publicIP = Get-AzPublicIpAddress -Name MyPublicIP -ResourceGroupName MyResourceGroup
$publicIP.IdleTimeoutInMinutes = "15"
Set-AzPublicIpAddress -PublicIpAddress $publicIP

For HTTP/2 connections to the frontend IP address on Application Gateway v2 SKU, the idle timeout is set to 180 seconds and is nonconfigurable.

Yes. Application Gateway reuses the existing TCP connections with a backend server.

No. There's no way to rename an Application Gateway resource. You must create a new resource with a different name.

No. There's no way to restore an Application Gateway resource or its public IP after deletion. You must create a new resource.

In Application Gateway v1 SKU, the VIP can change if you stop and start the application gateway. But the DNS name associated with the application gateway doesn't change over the lifetime of the gateway. Because the DNS name doesn't change, you should use a CNAME alias and point it to the DNS address of the application gateway. In Application Gateway v2 SKU, IP addresses are static, so the IP address and DNS name won't change over the lifetime of the application gateway.

Yes. The Application Gateway v2 SKU supports static public IP addresses and static internal IPs. The v1 SKU supports static internal IPs.

An application gateway supports only one public IP address per IP protocol. If the application gateway is configured as DualStack, it can support two Public IPs, one for IPv4 and one for IPv6.

See Application Gateway subnet size considerations.

Yes. In addition to multiple instances of a given Application Gateway deployment, you can provision another unique Application Gateway resource to an existing subnet that contains a different Application Gateway resource.

A single subnet can't support both v2 and v1 Application Gateway SKUs.

Yes, but only specific scenarios. For more information, see Application Gateway infrastructure configuration.

Yes. See Modifications to a request.

New Application Gateway v1 SKU deployments can take up to 20 minutes to provision. Changes to instance size or count aren't disruptive, and the gateway remains active during this time.

Most deployments that use the v2 SKU take around 6 minutes to provision. However, the process can take longer depending on the type of deployment. For example, deployments across multiple availability zones with many instances can take more than 6 minutes.

Updates initiated to Application Gateway are applied one update domain at a time. As each update domain's instances are being updated, the remaining instances in other update domains continue to serve traffic¹. Active connections are gracefully drained from the instances being updated for up to 5 minutes to help establish connectivity to instances in a different update domain before the update begins. During update, Application Gateway temporarily runs at reduced maximum capacity, which is determined by the number of instances configured. The update process proceeds to the next set of instances only if the current set of instances were upgraded successfully.

¹ We recommend a minimum instance count of 2 to be configured for Application Gateway v1 SKU deployments to ensure at least one instance can serve traffic while updates are applied.

Application Gateway supports TLS/TCP protocol proxy through its Layer 4 proxy in Preview.

Application gateway's Layer 7 proxy with HTTP(S) protocols will not support email protocols such as SMTP, IMAP, and POP3. However, for some supporting email services, such as Outlook Web Access (OWA), ActiveSync, and AutoDiscovery traffic that uses HTTP(S) protocols, you can use Layer 7 proxy, and their traffic should flow through. (Note: Exclusions in the WAF rules might be required when using a WAF SKU).

Yes. For more information, see Migrate Azure Application Gateway and Web Application Firewall from v1 to v2.

Yes. The Application Gateway v1 SKU continues to be supported. We strongly recommend moving to v2 to take advantage of the feature updates in that SKU. For more information on the differences between v1 and v2 features, see Autoscaling and zone-redundant Application Gateway v2. You can manually migrate Application Gateway v1 SKU deployments to v2 by following our v1-v2 migration document.

No. Application Gateway v2 doesn't support proxying requests with NTLM or Kerberos authentication.

Request header names can contain alphanumeric characters and hyphens. Request header names that contain other characters are discarded when a request is sent to the backend target. Response header names can contain any alphanumeric characters and specific symbols as defined in RFC 7230.

Yes. The Chromium browser v80 update introduced a mandate on HTTP cookies without the SameSite attribute to be treated as SameSite=Lax. This means that the Application Gateway affinity cookie won't be sent by the browser in a third-party context.

To support this scenario, Application Gateway injects another cookie called ApplicationGatewayAffinityCORS in addition to the existing ApplicationGatewayAffinity cookie. These cookies are similar, but the ApplicationGatewayAffinityCORS cookie has two more attributes added to it: SameSite=None and Secure. These attributes maintain sticky sessions even for cross-origin requests. For more information, see the Cookie-based affinity section.

An active listener is a listener that's associated to a rule and sending traffic to a backend pool. Any listener that only redirects traffic isn't an active listener. Listeners associated with redirect rules aren't considered active. If the redirect rule is a path-based rule, all the paths in that redirect rule must be redirecting traffic or else the listener is considered active. For individual component limit details, see Azure subscription and service limits, quotas, and constraints.

The Application Gateway v1 SKU supports high-availability scenarios when you've deployed two or more instances. Azure distributes these instances across update and fault domains to ensure that instances don't all fail at the same time. The v1 SKU supports scalability by adding multiple instances of the same gateway to share the load.

The v2 SKU automatically ensures that new instances are spread across fault domains and update domains. If you choose zone redundancy, the newest instances are also spread across availability zones to offer zonal failure resiliency.

Use Azure Traffic Manager to distribute traffic across multiple application gateways in different datacenters.

Yes. You can set up connection draining to change members within a backend pool without disruption. For more information, see the Connection draining section of Application Gateway.

Yes, the Application Gateway v2 SKU supports autoscaling. For more information, see Autoscaling and zone-redundant Application Gateway.

No. Instances are distributed across upgrade domains and fault domains.

Yes.

Yes.

Yes. Application Gateway is always deployed in a virtual network subnet. This subnet can contain only application gateways. For more information, see Virtual network and subnet requirements.

If you have IP connectivity, Application Gateway can communicate with instances outside of the virtual network that it's in. Application Gateway can also communicate with instances outside of the subscription it's in. If you plan to use internal IPs as backend pool members, use virtual network peering or Azure VPN Gateway.

Like any DNS resolver, the Application Gateway resource honors the Time to Live (TTL) value of the backend server's DNS record. After the TTL expires, the gateway performs a lookup to update that DNS information. During this lookup, if your application gateway encounters a problem getting a response (or no DNS record is found), the gateway continues using the last-known-good DNS value to serve the traffic. For more information, see How an application gateway works.

The instances of your application gateway use the virtual network's DNS configuration for name resolution. After changing any DNS server configuration, you need to restart (Stop and Start) the application gateway for the new DNS servers to get assigned. Until then, FQDN-based name resolutions for outbound connectivity could fail.

No. But you can deploy other application gateways in the subnet.

You can move an application gateway across subnets within the same virtual network only. It's supported with v1 with a public and private frontend (dynamic allocation) and v2 with a public frontend only. We can't move the application gateway to another subnet if the private frontend IP configuration is statically allocated. The application gateway should be in a Stopped state to perform this action. Stopping or starting v1 changes the public IP. This operation can only be done by using Azure PowerShell and the Azure CLI by running the following commands:

Azure PowerShell

$VNet = Get-AzVirtualNetwork -Name "<VNetName>" -ResourceGroupName "<ResourceGroup>"
$Subnet = Get-AzVirtualNetworkSubnetConfig -Name "<NewSubnetName>" -VirtualNetwork $VNet
$AppGw = Get-AzApplicationGateway -Name "<ApplicationGatewayName>" -ResourceGroupName "<ResourceGroup>"
Stop-AzApplicationGateway -ApplicationGateway $AppGw
$AppGw = Set-AzApplicationGatewayIPConfiguration -ApplicationGateway $AppGw -Name $AppGw.GatewayIPConfigurations.Name -Subnet $Subnet
#If you have a private frontend IP configuration, uncomment and run the next line:
#$AppGw = Set-AzApplicationGatewayFrontendIPConfig -Name $AppGw.FrontendIPConfigurations.Name[1] -Subnet $Subnet -ApplicationGateway $AppGw
Set-AzApplicationGateway -ApplicationGateway $AppGw

For more information, see Set-AzApplicationGatewayIPConfiguration.

Azure CLI

az network application-gateway stop -g <ResourceGroup> -n <ApplicationGatewayName>
az network application-gateway update -g <ResourceGroup> -n <ApplicationGatewayName> --set gatewayIpConfigurations[0].subnet.id=<subnetID>

See Network security groups in the Application Gateway subnet.

See User-defined routes supported in the Application Gateway subnet.

No. Service endpoint policies for storage accounts aren't supported in the Application Gateway subnet and configuring it blocks Azure infrastructure traffic.

See Application Gateway limits.

Yes. Application Gateway supports one internal IP and one external IP per application gateway.

Yes. Virtual network peering helps load-balance traffic in other virtual networks.

Yes, as long as traffic is allowed.

Microservice architecture is supported. To probe on different ports, you need to configure multiple backend settings.

No.

See Order of processing rules.

The Host field specifies the name to send the probe to when you've configured multisite on Application Gateway. Otherwise, use 127.0.0.1. This value is different from the virtual machine host name. Its format is <protocol>://<host>:<port><path>.

Yes. See Restrict access to specific source IPs.

Yes, you can use public-facing and private-facing listeners with the same port number to simultaneously support public and private clients. If a network security group (NSG) is associated with your application gateway's subnet, a specific Inbound rule might be needed depending on its configuration. Know more.

Application Gateway v2 supports IPv4 and IPv6 frontends. Currently, IPv6 support is available for new application gateways only. To support IPv6, the virtual network should be dual stack. Application Gateway v1 doesn't support dual-stack virtual networks.

Application Gateway v2 currently supports private IP frontend configuration only (no public IP) via public preview.

For current general availability support, Application Gateway v2 supports the following combinations:

• Private IP and public IP
• Public IP only

To restrict traffic only to private IP addresses with current functionality, follow this process:

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 for the Application Gateway subnet with the following configuration in the order of priority:

   1. Allow traffic from Source as the service tag GatewayManager, Destination as Any, and the destination Port as 65200-65535. This port range is required for Azure infrastructure communication. These ports are protected (locked down) by certificate authentication. External entities, including the gateway user administrators, can't initiate changes on those endpoints without appropriate certificates in place.

   2. Allow traffic from Source as the service tag AzureLoadBalancer and the destination Port as Any.

   3. Deny all inbound traffic from Source as the service tag Internet and the destination Port as Any. Give this rule the least priority in the inbound rules.

   4. Keep the default rules like AllowVNetInBound so that the access on a private IP address isn't blocked.

   5. Outbound internet connectivity can't be blocked. Otherwise, you face issues with logging and metrics.

Sample NSG configuration for private IP-only access:

You can use Azure PowerShell or the Azure CLI to stop and start Application Gateway. When you stop and start Application Gateway, billing also stops and starts. Any PUT operation done on a stopped application gateway (like adding tag, health probe, or listener) triggers a start. We recommend that you stop the application gateway after the configuration is updated.

# Stop an existing Azure Application Gateway instance

$appGateway = Get-AzApplicationGateway -Name $appGatewayName -ResourceGroupName $resourceGroupName
Stop-AzApplicationGateway -ApplicationGateway $appGateway       

# Start an existing Azure Application Gateway instance

$appGateway = Get-AzApplicationGateway -Name $appGatewayName -ResourceGroupName $resourceGroupName
Start-AzApplicationGateway -ApplicationGateway $appGateway           

# Stop an existing Azure Application Gateway instance

az network application-gateway stop -g MyResourceGroup -n MyAppGateway

# Start an existing Azure Application Gateway instance

az network application-gateway start -g MyResourceGroup -n MyAppGateway

Application Gateway supports self-signed certificates, certificate authority (CA) certificates, Extended Validation (EV) certificates, multi-domain (SAN) certificates, and wildcard certificates.

Application Gateway supports the following cipher suites:

• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_AES_256_GCM_SHA384
• TLS_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA256
• TLS_RSA_WITH_AES_128_CBC_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA
• TLS_RSA_WITH_AES_128_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
• TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
• TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
• TLS_DHE_DSS_WITH_AES_256_CBC_SHA
• TLS_DHE_DSS_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_3DES_EDE_CBC_SHA
• TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA

For information on how to customize TLS options, see Configure TLS policy versions and cipher suites on Application Gateway.

Yes. Application Gateway supports TLS offload and end-to-end TLS, which reencrypts traffic to the backend.

Yes. You can configure Application Gateway to deny TLS1.0, TLS1.1, and TLS1.2. By default, SSL 2.0 and 3.0 are already disabled and aren't configurable.

Yes. In Application Gateway, you can configure cipher suites. To define a custom policy, enable at least one of the following cipher suites:

• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA256
• TLS_RSA_WITH_AES_128_CBC_SHA256

Application Gateway uses SHA256 for backend management.

Application Gateway supports up to 100 TLS/SSL certificates.

Yes, Application Gateway supports certificates with OCSP extensions and OCSP stapling for server certificates.

Application Gateway supports up to 100 authentication certificates.

Yes, the Application Gateway v2 SKU supports Key Vault. For more information, see TLS termination with Key Vault certificates.

For multiple domain-based (host-based) routing, you can create multisite listeners, set up listeners that use HTTPS as the protocol, and associate the listeners with the routing rules. For more information, see Hosting multiple sites by using Application Gateway.

No. Use only alphanumeric characters in your .pfx file password.

CA/Browser members recently published reports detailing multiple certificates issued by CA vendors that are used by our customers, Microsoft, and the greater technology community that were out of compliance with industry standards for publicly trusted CAs. The reports regarding the noncompliant CAs can be found here:

• Bug 1649951
• Bug 1650910

According to the industry's compliance requirements, CA vendors began revoking noncompliant CAs and issuing compliant CAs, which requires customers to have their certificates reissued. Microsoft is partnering closely with these vendors to minimize the potential impact to Azure services. However, your self-issued certificates or certificates used in Bring Your Own Certificate (BYOC) scenarios are still at risk of being unexpectedly revoked.

To check if certificates utilized by your application were revoked, see DigiCert's announcement and the Certificate Revocation Tracker. If your certificates were revoked, or will be revoked, you need to request new certificates from the CA vendor utilized in your applications. To avoid your application's availability being interrupted because of certificates being unexpectedly revoked, or to update a certificate that has been revoked, see Revocation of noncompliant Certificate Authorities potentially impacting customer's Azure services.

For information specific to Application Gateway:

If you're using a certificate issued by one of the revoked ICAs, your application's availability might be interrupted. Depending on your application, you might receive various error messages including but not limited to:

• Invalid certificate/revoked certificate
• Connection timed out
• HTTP 502

To avoid any interruption to your application because of this issue, or to reissue a CA that has been revoked, you need to take the following actions:

1. Contact your certificate provider on how to reissue your certificates.
2. After they're reissued, update your certificates on the Application Gateway/WAF with the complete chain of trust (leaf, intermediate, and root certificate). Based on where you're using your certificate, either on the listener or the HTTP settings of the application gateway, follow the steps here to update the certificates. For more information, check the documentation links mentioned.
3. Update your backend application servers to use the reissued certificate. Depending on the backend server that you're using, your certificate update steps might vary. Check for the documentation from your vendor.

To update the certificate in your listener:

1. In the Azure portal, open your Application Gateway resource.
2. Open the listener settings that are associated with your certificate.
3. Select Renew or edit selected certificate.
4. Upload your new PFX certificate with the password and select Save.
5. Access the website and verify if the site is working as expected. For more information, see Renew Application Gateway certificates.

If you're referencing certificates from Key Vault in your Application Gateway listener, we recommend the following steps for a quick change:

1. In the Azure portal, go to your Key Vault settings that are associated with the application gateway.
2. Add or import the reissued certificate in your store. For more information, see Quickstart: Create a key vault using the Azure portal.
3. After the certificate has been imported, go to your Application Gateway listener settings and under Choose a certificate from Key Vault, select the Certificate dropdown and select the recently added certificate.
4. Select Save. For more information on TLS termination on Application Gateway with Key Vault certificates, see TLS termination with Key Vault certificates.

To update the certificate in your HTTP settings:

If you're using the v1 SKU of the Application Gateway/WAF service, you have to upload the new certificate as your backend authentication certificate.

1. In the Azure portal, open your Application Gateway resource.
2. Open the HTTP settings that are associated with your certificate.
3. Select Add certificate, upload the reissued certificate, and select Save.
4. You can remove the old certificate later by selecting the ... options button next to the old certificate. Select Delete and then select Save. For more information, see Configure end-to-end TLS by using Application Gateway with the portal.

If you're using the V2 SKU of the Application Gateway/WAF service, you don't have to upload the new certificate in the HTTP settings since V2 SKU uses "trusted root certificates", and no action needs to be taken here.

Yes. Both Layer 7 and Layer 4 routing through application gateway use the same frontend IP configuration. This way, you can direct all your clients to a single IP address (public or private) and the same gateway resource will route them based on the configured listener protocols and the ports.

While the HTTP(S) traffic can be served through L4 proxy protocols as well, we don't recommend doing so. The L7 proxy solution of Application Gateway offers greater control and security over the HTTP(S) protocols through advanced features such Rewrites, Session Affinity, Redirection, WebSockets, WAF and more.

The resource properties for Layer 4 features are different from the Layer 7 ones. Accordingly, when using REST API or CLI, you must use the following properties.

• REST API
• CLI

No. You can't cross-link Layer 4 and Layer 7 properties. Therefore, a routing rule will only allow you to link a Layer 4-type listener to a Layer 4-type Backend setting.

You can't use the same name for an L7 (httpListeners) and L4 (listeners). This applies to other L4 properties such as backendSettingsCollection and routingRules also.

Absolutely. Similar to Layer 7 proxy, you can add a private endpoint to the backend pool of your application gateway. This private endpoint must be deployed in an adjacent subnet of the same virtual network of your application gateway.

It doesn't use Keepalive for backend connections. For each incoming request on the frontend listener connection, Application Gateway initiates a new backend connection to fulfill that request.

The backend server sees the IP address of the application gateway. Currently, we don't support “Client IP preservation” through which the backend application can be made aware of the original client’s IP address.

The same TLS/SSL policy configuration is applicable for both Layer 7 (HTTPS) as well as Layer 4 (TLS). You can now use SSL Profile (for listener-specific TLS policy and Mutual Authentication) for TLS listeners. However, currently an SSL profile can be associated with a TLS listener through CLI, PowerShell or REST API only.

No. Routing a client to the same backend server isn't supported at the moment. The connections will be distributed in a round-robin manner to the servers in a backend pool.

Yes, the autoscale feature will operate for spikes and reductions in traffic for TLS or TCP protocol as well.

The Web Application Firewall (WAF) capabilities won't work for Layer 4 usage.

No. UDP support isn't available at this time.

The same list of allowed port range and exceptions apply for the Layer 4 proxy too.

The use of a common port for TLS/TCP listeners is currently not supported.

Kubernetes allows creation of deployment and service resources to expose a group of pods internally in the cluster. To expose the same service externally, an Ingress resource is defined, which provides load balancing, TLS termination, and name-based virtual hosting. To satisfy this Ingress resource, an ingress controller is required, which listens for any changes to Ingress resources and configures the load balancer policies.

The Application Gateway Ingress Controller (AGIC) allows Application Gateway to be used as the ingress for an Azure Kubernetes Service, also known as an AKS cluster.

Direct configuration of Application Gateway isn't supported.

If there is a need to change settings on Application Gateway, make the change by using the exposed configuration on the ingress controller or other Kubernetes objects, such as by using supported annotations. After an Application Gateway is linked to Application Gateway Ingress Controller (AGIC), nearly all configuration of that gateway will be synced and controlled by the ingress controller. If you're trying to directly configure Application Gateway imperatively or through infrastructure as code, those changes will eventually be overwritten by the ingress controller.

Currently, one instance of an ingress controller can only be associated to one application gateway.

AGIC tries to automatically associate the route table resource to the Application Gateway subnet but might fail to do so because of lack of permissions from the AGIC. If AGIC is unable to associate the route table to the Application Gateway subnet, an error appears in the AGIC logs. In this case, you have to manually associate the route table created by the AKS cluster to the Application Gateway's subnet. For more information, see Supported user-defined routes.

Yes, as long as the virtual networks are peered and they don't have overlapping address spaces. If you're running AKS with kubenet, be sure to associate the route table generated by AKS to the Application Gateway subnet.

For the differences between AGIC deployed through Helm versus deployed as an AKS add-on, see Difference between Helm deployment and AKS add-on, especially the tables that document which scenarios are supported by AGIC deployed through Helm as opposed to an AKS add-on. In general, deploying through Helm allows you to test out beta features and release candidates before an official release.

No. The AGIC add-on is a managed service, which means Microsoft automatically updates the add-on to the latest stable version.

Mutual authentication is two-way authentication between a client and a server. Mutual authentication with Application Gateway currently allows the gateway to verify the client sending the request, which is client authentication. Typically, the client is the only one that authenticates the application gateway. Because Application Gateway can now also authenticate the client, it becomes mutual authentication where Application Gateway and the client are mutually authenticating each other.

No, mutual authentication is currently only between the frontend client and the application gateway. Back-end mutual authentication is currently not supported.

Application Gateway provides three logs:

• ApplicationGatewayAccessLog: The access log contains each request submitted to the application gateway frontend. The data includes the caller's IP, URL requested, response latency, return code, and bytes in and out. It contains one record per application gateway.
• ApplicationGatewayPerformanceLog: The performance log captures performance information for each application gateway. Information includes the throughput in bytes, total requests served, failed request count, and healthy and unhealthy backend instance count.
• ApplicationGatewayFirewallLog: For application gateways that you configure with WAF, the firewall log contains requests that are logged through either detection mode or prevention mode.

All logs are collected every 60 seconds. For more information, see Back-end health, diagnostics logs, and metrics for Application Gateway.

Verify health by using the PowerShell cmdlet Get-AzApplicationGatewayBackendHealth or the portal. For more information, see Application Gateway diagnostics.

Diagnostic logs flow to the customer's storage account. Customers can set the retention policy based on their preference. Diagnostic logs can also be sent to an event hub or Azure Monitor Logs. For more information, see Application Gateway diagnostics.

In the portal, on the menu pane of an application gateway, select Activity Log to access the audit log.

Yes. In Application Gateway, alerts are configured on metrics. For more information, see Application Gateway metrics and Receive alert notifications.

You can view and analyze access logs in several ways. Use Azure Monitor Logs, Excel, Power BI, and so on.

You can also use a Resource Manager template that installs and runs the popular GoAccess log analyzer for Application Gateway access logs. GoAccess provides valuable HTTP traffic statistics such as unique visitors, requested files, hosts, operating systems, browsers, and HTTP status codes. For more information, in GitHub, see the Readme file in the Resource Manager template folder.

Usually, you see an unknown status when access to the backend is blocked by an NSG, custom DNS, or user-defined routing on the Application Gateway subnet. For more information, see Back-end health, diagnostics logging, and metrics for Application Gateway.

Because of current platform limitations, if you have an NSG on the Application Gateway v2 (Standard_v2, WAF_v2) subnet and if you've enabled NSG flow logs on it, you see nondeterministic behavior. This scenario is currently not supported.

Application Gateway doesn't move or store customer data out of the region in which it's deployed.

Next steps

• To learn more about Application Gateway, see What is Azure Application Gateway.
• To learn about TLS termination and end-to-end TLS with Application Gateway, see Enable end-to-end TLS on Azure Application Gateway.