Design for resource groups
Resource groups are logical containers into which Azure resources are deployed and managed. These resources can include web apps, databases, and storage accounts. You can use resource groups to:
Place resources of similar usage, type, or location in logical groups.
Organize resources by life cycle so all the resources can be created or deleted at the same time.
Apply role permissions to a group of resources or give a group access to administer a group of resources.
Use resource locks to protect individual resources from deletion or change.
Things to know about resource groups
As you plan the governance strategy for Tailwind Traders, consider these characteristics of resource groups:
Resource groups have their own location (region) assigned. This region is where the metadata is stored.
If the resource group's region is temporarily unavailable, you can't update resources in the resource group because the metadata is unavailable. The resources in other regions still function as expected, but you can't update them.
Resources in the resource group can be in different regions.
A resource can connect to resources in other resource groups. You can have a web application that connects to a database in a different resource group.
Resources can be moved between resource groups with some exceptions.
You can add a resource to or remove a resource from a resource group at any time.
Resource groups can't be nested.
Each resource must be in one, and only one, resource group.
Resource groups can't be renamed.
Things to consider when creating resource groups
Tailwind Traders has two Azure-based applications (App1 and App2). Each application has a web service with SQL database, virtual machines, and storage. You need to decide how to organize the resource groups for Tailwind Traders.
Consider group by type. Group resources by type for on-demand services that aren't associated with an app. For Tailwind Traders, you can have a resource group for the SQL databases (SQL-RG) and a separate resource group (WEB-RG) for the web services.
Consider group by app. Group resources by app when all resources have the same policies and life cycle. This method can also be applied to test or prototype environments. For Tailwind Traders, App1 and App2 can have separate resource groups. Each group can have all the resources for the specific application.
Consider group by department, group by location (region), and group by billing (cost center). Review other grouping strategies that aren't common but might be useful in your situation.
Consider a combination of organizational strategies. Don't restrict your Tailwind Traders strategy to using only a single resource group option. A combination of options is best.
Consider resource life cycle. Design your resource groups according to life cycle requirements. Do you want to deploy, update, and delete certain resources at the same time? If so, place these resources in the same resource group.
Consider administration overhead. Include overhead planning in your strategy. How many resource groups would you like to manage? Does Tailwind Traders have centralized or decentralized Azure administrators?
Consider resource access control. Implement access control for your resource groups. At the resource group level, you can assign Azure policies, Azure roles, and resource locks. Resource locks prevent unexpected changes to critical resources.
Consider compliance requirements. Plan to build in support for compliance in your Tailwind Traders strategy. Do you need to ensure your resource group metadata is stored in a particular region?