1. Application Gateway Instances Download
2. Instance It
3. Application Gateway Instances Free
4. Application Gateway Instance Size
5. Single Instance Application

Azure App Services (Web Apps) are publicly exposed to the Internet by default, accessible with their *.azurewebsites.net URL. This means that anyone in the world can access your site simply by knowing its URL, including hackers and spammers.

Get application-level load-balancing services and routing to build a scalable and highly available web front end in Azure. Autoscaling (preview) offers elasticity by automatically scaling Application Gateway instances based on your web application traffic load.

A maximum of 50 application gateways can be created for each subscription, and each application gateway with its specific configuration can be run in a maximum of 10 instances. By Jason Milgram, Director of Software Development & Microsoft Azure MVP, Champion Solutions Group / MessageOps. A maximum of 50 application gateways can be created for each subscription, and each application gateway with its specific configuration can be run in a maximum of 10 instances. By Jason Milgram, Director of Software Development & Microsoft Azure MVP, Champion Solutions Group / MessageOps. Mar 20, 2019  Note. These values are approximate values for an application gateway throughput. The actual throughput depends on various environment details, such as average page size, location of back-end instances, and processing time to serve a page. I currently have an Azure Application Gateway that is configured for a minimum of 2 instances and a maximum of 10 instances. It's Tier is 'WAF V2' and autoscaling is enabled. If autoscaling is enabled, then theoretically there should be somewhere between 2 and 10 instances.

We can secure our site by using an Application Gateway as a frontend. Azure App Gateway is an HTTP load balancer that allows you to manage traffic to your web apps. App Gateway operates at layer 7 (application layer) and can scan incoming requests using OWASP common vulnerabilities rule set and/or route based on URL syntax. The App Gateway offers many other features including DDoS protection: https://docs.microsoft.com/en-us/azure/application-gateway/overview.

Application Gateway v2 is currently in public preview with upcoming general availability. Organizations and individuals concerned with security/compliance in the cloud can leverage these services for an isolated environment where their backend Web App is entirely secured.

Here’s what it looks like:

SSL Termination vs End to End SSL

It’s also important to understand the role of SSL in this scenario. There are two options, either SSL termination at the App Gateway or end to end SSL all the way through to the backend. With SSL termination the PFX is uploaded directly to the App Gateway, traffic flows unencrypted to the backend, if the resources exist in the same datacenter the traffic never egresses but it is still unencrypted which is vulnerable. The benefit of SSL termination is that the backend is unburdened by the additional overhead.

With end to end SSL, the App Gateway terminates SSL sessions at the gateway and decrypts client traffic. It then applies the configured rules to target the appropriate backend pool. A new SSL connection is initiated to the backend server and re-encrypted using the backend server’s public key certificate. This connectivity between the App Gateway and the backend server occurs securely over port 443. Each individual’s security requirements or paranoia will determine which is a better option.

Create Application Gateway V2

To start off we will deploy an App Gateway V2, selecting Standard V2 as the tier, and Central US as the location. It’s worth noting that the App Gateway is free of charge until GA.

Create backend Web App

Next we will deploy a regular Web App with a Free tier App Service Plan in Location: Central US.

Now I will edit the default homepage of my Web App to dump out all of the request headers, which is useful for understanding how the App Gateway works, relying on Host header and others like x-forwarded-for.

• Access the Kudu site at https://<webAppName>.scm.azurewebsites.net/DebugConsole and navigate into the sitewwwroot directory
• Delete the hostingstart.html file
• On the command line type: touch default.aspx
• Click the pencil icon to edit the file, and paste in this source code: https://pastebin.com/d6XXASiK
• Save the file
• Test the site directly now by going to https://<webAppName>.azurewebsites.net and you will see all the request headers dumped out

Configure the Custom Hostname DNS and create the HTTPS Listener

Now I need to decide what custom hostname I want to access the site on and I will need to have a matching SSL certificate. For this test I will use my valid SSL certificate for www.patrickob.com, but for testing purposes you can create a self-signed cert and export the PFX.

• I don’t want to interrupt the active routing of my site so I’m going to edit my Hosts file to point at my new App Gateway’s public IP, or use a fake domain for testing
• We can see this in the Azure Portal from the Overview blade of the App Gateway
• Update my local machine’s Hosts file to include this entry
• I need to have the PFX file for the SSL certificate that matches this custom hostname, because it needs to be uploaded to the App Gateway to serve to clients
• Open the App Gateway in the Azure Portal and click on the Listeners blade, create a new Multi-Site Listener
• Set the host name property appropriately and upload the matching PFX

Create HTTPS Health Probe

• Open the Health Probes blade of the App Gateway
• Create a new HTTPS health probe, which will be used to verify the backend health

Create an HTTP Setting with End to End SSL enabled

• Open the HTTP Settings blade of the App Gateway
• Create a new HTTP Setting, which is what will be used to configure our connection to the backend pool
• In this case we want to use end to end SSL for maximum security, the backend Web App certificates are trusted by default
• Select HTTPS protocol, Use for App Service, and select the custom probe created previously

