Issue 50

Overview of Azure CDN

Radu Vunvulea
Solution Architect


This article provides an analysis of Azure CDN from 3 different perspectives:

Our main goal is to know what we can do and what we cannot do with Azure CDN.

Azure CDN - Available features and functionality

Let us start with the first topic, and talk about the features and functionality that are available at the moment (Q3, 2016) on Azure CDN.  You will find a lot of useful information on the Azure page and I am pretty sure that you already checked it.
In comparison with the last few years, Microsoft took a big step forward, by signing partnerships with Akamai and Verizon (both of them are some of the biggest CDN providers in the world).

This was a smart choice, because developing and building your own CDNs is expensive, and a lot of effort is required. There are some things that you do not need to create all by yourself if you do not need additional features. 
A nice thing here is that you do not need a dedicated contract with each provider. You only need your Azure Subscription, without any custom contract or invoice from Akamai or Verizon.

In general, the CDN features that are provided by them are similar. Some small exceptions apply and they may (not) impact your business.  Based on the list of available features, we could say that Akamai is the most basic one, while Verizon has some additional features, but both of them offer the base functionality that is required by a CDN.

The Verizon elements that are available only on Azure CDN are:

Now, let us see what features are supported by Azure CDN from Akamai and Azure CDN from Verizon:

Azure CDN from Verizon is available in two tires, Standard and Premium. Of course, except for the price, there are features that are available only for the Premium version, such as:

As we can see, there are a lot of features available for Azure CDNs. For normal use cases, you can use the product without any problems.

Things that are not available

Let us take a look at some features or functionalities that we do not have on Azure CDNs, even though, many times, we assume that we have them.

SAS Support for Blob Storage

The most common functionality that people think is available on Azure CDN is Shared Access Signature for Blob Storage. Shared Access Signature (SAS) is one of the most used and most powerful features of Blob Storage. On Azure CDN we can cache a blob storage using the full URL, including the URL.
It is, perhaps, because of this that people have the impression that Azure CDN will take into consideration the SAS validity and, once the SAS expires, it will also invalidate the cache.
The fact of the matter is that, at the moment, Azure CDN treats the URL of an Azure Blob that has SAS just like any other URL. If the content can be accessed, then it will copy the payload and replicate it to the CDN. The content will be removed from the CDN nodes only when the TTL value on the CDN, which does not have any connection to SAS, expires.

HTTPS for Custom DNS Domains

Even if Azure CDN has support for custom DNS, as well as for HTTPS, it does not mean that you can use HTTPS using your own domain name. It sounds strange, and it can sometimes be confusing when you have two supported features, but the combination between them is not supported.
This means that, if you need HTTPS, then you need to use Azure CDN DNS. The good news is that this is a feature that is most voted for CDN, on Azure Voice, and we will have support for it very soon.

HTTPS Client Certificates

When you use Azure CDN, it is important to remember that, even if there is support for HTTPS, there is no support for client certificates, at the moment. You are allowed to use only SSL certificates provided by the CDN.
This is why we do not have support for client certificates on custom DNS domains for Azure CDN yet, but things will improve soon.


The new Internet protocol - if we can call it this way - is not yet supported. In general, this is not a blocker, except if you have a complex web application and you want to minimize the number of requests that are sent by the client browser.
For these situations, working with Azure CDN might not be so simple, but there are workarounds.

Fallback to custom URI

Some CDN providers, give us the possibility to specify an URI that can be used as a fallback when the content is not found in the original location. This is useful when you are working with an application where time availability is critical and you need to provide a valid location for all content.
Of course, with a little imagination you can solve this problem pretty easily. If you place Azure Traffic between Azure CDN and your content, that would allow you to specify a fallback list of URIs.

Access logs of CDNs are raw data

Many people request access to the raw data of logs, similarly with the one from Azure Storage. This might be a useful feature, but, at the same time, I have some concerns regarding it.
The main goal of a CDN is to cache and serve content that is often requested from a location that is as near as possible to the client. It is used for cases where the RPS (requests per second) is very high. Generating a file with raw data could be expensive and you could end up with logs that are big. Processing such files might be expensive.

It is important to remember that some of these features are already planned by the Azure team and, in the near future, we might find them in Azure CDN. Also, do not forget that an out-of-the-box solution is hard to find, but that a solution can be found, with a little imagination.

Azure CDN - Solutions for things that are not available

Let us see what we can do when we need the Azure CDN features that are currently missing. In the last post we talked about these features, and we will not focus on explaining them (please check the previous post for details).

SAS Support for Blob Storage

If you need a CDN system that has support for SAS, in addition to Azure Store, then you need to be inventive. The most simple solution is to replicate the content in multiple Azure Storage Accounts or even in the same Storage Account (if the problem is the download speed) and create a web endpoint (that can be hosted as a web app), which that will provide the locations from where the content can be downloaded.
This web endpoint can have a Round Robin mechanism (the simplest thing) to serve different locations.

By using this approach, you will also need a mechanism that replicates the content in multiple locations. AzCopy might be a good out-of-the-box solution.

HTTPS for Custom DNS Domains

Azure CDN and Azure Storage use the same storage. At the moment, we do not have support for HTTPS and Custom DNS Domains. In this case, if you really need HTTPS, then the only solution is to serve the content from an Azure Web App. There are not too many options for now.

HTTPS Client Certificates

The story is similar with the previous one. We do not have too many options. The best way for now is to use an Azure Web App and serve your binary content from there.


None. As above an Azure Web App.

Fallback to custom URI

For these situations, we have a simple solution. We can go with the approach presented in the SAS Support example. The additional thing that we need to do is to have multiple Azure Web Apps that can serve the content location and add an Azure Traffic Manager in front of them.

Access logs of CDNs are raw data

If you really need these logs, then you need to use Azure Blob Storage. You should use the approach above and activate logs in each Azure Storage Account.

As we can see, there are many features supported by Azure CDN. Of course, we will not be able to find a perfect solution that supports all the things that we need. The same happens with Azure CDN. What is important to remember is that a part of the features that are missing are already marked on Azure's feedback portal. This means that we will have support for them as well very soon.




  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • Yardi
  • P3 group
  • Ing Hubs
  • Colors in projects