Namensgebung und Tags¶

Von der Plattform erstellte Namen¶

Element	Muster
Subscription	Der in der Spoke-Anfrage angegebene Name oder das Namenstemplate der Plattform (zum Beispiel `sub-<workload>-<env>`)
Spoke resource group	`rg-canvas-<workload>-<env>-<region>-001` (kann im Spoke-JSON überschrieben werden)
Spoke Service Principal	`SPN-SPOKE-<workload>-<env>`
VNet, Subnets, NSGs	Die Namen aus deiner Anfrage. Die Platzhalter `##wlshortname##`, `##environment##`, `##region##` werden ersetzt.
Spoke-Gruppen	Aus dem Namenstemplate der Plattform
Azure DevOps Repository und Service Connection (optional)	Im Block `azdo` des Spoke-JSON festgelegt, mit denselben Platzhaltern (Spoke-JSON-Referenz)

Der Workload-Kurzname (max. 6 Zeichen) und die Umgebung sind Teil aller dieser Namen und des Plattform-state. Sie können danach nicht mehr geändert werden (Einschränkungen).

Namen für deine eigenen Ressourcen¶

Verwende in deinem Workload eine einheitliche Konvention. Eine gängige folgt dem Microsoft Cloud Adoption Framework:

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

Komponente	Bedeutung	Beispiele
Ressourcentyp	Abkürzung des Ressourcentyps	`rg`, `vnet`, `vm`, `log`, `kv`, `st`
Workload / Bezeichner	Deine Anwendung oder dein Service	`invprt`, `app1`
Umgebung	Lebenszyklusphase	`dev`, `tst`, `acc`, `prd`
Region	Kurzer Regionscode	`weu`, `neu`
Instanz	Zähler	`001`

Wichtige Punkte:

Namen von Key Vaults und Storage Accounts haben strenge Grenzen: höchstens 24 Zeichen, und Storage Accounts erlauben keine Bindestriche. Lass bei diesen die Trennzeichen weg (zum Beispiel kvinvprtprdweu001, stinvprtprdweu001).
Verwende innerhalb eines Workloads dieselbe Konvention. Wenn du abweichen musst, dokumentiere den Grund im Workload.
Die Konvention deiner Organisation hat Vorrang. Frag das Plattform-Team, ob eine verpflichtend ist und ob eine Policy sie erzwingt.
Wenn ein Workload eine andere Konvention braucht, behalte alle fünf Komponenten bei, weiche so wenig wie möglich ab, bleibe innerhalb des Workloads konsistent (eine Konvention, nicht mehrere) und dokumentiere die Abweichung und den Grund im Workload.
Benenne abhängige Ressourcen nach ihrer übergeordneten Ressource, damit sie zusammenbleiben: eine Netzwerkschnittstelle nic-<vm name>, ein OS-Disk dsk-os-<vm name>, ein Daten-Disk dsk-data-<vm name>-<n>.
In Terraform kannst du Namen aus einer Konvention mit dem öffentlichen Azure-naming-Modul generieren.

Umgebungs- und Regionscodes¶

Verwende kurze, feste Codes, damit Namen kurz bleiben und gut sortierbar sind. Ein gängiger Satz:

Umgebung	Code
Produktion	`prd`
Abnahme	`acc`
Test	`tst`
Entwicklung	`dev`

Region	Code
West Europe	`weu`
North Europe	`neu`

Die Kurznamen der Regionen der Plattform stammen aus deiner Konfiguration (active_regions). Verwende dieselben Codes für deine eigenen Ressourcen. Manche Ressourcen sind nicht an eine Region gebunden (zum Beispiel eine subscription): Lass bei ihnen die Region weg.

Namensgrenzen, auf die du stößt¶

Die häufigsten Grenzen. Prüfe die aktuellen Regeln jedes Ressourcentyps auf Microsoft Learn.

Ressource	Länge	Zeichen	Konsequenz
Storage Account	3-24	Nur Kleinbuchstaben und Zahlen	Keine Bindestriche
Key Vault	3-24	Buchstaben, Zahlen und Bindestriche	Lass bei längeren Namen die Trennzeichen weg
Container Registry	5-50	Nur Buchstaben und Zahlen	Keine Bindestriche
Resource Group	1-90	Buchstaben, Zahlen, Bindestriche, Unterstriche
Log Analytics workspace	4-63	Buchstaben, Zahlen, Bindestriche
Virtual Network	2-64	Buchstaben, Zahlen, Bindestriche, Unterstriche

Da Regionscode und Instanznummer Platz brauchen, ermöglicht ein kurzer Workload-Name Namen mit 24 Zeichen.

Tags¶

Tags sind auf der Subscription und den Plattform-Ressourcen erforderlich und dienen der Kostenzuordnung und der Zuordnung von Verantwortlichkeiten.

Tag	Bedeutung	Wer setzt ihn
`owner`	Das verantwortliche Team	Du lieferst ihn, die Plattform wendet ihn aus dem Spoke-JSON an
`department`	Verantwortliche Abteilung	Du lieferst ihn
`workload`	Der Workload	Du lieferst ihn
`pii`	`yes` oder `no`: personenbezogene Daten	Du lieferst ihn
`costcentre`	Wer bezahlt	Du lieferst ihn
`environment`	`dev`, `tst`, `acc`, `prd`	Du lieferst ihn

Versieh auch deine eigenen Ressourcen mit Tags, damit Kosten und Verantwortlichkeiten sichtbar bleiben, mindestens mit demselben Satz. Deine Plattform kann eine Policy ergänzen, die Tags verlangt oder vererbt (siehe Policy → Assignments), und manche Organisationen fügen weitere Tags hinzu (zum Beispiel Kontaktadresse, Datenklassifizierung, Geschäftskritikalität).

Wozu Tags¶

Nutzen	Beispiel
Kostenzuordnung und -optimierung	Kosten einer Abteilung, einem Projekt oder einer Kostenstelle zuordnen; erkennen, was optimiert werden kann
Verantwortung und Lebenszyklus	Wissen, wer verantwortlich ist und wann eine Ressource enden soll
Security und Compliance	Sensitivität und geltende Anforderungen für Audits kennzeichnen
Automatisierung	Policies und Monitoring-Regeln, die auf Tags reagieren (siehe Monitoring-Regeln)
Suche und Reporting	Im Portal filtern, Berichte pro Team erstellen

Erweiterter Tag-Satz (optional)¶

Manche Organisationen fügen weitere Tags hinzu. Das hier sind Beispiele, nach Zweck gruppiert. Welche davon verpflichtend sind und wie sie erzwungen werden, legt die Tag-Policy deiner Plattform fest.

Gruppe	Tag	Bedeutung
Accounting	`approver`, `budgetamount`, `costcentre`, `startdate`, `enddate`	Wer die Kosten genehmigt, das Budget, wer bezahlt, geplanter Start und geplantes Ende des Workloads
Partnership	`owner`, `requester`, `stakeholders`, `businessowner`, `technicalowner`, `financialowner`	Die Personen, die mit dem Workload zu tun haben oder davon betroffen sind
Classification	`businesscriticality`, `serviceclass`, `confidentiality`, `integrity`, `availability`, `rpo`, `rto`, `mtpd`	Wie wichtig der Workload ist, welches Supportlevel er erhält, seine Klassifizierung (Sicherheitsklassifizierung)
Functional	`landingzonetype`, `applicationname`, `tier`, `environment`	Wofür die Ressource da ist und wo sie läuft

Verwende eine Service Class (zum Beispiel Dev, Bronze, Silver, Gold), um festzulegen, welches Supportlevel für eine subscription gilt. Verwende die Business Criticality (zum Beispiel Mission critical, Critical, Essential) für die Auswirkung. Wähle einen Satz von Werten für die Organisation und dokumentiere ihn.

Tag-Vererbung: Tags auf der subscription liegen nicht automatisch auf ihren Ressourcen. Wenn deine Organisation Tags auf Ressourcen verlangt, sorgt eine Policy, die sie vererbt oder verlangt, dafür (prüfe Policy → Assignments).

Fordere eine Tag-Änderung über So änderst du an, wenn sich die Verantwortung oder die Kostenstelle ändert.