Create a Backend Pool

• Open the Backend Pools blade of the Application Gateway
• Add a new backend pool and target our previously created App Service

Create a Routing Rule

• Open the Rules blade of the Application Gateway
• Add a new Basic rule and select our previously created Listener, Backend Pool, and HTTP Setting

Configure IP Restrictions on the Web App to restrict access to only the App Gateway

• We want to block all direct access to the backend Web App except from the client IP of our App Gateway, which is static and same as the frontend IP found previously
• Open the Web App in the Azure portal and click on the Networking blade, then Access Restrictions
• Add a rule that allows the App Gateway’s IP address, with the /32 subnet block
• You can now test the site using its default *.azurewebsites.net URL to confirm that direct access is denied

Test the Site and confirm Solution

• Click on the Backend Health blade of the App Gateway, here we can confirm our new probe is receiving a healthy status from the backend over port 443

• We can now test accessing the site through the Application Gateway by using the custom domain we setup previously, in my case www.patrickob.com
• Note several important headers, including the Host header which shows that we have reached the backend over its default hostname and port 443

My backend is now isolated and all clients must route through my Application Gateway, which protects me from common vulnerabilities and DDoS. This is only an elementary introduction to App Gateway and it offers many powerful features.

I hope this example is helpful~!

Additional Resources

-->

Azure Application Gateway is a web traffic load balancer that enables you to manage traffic to your web applications. Traditional load balancers operate at the transport layer (OSI layer 4 - TCP and UDP) and route traffic based on source IP address and port, to a destination IP address and port.

With Application Gateway, you can make routing decisions based on additional attributes of an HTTP request, such as URI path or host headers. For example, you can route traffic based on the incoming URL. So if /images is in the incoming URL, you can route traffic to a specific set of servers (known as a pool) configured for images. If /video is in the URL, that traffic is routed to another pool that's optimized for videos.

This type of routing is known as application layer (OSI layer 7) load balancing. Azure Application Gateway can do URL-based routing and more.

The following features are included with Azure Application Gateway:

Secure Sockets Layer (SSL/TLS) termination

Application gateway supports SSL/TLS termination at the gateway, after which traffic typically flows unencrypted to the backend servers. This feature allows web servers to be unburdened from costly encryption and decryption overhead. But sometimes unencrypted communication to the servers is not an acceptable option. This can be because of security requirements, compliance requirements, or the application may only accept a secure connection. For these applications, application gateway supports end to end SSL/TLS encryption.

Autoscaling

Application Gateway or WAF deployments under Standard_v2 or WAF_v2 SKU support autoscaling and can scale up or down based on changing traffic load patterns. Autoscaling also removes the requirement to choose a deployment size or instance count during provisioning. For more information about the Application Gateway Standard_v2 and WAF_v2 features, see Autoscaling v2 SKU.

Zone redundancy

An Application Gateway or WAF deployments under Standard_v2 or WAF_v2 SKU can span multiple Availability Zones, offering better fault resiliency and removing the need to provision separate Application Gateways in each zone.

Static VIP

The application gateway VIP on Standard_v2 or WAF_v2 SKU supports static VIP type exclusively. This ensures that the VIP associated with application gateway doesn't change even over the lifetime of the Application Gateway.

Web application firewall

Web application firewall (WAF) is a feature of Application Gateway that provides centralized protection of your web applications from common exploits and vulnerabilities. WAF is based on rules from the OWASP (Open Web Application Security Project) core rule sets 3.1 (WAF_v2 only), 3.0, and 2.2.9.

Web applications are increasingly targets of malicious attacks that exploit common known vulnerabilities. Common among these exploits are SQL injection attacks, cross site scripting attacks to name a few. Preventing such attacks in application code can be challenging and may require rigorous maintenance, patching and monitoring at many layers of the application topology. A centralized web application firewall helps make security management much simpler and gives better assurance to application administrators against threats or intrusions. A WAF solution can also react to a security threat faster by patching a known vulnerability at a central location versus securing each of individual web applications. Existing application gateways can be converted to a web application firewall enabled application gateway easily.

For more information, see Web application firewall (WAF) in Application Gateway.

URL-based routing

URL Path Based Routing allows you to route traffic to back-end server pools based on URL Paths of the request.One of the scenarios is to route requests for different content types to different pool.

For example, requests for http://contoso.com/video/* are routed to VideoServerPool, and http://contoso.com/images/* are routed to ImageServerPool. DefaultServerPool is selected if none of the path patterns match.

For more information, see URL-based routing with Application Gateway.

Multiple-site hosting

Multiple-site hosting enables you to configure more than one web site on the same application gateway instance. This feature allows you to configure a more efficient topology for your deployments by adding up to 100 web sites to one Application Gateway, or 40 for WAF (for optimal performance). Each web site can be directed to its own pool. For example, application gateway can serve traffic for contoso.com and fabrikam.com from two server pools called ContosoServerPool and FabrikamServerPool.

Requests for http://contoso.com are routed to ContosoServerPool, and http://fabrikam.com are routed to FabrikamServerPool.

