Freigeben über

The Basics of IP Addresses in Windows Azure

  • Artikel

Overview

I’ve noticed some confusion among my developer friends around IP addresses and Windows Azure. In fact, I discovered I could learn more and hence the purpose of this post.

It turns out there are two types of IP addresses. The first and most obvious type is the external IP address that all of us used to connect to the service. This is what your users would use as well. It is called a virtual IP address. When you ping your service you get the virtual IP address. The second IP addresses are internal IP addresses, used by the load balancer, invisible to the outside world.

image

Assume the virtual IP address is 65.48.12.113.

That means you can:

  • Access the web role at 65.48.12.113:80
  • Access the SSL port at 65.48.12.113:443
  • Access the remote desktop session port at 65.48.12.113:3389

Static IP Addresses

There are scenarios where static IP's are needed. Consider replicating a database, which needs immutable IP addresses. For the most part, the externally facing IP address will not change.

Lose the Virtual IP Address

The main reason this virtual IP address will change is if you delete the service.

Virtual IP Address Stays the same

In-place upgrade, VIP swap, and scaling will not make you to lose your public IP address.

Load balancer and my internal IP addresses

Now imagine that your web service has two instances running. This means that there are two internal IP addresses that the load-balancing knows about. When someone from the outside world accesses your service, they will use the virtual IP address. The internally assigned IP addresses are not accessible from the outside world. The algorithm inside of the load balancer will route the request to one of the two instances running, using the internal IP address that it knows about.

Comments from my colleagues

You can talk "directly" between cloud services by using the internal ip addresses assigned to the each instance. The internal IP will stay the same for each instance until that instance is stopped. This means it's possible to register the internal IP addresses, as the servers come online, in a database and then other servers could use that internal IP to connect directly… this might be enough for some scenarios.

Azure does provide the Virtual Network service for site-to-site, cross-premises connectivity. You can create virtual Private Networks, either Point-To-Site or Site-To-Site. https://www.windowsazure.com/en-us/documentation/articles/virtual-networks-create-site-to-site-cross-premises-connectivity/. Following the guidance will allow you to have a virtual network where you can deploy your Windows Azure services and virtual machines, which can then communicate directly with your company's network.

image

Other team members have commented that if you want developers to leverage the same dev/test environment that is networked to an on premise network, everyone needs to build within the same virtual network. Virtual networks are separate from one and other by design. In other words, if you have separate Azure subscriptions you cannot network VPNs across subscriptions. There may be a workaround to this I am not seeing.

This post describes some of the scenarios that are possible: As https://msdn.microsoft.com/en-us/library/windowsazure/jj156007.aspx

Hope this helps

There is more to learn here. I've talked about some of this in an MSDN article here: https://msdn.microsoft.com/en-us/magazine/dn520239.aspx

Comments