Forum Discussion
VNet & Subnet Architecture for Greenfield environment
Hi,
I think the general resource group / subscription design comes down to how you wish to manage and secure your resources. I would recommend the following as a starting point:
1. Design a naming convention for your resources, this is good practice to get right at the start as you build out 100's of resource components. It can be difficult or sometimes impossible to rename resources without re-deployment.
2. Resource Location - Where are your resources going to be accessed from, what dependency resources are there and where are they located.
3. Resource Tagging - Tag your resources it makes reporting and management easier down the line.
4. Think about your vnet design, do you need separate vnets with peering enabled or simply different subnets. Is there an on prem vpn gateway, are you going to forward traffic etc etc. Its important to think about these configurations with security and access at the forefront of the discussion.
5. Administration / Security Access - How are you going to manage the resources and who has access. Do you have a separate network, dba or infrastructure team, do you have DevOps.
Understanding who needs to administer the resources helps guide how you design your resource groups and what goes into them.
I have a customer as an example who have a networks team who manage all the network components, vnets, gateways, load balancers etc. So all the network components are in a Network RG and the network administrators only have access to that RG.
Other organisations may deploy specific solutions that are managed by a single team so it makes sense for them to build all the resources in a solution RG and set the appropriate security for that team.
All the best
Hi,
I think the general resource group / subscription design comes down to how you wish to manage and secure your resources. I would recommend the following as a starting point:
1. Design a naming convention for your resources, this is good practice to get right at the start as you build out 100's of resource components. It can be difficult or sometimes impossible to rename resources without re-deployment.
2. Resource Location - Where are your resources going to be accessed from, what dependency resources are there and where are they located.
3. Resource Tagging - Tag your resources it makes reporting and management easier down the line.
4. Think about your vnet design, do you need separate vnets with peering enabled or simply different subnets. Is there an on prem vpn gateway, are you going to forward traffic etc etc. Its important to think about these configurations with security and access at the forefront of the discussion.
5. Administration / Security Access - How are you going to manage the resources and who has access. Do you have a separate network, dba or infrastructure team, do you have DevOps.
Understanding who needs to administer the resources helps guide how you design your resource groups and what goes into them.
I have a customer as an example who have a networks team who manage all the network components, vnets, gateways, load balancers etc. So all the network components are in a Network RG and the network administrators only have access to that RG.
Other organisations may deploy specific solutions that are managed by a single team so it makes sense for them to build all the resources in a solution RG and set the appropriate security for that team.
All the best
I'm thinking to have Seperate RG for network that will have all VNet, subnet for that subscription. Later app based RG to use the VNET defined in RG VNET.
I was not sure if this is supported?
Also, can't find any blog / article on it.
Hi.
Yes that's absolutely fine. As I mentioned the advantage of grouping similar resources into their own RG is to ease the administration of applying security. So a network team as an example can have access only to the 'network' RG.
