Naming and Tags

Names created by the platform

Item	Pattern
Subscription	The name set in the spoke request, or the platform's naming template (for example sub-<workload>-<env>)
Spoke resource group	rg-canvas-<workload>-<env>-<region>-001 (can be overridden in the spoke JSON)
Spoke service principal	SPN-SPOKE-<workload>-<env>
VNet, subnets, NSGs	The names in your request. Placeholders ##wlshortname##, ##environment##, ##region## are replaced.
Spoke groups	From the platform's naming template
Azure DevOps repository and service connection (optional)	Set in the azdo block of the spoke JSON, with the same placeholders (Spoke JSON reference)

The workload short name (max 6 characters) and the environment are part of all these names and of the platform state. They can't change afterwards (Limits).

Names for your own resources

Use a consistent convention in your workload. A common one follows the Microsoft Cloud Adoption Framework:

<resource type>-<workload or identifier>-<environment>-<region>-<instance>, for example rg-app1-prd-weu-001.

Component	Meaning	Examples
Resource type	Abbreviation of the resource type	rg, vnet, vm, log, kv, st
Workload / identifier	Your application or service	invprt, app1
Environment	Lifecycle stage	dev, tst, acc, prd
Region	Short region code	weu, neu
Instance	Counter	001

Key points:

• Key Vault and storage account names have strict limits: at most 24 characters, and storage accounts allow no hyphens. Drop the separators for these (for example kvinvprtprdweu001, stinvprtprdweu001).
• Use the same convention within one workload. If you must deviate, document the reason in the workload.
• Your organisation's own convention wins. Ask the platform team whether one is mandatory and whether a policy enforces it.
• If a workload needs a different convention, keep all five components, deviate as little as possible, stay consistent inside the workload (one convention, not several) and document the deviation and the reason in the workload.
• Name dependent resources after their parent so they stay together: a network interface nic-<vm name>, an OS disk dsk-os-<vm name>, a data disk dsk-data-<vm name>-<n>.
• In Terraform you can generate names from one convention with the public Azure naming module.

Environment and region codes

Use short, fixed codes so names stay short and sort well. A common set:

Environment	Code
Production	prd
Acceptance	acc
Test	tst
Development	dev

Region	Code
West Europe	weu
North Europe	neu

The platform's region short names come from your configuration (active_regions). Use the same codes for your own resources. Some resources are not tied to a region (a subscription, for example): leave the region out for them.

Name limits you run into

The most common limits. Check Microsoft Learn for the current rules of every resource type.

Resource	Length	Characters	Consequence
Storage account	3-24	Lowercase letters and numbers only	No hyphens
Key Vault	3-24	Letters, numbers and hyphens	Drop the separators in longer names
Container registry	5-50	Letters and numbers only	No hyphens
Resource group	1-90	Letters, numbers, hyphens, underscores
Log Analytics workspace	4-63	Letters, numbers, hyphens
Virtual network	2-64	Letters, numbers, hyphens, underscores

Because the region code and instance number take up space, a short workload name keeps the 24-character names possible.

Tags

Tags are required on the subscription and the platform resources, and are used for cost allocation and ownership.

Tag	Meaning	Who sets it
owner	The team responsible	You supply, the platform applies from the spoke JSON
department	Responsible department	You supply
workload	The workload	You supply
pii	yes or no: personal data	You supply
costcentre	Who pays	You supply
environment	dev, tst, acc, prd	You supply

Also add tags to your own resources so that costs and ownership stay visible, at least the same set. Your platform may add a policy that requires or inherits tags (check Policy → Assignments), and some organisations add more tags (for example contact address, data classification, business criticality).

Why tags

Use	Example
Cost allocation and optimisation	Charge costs to a department, project or cost centre; find what to optimise
Ownership and lifecycle	Know who is responsible and when a resource should end
Security and compliance	Mark sensitivity and which requirements apply, for audits
Automation	Policies and monitoring rules that act on tags (see Monitoring rules)
Search and reporting	Filter in the portal, build reports per team

Extended tag set (optional)

Some organisations add more tags. These are examples, grouped by purpose. Which ones are required, and how they are enforced, is set by your platform's tag policy.

Group	Tag	Meaning
Accounting	approver, budgetamount, costcentre, startdate, enddate	Who approves cost, the budget, who pays, planned start and end of the workload
Partnership	owner, requester, stakeholders, businessowner, technicalowner, financialowner	The people related to or affected by the workload
Classification	businesscriticality, serviceclass, confidentiality, integrity, availability, rpo, rto, mtpd	How important the workload is, which support level it gets, its classification (Security classification)
Functional	landingzonetype, applicationname, tier, environment	What the resource is for and where it runs

Use a service class (for example Dev, Bronze, Silver, Gold) to tell which support level applies to a subscription. Use business criticality (for example Mission critical, Critical, Essential) for impact. Pick one set of values for the organisation and document them.

Tag inheritance: tags set on the subscription are not automatically on its resources. If your organisation requires tags on resources, a policy that inherits or requires them does that (check Policy → Assignments).

Ask for a tag change through How to change when ownership or cost centre changes.