DCSIMG
Introducing the Windows Azure Content Delivery Network - Windows Azure - Site Home - MSDN Blogs

Introducing the Windows Azure Content Delivery Network

Introducing the Windows Azure Content Delivery Network

  • Comments 17

As part of the Windows Azure CTP, we are announcing the Windows Azure Content Delivery Network (CDN) to deliver Windows Azure Blob content. Windows Azure CDN offers developers a global solution for delivering high-bandwidth content.

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.

The benefit of using a CDN is better performance and user experience for users who are farther from the source of the content stored in the Windows Azure Blob service. In addition, Windows Azure CDN provides worldwide high-bandwidth access to serve content for popular events.

When you enable CDN access for a storage account, the Windows Azure portal provides you with a domain name of the following format: http:/ /<guid>.vo.msecnd.net/. This domain name can then be used to access blobs in a public container. For example, given a public container “images” and a storage account “cohowinery”, once the storage account is enabled for CDN access, users can access the blobs in that container using either of the following two URLs:

  • Windows Azure Blob service URL: http://cohowinery.blob.core.windows.net/images/
  • Windows Azure CDN URL: http://<guid>.vo.msecnd.net/images/

When a request is made using the Windows Azure Blob service URL, the blob is read directly from the Windows Azure Blob service. When a request is made using the Windows Azure CDN URL, the request is redirected to the CDN endpoint closest to the location from which the request was made to provide access to the blob. If the blob is not found at that endpoint, then it is retrieved from the Blob service and cached at the endpoint, where a time-to-live (TTL) setting is maintained for the cached blob. 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.

The value of caching blobs in the Windows Azure CDN is realized only when the content is delivered from the CDN edge cache, so content requested only once during the blob’s TTL period will not get performance improvements from edge caching. The blob content that benefits the most from caching are blobs accessed frequently during their cached TTL period.

You may also register one custom domain name for Windows Azure CDN access per storage account in the Windows Azure Developer Portal. For example, if you wanted to access CDN content through the domain “merlot.cohowinery.com”, you can register that custom domain name for the CDN endpoint in the portal. Continuing with our example, this would allow you to then access your blobs via one of the following three URLs:

  1. http://cohowinery.blob.core.windows.net/images/
  2. http://<guid>.vo.msecnd.net/images/
  3. http://merlot.cohowinery.com/images/

The last two URLs above would access the blobs in the “images” container via the Windows Azure CDN, whereas the first URL would access the blobs directly from the Windows Azure Blob service.

The following steps are to enable CDN access to a storage account:

  1. Go to the Windows Azure Developer Portal.
  2. Click on your storage account.
  3. Click on “Enable CDN” for your storage account.
  4. The portal provides a CDN domain name in the form of: http://<guid>.vo.msecnd.net/ .

The configuration created for this endpoint is not immediately available; it can take up to 60 minutes for the registration to propagate through the CDN network worldwide. Users who try immediately to use the CDN domain name will get a 400 error until the configuration is updated worldwide.

