Why Resource Organization Matters

Azure’s hierarchy (Tenant, Management Group, Subscription, Resource Group, Resource) provides the structural foundation for governance, but structure alone does not keep environments manageable. As resource counts grow into the hundreds or thousands, two questions surface repeatedly: “What is this resource for?” and “Who owns it?”

Naming conventions, tagging policies, resource locks, and resource move strategies are the operational tools that make Azure environments navigable, auditable, and cost-trackable. Without them, teams spend increasing amounts of time answering basic questions about their own infrastructure.

Naming Conventions

Why Naming Conventions Matter

Every Azure resource has a name, and most resource names are permanent. Renaming a resource typically means deleting and recreating it, which causes downtime and breaks references from other resources. Getting names right from the start avoids painful rework.

A consistent naming convention lets anyone looking at a resource understand its purpose, environment, region, and ownership without clicking into its properties or checking tags. It also makes resources filterable and searchable in the Azure portal, CLI, and scripts.

Microsoft’s Recommended Naming Pattern

Microsoft’s Cloud Adoption Framework naming convention recommends a pattern of:

<resource-type>-<workload/app>-<environment>-<region>-<instance>

Examples:

Resource Type Abbreviations

Microsoft publishes a recommended list of abbreviations for Azure resource types. Common abbreviations include:

Naming Constraints to Watch

Different Azure resource types have different naming rules. Three constraints cause the most friction:

Storage accounts allow only lowercase letters and numbers, no hyphens, with a maximum of 24 characters. This forces a compressed naming format like stwebappprodeus2001 instead of the hyphenated pattern used elsewhere.

Key Vaults have globally unique names with a 24-character limit. Short abbreviations for region and environment help stay within the limit.

Globally unique names are required for storage accounts, Key Vaults, App Services, SQL Servers, and Cosmos DB accounts. Adding a short random suffix or instance number prevents naming collisions, especially in dev/test environments where multiple instances may coexist.

Naming Convention Red Flags

• No convention at all: Resources named myvm1, test-storage, SqlServer2 become impossible to manage at scale.
• Inconsistent conventions across teams: If one team uses prod and another uses prd for production, automation and filtering break.
• Including information that changes: Avoid encoding team names or project codes that may change during reorganizations. Use tags for volatile metadata instead.
• Not accounting for naming constraints: Designing a convention that produces names exceeding character limits for certain resource types.

Tagging Strategy

What Tags Are

Tags are name-value pairs attached to Azure resources, resource groups, and subscriptions. They provide metadata that is not expressed by the resource’s name, type, or location. Tags are searchable, filterable, and reportable across the entire Azure estate.

Unlike names, tags can be added, changed, and removed without affecting the resource itself. This makes them the right place for metadata that may evolve over time.

Why Tags Matter

Tags serve four primary purposes:

Cost allocation: Azure Cost Management can group, filter, and report costs by tag. Tagging resources with a cost center, department, or project code enables chargeback and showback reporting without custom tooling.

Operations: Tags like environment:production or maintenance-window:sunday-02:00-utc enable automation scripts and runbooks to target specific resource sets. Azure Automation, Azure Functions, and third-party tools can query resources by tag to apply operational actions selectively.

Governance and compliance: Tags like data-classification:confidential or compliance:pci help audit and reporting tools identify resources that fall under specific regulatory requirements.

Ownership and accountability: Tags like owner:team-platform or contact:jane@example.com establish who is responsible for a resource when questions arise during incidents, cost reviews, or decommissioning decisions.

Recommended Tag Taxonomy

A tag taxonomy defines which tags are required, which are optional, and what values are acceptable for each. Start with a small set of required tags and expand as needs emerge.

Recommended required tags:

Recommended optional tags:

Enforcing Tags with Azure Policy

Tags are only useful if they are consistently applied. Azure Policy can enforce tagging requirements at the subscription or management group level.

Common tag enforcement policies:

• Require a tag on resource groups: Denies creation of resource groups missing required tags. Since resource groups are the deployment scope, catching missing tags here prevents untagged resources from being created inside them.
• Inherit a tag from the resource group: Automatically copies a tag from the resource group to every resource created within it. This reduces the tagging burden on individual deployments while ensuring consistency.
• Require a tag on resources: Denies creation of any resource missing required tags. More granular than resource group inheritance but requires every deployment template to include tags.
• Audit resources missing tags: Flags non-compliant resources without blocking creation. Useful during rollout when you want visibility before enforcement.

Enforcement rollout pattern:

1. Start with audit-only policies to identify existing resources missing tags
2. Apply tag inheritance policies so new resources automatically inherit tags from their resource group
3. Enable deny policies on new resource groups to require tags at the deployment scope
4. Gradually tighten enforcement, moving from audit to deny as teams adapt

Tag Inheritance Behavior

Tags do not automatically inherit down the hierarchy. A tag on a subscription does not appear on its resource groups, and a tag on a resource group does not appear on its resources unless an Azure Policy explicitly copies it.

