Skip to content

Commit 28f7981

Browse files
bug fix
Updated image source for Azure tags resource group diagram.
1 parent ba78f07 commit 28f7981

1 file changed

Lines changed: 1 addition & 1 deletion

File tree

learn-pr/wwl-azure/implement-security-controls-azure-ai-ready-infrastructure/includes/3-implement-azure-governance-scopes-ai-resources.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -12,7 +12,7 @@ Building on this concept, resource groups provide your next level of organizatio
1212

1313
At the same time, resource groups establish cost tracking boundaries. Azure tags each resource with its parent resource group, enabling you to generate monthly reports showing exactly how much the sentiment analysis project costs. When your finance team asks "How much did we spend on AI infrastructure last quarter?", you filter costs by resource group tags rather than manually correlating dozens of individual resource charges. This becomes especially important when your AI platform scales to support multiple projects—without resource group organization, cost attribution becomes nearly impossible. Organizations that implement consistent resource group naming conventions (for example, "rg-[project-name]-[environment]") report 60-80% faster budget reconciliation compared to ad-hoc resource naming.
1414

15-
:::image type="content" source="../media/azure-tags-resource-resource-group.png" alt-text="Diagram showing how Azure tags each resource with its parent resource group.":::
15+
:::image type="content" source="../media/azure-tags-resource-group.png" alt-text="Diagram showing how Azure tags each resource with its parent resource group.":::
1616

1717
However, this changes when you have shared infrastructure that multiple projects depend on. Your AI platform likely includes centralized services like a common Azure Container Registry for model images, a shared Azure Key Vault for secrets, and enterprise-wide networking components. These shared resources belong in their own "shared-services" resource group, separate from project-specific groups. This pattern—often called the hub-and-spoke model—places shared infrastructure in a hub resource group with delegated access policies, while project workloads live in spoke resource groups with more permissive experimentation policies. As you see when we explore the Microsoft Foundry Account pattern, this separation simplifies both security management and cost chargeback.
1818

0 commit comments

Comments
 (0)