Applications are not always designed with scalability as a priority. Handling greater demand may only be possible by multiplying application instances and servers. Workloads and traffic must then be distributed appropriately between each instance of the application. Further complexity arises when sessions must always be connected to the same endpoint (when using shopping carts, for instance) – or on the contrary, when they must connect to different endpoints (in content delivery networks, for example.) In other cases, applications with minimal or no built-in security must provide secure outward-facing access over the internet, but without negatively affecting their performance.

Azure App Gateway

Azure Application Gateway helps resolve these issues. This layer 7 (application layer in the OSI model) load balancing solution allows you to create traffic routing rules based on HTTP, offers cookie-based session affinity, and provides Secure Sockets Layer (SSL) processing to offload SSL processing work from resources such as web farms, thus protecting their performance. As an Azure service, it offers high availability and also provides resource health monitoring and management.

Which Load Balancer Do You Need?

Azure also offers a number of load-balancing solutions at different levels:

  • Azure Application Gateway. Provides a termination point for each client connection, then forwards the corresponding requests to the relevant backend endpoints. Makes routing decisions based on the layer 7 HTTP and HTTPS information in the traffic it handles. Handles any Azure Internal IP address, including Azure VNets, or public internet IP address. Provides session or SSL management.
  • Azure Load Balancer. Operates at layer 4 (transport layer TCP and UDP level), to distribute traffic between instances of an application in the same Azure data center. Addresses Azure VMs (virtual machines) and Cloud Services role instances, including Vnets and public internet addresses, but does not provide session or SSL management.
  • Traffic Manager. This load balancer uses DNS responses to route traffic to different endpoints that are distributed globally. Client connections to the endpoint concerned are then made directly. Addresses Azure VMs, cloud services, Azure Web Apps and external endpoints. Only handles public internet addresses, not Azure Internal addresses. Does not provide session or SSL management.

Each load balancing solution can be used independently or in combination with one or both of the others.

Health Monitoring in Application Gateway

Failover is part of Azure Application Gateway capabilities, as well as performance-based routing. Via its health probes, the gateway monitors the health of each back-end resource and tracks its health rating. It automatically removes a resource from the pool if the resource health rating dips below a predefined level. However, the gateway also continues to monitor unhealthy as well as healthy resources and will return a resource to the healthy backend pool if the availability and performance of the resource justify doing so. Backend resources can be located in the cloud and on-premises. Custom health probes give you finer control over health monitoring, allowing you to configure probe intervals, URLs and paths to be tested, as well as the maximum acceptable number of failure responses before declaring a backend resource to be unhealthy.

Setting Up Application Gateway

Implementation of Azure Application Gateway starts by defining a subnet within an Azure virtual network, for the exclusive use of the application gateway. The application gateway is then created as a resource on that subnet. The servers using the application gateway must have their endpoints defined on the same virtual network (but not the same subnet as the gateway), or have public IP addresses. The next step is to configure the application gateway, by defining the following values:

  • Backend server pool. This is a list of the IP addresses of the servers or endpoints behind the application gateway.
  • Backend server pool settings. Examples are port number, protocol, and cookie-based affinity. The settings apply to a pool as a whole and are applied to all the servers in that pool.
  • Frontend port. Traffic arrives at this port and is then redirected by the gateway to one of the backend servers.
  • Listener. A listener is configured with a frontend port, a protocol (Http or Https), and an SSL certificate name, if SSL certification is being offloaded from a back-end pool.
  • Rule. This defines the backend server pool destination for traffic handled by the corresponding listener.

Small, medium and large versions of the Azure Application Gateway are available. The small version is intended for developers and testers. 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, Sirius / MessageOps

Was this article helpful?