This is an important distinction from how RBAC and Azure Policy assignments work (those do inherit). Tag inheritance requires explicit policy configuration.

Tagging Red Flags

• No tags at all: Resources become unattributable. Cost reviews turn into detective work, and incident response starts with “who owns this?”
• Inconsistent tag names: Environment vs environment vs env vs Env fragments reporting and filtering. Tag names are case-insensitive in Azure, but tag values are case-sensitive. Standardize on lowercase.
• Too many required tags: Every additional required tag slows down provisioning and increases the chance of non-compliance. Start with four to five required tags and add more only when justified by a specific reporting or governance need.
• Free-text values without validation: If cost-center accepts any string, you will end up with cc-1234, CC1234, cost center 1234, and engineering all representing the same thing. Use Azure Policy’s allowedValues to constrain values where practical.
• Not tagging resource groups: Even with tag inheritance policies, the resource group itself needs tags. Many cost reports and governance dashboards operate at the resource group level.

Resource Locks

What Resource Locks Do

Resource locks prevent accidental modification or deletion of Azure resources. They apply regardless of RBAC permissions, which means even a user with Owner role on a resource cannot delete it if a CanNotDelete lock is in place (unless they first remove the lock).

Lock Types

Lock Scope and Inheritance

Locks can be applied at the subscription, resource group, or individual resource level. Locks applied at a higher scope inherit downward:

• A lock on a subscription applies to all resource groups and resources within it
• A lock on a resource group applies to all resources within it
• A lock on an individual resource applies only to that resource

When to Use Locks

CanNotDelete locks are appropriate for production resource groups and critical shared resources like hub VNets, DNS zones, ExpressRoute circuits, Log Analytics workspaces, and Key Vaults. These are resources where accidental deletion would cause significant outages or data loss.

ReadOnly locks are appropriate for resources that should never be modified after deployment, such as policy-managed resources or audit infrastructure. Use ReadOnly locks sparingly because they block legitimate updates like scaling operations, configuration changes, and even some diagnostic settings modifications.

Lock Management Considerations

Locks protect against accidents, not malice. Anyone with sufficient RBAC permissions (Owner or User Access Administrator plus the lock management permission) can remove a lock. The value of locks is that they add a deliberate step between “I want to delete this” and “it’s deleted,” preventing fat-finger mistakes.

Automation pipelines (Bicep, Terraform, CI/CD) need to account for locks. A pipeline that deploys to a locked resource group may fail on operations the lock blocks. The pipeline should either remove and reapply locks around deployments or target individual resources rather than wholesale resource group operations.

Lock Red Flags

• No locks on production resources: Critical production resources are one accidental deletion away from an outage.
• ReadOnly locks on resources that need updates: ReadOnly locks block legitimate operations like auto-scaling, backup configuration changes, and diagnostic settings updates. Use CanNotDelete instead for most production resources.
• Locks without documented ownership: If no one knows who applied a lock or why, removing it during an incident becomes a stressful guessing game. Document lock purpose in a tag or operations wiki.

Resource Moves

Moving Resources Between Resource Groups

Azure supports moving resources between resource groups within the same subscription or across subscriptions within the same tenant. This is useful when resource group organization needs to change, workloads are being consolidated, or resources were provisioned in the wrong group.

Move Support Varies by Resource Type

Not all Azure resources support moves. Before planning a move, check the move support matrix for each resource type involved.

Resources that commonly support moves:

• Virtual Machines (with constraints around availability sets and managed disks)
• Storage Accounts
• SQL Databases and Servers
• App Services and App Service Plans (within the same geographic region)
• Key Vaults
• Virtual Networks (if no dependent resources block the move)

Resources that commonly do not support moves or have significant restrictions:

• Azure Kubernetes Service (AKS) clusters
• Application Gateway
• Azure Firewall
• ExpressRoute circuits
• Resources with resource locks (locks must be removed before moving)

Cross-Subscription Moves

Moving resources between subscriptions within the same Entra ID tenant is supported for many resource types, but it changes the billing boundary. After a move, charges for the resource appear on the destination subscription’s bill.

Cross-subscription moves also require appropriate RBAC permissions in both the source and destination subscriptions. The user performing the move needs at least Contributor access on the source resource group and Contributor access on the destination resource group.

Move Considerations

• Dependent resources: Some resources have dependencies that must move together. A VM’s managed disks, network interfaces, and public IPs may need to move as a unit.
• Downtime: Most resource moves do not cause downtime, but the resource is locked (cannot be modified) during the move operation. Plan moves during maintenance windows for critical resources.
• Resource IDs change: When a resource moves to a different resource group or subscription, its resource ID changes. Any automation, alerts, dashboards, or RBAC assignments that reference the resource by ID need to be updated.
• Cross-region moves are not supported through the move operation: The move operation changes the resource group or subscription, not the Azure region. To move a resource to a different region, use Azure Resource Mover or redeploy the resource.

