Overview on Azure 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. 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.
Azure Application Gateway delivers application-level routing and load balancing that enable sin creating reliable and scalable websites and web applications. It can be integrated with Azure Cloud Services and provides multi-regional redirection, automatic failover, and run time scalability for internet facing as well as internal web-based applications and services
Prerequisite
- Azure Subscription
- Basic understanding of Load Balancer
- Web Servers running on VM for demo
- Basic Understanding of WAF
Step 01: - Deploy Azure Application Gateway
Search the service Application Gateway in your subscription. As per the below image you can see the service in the results.
On the Basics tab, enter these values for the following application gateway settings: Name of the resource group, Subscription, Name of Application gateway, and very important is Tier: select WAF V2. We are using WAF V2 as we want to configure our Application Gateway as Load Balancer and additional Web Application Firewall service.
For communication between the backend resources that you create, it needs a virtual network. You can either create a new virtual network or use an existing one. Application Gateway instances are required separate subnets.
We will create two subnets in this existing network one for the application gateway, and another for the backend web servers.
As per the below image, we will create a new Public IP Address for our application gateway frontend.
Next will add our Backend VM’s to the backend pool. Backend pool is nothing but your application serving endpoints which we will use with the application gateway. Here in our example, we are using Virtual Machines as the backend.
Once you added the backend you can see those in targets.
In the configuration tab, we have to create routing rules for our application gateway. Here we have two things to configure; one is Listener and other is backend targets.
In listener, you can select port like 80 or 443 means HTTP or HTTPS configuration. If you select HTTPS, then you have to upload an SSL certificate there.
Next is to configure Backend Targets as we already created backend pool here, we have to just specify the one which we want to use in the routing rule.
And finally, it will validate all the configurations and then you can hit on create.
Step 02: - Overview on Application Gateway Configurations
Application Gateway has two versions of the WAF SKU: Application Gateway WAF_v1 and Application Gateway WAF_v2. WAF policy associations are only supported for the Application Gateway WAF_v2 SKU. This provides greater SLAs.
SLA for Application Gateway | Azure
If you don’t want to use WAF you can scale down or you can change to Application Gateway Standard V2.
And the best feature of this is we get an autoscaling feature. This means if you have a lot of data to process and huge traffic so it automatically scales up the Application Gateway instance on the basis of metrics.
Next is to understand WAF Rules. When you use WAF with Application gateway Microsoft offers to prebuild rules to use it.
So, you can go through the WAF option and select Rules as per compliance. You can create custom rules in WAF also like based on Geo locations, IP restrictions, etc.
In Backend Pools tap you can add multiple Backends so we have the option to add target as FQDN like domain URL and Public IP addresses, Azure App Services and according to that you can configure routing rules.
Step 03: - Monitoring Azure Application Gateway using the portal
Now we should understand how we can monitor our resources especially if we are using Load Balancer which can be a single point of failure if this only went down.
We can go to metrics and find details on basis of multiple metrics available as per the image.
The next way to get monitor using logs as every azure resource can be integrated with Log Analytics to storage logs and ingest them for troubleshooting.
You can write custom queries and on basis of that, you can create alerts. Like alert when backend host went down.
And another way we have Insight can give us a graphical representation of our application gateway architecture and workflow. It is a very useful feature as with this you can understand the application gateway configuration.
It also shows the status of resources. As per the image you can see my backend VM’s are unhealthy
And the same way dedicated options to see backend health. Which is self-explanatory.
Summary
This Application Gateway with Standard_v2 and WAF_v2 respectively and are fully supported with a 99.95% SLA. The new SKUs offer significant improvements and additional capabilities to customers. Autoscaling allows elasticity for your application by scaling the application gateway as needed based on your application’s traffic pattern. You no longer need to run the application gateway at peak provisioned capacity, thus significantly saving on the cost.
- Protect your web applications from web vulnerabilities and attacks without modification to back-end code.
- Create custom WAF policies for different sites behind the same WAF.
- You can use WAF in Detect Mode and Prevent Mode which is very useful for understanding applications initially.
Reference Links
- What is Azure Web Application Firewall on Azure Application Gateway? - Azure Web Application Firewall | Microsoft Docs
- SLA for Application Gateway | Azure
- Frequently asked questions about Azure Application Gateway | Microsoft Docs