[DEEP] Azure VNets – setting the fundament

So as we know the Azure Networking Basics now, we can focus on the base element in Networking in Azure: Azure VNets

Azure Virtual Networks a.k.a. VNets

An Azure Virtual Network is the fundamental building block in an Azure environment. It is your private network portion of the azure network.

Each VNet is a separated and isolated from other VNets, as long as you do not create any connection between them. Azure VNets have three default boundaries:

• Region – a VNet can only span one region. If you need a VNet in another region you have to create a separate resource.
• Subscription – a VNet can only exist in one subscription. If you are running multiple subscriptions you will require multiple VNets
• Address Space – a VNet is limited by it’s address space by default. But you can adjust the address space or add other IP ranges anytime

This leads to different approaches in VNET-Design

The virtual network is used to create a connection:

• between Azure Resources – via an Azure VNet resources can communicate on a private network with each other
• to the internet – by default all resources in a VNet can communicate outbound to the internet
• to on-premises – there are options to connect a VNet to an on-premises network, but this will be covered later

A VNet can have multiple address spaces which even can have totally different masks.

Subnets in VNets

Azure VNet cannot work without having a proper subnet set up. The subnets enable you to segment the virtual network and allocate a portion of the virtual network’s address space to each subnet. You can then deploy Azure resources in a specific subnet. Just like in a traditional network, subnets allow you to segment your VNet address space into segments that are appropriate for the organization’s internal network.

Be aware that a Subnet is a subset of your VNets address space. So you can never have a larger subnet than the VNet space allows.

another important thing to know, is that all Subnets inside a VNet are routed by default:

So the two Subnets in the graphic can communicate to each other. The network virtualization is doing routing and switching here automatically. This is important to understand in case Subnets are created to saparate workloads from each other.

In this case you have to modify the routing of the VNet or work with a central firewall.

VM NICs attached to Subnets

If you create a resource it will be always attached to the subnet and never directly to a VNet. This is also the reason why it is recommended to not fill all the address space of a VNet with Subscriptions. Some resources will create their own Subnet during deployment. Therefore it is required to have some space left in the VNet.

Dieser Post ist auch verfügbar auf: Englisch