Its an Application Delivery Controller with some load balancing features thrown in. Post over, like if you found it useful.
Seriously though it sounds simple but, there is a lot of depth and complexity to the Azure App Gateway. It also differs a bit from the more traditional Azure Load Balancers which I'll go through in the blog.
Why use an Azure App Gateway?
Azure App Gateway is used to prevent bottlenecks in the application and to maximize the throughput. Thus reducing the response time of the application at peak times and preventing the overloading of idle compute units. It is used to make intelligent routing decisions based on the content of traffic to the Azure App Gateway.
Parts of an Azure App Gateway:
The App Gateway is composed of several parts. Each of them serves a particular function inside the gateway.
Frontend IP Address:
Its the IP address that is associated with the gateway. You
can set a public and a private IP address but, they must both
reside in the same location as the gateway and virtual
network. These IPs are then associated with a Listener.
You can have multiple Listeners associated with a gateway.
Each one is responsible for listening to incoming requests to
gateway, and validating the request based on several factors
including http protocol, host name and IP address all
configured in that Listener. After the request has been
validated it is then send to the relevant backend pool. There
are two types of Listeners basic and multi-site. Basic
Listeners look out for a single domain site, and multi-site
monitors requests from several hostnames\ domains or web apps.
Web Application Firewall (WAF):
This service defines rules to further validate incoming
requests by detecting common threats such as SQL injection
attacks and cross-site forgery attacks. This is done by
reading the content of the traffic and matching that content
to known patterns for those types of attacks.
These act as a connector between the Listeners, Backend Pools
and the Backend HTTP Settings. They define how traffic should
be routed on the Listener. This can be done in two different
methods: Basic and Path-based. Basic Routing Rules forward
requests from the Listener to the associated Backend Pool.
Path-based uses the URL of the request and path matching to
route traffic to a Backend Pool, if no matches was found the
traffic is instead routed to the default Backend Pool.
Backend HTTP Settings:
These settings define how traffic is routed to backend pools. In the settings you can define: what http protocol to route requests over, what port the backend servers listen to traffic on, etc. You can also associate a custom probe to monitor health of the backend service and you can override the name of the backend service to route traffic to. There are more elements that can be configured in the Backend HTTP Settings including Cookie-based affinity for maintaining user sessions and reconfiguring the host name in the request.
Backend pools are used to route requests to the backend services that are going to consume the request. These can be configured to use Network Interface Cards (NIC) for connecting to virtual machines or a mix of IP addresses and vnets for cloud based connections.
These are used to monitor the health of backend pools. By default the gateway monitors the health of all backend pools but, this can be customized to allow for finer control over how the health of the application is monitored including sending custom error codes when something goes wrong.
Azure App Gateway vs Azure Load Balancers:
Well... you see although an Azure App Gateway is a kind of load balancer it is important to note that their are several key differences between the two Azure offerings.
Azure App Gateway can be used to make routing decisions for traffic to the application. Whereas Azure Load Balancer only routes traffic based on port and IP address and doesn't interact with it.
Azure App Gateway can include a WAF to help protect the application from common threats such as SQL injections attacks. Azure Load Balancer cannot filter traffic.
Azure App Gateway can preform end to end traffic encryption using TLS/ SSL encryption or allow unencrypted traffic to flow through in to the backends using TLS termination. Azure Load Balancers are port forwarding and use TCP/ UDP protocols for load balancing as such they cannot make use of TLS termination.
The traffic directed through the Azure App Gateway is read and decisions on it's routing is made based on the content of the traffic. Where as in an Azure Load Balancer the traffic is routed unread.
And probably the biggest difference between the two:
- The Azure Load Balancer is a zone redundant, high performance low latency layer 4 load balancer used to ensure high availability of the application. Where as the Azure App Gateway is an Application Delivery Controller that provides some layer 7 load balancing features.
I hope this blog has helped you to better understand what the Azure App Gateway is and why it is an important. If it has help feel free to like and share the post. You can also connect with me on linkedin if you'd like.
An Application Delivery Controller is a networking component that is used to preform load balancing as improve the security and resilience of the application.
By monitoring the health of the backend pools what is meant is that the backend services are sent a request to a particular endpoint. If the status of the response is a 200 ok the probe states that the backend pool is healthy else the probe is shown as unhealthy.
A vnet is a virtual network, a digital version of your network that can be divided into sub networks (subnets) which are ranges of IP addresses inside of your network.
A layer 4 load balancer operates on the transport layer over TCP and UDP protocols.
A layer 7 load balancer operates on the application level using protocols such as HTTP and SMTP.
A Network Interface Card is a component in Azure that allows resources to connect to the internet similar to it's hardware counterpart.