7

I had always been using the normal public IP to communicate between my virtual machine. However as I see in the portal there is an INTERNAL IP ADDRESS and I wonder what is the practical use of that?

Is it that using this internal IP to communicates between VMs would be faster? And is this restricted to VM in the same geo-region?

spacemilkman
  • 943
  • 1
  • 9
  • 15

1 Answers1

12

With Virtual Machines, you use external IP address (Input Endpoints, or Instance Input Endpoints) for external communication. The former is load-balanced, while the latter is direct-mapped to a specific virtual machine instance.

Within a cloud deployment, you may have several Virtual Machines. They may each talk directly with each other via IP / port. Each virtual machine will be assigned an IP address local to your cloud deployment's network (that is, the IP addresses are local to the deployment; you cannot talk with anyone else's VMs, unless there's a Virtual Network configured).

The advantage of direct IP internally: You don't need to enable any type of security. For instance: if you have a WCF service that you only access internally, you won't have to worry about SSL, certificates, etc.

One clarification on performance, from @Eilistraee's answer: There's no penalty for communicating with the external ip address. While the request does get routed to the data center's edge, your call won't actually leave the data center. Furthermore: As long as your communication is between VMs in the same data center, there's no outbound traffic costs.

Now: With Web/Worker roles in Cloud Services, you do not have carte blanche to talk to any IP address internally. Rather, you define specific Internal Endpoints, which ultimately map to a specific port on your web or worker instances (and each instance of a web or worker role will listen on that same port, though your code will have to manually choose which web/worker instance to talk to on that internal endpoint).

David Makogon
  • 69,407
  • 21
  • 141
  • 189
  • Thank you very much for this answer. It's good. And I assume that if you make a call to the load balanced hostname, you get the same behavior? – Eilistraee Apr 20 '13 at 16:44
  • If you make a call to a host name with a port number set up as a load-balanced port, then it would be load-balanced across the various virtual machines (maybe something like mysite.cloudapp.net or mysite.cloudapp.net:10000). If it's an input instance endpoint e.g. port 7474 maps to one specific server, then there wouldn't be any load-balancing (so maybe your db server is accessed via mysite.cloudapp.net:7474, which routes to one exact vm). – David Makogon Apr 20 '13 at 18:37
  • Is this answer out of date? I *think* I have evidence that using the external IP instead of the internal one can cost you and is slower. We were using the external IP in some connection strings from our web VM to our database VM. As an experiment, we switched to internal IP. Our "network out" on the database VM (which we get charged for) dropped to basically zero. Task manager also showed the "latency" for the connections drop from 13-50 ms to 3-5 ms. – Rainbolt Sep 21 '18 at 19:06
  • @Rainbolt - nope nothing has changed regarding bandwidth billing for outbound traffic: there is no billable bandwidth charges between services in the same region. – David Makogon Sep 29 '18 at 16:41