Azure Virtual networks (Vnet) are similar to the traditional networks in your on premises environment. They form the isolation boundary for your network in the cloud. They are the building blocks for your environment and allow other resources such as virtual machines to securely connect with each other or the Internet.
By default a Vnet would not be able to talk to other Vnet(s). However, they can be configured to communicate with each other.
In order to create a virtual network in cloud you need to decide few things:
- Subscription in which you will deploy the VNet. A virtual network cannot span over multiple subscriptions.
- Region where the Vnet lives.
- Resource group to deploy the VNet to.
- Address space used by the azure virtual network. A virtual network can contain multiple CIDR blocks. If it’s a hybrid environment that you’re working with, you MUST make sure that your on premises CIDR do not clash with the CIDR blocks in Azure.
- Subnets that segment the virtual network. Subnets are allocated IPs by segregating the VNet CIDR block(s) into multiple portions.
These are just few points that are primarily required when you create a Vnet. You have to be careful while making decision regarding these since it would be very difficult to change these at later stage of your project. Some configurations can be edited even after creating the resource. There are few other configurations, such as DNS, peering, etc. which will be added after creating the VNet. It is important that you have design in place that won’t be changing once you deploy other Azure resources. In an enterprise environment there are multiple criteria you’re required to factor in while making these decisions.
We will cover more best practices in another post.