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 developer portal provides you with a domain name of the following format: . 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:
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:
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: .
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 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:
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:
· 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.
· 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:
Stay tuned for more information about the Windows Azure CDN and additional new and exciting features at PDC 2009.
Windows Azure Storage
- Moved by Brian AurichMicrosoft employee, Moderator Thursday, March 24, 2011 7:57 PM Moving to active forum. (From:Windows Azure - Archive)
Is it possible to know how much POPs (Point-of-Present) exists in Asia right now?
I traced the IP address from my location ( Taiwan ). It looks like the most recent location is located in US. I'm not sure the Asia CDN has been enabled or not for now?
We have several POPs in Asia today, and in the majority of cases requests will be routed to a POP in region.
Routing to our CDN is based on BGP anycast.
Depending on the network you are on, and how this network connects to our CDN network, the requests could be routed to a POP further away.
In your case I imagine that the prefered BGP route between your ISP and our CDN network leads to one of our US locations rather than to one of our Asian locations.
As we continually improve our connectivity and coverage the routing will evolve over time and will most likely reach a POP geographically closer to you.
Windows Azure CDN
I'm located at Taiwan. I've tried few CDNs recently. Most of them's POP's latency are around 50ms. I was apply a Windows Azure Storage account and enabled CDN feature. I've tested that the average network latency is around 89ms ~ 92ms. Here is my ping result:
C:\>ping az1222.vo.msecnd.net Pinging az1222.vo.msecnd.net [184.108.40.206] with 32 bytes of data: Reply from 220.127.116.11: bytes=32 time=90ms TTL=53 Reply from 18.104.22.168: bytes=32 time=91ms TTL=53 Reply from 22.214.171.124: bytes=32 time=91ms TTL=53 Reply from 126.96.36.199: bytes=32 time=90ms TTL=53 Ping statistics for 188.8.131.52: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 90ms, Maximum = 91ms, Average = 90ms
Are you plan to having a POP setup on Taiwan?
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
It seems that any web browser that is configured to use Public DNS services (such as Google's DNS @ 184.108.40.206, and possibly Open DNS) won't return an optimal path for a CDN, thus increasing latency and download times. I haven't tested Azure CDN but most other CDN's return the host that is closest to that recursive resolver.
Would it make sense for Microsoft to round robin the response if the requestor is coming from those well known addresses?
Are there any issues with CDN and Anycasting? Is there any compatibiliy with Anycasting and Geo-replication?
Will, I can't comment about future location of our POPs.
We are working to further expand our connectivity and reach to various internet providers in Asia which will result in you being routed to a POP physically closer to Taiwan and further reduce the latency.
When using open DNS such as google or OpenDNS the machine running the browser will use anycast to query a Google or OpenDNS server, and that DNS server in turn will use anycast to query the domain's authoritative DNS server.
That DNS resolution can result in a choice of CDN POP that is further away from the browser than if one used their ISP DNS servers (that's the case for me in the USA).
Anycast is broadly used, our CDN uses it for DNS resolution of our msecnd.net domain. It however sometime can result in a choice of a CDN POP that may not be physically the closest to the user (but instead is a POP closest to the user based on the network routing topology).
Hi Djon, we're always looking into how we prioritize the delivery of new services such as CDN on top of the Windows Azure Web Role.
Thanks much for your requesting this, we will add it to our feature request list.
You may also want to submit this request at http://www.mygreatwindowsazureidea.com/ where we can have the user community review and vote on the various requests.
Thank you very much.
How do you overcome the Great Firewall of China problem? If some of your azure IP has been blocked by them, how do you ensure China user can see the website? If you have any POP or Data Center located within China, the problem may be solved.