Azure Resource Groups and How to Use Them

Azure Resource Groups are a fundamental component in Microsoft's cloud platform. They're logical containers, similar to folders on your desktop or laptop, which group resources such as virtual machines, databases, and storage accounts. They help organise management, monitoring, and access control of Azure resources from deployment to decommissioning.

Key Features of Azure Resource Groups

Unified Management

If you group resources that share the same lifecycle, you can streamline deployment, monitoring, and management.

For example, a Web App Service consists of at least two key components:

Web App Service Plan: Determines the compute power for the service.
Website: Runs on the service plan and can be updated or replaced frequently.

Since the Web App Service Plan remains fairly static while the website undergoes frequent changes, it's best to place them in separate resource groups. This ensures that:

Only the website is modified, while the service plan remains stable.
Access control is refined, allowing different users permissions for different groups.
Protection measures like locks can be applied to prevent accidental deletions of critical components.

Access Control

Implement role-based access control (RBAC) at the resource group level to define permissions and ensure security.

Applying the example above, access permissions can be granted separately for the Web App Service Plan and the website itself. This allows fine-grained control over who can modify or manage different components of the application.

Cost Management

Track and manage costs effectively by grouping resources based on their purpose or ownership.

For example:

Application-Based Grouping: If an application consists of a database, virtual machines, and a storage account, placing them in the same resource group simplifies cost tracking and budgeting.

However, this approach can have downsides when applied to application-based grouping:

Limited Flexibility: Some resources, like databases, may need to persist beyond application updates, making it restrictive to manage everything in one group.
Access Control Complexity: Different teams might manage different resources (e.g., a development team for applications and a database team for data management), leading to challenges in applying granular permissions.
Potential for Accidental Deletion: Deleting the resource group removes all contained resources, which can be problematic if certain components need to remain intact while others are replaced or modified separately.

Carefully considering these factors when applying application-based grouping ensures that resource management remains efficient and aligned with operational needs.

Department-Based Grouping: An organisation with finance, HR, and IT departments can assign separate resource groups for each department, enabling better cost management and visibility.

For example, the finance department might have virtual machines for payroll processing, HR might have databases for employee records, and IT might manage networking and security infrastructure. By grouping these resources separately, each department can track usage and expenses more effectively.

However, there are some downsides to this approach:

Cross-Department Collaboration Challenges: If multiple departments rely on shared resources, strict separation may introduce inefficiencies.
Overhead in Management: Maintaining multiple resource groups for different departments can increase administrative complexity.
Inconsistent Policies: If governance policies are not centrally enforced, departments might implement different security and access rules, leading to potential compliance issues.

This structured approach helps allocate budgets more efficiently and prevents unexpected expenses.

Location of Resource Groups

The location of a resource group determines where its metadata is stored. This metadata includes:

Deployment History: Tracks changes and updates to resources within the group.
Role Assignments: Defines which users or groups have permissions to manage the resources.
Resource Locks and Policies: Ensures compliance with organisational security and governance rules.

While resources within a group can be spread across multiple Azure regions, the resource group's metadata—such as deployment history, role assignments, and policies—is stored in the specified location of the resource group.

Key Considerations:

Compliance & Data Residency: Storing metadata in a designated region ensures compliance with data sovereignty requirements.
Performance: Deployment and management operations can be affected by the location of the metadata.

Regional Placement & Resource Group Behaviour:

Resources do not inherit the region of the resource group. Each resource’s region must be explicitly set during deployment.
A single resource group can include resources from multiple regions, allowing flexibility in global deployments.
However, administrative and operational metadata remains in one region, which can impact regulatory compliance and performance efficiency in distributed setups.

Selecting the right location for the resource group is crucial for ensuring both performance and adherence to governance policies.

This sounds great I can seriously organise my resources! But what if I need to structure them even further?

Unfortunately, Azure does not support nested resource groups. Each resource must belong to a single, non-hierarchical resource group.

If you need hierarchical organisation, consider using Azure Management Groups. These allow you to organise multiple subscriptions under a structured governance model.

Management Groups operate at a higher level than Resource Groups and are useful for:

Enforcing policies across multiple subscriptions
Managing access control at scale
Streamlining governance for large environments

While resource groups provide great flexibility, for more structured and large-scale organisation, Management Groups are the way to go.

Guidelines for Grouping Resources

Organising resources within Azure Resource Groups should align with your organisation's structure and operational requirements. Consider the following approaches:

By Application or Service

All resources related to a specific application should be grouped together, facilitating cohesive management and deployment.

As mentioned earlier, a customer-facing web application may include a database, virtual machines, and a storage account. Keeping these resources in the same resource group makes deployment and cost tracking easier.

However, as mentioned earlier, this approach has some downsides:

Limited Flexibility: If certain components, such as the database, need to persist beyond application updates, keeping everything in one group can be restrictive.
Access Control Complexity: Different teams might manage different components (e.g., developers handling VMs while the database team manages storage), making granular permissions harder to enforce.
Potential for Accidental Deletion: Deleting the resource group removes all resources inside it, which can lead to unintended data loss if not managed carefully.

This method works best when the application has a short lifecycle or is frequently redeployed as a unit.

By Environment

Separate resources based on environments such as development, testing, and production to maintain isolation and control.

This should be used alongside other approaches rather than as a standalone method.
It also allows you to restrict access to a production set of resources that should only be accessible to a certain group of users.

For example, an e-commerce platform may have a dev, test, and prod environment, each placed within separate resource groups.

To ensure the security and stability of the production environment:

Resource locks can prevent accidental deletions.
RBAC controls can restrict access only to authorised personnel, ensuring only approved users can make modifications.

This approach combines elements from other grouping strategies, providing both security and structured access control while allowing controlled operations as needed.