This article provides an analysis of Azure CDN from 3 different perspectives:
Available features
Missing features
Our main goal is to know what we can do and what we cannot do with Azure CDN.
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:
Reports related to Bandwidth, Cache status, HTTP error codes and so on.
Restricted access to the content, based on the country/area. Verizon enables you to specify a list of countries (DE, UK) or areas (EU, AP - Asia/Pacific) that can(not) access that content. The filtering is done based on the client IP and is per directory. It is good to remember that this rule is applicable recursively, at folder level, that there is no support for wildcards and that you can specify one rule per folder (that can contain multiple countries or areas). Being a recursive rule, if you define a rule one level down, only the rule defined on the sub-folder will apply - simple rule engine.
Now, let us see what features are supported by Azure CDN from Akamai and Azure CDN from Verizon:
HTTP support
DDOS protection
Dual Stack support (IPv4 and IPv6)
Query String Cache - It refers to how content is cached, when the path is a query and it is not static. There are 3 available options that enable us to cache each unique query, ignore query string and not cache URLs that contain query strings. The last option is very useful.
Fast purge - It allows us to clean the cache, even if the TTL (Time To Live) of the content did not expire. The purge can be done from Azure Portal, PowerShell or by REST API.
REST API for CDN configuration (as for all other Azure Services)
Custom domain name support
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:
Real-time CDN Status - It is useful if you need real-time data related to bandwidth, number of connections, error codes and cache status. It is nice to have this information for CDN, but you normally do your job without this kind of information.
Advance Reports - Detailed geographical reports related to traffic and different views per day, hour, file, file type, directory and so on.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.