Application Gateway

  • Author: Ronald Fung

  • Creation Date: May 9, 2023

  • Next Modified Date: May 9, 2024

A. Introduction

Azure Application Gateway is a web traffic load balancer that enables you to manage traffic to your web applications.

B. How is it used at Seagen

As a biopharma research company using Microsoft Azure, you can use Azure Application Gateway to manage and optimize web traffic to your applications. Here are some ways you can use Azure Application Gateway:

  1. Load balancing: Azure Application Gateway provides load balancing capabilities that allow you to distribute traffic across multiple servers or instances. This helps to ensure that your applications are highly available and can handle increased traffic.

  2. SSL/TLS termination: Azure Application Gateway provides SSL/TLS termination, which allows you to offload the burden of SSL/TLS encryption from your application servers. This helps to improve performance and scalability.

  3. Web application firewall: Azure Application Gateway provides a web application firewall (WAF) that can help protect your web applications from common attacks such as SQL injection and cross-site scripting (XSS).

  4. URL-based routing: Azure Application Gateway supports URL-based routing, which allows you to route traffic to different backend servers or instances based on the URL path.

  5. Session affinity: Azure Application Gateway provides session affinity, which allows you to ensure that client requests are always directed to the same backend server or instance. This is important for applications that require stateful connections.

  6. Health probes: Azure Application Gateway provides health probes, which allow you to monitor the health of your backend servers or instances and automatically route traffic to healthy servers.

Overall, Azure Application Gateway can help your biopharma research company manage and optimize web traffic to your applications. With load balancing, SSL/TLS termination, a web application firewall, URL-based routing, session affinity, and health probes, Azure Application Gateway can help you improve the performance, scalability, and security of your applications.

C. Features

Application Gateway includes the following features:

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 isn’t 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.

For more information, see Overview of SSL termination and end to end SSL with Application Gateway

Autoscaling

Application Gateway Standard_v2 supports 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 features, see What is Azure Application Gateway v2?.

Zone redundancy

A Standard_v2 Application Gateway 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 Standard_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 service 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 What is Azure Web Application Firewall?.

Ingress Controller for AKS

Application Gateway Ingress Controller (AGIC) allows you to use Application Gateway as the ingress for an Azure Kubernetes Service (AKS) cluster.

The ingress controller runs as a pod within the AKS cluster and consumes Kubernetes Ingress Resources and converts them to an Application Gateway configuration, which allows the gateway to load-balance traffic to the Kubernetes pods. The ingress controller only supports Application Gateway Standard_v2 and WAF_v2 SKUs.

For more information, see Application Gateway Ingress Controller (AGIC).

URL-based routing

URL Path Based Routing allows you to route traffic to backend 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 VideoServerPool are routed to VideoServerPool, and ImageServerPool are routed to ImageServerPool. DefaultServerPool is selected if none of the path patterns match.

For more information, see URL Path Based Routing overview.

Multiple-site hosting

With Application Gateway, you can configure routing based on host name or domain name for more than one web application on the same application gateway. It allows you to configure a more efficient topology for your deployments by adding up to 100+ websites to one application gateway. Each website can be directed to its own backend pool. For example, three domains, contoso.com, fabrikam.com, and adatum.com, point to the IP address of the application gateway. You’d create three multi-site listeners and configure each listener for the respective port and protocol setting.

Requests for ContosoServerPool are routed to ContosoServerPool, FabrikamServerPool are routed to FabrikamServerPool, and so on.

Similarly, two subdomains of the same parent domain can be hosted on the same application gateway deployment. Examples of using subdomains could include blog.contoso.com and app.contoso.com hosted on a single application gateway deployment. For more information, see Application Gateway multiple site hosting.

You can also define wildcard host names in a multi-site listener and up to 5 host names per listener. To learn more, see wildcard host names in listener.

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 Application Gateway redirect overview.

Session affinity

The cookie-based session affinity feature is useful when you want to keep a user session on the same server. 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.

For more information, see How an application gateway works.

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.

Connection draining

Connection draining helps you achieve graceful removal of backend pool members during planned service updates or problems with backend health. This setting is enabled via the Backend Setting and is applied to all backend pool members during rule creation. Once enabled, the application gateway ensures all deregistering instances of a backend pool don’t receive any new requests while allowing existing requests to complete within a configured time limit. It applies to cases where backend instances are:

explicitly removed from the backend pool after a configuration change by a user reported as unhealthy by the health probes, or removed during a scale-in operation The only exception is when requests continue to be proxied to the deregistering instances because of gateway-managed session affinity.

The connection draining is honored for WebSocket connections as well. Connection draining is invoked for every single update to the gateway. To prevent connection loss to existing members of the backend pool, make sure to enable connection draining.

For information on time limits, see Backend Settings configuration.

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.

For more information, see Custom Errors.

