setup single VNet with mutple subnets or multiple peered VNets with one subnet each ?

Question

Need help design our first Azure VNet in our new Azure Subscription.

Requirement:

1. We need to setup 4 networks (either VNet or Subnet) - Apps, DB, Web, & Dev.
2. All should be able to talk to each other.
3. No Isolation required.
4. Each will host about 50 VMs.
5. Cost is not a constraint

One of our System Admin has suggested to setup one VNet with 4 subnets - Apps, DB, Web, & Dev (with NSG)
But other System Admins are saying to setup separate 4 VNets with 1 subnet for each (Apps, DB, Web, & Dev) (with NGS) and peering them to each other, as separate VNets provide more security.

So, we are confused as which one is better and best practice, how others are setting is up in their environment and what's recommended.

Need your expert advice. Thanks.

Answer 1

As a rule of thumb you can look at your workloads. Workloads that have:

• the same maintenance team
• and have the same lifecycle (thus are all deployed together)
• and need not to be secured from each other (now and in the foreseeable future)
  only those workloads can be deployed to the same subnet.

Furthermore, I would ALWAYS separate the DEV and PRD resources into separate networks. This is however under the assumption that DEV workloads do not need to (or even are not allowed to) communicate with the PRD network resources.

A hub-and-spoke set-up has many advantages is your network set-up is growing and you want to couple on premises locations and P2S VPN locations to your network. This is however a step you can add at a later stage.

Peering VNETs will not add any security over using subnets. Peered VNETs are considered to be one big network, like one VNET is. Furthermore, data that is sent via the peering is costing you money. If there is a (future) need to remove the peering in a later stage, having your network already being split up into different VNETs is more easy. This is however under the assumption you already know how you want to split up your networks in the future.

My suggestion would be:
DEV vnet

• app1 subnet
• app2 subnet
• db app 1 subnet
• db app 2 subnet
• web app 1 subnet
• web app 2 subnet

PRD vnet

• app1 subnet
• app2 subnet
• db app 1 subnet
• db app 2 subnet
• web app 1 subnet
• web app 2 subnet

only peer these networks if there is a business need to have communication between DEV and PRD.

You can also add now, or in the future, relevant NSG's that allow specific communication between the subnets. i.e. DEV_app1 can communicate with the DEV_DB_app1, but not with DEV_DB_app2.

Answer 2

Hi,

Currently you have 4 vnets, let's say you create 4 vnets for each network and peer each other, it would absolutely work.

When you scale, for each vnet you add, you will need to create multiple vnet peering for mesh connectivity.

I would suggest you to think though this from the future requirement standpoint and make a decision on which approach to go.

Regards, Karthik Srinivas

Answer 3

Either will work, but separating the workloads to separate VNETs will allow greater flexibility in the long run.

Your best bet may be Hub & Spoke.

Hub for your site-to-site VPN, Firewall etc and spoke network for Production and Development, or a spoke network for each business unit etc.

Have a read of the following links:

https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-area/network-topology-and-connectivity?WT.mc_id=AZ-MVP-5004796
https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/design-areas?WT.mc_id=AZ-MVP-5004796
https://learn.microsoft.com/azure/architecture/reference-architectures/hybrid-networking/hub-spoke?tabs=cli&WT.mc_id=AZ-MVP-5004796

There are a few design decisions to consider, such as IP address range, the way your business works (ie do you want to allow other users or businesses to deploy into Azure), are you considering multiple regions etc. Have a read of the Azure Landing Zone and Hub & Spoke reference architecture from the Azure Architecture Center.