Cross-Subscription Resource Access

The Challenge

In a multi-subscription environment, resources in one subscription often need to access resources in another. A web application in sub-webapp-prod might need to reach a database in sub-data-prod or pull secrets from a Key Vault in sub-shared-services. Azure’s hierarchy does not block this by default, but it requires explicit configuration.

Networking Across Subscriptions

VNet Peering connects Virtual Networks across subscriptions within the same tenant. Peered VNets communicate as if they were on the same network, with traffic staying on Microsoft’s backbone. Peering requires network permissions in both subscriptions and is not transitive (if VNet A peers with VNet B and VNet B peers with VNet C, A and C cannot communicate unless they are also peered directly or use a hub-and-spoke topology).

Hub-and-spoke topology centralizes shared networking resources (firewall, VPN gateway, DNS) in a connectivity subscription. Spoke subscriptions peer their VNets with the hub, and all cross-spoke traffic routes through the hub. This is the standard Azure Landing Zone networking pattern.

Private Endpoints allow resources in one subscription to access PaaS services (SQL Database, Storage Account, Key Vault) in another subscription over a private IP address on the VNet. The Private Endpoint creates a network interface in the consuming VNet, and DNS resolution maps the PaaS service’s public hostname to that private IP.

Identity and RBAC Across Subscriptions

RBAC role assignments at the management group level cascade to all subscriptions below, which is the simplest way to grant cross-subscription access. For more granular control, assign roles directly on the target resource or resource group in the other subscription.

Managed Identities are the recommended way for Azure resources to authenticate to other Azure resources, including resources in different subscriptions. A Managed Identity assigned to an App Service in sub-webapp-prod can be granted a role on a Key Vault in sub-shared-services without any secrets or credentials.

Shared Services Patterns

A shared services subscription (sometimes called a “platform” subscription in the Landing Zone model) hosts resources consumed by multiple workload subscriptions:

• Networking hub: Hub VNet with Azure Firewall, VPN Gateway, and DNS zones
• Monitoring: Central Log Analytics workspace that collects logs and metrics from all subscriptions
• Container Registry: Shared Azure Container Registry for container images used across workloads
• Key Vault: Centralized secrets, certificates, and encryption keys accessed by multiple applications
• DNS: Private DNS Zones for name resolution across all VNets

Workload subscriptions (the “spokes”) access shared resources through VNet peering, Private Endpoints, and RBAC role assignments on the shared resources.

Cross-Tenant Access

For scenarios involving multiple Entra ID tenants (acquisitions, partner organizations, managed service providers), Azure Lighthouse enables delegated resource management. Lighthouse allows users in one tenant to manage resources in another tenant without switching directories, with fine-grained RBAC controlling what they can do.

Governance Automation

Azure Policy for Organization

Beyond tag enforcement, Azure Policy helps maintain organizational standards:

• Allowed locations: Restrict which Azure regions resources can be deployed to, ensuring compliance with data residency requirements
• Allowed resource types: Prevent creation of resource types that are not approved for the environment (no VMs in a serverless-only subscription, for example)
• Naming convention enforcement: Custom policies can validate that resource names match expected patterns, though this requires regex-based policy rules
• Require resource group tags before resource creation: Ensures the organizational metadata exists at the deployment scope before resources are provisioned

Azure Resource Graph

Azure Resource Graph enables querying resources across all subscriptions in a tenant using a SQL-like query language (Kusto Query Language). It is the primary tool for answering fleet-wide organizational questions:

• “Which resources are missing the owner tag?”
• “How many VMs are running in each subscription?”
• “Which resources were created in the last 7 days?”
• “Which storage accounts are not using HTTPS-only?”

Resource Graph queries return results in seconds across thousands of resources, making it far faster than iterating through resources via the ARM API. It integrates with Azure Workbooks for dashboards and can trigger alerts when query results change.

Key Takeaways

• Naming conventions should be established before the first resource is deployed. Names are permanent for most Azure resources, so changes mean deletion and recreation.
• Follow Microsoft’s recommended naming pattern of <type>-<workload>-<environment>-<region>-<instance> and account for resource-specific constraints like storage account character limits.
• Tags provide the metadata layer that names cannot: cost allocation, ownership, compliance classification, and operational context. Enforce required tags with Azure Policy, starting with audit mode and graduating to deny.
• Resource locks prevent accidental deletion of critical resources. Use CanNotDelete for production resources and reserve ReadOnly for truly immutable infrastructure.
• Resource moves between resource groups and subscriptions are supported for many resource types but not all. Always check the move support matrix and plan for resource ID changes.
• Cross-subscription access works through VNet peering, Private Endpoints, RBAC role assignments, and Managed Identities. A shared services subscription centralizes resources consumed by multiple workloads.
• Azure Resource Graph provides fleet-wide visibility across all subscriptions, enabling organizational governance queries that would otherwise require manual inspection.