Windows Azure Content Delivery Network, CDN, (http://www.microsoft.com/windowsazure/features/cdn/) targets on enhancing end user performance and reliability by placing copies of data closer to users. When I say 'Data', it is specifially targets on Static data - in other words, whatever data makes more sense for caching can be configured in CDN. As of today there are 24 Global nodes (http://www.microsoft.com/global/windowsazure/PublishingImages/cdn/950.gif) hosting CDN.

Following set of points need to considered when choosing CDN:

Distribution of Users: This is the basic thinking factor to go for CDN. If there is a good presence of users where the CDN node exists who consume data from Azure storage, then CDN can be considered.

Expected hit: Check for the number of hits and data usage from the zone where the CDN is considered. In some cases, where the hit ratio is higher, it might make sense to move the whole Azure services to that zone (or the nearest to that zone) other than adding CDN.

Type of Application: Need to have a deeper understanding of how the data is used in the application. For example, if each and every data from Azure storage is read of Web server and then streamed (bad programming), then CDN is of no use. Need see how the data is consumed by the application and add those objects which is consumed by the client browser directly. Also, CDN is highly recommended for Thick client applications using Azure storage (if it is across globe).

Data Handling: CDN is charged primarily with respect to the size of cached data. So, effective usage of CDN need to be thought through. Proper choice of objects to be cached and duration of caching will reduce the unnecessary charges.

Security: CDN is not recommended for caching data which has some security and compliance requirements. Normal usage of CDN should be considered for data which can be accessed as public rather than through set of credentials.