How to Publish an App Service using Azure Application Gateway

In this post, I’m going to explain how to publish an App service using the Application Gateway. An Azure Application Gateway is a web traffic load balancer that enables you to manage traffic to your web applications.

Core Components of the Azure Application Gateway

[do_widget id=hootkit-notice-4]

This “How to” shows you how to use the Azure portal to create an application Gateway. After creating the application gateway, you can check to verify it’s working correctly. This blog post assumes that you already have a resource group, virtual network, an up and running App service and a subnet dedicated for Application Gateway.

In my demo environment I already have an App service up and running.

Step 1 Make sure that the app service supports SSL.

Azure App Service | Settings | Scale up (App Service plan)

Not al pricing tiers do support SSL. Make sure that you have the right pricing tier.

Step 2 Deploy the Application Gateway

Log in to your Azure Portal and choose to create a new resource and choose the Application Gateway.

  1. On the Basics tab, enter these values for the following application gateway settings:
    • Resource group: Select the resource group you wish to store your application gateway in. If it doesn’t exist, select Create new to create it.
    • Application gateway name: Enter the name of your application gateway.
  2. For Azure to communicate between the resources that you create, it needs a virtual network. Application Gateway instances are created in separate subnets. You create two subnets in this example: one for the application gateway, and another for the backend servers.
  3. Under Configure virtual network, Select virtual network | Select Application Gateway Subnet
  4. On the Basics tab, accept the default values for the other settings and then select Next: Frontends.

On the Frontends tab, verify Frontend IP address type is set to Public.
You can configure the Frontend IP to be Public or Private as per your use case. In this example, you’ll choose a Public Frontend IP, so that it can be resolved externally (from the Internet).

Choose create new for the public IP address and specify a name for the Public IP address name and then select ok. Listeners are also associated to this IP address.

The backend pool is used to route requests to the backend servers that serve the request. Backend pools can be composed of NICs, virtual machine scale sets, public IPs, internal IPs, fully qualified domain names (FQDN), and multi-tenant back-ends like Azure App Service.

  1. On the Backends tab, select Add a backend pool.
  2. In the Add a backend pool window that opens, enter the following values to create an empty backend pool:
    • Name: Enter the name for the backend pool.
    • Choose Target type App service and select the App Service you wish to connect.
      Note : You have the following options :

For this demo I use the wacontainer01 App Service.

On the Configuration tab, you’ll connect the frontend and backend pool you created using a routing rule. This is the most important part of the application gateway which exactly tells the Application Gateway what to do.

You can also say that a rule glues together the configuration. A basic rule is pretty easy:

  • Traffic comes into a Listener
  • The HTTP(s) Setting determines how to forward that traffic to the backend pool
  • The Backend Pool lists the web servers that host the site

  1. Select Add a rule in the Routing rules column.
  2. In the Add a routing rule window that opens, enter the name for the Rule name.
  3. A routing rule requires a listener.
    [do_widget id=hootkit-notice-5]
    On the Listener tab within the Add a routing rule window, enter the following values for the listener:
    • Listener name: Enter the name for the name of the listener.
    • Frontend IP: Select Public to choose the public IP you created for the frontend. Accept the default values for the other settings on the Listener tab, then select the Backend targets tab to configure the rest of the routing rule.

Make sure to choose HTTPS. You can choose to upload a certificate or use a certificate from the Keyvault. When you choose to use a certificate stored in the keyvault, I advice you to create/use a managed identity to access that certificate.

  1. On the Backend targets tab, select the name of the Backend target.
  2. For the HTTP setting, select Create new to create a new HTTP setting. The HTTP setting will determine the behaviour of the routing rule. In the Add an HTTP setting window that opens, enter the name or the HTTP setting name. Accept the default values for the other settings in the Add an HTTP setting window, then select Add to return to the Add a routing rule window.
  1. On the Add a routing rule window, select Add to save the routing rule and return to the Configuration tab.
  2. Select Next: Tags (My advice is to use tags!)

and then Next: Review + create. Review the settings on the Review + create tab, and then select Create to create the virtual network, the public IP address, and the application gateway. It may take several minutes for Azure to create the application gateway. Wait until the deployment finishes successfully before moving on to the next section.

It takes about 6 minutes to deploy a V2 Application Gateway.

Create a Host A record in the DNS server

  1. Log on the Domain Controller Add a CNAME record to the corresponding Host A record of server.
  2. Add a Host A record in the public DNS server to the corresponding public IP address of the Application Gateway.

Test the application gateway

  1. Copy the public IP address or FQDN, and then paste it into the address bar of your browser.
  2. Check the response. A valid response verifies that the application gateway was successfully created and can successfully connect with the backend.

2 Comments

  1. Xander – thanks for the great content here on application gateway. Quick question for you – do you recommend deploying one application gateway per application, or sharing one application gateway among multiple applications? For example, have every application in the development environment share a single app gateway, or give every new application that comes on board needing app gateway its own dedicated instance? Curios to get your thoughts on this. Thanks!
    -Dave

    1. Author

      Hi Dave! My advice is to use the same Application Gateway for multiple websites!

Leave a Reply to XanderCancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.