The course is part of these learning pathsSee 2 more
Cloud-based virtual networks are software based, and they provide a standard way to organize and isolate Virtual Machines running in the cloud. A virtual network controls addressing, DNS settings, security policies, and routing tables.
Virtual Networks which are commonly referred to as “v-nets”, are isolated from one another. Due to the isolation, you can create networks for development, testing, and production that use the same address blocks.
To allow even further isolation, v-nets support subnets, which allow you to segment the network. Subnets will allow you to break out VMs by their purpose, which is common with tiered architectures. For example, if you have an application broken out into front-end and back-end tiers, then you might want to create two subnets, one for the front-end VMs, and another for the back-end tier.
If you're familiar with traditional networking components then you're going to feel right at home working with v-nets. So, if you're looking to learn more, then start in on the first lesson!
|Lecture||What you'll learn|
|Intro||What will be covered in this course|
|Overview||The componets of virtual networks|
|Creating a v-net||Creating a virtual network part 1|
|Completing the v-net||Creating a virtual network part 2|
|Application Gateway||The application load balancer|
|User defined routes||Using route tables|
|Traffic Manager||DNS based load balancing|
|Hybrid networking||VPNs and express route|
|Final thoughts||Wrapping up the course|
Welcome back! In this lesson we’re going to take a look at the components of a virtual network, so that in the coming lessons we can create a virtual network and watch how traffic flows through the network.
Cloud based virtual networks are software based, and they provide a standard way to organize and isolate Virtual Machines running in the cloud. The Virtual Network controls addressing, DNS settings, security policies, and routing tables.
Virtual Networks which are commonly referred to as “v-nets”, are isolated from one another. Due to the isolation you can create networks for development, testing, and production that use the same address blocks.
To allow even further isolation, v-nets support subnets, which allow you to segment the network. For example, subnets allow you to break out VMs by their purpose, which is common with tiered architectures.
If you have an application broken out into front-end and back-end tiers, then you might want to create two subnets, one for the front-end VMs, and another for the back-end tier.
Although v-nets are isolated from each other the VMs inside an individual v-net, as you’d expect, are not. VMs inside of a v-net can communicate with each other via their private IP address. The private IP address even allow VMs in different subnets to directly communicate.
Let’s check out a vnet diagram to better understand how these components interact at a high level before drilling down into them further.
So, a vnet is a software based, isolated network in Azure. Inside the vnet you can create subnets that will allow you to break the network up, for better organization or to better represent your application’s tiers.
In this example there are two subnets, and each of them has a network security group. A network security group, commonly called an NSG, serves as an access control list for incoming and outgoing network traffic. In this diagram the security groups are being applied to the subnet, however they can also be applied directly to a network interface. The difference is that if applied to the subnet, the rules will apply to all of the instances in the subnet; where if applied to an network interface the rules will only apply to that NIC.
To allow communication between the subnets, and from the public internet, a load balancer is being used. The Azure load balancer supports internal and external load balancers. The external load balancer will help your app remain highly available because it will direct traffic from the public internet to a healthy VM.
And the internal load balancer will also direct requests to a health VM, however they only allow communication from another cloud resource, or from a VPN connected to your on-premises network.
Virtual machines connect to a vnet with a software based network interface. Network interfaces in Azure are resources that can be created independently and attached to virtual machines. They allow for static or dynamic private IP addresses, static will ensure that the IP will remain the same, even after stopping and starting the VM; dynamic will be generated at startup with DHCP. It’s worth noting that you can have multiple network interfaces for the same VM, however you can’t currently do that with the portal. You’ll have to use PowerShell, the CLI or the API.
You might be wondering how the VMs inside the v-net deal with DNS. The answer is that by default all VMs are configured to use Azure-managed DNS servers, although, you can use your own DNS servers. If a VM uses the Azure-managed DNS, then it will be able to resolve the hostnames for VMs in the same v-net to the private IP address of the primary network interface.
So, having a private IP address allows for communication between the VMs inside the v-net, however it doesn’t help if you want to communicate with the VM directly. For that you can assign a public IP address. Public IP addresses are also independent resources, and allow you to create dynamic or static IP addresses. Having an public IP address will allow you to access a VM from the public internet.
Actually, since Public IP addresses are independent resources, you can also connect them to public load balancers, VPN gateways, and Application gateways.
Okay, that’s a high level of Azure networking, however if you’re anything like me, then you learn by doing. So that’s why we’ll walk through creating a virtual network in the next lessons.
Alright, if you’re ready to dive into creating a virtual network then let’s get started in the next lesson!
Ben Lambert is a software engineer and was previously the lead author for DevOps and Microsoft Azure training content at Cloud Academy. His courses and learning paths covered Cloud Ecosystem technologies such as DC/OS, configuration management tools, and containers. As a software engineer, Ben’s experience includes building highly available web and mobile apps. When he’s not building software, he’s hiking, camping, or creating video games.