We're planning to migrate a significant number of our on-prem servers to Azure in the upcoming weeks. One major challenge is figuring out how to effectively group our virtual machines (VMs). On-premise, we have a clear structure using Organizational Units (OUs) in Active Directory for grouping and applying Group Policy Objects (GPOs). However, I'm unsure how to achieve similar organization in Azure.
Each VM typically has at least four resources associated with it, such as the virtual machine itself, vNIC, OS disk, and network security group (NSG). We're considering using one subscription per environment (Test, Staging, Production), but it raises the question of whether we should create a single resource group (RG) per VM. Given that we have over 250 servers (with around 100 expected to migrate), managing so many RGs could be overwhelming. I've looked into the Azure Cloud Adoption Framework and Landing Zones, which have been helpful, but I'm seeking advice to streamline the organization process during the transition. Any insights or experiences would be greatly appreciated!
4 Answers
I believe grouping each VM into its own resource group can be pretty inefficient. Instead, consider organizing them by shared workload or by user management. For instance, if you have multiple app servers, group them accordingly rather than assigning them to different RGs. This approach makes management smoother and more streamlined, preventing overload with numerous resource groups. Tags can also help identify and manage resources better, making documentation and organization less of a headache.
In our case, we utilize descriptive tags for our RGs, like naming them after the applications they support. For example, we have resource groups like rg-customer-sap-location-prod. This helps make it clear what each group is for and makes management easier.
It's important to note that Azure VM organization doesn't have to mirror your AD structure. You should define your organizational structure based on needs like resource management, cost tracking, and lifecycle management. Remember, resources can’t be shared across subscriptions, so planning the network architecture is crucial.
Using tags is a great way to organize your VMs. For example, we implement tags like cost code, IaC (Infrastructure as Code), and service owner email to help keep things organized. Assigning a clear parent name that's shared across related resources such as NICs and storage accounts also helps in managing VMs as a collective, rather than individually.
That’s awesome! We also have a TAG system which includes DOPE: Department, Owner, Project, and Environment. It's really effective for us.
Do you have examples of tag structures that work well? I’m looking to propose a tagging system since we currently have none.