Was sind Tags?

Ein Tag ist ein Schlüssel-Wert-Paar, das auf eine Ressource angewendet wird und Metadaten zu dieser Ressource enthält. Jedes Tag ist ein Label, das aus einem Schlüssel und einem optionalen Wert besteht. Derzeit unterstützen nicht alle Dienste und Ressourcentypen Tags (siehe Dienste, die die Resource Groups Tagging API unterstützen). Andere Dienste unterstützen möglicherweise Tags über ihre eigenen APIs. Es ist zu beachten, dass Tags nicht verschlüsselt sind und nicht zum Speichern sensibler Daten (PII) verwendet werden sollten (z. B. personenbezogene Informationen (PII)).

Tags, die ein Benutzer mithilfe derAWS CLI, API oder der erstellt und auf AWS Ressourcen anwendet, AWS Management Console werden als benutzerdefinierte Tags bezeichnet. Verschiedene AWS DiensteAWS CloudFormation, wie Elastic Beanstalk und Auto Scaling, weisen Ressourcen, die sie erstellen und verwalten, automatisch Tags zu. Diese Schlüssel werden als AWSgenerierte Tags bezeichnet und haben in der Regel ein Präfix. aws Dieses Präfix kann nicht in benutzerdefinierten Tag-Schlüsseln verwendet werden.

Es gibt Nutzungsanforderungen und Beschränkungen für die Anzahl der benutzerdefinierten Tags, die einer AWS Ressource hinzugefügt werden können. Weitere Informationen finden Sie unter Beschränkungen und Anforderungen für die Benennung von Tags im AWSAllgemeinen Referenzhandbuch. AWSgenerierte Tags werden nicht auf diese benutzerdefinierten Tag-Limits angerechnet.

Tabelle 1 — Beispiele für benutzerdefinierte Tag-Schlüssel und -Werte

Instance-ID	Tag-Schlüssel	Tag-Wert
i-01234567abcdef89a	CostCenter	98765
	Stack	Test
i-12345678abcdef90b	CostCenter	98765
	Stack	Production

Tabelle 2 — Beispiele für generierte Tags AWS

AWSGenerierte Tag-Schlüssel	Begründung
aws:ec2spot:fleet-request-id	Identifiziert die Amazon EC2 Spot-Instance-Anfrage, mit der die Instance gestartet wurde
aws:cloudformation:stack-name	Identifiziert den AWS CloudFormation Stack, der die Ressource erstellt hat
lambda-console:blueprint	Identifiziert den Blueprint, der als Vorlage für eine AWS Lambda Funktion verwendet wird
elasticbeanstalk:environment-name	Identifiziert die Anwendung, die die Ressource erstellt hat
aws:servicecatalog:provisionedProductArn	Das bereitgestellte Produkt Amazon-Sachname (ARN)
aws:servicecatalog:productArn	Der ARN des Produkts, von dem aus das bereitgestellte Produkt gestartet wurde

AWSgenerierte Tags bilden einen Namespace. In einer AWS CloudFormation Vorlage definieren Sie beispielsweise eine Gruppe von Ressourcen, die zusammen bereitgestellt werden sollen. Dabei stack-name handelt es sich um einen aussagekräftigen Namenstack, den Sie zu ihrer Identifizierung zuweisen. Wenn Sie einen Schlüssel wie untersuchen, können Sie feststellenaws:cloudformation:stack-name, dass der Namespace, der für den Gültigkeitsbereich des Parameters verwendet wird, drei Elemente verwendet: aws die Organisation, cloudformation der Dienst und stack-name der Parameter.

Benutzerdefinierte Tags können auch Namespaces verwenden, und es wird empfohlen, eine Organisations-ID als Präfix zu verwenden. Auf diese Weise können Sie schnell erkennen, ob es sich bei einem Tag um etwas aus Ihrem verwalteten Schema oder um etwas handelt, das durch einen Dienst oder ein Tool definiert ist, das Sie in Ihrer Umgebung verwenden.

Im AWSWhitepaper Establishing Your Cloud Foundation on empfehlen wir eine Reihe von Tags, die implementiert werden sollten. Es ist sehr wahrscheinlich, dass verschiedene Unternehmen unterschiedliche zulässige Muster und unterschiedliche Listen für ein bestimmtes Tag verwenden. Schauen wir uns das Beispiel in Tabelle 3 an:

Tabelle 3 — Derselbe Tag-Schlüssel, unterschiedliche Regeln für die Wertevalidierung

