Azure application gateway – Path based URL routing

Introduction:

In today’s digital landscape, ensuring efficient and secure traffic management for web applications is crucial. An application gateway is vital in this process, acting as a reverse proxy that manages client requests and distributes them to various backend services. One of the standout features of an application gateway is its ability to perform path-based URL routing. This functionality allows the gateway to route incoming requests to different backend services based on the URL path, enabling more granular control and optimized resource utilization.

Path-based URL routing is particularly beneficial for organizations that host multiple services under a single domain. Businesses can enhance performance, improve security, and streamline maintenance by directing traffic to specific services based on the URL path. For instance, requests to /api can be routed to a microservice handling API calls, while requests to /static can be directed to a service serving static content. This level of precision in traffic management improves the user experience and simplifies the architecture of complex web applications.

In this article, we discuss how to configure path-based URL routing.

Scenario:

Imagine managing a web application requiring efficient traffic routing to two backend services. You have two app services: App Service A, which handles general web traffic, and App Service B, which is dedicated to API requests. To optimize performance and ensure that the appropriate service handles each request, you configure an application gateway with path-based URL routing. The rule is simple: any request with the path /userapi/* is directed to App Service B, while all other requests are routed to App Service A. This setup allows you to segregate API traffic from general web traffic, enhancing performance and security.

For instance, when a user accesses https://yourdomain.com/userapi/getUser, the application gateway recognizes the /userapi/* path and forwards the request to App Service B, which is optimized for handling API calls. Conversely, a request to https://yourdomain.com/home does not match the /userapi/* path and is, therefore, routed to App Service A, which serves the main website content. This targeted route ensures that each service can be scaled and managed independently, providing a seamless and efficient user experience while maintaining a clear separation of concerns within your application’s architecture.

Configuration Steps:

  • Create the Application Gateway

Set up an application gateway in your cloud environment.

  • Define Backend Pools
    • Backend Pool A

Add App Service A to this pool.

Hop into your Application gateway, select backend pools from them, add new backend pool,

Backend pool

Since we are trying to configure the application gateway for the App services, select the Target type as App Services and select the target

    • Backend Pool B

Create one more backend pool for another app service, similar to the way we configured for bep-npr-01.

  • Configure Backend Settings
    • Select backend settings from the settings blade, Add new backend settings
    • Backend protocol – HTTPS, since our backend App service is secured, go with the following backend port 443 and select Yes for the backend server’s certification is issued by a well-known CA,
    • Additional settings – Go with a default option
    • Request time-out – It is the number of seconds the application gateway waits to receive a response from the backend pool
    • Override backend path—This will allow us to override the backend path so that requests for a specific path can be routed to another part. We should provide “/” based on our scenario since we will configure a path-based URL. So wherever users try the path /userapi, the request will be redirected to the backend pool based on the backend rule we will configure.
  • Override with new hostname – Set to Yes  
    • Note: For Production, the recommended approach is not to override with a new hostname by configuring the custom domain to the app services  
    • Host name override – Pick the hostname from the backed target
    • Use custom probe – leave it to No; we can configure it later.
Override the host name
  • Create a Listener
    • Select Listener from the settings blade, Add/Edit Listener
    • Frontend IP – Set to public
    • Protocol – I went with HTTP. Ideally, it should be secured (HTTPS)
    • Listener type – set to basic
    • Custom error pages – If you have any custom error HTML pages, please define them here
  • Set Up Path-Based Routing Rules
    • Select Rules from the settings blade, Add/Edit Routing Rules
    • Provide the rule name
    • Define the priority
    • Listener – Map the listener that we configured in previous steps
Backend rule
    • Select the Backend Targets tab
    • Set the target type to the backend pool
    • Backend Target – Set our backend pool bep-npr-01 as a backend target that we configured in step 2
    • Backend Settings – set bes-npr-02 as a backend setting that we configured in step 3

Add path URL

    • Define the path-based routing as shown in the figure below
path based routing
    • Provide the path as /[user path name]/*, In our case it is /userapi/*
    • Target name – Provide some meaningful name for the rule
    • Backend settings – Select The backend settings that we configured in step 3
    • Backend Target – points to the 2nd backed pool, so whenever there is a request with the path /user API/, it will redirect the request to this backed target.
  • Configure a Custom Health probe  

To monitor the backend connectivity health 

    • Select Health Probe from the settings blade, Add/Edit Routing Rules 
    • Select the protocol as HTTPS  
    • Set Yes for Pick hostname from backend settings  
    • Set Yes for Pick port from backend settings  
    • Define the path of your application which returns the status code between 200-309, we can go with default values for the other mandatory fields  
    • Select the backend settings that we already configured  

Example Requests

Request 1:

    • URL: https://yourdomain.com/userapi/getUser
    • Routing: This request matches the path /userapi/* and is routed to App Service B.
  • Request 2:
    • URL: https://yourdomain.com/home
    • Routing: This request does not match the /userapi/* path and is routed to App Service A.
  • Benefits:
  • Optimized Traffic Management: You can optimize performance and resource utilization by directing specific requests to the appropriate backend service.
    • Improved Security: Isolating API traffic from general web traffic enhances security and simplifies monitoring.
    • Scalability: Each app service can be scaled independently based on load and requirements.

Summary:

In this article, we explore the process of setting up path-based URL routing in Azure Application Gateway. The guide provides detailed instructions on creating and configuring an Application Gateway, focusing on defining routing rules that direct traffic based on specific URL paths. This method enhances traffic management by ensuring requests are efficiently distributed to the appropriate backend pools based on the URL structure.

Gowtham K

Gowtham K has been awarded as MVP(Most Valuable Professional) for 9 times by Microsoft for his exceptional contribution in Microsoft technologies under the category “Developer Technologies & Security” . He has more than 12 years of experience on Microsoft technologies such as C#, ASP.NET MVC, ASP.NET WEB API, ASP.NET Core, MS SQL Server, Azure, Microsoft Entra ID, Azure AD B2C and other technologies such as JavaScript, jQuery, HTML and CSS .He is also a blogger and author of articles on various technologies. He is also a speaker and delivered talk on various technologies like ASP.NET MVC, Azure and Azure DevOps in the public events.

Leave a Reply

Your email address will not be published. Required fields are marked *