Azure networking concepts
The most common question I have to answer when it comes to Azure virtual networking is: how do I associate a route table with a virtual network? And the answer is: you don't. Route tables are associated with subnets, not vnets. Ha! Don't you love the cloud?
I have put together the following diagram to try to get this stuff straight in my own head, and hopefully it will be useful for others. (Also, please let me know if there are errors in it...)
In the diagram above, an arrow from 'A' to 'B' means that you go to 'A' in the Azure Portal and tell it to associate with 'B'. (Or you create a Terraform resource for 'A' and feed it the ID of 'B' as an input attribute, etc.)
The little '1:1'/'1:n'/'n:n' notations refer to the number of 'A's that can be connected to what number of 'B's. For example each subnet can have multiple route tables and each route table can be associated with multiple subnets ('n:n'). On the other hand multiple network interfaces can be associated with each network security group, but each network interface can only have one network security group ('n:1').
领英推荐
The next diagram gives some examples of how traffic flows through virtual networks:
Of course in reality the traffic doesn't go anywhere. For most customers, their entire Azure estate is hosted on a single AWS instance, and traffic does not leave that box. Virtual networking is the ultimate in 'talking to yourself'. However, when it comes to troubleshooting connectivity problems, the above diagram is your guide. You need to make sure you have things like peerings, route tables and NSGs in place, and know where to look for them.
The above is far from everything there is to know about Azure virtual networking, but it's a good start. Even for those of us who have been fiddling around with this stuff for years, it is useful to have some simple summary diagrams of what connects to what. Otherwise you will be trying to configure flow logs on your route tables, and that's not a good way to spend your evening. Enjoy! :-)