Azure CDN vs. Amazon CloudFront/S3

Earlier this summer we took a deep look at the CDN market, taking into account both established players (Limelight, Akamai, Level-3) and the emerging pay-as-you-go contenders (Amazon’s Cloud Front, Rackspace’s Cloud Files, SimpeCDN and the like). Today, ~1 week after Amazon’s Relational Database Service was announced, Microsoft responded with its own introduction of a new CDN that will offer 18 edge locations throughout the world [1] :

“Windows Azure CDN has 18 locations globally (United States, Europe, Asia, Australia and South America) and continues to expand. Windows Azure CDN caches your Windows Azure blobs at strategically placed locations to provide maximum bandwidth for delivering your content to users. You can enable CDN delivery for any storage account via the Windows Azure Developer Portal. The CDN provides edge delivery only to blobs that are in public blob containers, which are available for anonymous access.”

Note that the latest addition to the Azure family is in CTP release only. All we know is that, for the Windows Azure platform itself, PDC ‘09 (to be held later this month) is expected to announce new features and will be followed by an official launch in January and first billing cycle in February; it’s very likely that the CDN will be available along similar timelines as well.

Like CloudFront, Microsoft’s CDN doesn’t solve the HTTPS issue in its first release. In terms of pricing, if Windows Azure Platform Pricing is any indication, you can expect to pay ~0.17/Gb for each targeted zone.

As a refresher, Amazon uses 14 edge locations in major markets throughout worldwide: 8 in the United States (Ashburn, VA; Dallas/Fort Worth, TX; Los Angeles, CA; Miami, FL; Newark, NJ; Palo Alto, CA; Seattle, WA; St. Louis, MO), 4 in Europe (Amsterdam; Dublin; Frankfurt; London) and 2 in Asia (Hong Kong, Tokyo).

The North American edge locations are mapped below:

On the issue of TTLs, it’s still unclear whether the Azure CDN will support shorter TTLs required for niche applications:

“The TTL specifies that the blob should be cached for that amount of time in the CDN until it is refreshed by the Blob service. The CDN attempts to refresh the blob from Windows Azure Blob service only once the TTL has elapsed. The default TTL is 72 hours. At PDC 2009, we will allow you to specify the standard HTTP Cache-Control header for your Windows Azure blobs. If this value is specified for a blob, then the TTL period will be set to the value specified in Cache-Control header.”

And lastly, tools you need to get started with either service are the Azure Storage Explorer, the Amazon S3 Firefox Organizer (0.4.8) or CloudBerry Explorer (for S3 and Azure Blob Storage) – just note that, as Microsoft plays catch up here, the Azure tools don’t yet expose the same richness of features around CDN integration.

References:

[1] – Introducing the Windows Azure Content Delivery Network http://blogs.msdn.com/windowsazure/archive/2009/11/05/introducing-the-windows-azure-content-delivery-network.aspx

[2] – Using the New Windows Azure CDN with a Custom Domain http://blog.smarx.com/posts/using-the-new-windows-azure-cdn-with-a-custom-domain