Welcome to MSDN Blogs Sign in | Join | Help

Introducing the Windows Azure Content Delivery Network

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

Published Thursday, November 05, 2009 11:35 PM by WindowsAzure

Comments

# re: Introducing the Windows Azure Content Delivery Network

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.

Thursday, November 05, 2009 6:09 PM by SoulSolutions

# re: Introducing the Windows Azure Content Delivery Network

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.

Friday, November 06, 2009 6:46 AM by lsberman

# re: Introducing the Windows Azure Content Delivery Network

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!

Friday, November 06, 2009 1:45 PM by EdgeTech

# re: Introducing the Windows Azure Content Delivery Network

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!

Friday, November 06, 2009 10:21 PM by WindowsAzure

# re: Introducing the Windows Azure Content Delivery Network

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

Monday, November 09, 2009 1:23 PM by cloudberryman

# re: Introducing the Windows Azure Content Delivery Network

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?

Monday, November 16, 2009 3:22 PM by auchoa

# re: Introducing the Windows Azure Content Delivery Network

Is IIS Smooth Streaming available in the Azure CDN?

Tuesday, November 17, 2009 7:31 AM by nickknyc
Anonymous comments are disabled
 
Page view tracker