Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
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 eine Bezeichnung, die 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 sollte beachtet werden, dass Tags nicht verschlüsselt sind und nicht zum Speichern sensibler Daten wie personenbezogener Daten (PII) verwendet werden sollten.
Tags, die ein Benutzer mithilfe der AWS CLI, API oder der erstellt und auf AWS Ressourcen anwendet, AWS Management Console werden als benutzerdefinierte Tags bezeichnet. Verschiedene AWS Dienste AWS CloudFormation, wie Elastic Beanstalk und Auto Scaling, weisen Ressourcen, die sie erstellen und verwalten, automatisch Tags zu. Diese Schlüssel werden als AWS generierte 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 AWS Allgemeinen Referenzhandbuch. AWS generierte 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
AWS Generierte 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 Resource Name (ARN) |
aws:servicecatalog:productArn |
Der ARN des Produkts, von dem aus das bereitgestellte Produkt gestartet wurde |
AWS generierte 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 AWS Whitepaper 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 AWS
Ressourcen 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 behandelt,Entwickeln Sie Ihre Tagging-Strategie.