Azure App Gateway in Cloud Computing
Balamurugan Jeyakumar
in Azure, Blog, Business Intelligence, Cloud, Digital Experience, Microsoft
Introduction
In this article am going to walk you through the Application Gateway or App Gateway service in Microsoft Azure. I will be covering the purpose, various components, and the features of the Application Gateway that are leveraged in common. I also have a small example to explain the Application Layer Load Balancing (OSI Layer 7) using App Gateway.
Web application security, load balancing, SSL communication between the request, response, and URL based routing are the post-development and time-consuming activities when any application is deployed in production in the On Perm server-based deployment. As the Cloud compute evolves, this has become easy by doing a set of configurations in the Cloud networking service. A service in Azure that allows you to achieve these through configurations is called as an App Gateway. App Gateway makes the Network Engineers, Security Engineers and Dev Ops work easy for the App layer load balancing, enforcing the OWASP security rules, URL-based routing and SSL communication in the external-facing web application. Let’s see the components, features, and use of the App Gateway, in detail in this article.
Why App Gateway
- HTTPS can be enabled without changing application code when migrating Web application from Server based deployment to Cloud based deployment
- Route your request to different servers based on the URL change
- Add an application layer load balancer to apps by installing apps in different server
- Enhance application layer security with the help of Web application Firewall Features
- When migrating application to cloud and there is a need to use the sub domain as different application, then Application Gateway can be used
- When cloud application in the need of HTTP to HTTPS redirection
- When cloud application in the need of SSL Termination (The internal communication will not require encryption and decryption)
- When applications are running in Azure Kubernetes Service , we can use the Application Gateway as a ingress controller to avoid another PIP based Load balancer and multiple hop
- To host multiple sites under one Application Gateway . In this case, the host name may be different
- To keep an user session on the same server for your application
What is App Gateway
Azure Application Gateway is a web traffic load balancer that enables to management of traffic to web applications. (Referenced: Microsoft Official Docs).
Application Gateway is an advanced version of the load balancer in the OSI Layer 7 with more features including the application layer security. The traditional load balancer supports OSI layer 4 with the TCP/UDP but Application Gateway, supports OSI layer 7 and it works only with http/https protocols (port 80 and 443). With Application Gateway, we can be more specific about the route to be followed and the destination to be reached. We can route the traffic based on the incoming URL. For example let’s consider a scenario, where the environment is configured with two different destinations to handle two different requests, one will handle Image file requests and the other one will handle Video file requests. In this case, Application Gateway is smart enough, by taking the help of Listener and rules, it can route the traffic to the correct and accurate destination.
Application Gateway distributes incoming application traffic across different backend pools and it may be an (application hosted in ) VMs, VM Scale Sets, Azure App Service, and On Perm External Servers.
Components of App Gateway
- Frontend IP Configurations
The Frontend IP address is the PIP or local IP associated with the Application Gateway. It will support one PIP or one private IP. A public IP address is required to host a back end that clients must access over the Internet via an Internet-facing virtual IP (VIP). When the Application Gateway uses as an Internal Load balancer then PIP is not required.
- Listeners
The listener is a component in the Application Gateway and it will check the incoming request based on the Port, Host, Protocol and IP Address. It has 2 Types.
- Basic will be used If all requests (for any domain) to be accepted and forwarded to backend pools.
- Multi-Site will be used to forward requests to different backend pools based on the host header or host names.
- Ports and Protocol:
A port is where a listener listens for the client’s request. The supported protocols are,
HTTP, HTTPS, HTTP/2, and WebSocket
- Backend Pools
A backend pool routes request to backend servers, which serve the request. Backend pools can contain:
- NICs
- Virtual machine scale sets
- Public IP addresses
- Internal IP addresses
- FQDN
- Multitenant backends (such as App Service)
As Application Gateway can communicate with instances outside of the virtual network (If the VNET peering is enabled between VNET) the members of the backend pools can be across clusters, across datacenters or outside Azure as long as there’s IP connectivity.
- Rules
A request routing rule is a key component of an Application Gateway because it determines how to route traffic on the listener. The rule binds the listener, the back-end server pool, and the backend HTTP settings.
There are two types of request routing rules:
Basic – All requests on the associated listener (for example, blog.contoso.com/*) are forwarded to the associated backend pool by using the associated HTTP setting.
Path-based – This routing rule lets you route the requests on the associated listener to a specific backend pool, based on the URL in the request. If the path of the URL in a request matches the path pattern in a path-based rule, the rule routes that request. It applies the path pattern only to the URL path, not to its query parameters. If the URL path on a listener request doesn’t match any of the path-based rules, it routes the request to the default backend pool and HTTP settings.
- Health Probe
Heath Probe components in App Gateway will monitor the health of all the resources in the backend pool and it will remove if it is unhealthy. Also, it will add automatically when it is back to healthy state. This will make sure the backend resource are healthy to serve the response for the request.
- HTTP Settings
An Application Gateway routes traffic to the backend servers (specified in the request routing rule that includes HTTP settings) by using the port number, protocol, and other settings detailed in this component.
Features of App Gateway
- Web application Firewall
Web Application Firewall (WAF) is a Cloud service that provides centralized protection of the 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.
A centralized web application firewall helps make security management much simpler and gives better assurance to the application administrators against threats. 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.
- Connection Draining
Application Gateway provides a connection draining feature to improve the availability of backend instances. This feature maintains the backend pool instances, if a back-end instance fails health checks, then the connection draining feature will not send any new requests to the unhealthy instance and remove the instance from the back-end pool and keep checking the health report for removed instances till received a good health report. It adds the removed instance back to the back-end pool once the instance is in good health.
We can perform maintenance or replacement of back-end instances without impacting our customers’ experience. This feature is also helping to scale up the instances as per the requirement.
- URL Based Routing
A URL Path-based Routing allows Application Gateway to route the incoming traffic to back-end server pools based on URL Paths of the request. Due to this feature routing the traffic to its destination is very accurate.
- Cookie Based Session Affinity
The cookie-based session affinity feature is useful 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 the session state is saved locally on the server for a user session. This feature is optional and can be configured later if required.
- SSL Termination
SSL Termination allows communication with the backend instances is un-encrypted. SSL Termination at Application Gateway, remove the encryption and decryption overhead from the webserver. It will give you some of the advantages in the request-response time and processing. Following are the advantages of the SSL Termination.
Improved performance – The biggest performance hit when doing TLS decryption is the initial handshake. To improve performance, the server does the decryption, caches TLS session IDs, and manages TLS session tickets. If this is done at the Application Gateway, then all requests from the same client can use the cached values. If it’s done on the backend servers, then each time the client’s requests have to go to a different server and the client must re‑authenticate. The use of TLS tickets can help mitigate this issue, but they are not supported by all clients and can be difficult to configure and manage.
Better utilization of the backend servers – SSL/TLS processing is very CPU intensive and is becoming more intensive as key sizes increase. Removing this work from the backend servers allows them to focus on delivering content, what they are most efficient at
Intelligent routing – By decrypting the traffic, the Application Gateway has access to the requested content, such as headers, URI, and so on, and can use this data to route requests.
Certificate management – Certificates only need to be purchased and installed on the Application Gateway and not all backend servers. This saves both time and money.
- Custom Error Pages
Application Gateway allows you to create custom error pages instead of displaying default error pages. You can use your own branding and layout using a custom error page. Ex. You can use your own maintenance page if your backend pool is not reachable. Also, you can set a custom error page when some of the requests have been blocked by the Application Gateway. For example, if you are sending a volume of data (more than 128 KB) in your request body, then it will block (If WAF Prevention mode is enabled) the request from the processing, and the corresponding custom page is displayed based on the HTTP Error code.
We can use the custom pages in the below two scenarios,
Maintenance page – This custom error page is shown instead of a 502 bad gateway page. The error page is shown when Application Gateway has no backend to route traffic to. For example, when there’s scheduled maintenance or when an unforeseen issue affects backend pool access.
Unauthorized access page – This custom error page is sent instead of a 403 unauthorized access page. The error page is shown when the Application Gateway WAF detects malicious traffic and blocks it.
Custom error pages can be defined at the global level and at the listener level:
Global level – the error page applies to traffic for all the web applications deployed on that Application Gateway.
Listener level – the error page is applied to the traffic received on that listener.
Both – the custom error page defined at the listener level overrides the one set at a global level.
- Multi-Site Hosting
The multi-Site Hosting feature of Application Gateway allows us to configure more than one website on the same Application Gateway instance. It helps to configure a more efficient topology for deployment by adding up to 100 websites for one Application Gateway. We can add up to 100 listeners to handle those 100 websites, each website can have its own back-end pool.
- Re Write HTTP Headers
Rewrite HTTP headers feature allows a client and server to pass additional information with requests or responses. This feature allows adding, removing, or updating HTTP request and response headers while the request and response packets move between the client and backend pools. Following are some of the scenarios.
- 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.
An Application Gateway inserts four additional headers to all requests before it forwards the requests to the backend. These headers are x-forwarded-for, x-forwarded-proto, x-forwarded-port, and x-original-host. The format for x-forwarded-for header is a comma-separated list of IP:port. If session affinity is enabled as an option, then it adds a gateway-managed affinity cookie.
- Web Socket and HTTP/2 Traffic
WebSockets/ HTTP 2.0 provide a persistent connection between a client and server that both parties can use to start sending data at any time. Client and Server communicate over the same TCP connection for the life-cycle of WebSocket connection. The server can push information to the client (which does not allow direct HTTP).
Demo (App gateway as Layer 7 Load balancer:
Level: Intermediate
We will be doing the below in the exercise,
- Create Azure App Gateway using ARM template
- Create associated Network Components (VNets), PIP, Bastion Service, few VMs and IIS installed on those VMs
- Host the application in IIS in the VM in port 80
- Allow the application access (with an app layer load balance) through Public IP assigned to the App Gateway (as I don’t have the domain purchased :)) and without assigning any PIP to the VMs.
- Adds an addition security by enforcing the Web application Firewall (WAF). As we have 2 different VMs hosted with same application in IIS, this will explain about the Load balance to the app server.
Resources are required to run this Demo.
1. Have an Azure Subscription
2. Download the ARM Template for this Demo
3. Watch and follow the demo video
Summary:
I hope this article provided an intermediate level of understanding of the Azure Application Gateway, its features and the scenarios on when to use Application Gateway. We will discuss more WAF in Application Gateways in the next article
How iLink can help your business?
iLink’s extensive knowledge and expertise can help you learn more about Azure and bring it to your organization today. Get in touch with us to learn how we can help.
