Azure Networking or: How I Learned to Stop Worrying and Love Dynamic Addressing

Very few things need statically assigned addresses anymore.  Routers, which includes load balancers and firewalls, and DHCP servers being the top of the list.  Once you move to the cloud, those two are handled for you.

If you set a static IP on a device in Azure, it will actually break the networking on the device in strange and interesting ways.  You must configure the networking via the portal, PowerShell, or API.  The “static” IPs you assign from the portal are actually DHCP reservations.  This centralization of IP management makes it incredibly easy to prevent conflicts, track resource utilization, and programatically apply CRUD to the network.  On top of that, it removes the hassle of remembering where to set the IP on the host (/etc/network/interfaces vs /etc/sysconfig/network-scripts vs Set-NetIPAddress).

A common downside to DHCP is due to its broadcast nature, however Azure doesn’t have standard broadcast domains (meaning a /16 isn’t any worse than a /24 in IPv4 space).  Azure does away with this by discarding all broadcast and multicast traffic, except those going to the DHCP server or router in IPv6’s case. This helps simplify networking and reduce the overhead for large networks. Instead of doing subnetting to reduce a broadcast domain, or enforce security, Azure doesn’t need that. For security, you should be doing VM level security via Network Security Groups.

A thing to note about IPv6 in Azure is that it’s very limited currently.  Not all zones support it 1, VMs cannot communicate with eachother directly via IPv6, and can only be assigned dynamic internal addresses, and only load balancers can get external IPv6 addresses 2.