Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update Rule “azure-naming-resource-groups/rule” #10022

Merged
Show file tree
Hide file tree
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 10 additions & 2 deletions rules/azure-naming-resource-groups/rule.md
Original file line number Diff line number Diff line change
@@ -1,7 +1,9 @@
---
seoDescription: Learn how to effectively organize your Azure resources using logical resource groups named consistently across environments for clarity and efficiency.
type: rule
title: Resource Groups - Do you know how to arrange your Azure resources?
seoDescription: Learn how to effectively organize your Azure resources using
logical resource groups named consistently across environments for clarity and
efficiency.
uri: azure-naming-resource-groups
authors:
- title: Adam Cogan
Expand Down Expand Up @@ -35,6 +37,8 @@ Name your Resource Groups as **Product.Environment**. For example:

There are no cost benefits in consolidating Resource Groups, so use them! Have a Resource Group per product, per environment. And most importantly: **be consistent in your naming convention**.

**Remember it's difficult to change a resource group name once everything is deployed without downtime**

<!--endintro-->

### Keep your resources in logical, consistent locations
Expand All @@ -55,7 +59,7 @@ There's nothing worse than opening up a Resource Group and finding several insta

### Don't categorize Resource Groups based on resource type

There is no cost saving to group resources of the same type together. For example, there is no reason to put all your databases in one place. It is better to provision the database in the same resource group as the application that uses it.
There is no inherent cost-saving benefit to grouping resources of the same type together unless they share underlying infrastructure. For example, consolidating all databases into a single SQL Server can reduce costs, as can hosting multiple apps under a single App Service Plan. However, arbitrarily placing all resources of the same type in one location—without considering dependencies—does not save money. Instead, it is best to provision resources in the same resource group as the applications that use them for better management and alignment with their lifecycle.

::: bad
![Figure: Bad example - SSW.SQL has all the Databases for different apps in one place](arrange-azure-resources-bad.jpg)
Expand All @@ -64,3 +68,7 @@ There is no cost saving to group resources of the same type together. For exampl
::: good
![Figure: Good example (for all the above) - Resource Group contains all staging resources for this product](rg-good.png)
:::

::: good
![Figure: Adding underlying infrastructure to the same Resource Group can save $](screenshot-2025-03-18-080729.png)
:::
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading