In this post I will discuss the resolution of IP and DNS addresses between IaaS VMs.
The key to optimizing and understanding the use and resolution of internal IP vs. external IP addresses is whether or not the client and server VMs are both in the same VNET. Either way, whether you use the internal IP / DNS Cloudapp.net to access a VM, if the client and server VMs are in the same VNET, the implicit (or explicit) DNS for the VNET realizes we are referring to a VM in the VNET and routes it to the internal IP. So this is not an issue as long as the VMs are contained in the same VNET (can be different or same subnets does not matter).
However if the VMs are not in the same VNET, then when using the DNS name the internal DNS router will send the request out to the public internet can back in through the external firewall.
As an example let’s look at a Web Role in one cloud service, and a SQL Server VM in another (remember IaaS VMs are contained within a cloud service ‘container’ too). The Web Role would communicate with the SQL Server by using the SQL Server’s publically accessible endpoint (i.e. mysqlserver.cloudapp.net:1433). You could make this more secure by adding an ACL to the SQL Server cloud service, but that is not depicted in the diagram.
By contrast, if the Web Role cloud service and SQL Server VM cloud service are in the same Virtual Network, then the Web Role would communicate with the SQL Server instance using a direct (private) IP address on the network (e.g. 10.20.0.2:1433). Windows Azure’s built-in DNS does not span cloud services, even within a Virtual Network. So, to get DNS resolution, one would need to deploy their own DNS server or update a HOSTS file on the calling server (in this case the web server). Or, just go with IP address and forget about DNS resolution.