Organisation	Tag-Schlüssel	Validierung von Tag-Werten	Beispiel für einen Tag-Wert
Firma A	CostCenter	5432, 5422, 5499	5432
Firma B	CostCenter	ABC*	ABC123

Wenn sich diese beiden Schemas in unterschiedlichen Organisationen befinden, liegt kein Problem mit Tag-Konflikten vor. Sollten diese beiden Umgebungen jedoch zusammengeführt werden, kann es zu Konflikten zwischen den Namespaces kommen und die Validierung wird komplexer. Dieses Szenario mag unwahrscheinlich erscheinen, aber Unternehmen werden übernommen oder fusioniert, und es gibt andere Szenarien, wie z. B. Kunden, die mit einem Managed Service Provider, einem Spieleverlag oder einem Risikokapitalunternehmen zusammenarbeiten, bei dem Konten verschiedener Organisationen Teil einer gemeinsamen Organisation sind. AWS Durch die Verwendung des Firmennamens als Präfix zur Definition eines eindeutigen Namespaces können diese Probleme vermieden werden, wie in Tabelle 4 dargestellt:

Tabelle 4 — Verwendung von Namespaces in Tag-Schlüsseln

Organisation	Tag-Schlüssel	Validierung von Tag-Werten	Beispiel für einen Tag-Wert
Firma A	company-a:CostCenter	5432, 5422, 5499	5432
Firma B	company-b:CostCenter	ABC*	ABC123

In großen und komplexen Organisationen, in denen Unternehmen regelmäßig erworben und veräußert werden, wird diese Situation häufiger auftreten. Da die Prozesse und Praktiken der neuen Akquisition in der gesamten Gruppe harmonisiert sind, ist die Situation gelöst. Es ist hilfreich, klare Namespaces zu haben, da über die Verwendung der älteren Tags berichtet werden kann und die zuständigen Teams kontaktiert werden können, um das neue Schema zu übernehmen. Ein Namespace kann auch verwendet werden, um einen Geltungsbereich anzugeben oder einen Anwendungsfall oder einen Verantwortungsbereich darzustellen, der auf die Eigentümer der Organisation zugeschnitten ist.

Tabelle 5 — Beispiel für einen Geltungsbereich oder einen Anwendungsfallbereich innerhalb von Tag-Schlüsseln

Anwendungsfall	Tag-Schlüssel	Begründung	Zulässige Werte
Klassifizierung von Daten	example-inc:info-sec:data-classification	Definierter Satz zur Datenklassifizierung im Bereich Informationssicherheit	sensitive, company-confidential, customer-identifiable
Operationen	example-inc:dev-ops:environment	Implementieren Sie die Planung von Test- und Entwicklungsumgebungen	development, staging, quality-assurance, production
Notfallwiederherstellung	example-inc:disaster-recovery:rpo	Definieren Sie das Recovery Point Objective (RPO) für eine Ressource	6h, 24h
Kostenzuweisung	example-inc:cost-allocation:business-unit	Finanzteams benötigen Kostenberichte über die Nutzung und die Ausgaben der einzelnen Teams	corporate, recruitment, support, engineering

Tags sind einfach und flexibel. Sowohl der Schlüssel als auch der Wert des Tags sind Zeichenketten variabler Länge und können einen breiten Zeichensatz unterstützen. Weitere Informationen zu Längen und Zeichensätzen finden Sie unter AWSRessourcen mit Tags versehen in der Allgemeinen Referenz. AWS Bei Tags wird zwischen Groß- und Kleinschreibung unterschieden, was bedeutet, dass costcenter es sich bei costCenter und um unterschiedliche Tagschlüssel handelt. In verschiedenen Ländern kann die Schreibweise eines Wortes unterschiedlich sein, was sich auf Ihre Schlüssel auswirken kann. In den Vereinigten Staaten könnte man einen Schlüssel beispielsweise als definierencostcenter, aber im Vereinigten Königreich costcentre könnte dies bevorzugt werden. Aus Sicht der Ressourcen-Tagging handelt es sich dabei um unterschiedliche Schlüssel. Definieren Sie Rechtschreibung, Groß- und Kleinschreibung und Zeichensetzung als Teil Ihrer Tagging-Strategie. Verwenden Sie diese Definitionen als Referenz für alle, die Ressourcen erstellen oder verwalten. Dieses Thema wird im nächsten Abschnitt ausführlicher behandeltEntwickeln Sie Ihre Tagging-Strategie.