After you’ve followed the steps listed above, you have to designate the containers you want to provide access to as a public container (http://msdn.microsoft.com/en-us/library/dd179391.aspx). You can then access blobs in that container using the CDN URL. The CDN domain name represents the storage account, so any public blob container within that storage account can be accessed via the CDN URL.

You can also register a custom domain name for the Windows Azure CDN endpoint. Follow these steps to register and use a custom storage domain name for your CDN content:

  1. Go to the Windows Azure Developer Portal
  2. Click on your storage account
  3. Click on “Manage” for your http://<guid>.vo.msecnd.net/ endpoint.
  4. Enter your custom domain name.
  5. To complete the register of your custom domain name you will be asked to verify that you own the domain. You will be asked to register for your “custom.domain.name” a CNAME record from “<guid>.custom.domain.name” to “domainnameverification.windows.azure.com”, where the <guid> is specified by us in the portal.
  6. Once you have registered that CNAME, click on validate in the portal for the CDN endpoint. Windows Azure will then validate that the CNAME record exists, and if successful your custom domain name will be registered.

To use the custom storage domain name:

  1. Create a CNAME record from “custom.domain.name” to “<guid>.vo.msecnd.net”
  2. Make the containers you want to provide anonymous access for public containers using the following blob API:
    http://msdn.microsoft.com/en-us/library/dd179391.aspx
  3. You can then begin providing anonymous access to your blobs with http://custom.domain.name/ via the Windows Azure CDN.

If you no longer wish to cache a blob in the CDN, you can:

  • Delete the blob from the public container
  • Make the container private instead of public using the blob API:
    http://msdn.microsoft.com/en-us/library/dd179391.aspx
  • Remove the Windows Azure CDN endpoint from your storage account in the Windows Azure Developer Portal.

Blobs already cached in the CDN will remain cached until the TTL for each blob expires. When the TTL expires, the Windows Azure CDN will check to see whether the CDN endpoint is still valid and the Windows Azure blob is still anonymously accessible. If it is not, then the blob will no longer be cached. This means that if you want to change the content of the blob and the blob is currently cached in the CDN, the new content will not be available via the CDN until the CDN refreshes its content when the cached content TTL expires.

Additional information:

  • At this time there is no charge for CDN access to your blobs while in CTP. Information on pricing for the Windows Azure CDN offering will be provided in the future.
  • For best performance, we recommend caching blobs less than 10 GB in size.
  • Windows Azure CDN access only works for anonymous access and for HTTP. HTTPS is not supported for CDN access.
  • A custom domain name can be registered for only one storage account endpoint at a time. For example, one could not register the domain name “merlot.cohowinery.com” for two different Windows Azure CDN endpoints at the same time.
  • You can register overlapping domain names for different endpoints. For example, the following domain names can be registered at the same time for different storage accounts or endpoints:
    • http://merlot.cohowinery.com/
    • http://vintage.merlot.cohowinery.com/

Stay tuned for more information about the Windows Azure CDN and additional new and exciting features at PDC 2009.

 

Brad Calder
Windows Azure Storage

Comments
  • Simply awesome. This is where you can start showing the real power of Windows Azure. As an Australian with 250ms latency to the US I'm really looking forward to seeing how this performs.

    Allowing Cnames is great, I hope we can map multiple domains to the same store.

  • Excellent!  I do, however, have a question as to authorization.  Will all the content be intrinsically public or will there be one or more mechanisms for securing end-user access?

    As an example our current CDN requires that all "secured" requests (served up via http; not by https!) include a dynamically generated validation token on the query string.  Before the content gets delivered the CDN hits simple a web service on our servers to see if the request is authorized.  If not a 403 error is generated.

  • Great news...this was much needed to scale the blob content...it's great to see Windows Azure thinking ahead and innovating in this space. THANK YOU!

  • lsberman: currently, the Windows Azure CDN only caches and serves public (anonymously accessed) blobs, so our CDN may not be the best option if your content requires authentication.  Thank you for feedback!

  • Are you planning on opening the API for configuring Azure CDN in the same way you can configure Amazon CloudFront? we would like to support managing Azure CDN in our CloudBerry Explorer for Azure Blob Storage http://www.cloudberrylab.com/default.aspx?page=explorer-azure

  • And what could be used to index the content? Only the URI? CDNs like Akamai, for example, allow us to use information in cookies to compose the index with the URI. Does it make sense to you?

    And what about delivering my Web Applications Pages through the CDN? Is it in the roadmap?

  • Is IIS Smooth Streaming available in the Azure CDN?

  • Will you also support CDN services on top of Windows Azure Web Roles to allow better and more efficient worldwide application experience?

    Currently we're investigating the option of running the same Web Roles in multiple data centers; which is far from ideal due to slow access to shared backend data (SQL) and traffic routing issues.

    Djon Kleine

  • Where are the European servers located?

    Do you have ping and bandwidth performance extimation?

  • Get the advantages of Windows Azure and Marketing benefits from Microsoft for FREE by joining the Microsoft Front Runner for Azure (in the US) (or the Green Light Program outside the US) to access one-on-one technical support by phone or e-mail from our developer experts, who can help get your applications in the cloud. Once your application is compatible, you'll get a range of marketing benefits to help you.

    Visit

    In the US http://frontrunner.msdev.com/whyjoin/windowsazure.aspx

    to join Front Runner.

    Outside the US https://www.isvappcompat.com/Home/Start

    to join Green Light.

  • Hi auchoa,

    I too would like to have the "delivering my Web Applications Pages through the CDN".

    I put the idea to the Windows Azure Feature Voting Forum, you can comment or vote for it here:

    windowsazure.uservoice.com/.../34192-windows-azure-feature

    -voting/suggestions/781077-http-cache-proxy-cdn-like-geo-aware-highly-a?ref=title

    For admins, I hope it is OK to propagate my own voting ideas here :-)

  • the link to the Windows Azure Feature Voting was not properly displayed, so I had to use URL shortener.

    For anyone interested in "delivering Web Applications Pages through the CDN", you can vote or comment at:

    http://bit.ly/bz26oh

  • Any plans of introducing authentication support? The CDN could be very useful in distributed business applications, given a proper authentication model.

  • Is there an API for the CDN features?

  • Hi,

    I work on Azure CDN product management.  

    We definitely understand the request for CDN services for objects in compute instances rather than Azure Storage.  Stay tuned on that one.  We haven't got anything to announce yet, but it's definitely on our radar.

    We don't have an API opened up for public use yet.  Top of our list will obviously be content purge, and probably basic reporting after that.  What would you like to see in an API?

    We don't have any sort of authentication model -- as someone else noted, it's counter to the scale and public-delivery objective of a CDN.  That said, I'd be curious to know how you see this implemented -- using basic browser authentication, or something else?

    IIS Smooth Streaming is not directly integrated into Azure CDN -- yet.  This is the top feature request that we get.  You can do it today if you're comfortable with .NET code and preassembling your on-demand content -- see SMarx's blog post:

    blog.smarx.com/.../smooth-streaming-with-windows-azure-blobs-and-cdn

    As for actual node locations, we'll have a blog post going up in the next couple weeks with the details.

    My direct mail is jason [dot] sherron (at) microsoft -dot- com if you want to discuss more.

Page 1 of 2 (17 items) 12
Leave a Comment
  • Please add 3 and 1 and type the answer here:
  • Post