Serving Static Content From Azure Storage: Content Delivery Networks Overview

While Azure Storage is perfectly capable of serving high-volume, highly available HTTP requests for static files such as images, JSON, etc., it makes a lot more sense to use a content delivery network to act as a proxy for your storage container itself.

Basically, a content delivery network — CDN — is a worldwide set of HTTP servers, each of which holds the same file.

For example, I have a single Azure Storage account in US East, which is physically located in a single datacenter in Virginia. If I serve files only from that, it will work; but users in Japan or Brazil or South Africa might find performance wanting.

By serving the files in that Storage account via a CDN, my files are now physically located worldwide, on hundreds of servers located in Europe, Asia, South America, India and North America. When a request is sent to my file’s CDN URL, the CDN figures out which of those hundreds of servers will respond fastest to the request, and sends the file from that server.

  • CDNs give your files many points of presence worldwide. That means a user can more quickly access your files, regardless of his geographic location.
  • You get real cache control. When serving files directly from Azure Storage, you can send Cache-Control headers that most browsers should respect; but they might not. A CDN creates true cache control, using both headers and querystrings to set cache control. Also, if you opt for EdgeCast, you can implement specific caching rules on a variety of conditions, such as the client’s user agent, location, IP address, etc.
  • CDNs naturally balance load and can scale independent of your storage account, which is helpful both for handling unexpected demand and working around DDoS attacks.
  • Depending on the user’s geographic location and the CDN version you choose, you can restrict access to your files based on geographic location, user agent and the like.
  • In some cases, it’s cheaper to serve files from CDN than directly from storage, especially for files on an extended cache.

Three CDN options

Azure has three flavors of CDN. One is powered by Akamai; the other two are basically store-branded versions of Verizon EdgeCast.

The primary advantage of the premium Verizon CDN is limiting allowed origin domains for CORS and otherwise applying custom headers to requests.

It’s way easier to restrict CORS access to specific domains via the premium Verizon CDN, which allows for the creation of dynamic headers via a rules engine. The two standard CDN offerings don’t allow for header modifications on-the-fly; there’s a querystring-based workaround that will let you assign CORS origin restrictions for CDN files, but it’s clunky.

The biggest advantage of the Verizon CDNs is content preloading. This ensures all points of presence for the CDN have your files before the first client request is made. Therefore, the first people to visit each CDN endpoint don’t have to wait for the file to be retrieved; it’s already on hand.

Verizon CDNs also allow country filtering, so you can restrict access to certain files based on client IP address. This is handy for dealing with various regulatory restrictions.

The EdgeCast CDNs also provide basic analytics right from the Azure Portal.

The Akamai CDN refreshes much faster than Verizon’s versions, where changes can take up to 90 minutes to fully propagate; changes across the Akamai CDN should happen within a minute. Also, Akamai takes advantage of the HTTP/2 protocol, meaning modern Web browsers get especially snappy performance.

Pricing for the Standard Verizon and Akamai CDNs are, at this writing, the same worldwide, while the Premium Verizon CDN cost 2-4 times the Standard price, depending on volume.

Which version to use?

For most use cases, Standard Akamai is your best choice, because changes are propagated immediately.

Also, you almost never need metrics on static content. Page views and interactions are what most people want to measure, not “how many times did that favicon load?”

Wherever I mention Standard Verizon, below, the same feature is available in Premium Verizon.

You’ll want to use a Verizon CDN in these cases:

  • Files must be primed to all endpoints: Standard Verizon.
  • Files must have CORS origin restrictions or other custom headers: Premium Verizon.
  • Basic throughput / access metrics: Standard Verizon.
  • Advanced metrics: Premium Verizon.
  • Restrict access by country: Standard Verizon.
  • Restrict access via client type, IP or other environment variables: Premium Verizon.

Blob security and availability

An important note: Azure CDNs exist at the Storage account level.

That is, when I create a CDN in Azure, I can associate it with an Azure Storage account. Thus, all public containers and public blobs will, in theory, be accessible via that CDN endpoint.

I can prevent that by simply setting a container’s visibility to private container, which would exclude all the blobs within it from the CDN.

But I cannot be granular; at least, not with the standard CDNs. If I set my container to “public blob” or “public container” visibility, I can’t prevent access to a specific blob via the standard CDNs. In theory I could restrict specific file access via rules in a Premium CDN.

However, to keep things straightforward and manageable: Assume that if a container is set to public container or public blob, all blobs in that container will be available via the CDN.

In the next post, we’ll get into the setup and management of an Akamai CDN.

Featured photo by terimakashi via Pixabay, in the public domain.
Featured photo by terimakashi via Pixabay, in the public domain.

Leave a Reply

  • Check out the Commenting Guidelines before commenting, please!
  • Want to share code? Please put it into a GitHub Gist, CodePen or pastebin and link to that in your comment.
  • Just have a line or two of markup? Wrap them in an appropriate SyntaxHighlighter Evolved shortcode for your programming language, please!