I recently needed to build a website that would quickly serve users across the United States. To accomplish this objective I decided to use Azure to serve ASP.NET pages in Cloud Services. The Cloud Services would reside on both the East and West coast of the US and I would direct the incoming HTTP request to the closest Cloud Service on Azure.
To accomplish the task of routing the request to the nearest data center, I decided to use Azure's Traffic Manager. The Traffic Manager is able to determine which data center has the lowest latency for the request. To use Traffic Manager in this situation, I need to make a Traffic Manager profile by specifying a DNS name as in: myname.trafficmanager.net. This can be done with the Azure portal or with PowerShell.
Once the Traffic Manager is set up, it needs endpoints. The endpoints are the Cloud Services that you want the requests to go to. After deploying the Cloud Services to the data centers on both coasts, I can add them as endpoints. From here the request to myname.trafficmanager.net can resolve to the closest Cloud Service because my load balancing method is set to: Performance. There are other settings, such as Round Robin (to distribute endpoints) and Failover (with a primary endpoint).
Once this is set up, it is possible to route a request for a domain to the Traffic Manager. This is done by using a CNAME. In my case, I used GoDaddy for the domain and made a CNAME that pointed “www” to myname.trafficmanager.net. After doing this, requests to www.sleeptightmouthpice.com would go to the load balanced Traffic Manager Cloud Service. To get the root request to resolve (non-www) I needed to do domain forwarding so that sleeptightmouthpiece.com would forward to the “www” CNAME.
It's best to have multiple Cloud Services at each data center that I want to load balance across. This is because Azure performs maintenance and will restart them every so often, one instance at a time in each Cloud Service. It also provides some fault tolerance this way. You can use an SSL in this scenario as well but requests for https://domain.tld will not resolve as far as I can see (supposedly it would require trafficmanager.net to assist in this regard since the SSL was not generated by them).
You should confirm that your requests are going to different data centers. One way to do that, in the case of a Cloud Service with RDP enabled, is to log into in and find your application's log. It is located at: C:\Resources\Directory{DeploymentID}.{Rolename}.DiagnosticStore inside a .txt file deep down in the directory. If you have the ability to send requests from different distant locations, you can see which data center picks up the request by looking for the IP address in the log of each Cloud Service.
Every application is different, in this case the priority was to deliver the initial page quickly. The initial request does not have a server side database call with a database on a single data center. In that scenario the Traffic Manager could actually slow down the requests. There are other resources that may need to be load balanced like static files however, you can use Traffic Manager to assist with directing requests to different Azure sub domains in a similar way. It can also be used to monitor the status of the services you deploy services.
