Resource Groups

How to either create new or connect to existent Azure Resource Groups to organize your Dev Box Landing Zone
Tags:

Overview

This YAML configuration file azureResources.yaml defines the organizational structure for Azure resource groups as part of the Microsoft Dev Box Accelerator. It follows Azure Landing Zone best practices, enabling modular, decoupled, and scalable management of cloud resources. By segmenting resources into functional groups—workload, security, monitoring, and connectivity—the configuration supports clear governance, access control, and lifecycle management for enterprise-scale Dev Box deployments.

Role in Dev Box Accelerator:
This file is a foundational component, ensuring that all resources deployed for Microsoft Dev Box environments are organized, tagged, and governed according to enterprise standards. It enables teams to manage infrastructure and workloads independently, supporting both operational efficiency and compliance.

Table of Contents

Configurations

Each top-level section in the YAML file represents a distinct Azure resource group category. Below is a breakdown of each section, its keys, and their purposes.

Workload Resource Group

Purpose:
Contains the primary Dev Box workload resources including Dev Center resources, Dev Box definitions, Dev Box pools, and project resources.

Best Practice:
Separate application workloads from infrastructure components to enable independent scaling, access control, and lifecycle management.

YAML Representation:

workload:
  create: true
  name: devexp-workload
  description: prodExp
  tags:
    environment: dev           # Deployment environment (dev, test, prod)
    division: Platforms        # Business division responsible for the resource
    team: DevExP              # Team owning the resource
    project: Contoso-DevExp-DevBox  # Project name
    costCenter: IT            # Financial allocation center
    owner: Contoso            # Resource owner
    landingZone: Workload     # Landing zone classification
    resources: ResourceGroup  # Resource type

Key Explanations:

  • create: Whether to create this resource group (true/false).
  • name: Resource group name, following a consistent naming convention.
  • description: Brief summary of the group’s purpose.
  • tags: Metadata for governance, cost allocation, and management.

Security Resource Group

Purpose:
Contains security-related resources including Key Vaults for secret management, Microsoft Defender for Cloud configurations, Network Security Groups, and private endpoints.

Best Practice:
Isolate security resources to apply stricter access controls and enable separate monitoring/auditing of security components.

YAML Representation:

security:
  create: true
  name: devexp-security
  description: prodExp
  tags:
    environment: dev
    division: Platforms
    team: DevExP
    project: Contoso-DevExp-DevBox
    costCenter: IT
    owner: Contoso
    landingZone: Workload
    resources: ResourceGroup

Key Explanations:
Same structure as workload, but dedicated to security assets for stricter access and monitoring.

Monitoring Resource Group

Purpose:
Contains monitoring and observability resources including Log Analytics workspaces, Application Insights components, Azure Monitor alerts and action groups, and dashboard/reporting resources.

Best Practice:
Centralize monitoring resources to provide a unified view of operational health and simplify diagnostic activities.

YAML Representation:

monitoring:
  create: true
  name: devexp-monitoring
  description: prodExp
  tags:
    environment: dev
    division: Platforms
    team: DevExP
    project: Contoso-DevExp-DevBox
    costCenter: IT
    owner: Contoso
    landingZone: Workload
    resources: ResourceGroup

Key Explanations:
Enables unified operational health monitoring and diagnostics.

Examples and Use Cases

Example: Deploying Dev Box Resources

Suppose you want to deploy a new Dev Box environment for the “Contoso-DevExp-DevBox” project in a development environment:

  • Workload group will host Dev Box definitions and pools.
  • Security group will contain Key Vaults for secrets used by Dev Box VMs.
  • Monitoring group will centralize logs and metrics for all Dev Box resources.
  • Connectivity group will manage VNets and NSGs for secure access.

Sample Usage in a Deployment Pipeline:

# Pseudocode for pipeline step
- task: AzureResourceManagerTemplateDeployment
  inputs:
    resourceGroupName: $(workload.name)
    templateLocation: 'Linked artifact'
    csmFile: 'devboxTemplate.json'
    deploymentMode: 'Incremental'

This ensures resources are deployed into the correct, pre-defined groups.

Best Practices

  • Consistent Naming:
    Use a standard naming convention for resource groups (e.g., [project]-[purpose]-[environment]-rg) to simplify management and automation.

  • Tagging:
    Apply consistent tags across all resource groups for effective cost tracking, ownership, and compliance.

  • Separation of Concerns:
    Segregate resources by function (workload, security, monitoring) to enable independent scaling, access control, and lifecycle management.

  • Workload Group:
    Separate application workloads from infrastructure components for flexibility and easier management.

  • Security Group:
    Isolate security resources to apply stricter access controls and enable separate monitoring/auditing.

  • Monitoring Group:
    Centralize monitoring resources to provide a unified view of operational health and simplify diagnostics.

  • Adapt for Environments:
    Duplicate or adjust sections for different environments (dev, test, prod) by changing the environment tag and resource group names.

  • Documentation:
    Keep descriptions up to date to reflect the actual purpose of each group, aiding onboarding and audits.

  • Automation:
    Integrate this YAML into your Infrastructure as Code (IaC) pipelines to automate resource group creation and tagging.

References:

Last modified July 3, 2025: update Resource Organization doc (060355e)