Forum Discussion

Admin O365's avatar
Admin O365
Brass Contributor
Jan 20, 2019

VNet & Subnet Architecture for Greenfield environment

Implementing Greenfield in Azure with Non-prod and Prod subscription in a Azure Tenant.

I have 3 subnet ranges for each Environment.
Looking for assistance to understand does it make sense to design the VNET in a Resource group (RG) and later as per requirements host multiple applications in its own RG with VNET part of another RG.

Found so, I can lay down my VNET n subnet.

Please guide.
  • 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

  • CharlieAirey's avatar
    CharlieAirey
    Copper Contributor

    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

    • Admin O365's avatar
      Admin O365
      Brass Contributor
      Thanks for your response.

      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.
      • CharlieAirey's avatar
        CharlieAirey
        Copper Contributor

        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.

Resources