Similarly, two subdomains of the same parent domain can be hosted on the same application gateway deployment. Examples of using subdomains could include http://blog.contoso.com and http://app.contoso.com hosted on a single application gateway deployment.

For more information, see multiple-site hosting with Application Gateway.

Redirection

A common scenario for many web applications is to support automatic HTTP to HTTPS redirection to ensure all communication between an application and its users occurs over an encrypted path.

In the past, you may have used techniques such as dedicated pool creation whose sole purpose is to redirect requests it receives on HTTP to HTTPS. Application gateway supports the ability to redirect traffic on the Application Gateway. This simplifies application configuration, optimizes the resource usage, and supports new redirection scenarios, including global and path-based redirection. Application Gateway redirection support isn't limited to HTTP to HTTPS redirection alone. This is a generic redirection mechanism, so you can redirect from and to any port you define using rules. It also supports redirection to an external site as well.

Application Gateway redirection support offers the following capabilities:

• Global redirection from one port to another port on the Gateway. This enables HTTP to HTTPS redirection on a site.
• Path-based redirection. This type of redirection enables HTTP to HTTPS redirection only on a specific site area, for example a shopping cart area denoted by /cart/*.
• Redirect to an external site.

For more information, see redirecting traffic with Application Gateway.

Session affinity

The cookie-based session affinity feature is useful when you want to keep a user session on the same server. By using gateway-managed cookies, the Application Gateway can direct subsequent traffic from a user session to the same server for processing. This is important in cases where session state is saved locally on the server for a user session.

Websocket and HTTP/2 traffic

Application Gateway provides native support for the WebSocket and HTTP/2 protocols. There's no user-configurable setting to selectively enable or disable WebSocket support.

The WebSocket and HTTP/2 protocols enable full duplex communication between a server and a client over a long running TCP connection. This allows for a more interactive communication between the web server and the client, which can be bidirectional without the need for polling as required in HTTP-based implementations. These protocols have low overhead, unlike HTTP, and can reuse the same TCP connection for multiple request/responses resulting in a more efficient resource utilization . These protocols are designed to work over traditional HTTP ports of 80 and 443.

For more information, see WebSocket support and HTTP/2 support.

Azure Kubernetes Service (AKS) Ingress controller preview

The Application Gateway Ingress controller runs as a pod within the AKS cluster and allows Application Gateway to act as ingress for an AKS cluster. This is supported with Application Gateway v2 only.

For more information, see Azure Application Gateway Ingress Controller.

Application Gateway Instances Download

Connection draining

Connection draining helps you achieve graceful removal of backend pool members during planned service updates. This setting is enabled via the backend http setting and can be applied to all members of a backend pool during rule creation. Once enabled, Application Gateway ensures all de-registering instances of a backend pool do not receive any new request while allowing existing requests to complete within a configured time limit. This applies to both backend instances that are explicitly removed from the backend pool by an API call, and backend instances that are reported as unhealthy as determined by the health probes.

For more information, see the Connection Draining section of Application Gateway Configuration Overview.

Custom error pages

Application Gateway allows you to create custom error pages instead of displaying default error pages. Software bundle sites. You can use your own branding and layout using a custom error page.

For more information, see Custom Errors.

Rewrite HTTP headers

HTTP headers allow the client and server to pass additional information with the request or the response. Rewriting these HTTP headers helps you accomplish several important scenarios, such as:

• Adding security-related header fields like HSTS/ X-XSS-Protection.
• Removing response header fields that can reveal sensitive information.
• Stripping port information from X-Forwarded-For headers.

Application Gateway supports the capability to add, remove, or update HTTP request and response headers, while the request and response packets move between the client and back-end pools. It also provides you with the capability to add conditions to ensure the specified headers are rewritten only when certain conditions are met.

For more information, see Rewrite HTTP headers.

Sizing

Instance It

Application Gateway Standard_v2 and WAF_v2 SKU can be configured for autoscaling or fixed size deployments. These SKUs don't offer different instance sizes. For more information on v2 performance and pricing, see Autoscaling v2 SKU.

The Application Gateway Standard and WAF SKU is currently offered in three sizes: Small, Medium, and Large. Small instance sizes are intended for development and testing scenarios.

For a complete list of application gateway limits, see Application Gateway service limits.

The following table shows an average performance throughput for each application gateway v1 instance with SSL offload enabled:

Average back-end page response size	Small	Medium	Large
6 KB	7.5 Mbps	13 Mbps	50 Mbps
100 KB	35 Mbps	100 Mbps	200 Mbps

Application Gateway Instances Free

Note

These values are approximate values for an application gateway throughput. The actual throughput depends on various environment details, such as average page size, location of back-end instances, and processing time to serve a page. For exact performance numbers, you should run your own tests. These values are only provided for capacity planning guidance.

Application Gateway Instance Size

Next steps

Single Instance Application

Depending on your requirements and environment, you can create a test Application Gateway using either the Azure portal, Azure PowerShell, or Azure CLI: