You dont have javascript enabled! Please enable it! How To Configure Application Gateway In Front Of Azure Blob Storage - CHARBEL NEMNOM - MVP | MCT | CCSP | CISM - Cloud & CyberSecurity

How to Configure Application Gateway in Front of Azure Blob Storage

6 Min. Read

In this article, we will show you how to configure Azure Application Gateway in front of Azure Blob Storage, so you can expose and secure access to a storage container with custom domains.


Azure Application Gateway manages the requests that client applications can send to a web app. Application Gateway routes traffic to a pool of web servers based on the URL of a request. This is known as application-layer routing. The pool of web servers can be Azure virtual machines, Azure virtual machine scale sets, Azure App Service, and even on-premises servers.

Azure Application Gateway
Azure Application Gateway

I have recently come across a use case where I need to publish my data in Azure blob storage with a custom domain to expose the content publicly. All worked as planned except for HTTPS secure access. Once you browse the custom domain, you receive the warning message that says “Your connection to this site is not secure“.azure blob storage

How to Configure Application Gateway in Front of Azure Blob Storage 1

To address this issue, Microsoft noted clearly in their documentation here that if you need to enable HTTPS for custom domains on Azure storage, then you’ll have to use Azure Content Delivery Network (CDN) because Azure Storage does not yet natively support HTTPS.

What if you have a data sovereignty requirements and you don’t want to use Azure CDN?

The good news is, if you are already using Azure Application Gateway (Standard or WAF SKU), you can leverage it to enable HTTPS access to Azure blob storage with custom domains, and without using Azure CDN.


To follow this article, you need to have the following:

1) Azure subscription – If you don’t have an Azure subscription, you can create a free one here.

2) Azure storage account – To create a general-purpose storage account, you can follow the instructions described here.

3) You need a static public IP address with Standard SKU – you can create a new public IP by running the following Azure CLI command:

az network public-ip create -n pip-agw-v2 -g resourceGroupName --allocation-method Static --sku Standard

4) You need a virtual network and dedicated subnet for the Application Gateway. For more information, please follow the instructions described here.

5) Application Gateway v2 SKU up and running (Standard or WAF) – If you don’t have an Application Gateway, you can follow the step-by-step guide and create one here.

  • You need a private (.pfx) certificate for your custom domain so you can upload it to the Application Gateway listeners.

Application Gateway and Azure Blob Storage Architecture

Below you can find the architecture diagram used for this solution:

Application Gateway Deployment Architecture
Application Gateway Deployment Architecture

Configure DNS

Please note that if you are using Application Gateway V1 SKU, the VIP can change if you stop and start the application gateway. But the DNS name associated with the application gateway doesn’t change over the lifetime of the gateway. Because the DNS name doesn’t change, you should use a CNAME alias and point it to the DNS address of the application gateway. In Application Gateway V2 SKU, you can set the IP address as static, so IP and DNS names will not change over the lifetime of the application gateway.

So make sure you set and create a CNAME alias or A record to point the custom domain to the Application Gateway public IP.

Configure Storage account

First, you need to make sure that your storage account is configured correctly. When you deploy a storage account in Azure, by default secure transfer is Enabled and TLS Version is set to a minimum of 1.2. So nothing to change here.

If you want to configure the Storage account with no public access and Private Endpoint, please check the following section.

How to Configure Application Gateway in Front of Azure Blob Storage 2

Next, you want to configure your storage account to allow access only from the virtual network and the subnet (e.g. AppGW-Subnet) where Application Gateway is deployed.

Within the same storage account, browse to Firewalls and virtual networks as shown in the figure below, choose selected networks, and add your existing virtual network. Additionally, it’s very important to add your public IP address or your on-premises networks under the Firewall (Address range) so you would be able to manage and access the storage container in the Azure Portal.

How to Configure Application Gateway in Front of Azure Blob Storage 3

This means that TLS is enforced with Application Gateway for public access, and then forwards requests securely to a storage account with encryption as well, so this is end-to-end TLS encryption. And by enabling firewall rules for the selected virtual networks, we take additional security measures to allow requests only from the application gateway subnet.

You can find more details about Azure Storage firewalls and virtual networks in the documentation here.

Configure Application Gateway

Assuming you have all the prerequisites in place, take now the following steps to configure the Application Gateway to access the storage container securely.

Backend pools

First, you need to add a new backend pool with the blob storage as a target. The target is the FQDN of the Azure storage blob service as shown in the figure below.

How to Configure Application Gateway in Front of Azure Blob Storage 4


Next, you need to add a new listener using the ‘Frontend IP‘ as Public, listening on port 443 (HTTPS). Then you need to upload your custom domain (.pfx) private certificate.

Then you need to make sure to select the ‘Listener type‘ as Multisite and specify your custom domain since you will be hosting more than one site behind this Application Gateway.

How to Configure Application Gateway in Front of Azure Blob Storage 5

HTTP Settings

Next, you need to add HTTP settings with the following details:

  • Backend protocol: HTTPS
  • Backend protocol: 443
  • Trusted root certificate
    • Use well-known CA certificate: Yes – This option is only available for Application Gateway v2 SKU and not in the v1 SKU. This means that we trust the wildcard certificate issued by Microsoft to (* This allows us to securely forward the requests from the Application Gateway to the blob storage over HTTPS (end-to-end encryption).
  • Additional settings:
    • Cookie-based affinity: Disable
    • Connection draining: Disable
      • Request time-out: 20 seconds
      • Override backend path: /
  • Hostname:
    • Override with new hostname: Yes
    • Override with the specific domain name: Enter your
  • Use a custom probe: No – We will select the health probe in the next step.

How to Configure Application Gateway in Front of Azure Blob Storage 6

Custom Health probe

Next, you need to create a custom health probe with the following details:

  • Protocol: HTTPS
  • Pick hostname from backend HTTP settings: Yes
  • Pick port from backend HTTP settings: Yes
  • Path: /
  • Use probe matching conditions: Yes
  • HTTP response status code match: 400
  • HTTP settings: Choose the HTTP settings (443) that you created in the previous step

This step is very important because custom probes allow you to have more granular control over health monitoring. When using custom probes, you can configure a custom Hostname, URL path, probe interval, and how many failed responses to accept before marking the back-end pool instance as unhealthy, etc.

In this case, since we are using Azure blob container as the backend which is not a static or dynamic website you will receive an unhealthy status. Thus, you need to specify the HTTP response status code match as 400. The status code 400 is expected here since accessing the blob storage without specifying the full URL, you will receive the error message ‘Value for one of the query parameters specified in the request URI is invalid‘ which translates to code 400.

How to Configure Application Gateway in Front of Azure Blob Storage 7

Routing Rules

The final step is to create a new routing rule that will send traffic from a given frontend public IP address to your backend targets (Azure blob storage account). A routing rule must contain a listener and at least one backend target.

Click add + Request routing rule with the following details:

  • Rule name: Choose a descriptive name.
  • Listener: Choose the listener that you created in the previous step.

How to Configure Application Gateway in Front of Azure Blob Storage 8

Select Backend targets and choose the following settings:

  • Target Type: Backend pool
  • Backend target: Select the backed target that you create in the first step.
  • HTTP settings: Select the HTTP settings (port 443) that you created in the previous step.

How to Configure Application Gateway in Front of Azure Blob Storage 9

Backend health

Once you applied all the configurations noted above, as well as the creation of the CNAME alias in DNS pointing to the public IP address of Application Gateway. Then go to Azure Portal, navigate to the resource group, and application gateway, and check the Backend Health blade to ensure that your server (backend pool) which is the FQDN of your storage account is healthy as shown in the figure below.

How to Configure Application Gateway in Front of Azure Blob Storage 10

Verify access

Once the Application Gateway is configured and the backend pool is in a healthy state, you can browse your custom domain via HTTPS and access securely your storage container.

How to Configure Application Gateway in Front of Azure Blob Storage 11

Now it works! You can enjoy your web page, requested from the Azure blob storage account with a custom domain and SSL support.

There’s more…

You could also use a private frontend IP on the Application Gateway, and a Private Endpoint on the storage account for added security.

For this scenario to work, you need to make sure you have the following configuration in place:

1) Private frontend IP on the Application Gateway: Private listener, you configure the Custom health probe with status code 409 (instead of 400).

2) Storage account with the private endpoint: No public network access.

  • Storage account “Allow Blob public access” is set to disable – which returns 409 instead of 400 to the health probe.

That’s it there you have it!


In this guide, I showed you how to configure Azure Application Gateway in front of Azure Blob Storage, so you can expose and enable HTTPS access to Azure storage containers with custom domains without using Azure Content Delivery Network (CDN).

Please note that the same steps described above will also apply to hosting your website in Azure Storage. For more information about static websites, please check how to host a static website on Azure Blob Storage.

Azure Application Gateway provides an application delivery controller (ADC) as a service. It offers various layer 7 load-balancing capabilities for your applications. This service is highly available, scalable, and fully managed by Azure.

To learn more about Application Gateway, see What is Azure Application Gateway.

Thank you for reading my blog.

If you have any questions or feedback, please leave a comment.

-Charbel Nemnom-

Photo of author
About the Author
Charbel Nemnom
Charbel Nemnom is a Senior Cloud Architect with 21+ years of IT experience. As a Swiss Certified Information Security Manager (ISM), CCSP, CISM, Microsoft MVP, and MCT, he excels in optimizing mission-critical enterprise systems. His extensive practical knowledge spans complex system design, network architecture, business continuity, and cloud security, establishing him as an authoritative and trustworthy expert in the field. Charbel frequently writes about Cloud, Cybersecurity, and IT Certifications.

How to Get Azure File Sync Cloud Tiering Efficiency with PowerShell

Effective Way To Check Azure Defender Status Plan


24 thoughts on “How to Configure Application Gateway in Front of Azure Blob Storage”

Leave a comment...

  1. Hi Charbel, I was on mobile and somehow got missed that part, sorry for that and thank you for answering my question 😊! Was there any specific reason in this case to use a custom domain? Thanks again and have a great day!

  2. No problem, Edem, thanks for the comment!
    Yes, we used a custom domain because the website of the domain in question is built in WordPress and we need to leverage (offload) media files to Azure Blob Storage, and we need a secure connection over HTTPS.
    Hope it helps!

  3. Thanks for writing the article!

    I’m struggling to get the backend probe to work – I have

    “The Common Name of the leaf certificate presented by the backend server does not match the Probe or Backend Setting hostname of the application gateway.”

    Backend certificate Type: Well Known CA
    Hostname Value:
    Backend Server Common Name: *

    Have you seen this happen? I thought about adding a custom domain and non-wildcard certificate as a workaround, but I’d actually like to use private endpoint and that might make things even more complicated.

  4. Hello Joel, thanks for the comment!

    It seems like you’re encountering a common challenge with the backend probe due to a mismatch in the Common Name (CN) of the backend server’s leaf certificate and the configured Hostname Value in your application gateway. Here are a few steps you can take to address this issue:

    1) Verify Common Name (CN): Ensure that the Common Name in the leaf certificate presented by the backend server matches the Hostname Value configured in your application gateway. In your case, confirm that the CN is indeed *
    2) Wildcard Certificates: Since you’re using a wildcard certificate for your backend server, ensure that it covers the specific domain you’ve set in the Hostname Value. In your case, the wildcard * should match.
    3) Custom Domain and Non-Wildcard Certificate: As you’ve considered, adding a custom domain and using a non-wildcard certificate is a viable workaround. This might be a good option if the wildcard certificate is causing issues. Make sure that the certificate you use explicitly matches the Hostname Value.
    4) Private Endpoint: If you’re planning to implement a private endpoint, keep in mind that this can indeed add another layer of complexity. Ensure that the private endpoint is correctly configured, and the private DNS zone resolves to the correct IP address.

    Hope it helps!

Let us know what you think, or ask a question...