Jan 20 2019 12:39 PM
Jan 22 2019 12:44 AM
Hi,
what about this template?
https://github.com/Azure/azure-quickstart-templates/tree/master/101-vnet-two-subnets
This will create a vnet with two subnet as your first requirement. (Just add another subnet)
Next, as far as I know, there is no limitation in creating a VNET in one RG and then creating a resource (nic/IP) in a different RG that is using this VNET.
Jan 22 2019 04:40 AM
SolutionHi,
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
Jan 22 2019 11:07 AM
Jan 24 2019 07:54 AM
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.
Jan 22 2019 04:40 AM
SolutionHi,
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