Rewrite HTTP headers and URL

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 and WAF v2 SKU supports the capability to add, remove, or update HTTP request and response headers, while the request and response packets move between the client and backend pools. You can also rewrite URLs, query string parameters and host name. With URL rewrite and URL path-based routing, you can choose to either route requests to one of the backend pools based on the original path or the rewritten path, using the reevaluate path map option.

It also provides you with the capability to add conditions to ensure the specified headers or URL are rewritten only when certain conditions are met. These conditions are based on the request and response information.

For more information, see Rewrite HTTP headers and URL.

Sizing

Application Gateway Standard_v2 can be configured for autoscaling or fixed size deployments. The v2 SKU doesn’t offer different instance sizes. For more information on v2 performance and pricing, see Autoscaling V2 and Understanding pricing.

The Application Gateway Standard (v1) is 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.

D. Where implemented

LeanIX

E. How it is tested

Testing Azure Application Gateway involves ensuring that the gateway is functioning correctly, securely, and meeting the needs of all stakeholders involved in the project. Here are some steps to follow to test Azure Application Gateway:

  1. Define the scope and requirements: Define the scope of the project and the requirements of all stakeholders involved in the project. This will help ensure that Azure Application Gateway is designed to meet the needs of all stakeholders.

  2. Create test plans: Develop test plans that cover all aspects of Azure Application Gateway functionality, including load balancing, SSL/TLS termination, Web Application Firewall (WAF), and routing rules. The test plans should be designed to meet the needs of the organization, including scalability and resilience.

  3. Conduct unit testing: Test the individual features and modules of Azure Application Gateway to ensure that they are functioning correctly. This may involve using tools like PowerShell or Azure CLI for automated testing.

  4. Conduct integration testing: Test Azure Application Gateway in an integrated environment to ensure that it works correctly with other systems and applications. This may involve testing Azure Application Gateway with different operating systems, browsers, and devices.

  5. Conduct user acceptance testing: Test Azure Application Gateway with end-users to ensure that it meets their needs and is easy to use. This may involve conducting surveys, interviews, or focus groups to gather feedback from users.

  6. Automate testing: Automate testing of Azure Application Gateway to ensure that it is functioning correctly and meeting the needs of all stakeholders. This may involve using tools like Azure DevOps to set up automated testing pipelines.

  7. Monitor performance: Monitor the performance of Azure Application Gateway in production to ensure that it is meeting the needs of all stakeholders. This may involve setting up monitoring tools, such as Azure Application Insights, to track usage and identify performance issues.

  8. Address issues: Address any issues that are identified during testing and make necessary changes to ensure that Azure Application Gateway is functioning correctly and meeting the needs of all stakeholders.

By following these steps, you can ensure that Azure Application Gateway is tested thoroughly and meets the needs of all stakeholders involved in the project. This can help improve the quality of Azure Application Gateway and ensure that it functions correctly in a production environment.

F. 2023 Roadmap

????

G. 2024 Roadmap

????

H. Known Issues

There are several known issues that can impact Azure Application Gateway. Here are some of the most common issues to be aware of:

  1. SSL/TLS certificate issues: Azure Application Gateway requires a valid SSL/TLS certificate to terminate SSL/TLS connections. If the certificate is not valid or has expired, it can cause issues with SSL/TLS termination and impact the performance of the gateway.

  2. WAF configuration issues: The Web Application Firewall (WAF) feature of Azure Application Gateway can be complex to configure, and misconfiguration can cause issues with application traffic and security. It is important to ensure that the WAF is configured correctly and tuned to meet the needs of your environment.

  3. Load balancing issues: Load balancing is a critical feature of Azure Application Gateway, and misconfiguration can cause issues with application traffic and performance. It is important to ensure that load balancing is configured correctly and optimized to meet the needs of your environment.

  4. Integration issues: Integration issues can arise when integrating Azure Application Gateway with other systems and applications. It is important to ensure that Azure Application Gateway is designed to work seamlessly with other systems and applications to avoid integration issues.

  5. Scaling issues: Scaling Azure Application Gateway requires careful planning and management to ensure that it can handle the increased traffic and user demands that come with organizational growth. It is important to ensure that Azure Application Gateway is properly scaled to avoid scaling issues.

  6. Performance issues: Performance is a critical concern when it comes to Azure Application Gateway. If the gateway is not performing well, it can impact the user experience and cause delays in processing requests. This can impact the overall performance of the application.

Overall, Azure Application Gateway requires careful planning and management to ensure that it is functioning correctly and meeting the needs of all stakeholders involved in the project. By being aware of these known issues and taking steps to address them, you can improve the quality of Azure Application Gateway and ensure the success of your project.

[x] Reviewed by Enterprise Architecture

[x] Reviewed by Application Development

[x] Reviewed by Data Architecture