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. # Entwickeln Sie Ihre Tagging-Strategie Wie bei vielen betrieblichen Praktiken ist die Implementierung einer Tagging-Strategie *ein Prozess der Iteration* und Verbesserung. Fangen Sie klein mit Ihrer unmittelbaren Priorität an und erweitern Sie das Tagging-Schema nach Bedarf. ![\[Diagramm, das eine grafische Darstellung des Iterations- und Verbesserungszyklus der Tagging-Strategie zeigt\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/tagging-best-practices/images/tagging-strategy-cycle.png) Während dieses gesamten Prozesses ist Eigenverantwortung der Schlüssel zu Rechenschaftspflicht und Fortschritt. Da Tags für eine Vielzahl von Zwecken verwendet werden können, kann die gesamte Tagging-Strategie in Verantwortungsbereiche innerhalb einer Organisation aufgeteilt werden. Tagging ermöglicht einen programmatischen Ansatz für Aktivitäten, die von der Charakterisierung der Ressourcen abhängen. Die Anzahl der Interessengruppen, die von der Kennzeichnung profitieren können, hängt von der Größe der Organisation und den betrieblichen Praktiken ab. Größere Organisationen können von einer klaren Definition der Verantwortlichkeiten der Teams profitieren, die an der Entwicklung und Umsetzung einer Tagging-Strategie beteiligt sind. Einige Stakeholder können dafür verantwortlich sein, den Bedarf an Tagging zu ermitteln (Anwendungsfälle zu definieren); andere wiederum können für die Pflege, Implementierung und Verbesserung der Tagging-Strategie verantwortlich sein. Durch die Übertragung der Verantwortung sind Sie in einer guten Position, um einzelne Aspekte der Strategie umzusetzen. Gegebenenfalls kann diese Eigenverantwortung als Richtlinie formalisiert und in einer Verantwortungsmatrix (z. B. RACI: Responsible, Accountable, Consulted, Informed) oder in einem Modell der gemeinsamen Verantwortung dokumentiert werden. In kleineren Organisationen können Teams in einer Tagging-Strategie mehrere Rollen spielen, von der Definition der Anforderungen bis hin zur Implementierung und Durchsetzung. # Definition von Bedürfnissen und Anwendungsfällen Beginnen Sie mit der Entwicklung Ihrer Strategie, indem Sie mit Stakeholdern zusammenarbeiten, die ein grundlegendes Bedürfnis haben, Metadaten zu nutzen. Diese Teams definieren die Metadaten, mit denen Ressourcen gekennzeichnet werden müssen, um ihre Aktivitäten wie Berichterstattung, Automatisierung und Datenklassifizierung zu unterstützen. Sie beschreiben, wie die Ressourcen organisiert werden müssen und welchen Richtlinien sie zugeordnet werden müssen. Zu den Rollen und Funktionen, die diese Interessengruppen in Organisationen haben können, gehören unter anderem: + **Finanzen** und **Geschäftsbereiche müssen den Wert von** Investitionen verstehen, indem sie sie den Kosten zuordnen, um Maßnahmen zu priorisieren, die zur Behebung von Unzulänglichkeiten ergriffen werden müssen. Das Verständnis der *Kosten im Vergleich zum generierten Wert* hilft dabei, erfolglose Geschäftsbereiche oder Produktangebote zu identifizieren. Dies führt zu fundierten Entscheidungen über die Fortsetzung des Supports, die Einführung einer Alternative (z. B. die Nutzung eines SaaS-Angebots oder eines verwalteten Dienstes) oder die Einstellung eines unrentablen Geschäftsangebots. + **Unternehmensführung** und **Compliance** müssen die Kategorisierung von Daten (z. B. öffentlich, sensibel oder vertraulich) verstehen, wissen, ob ein bestimmter Workload anhand eines bestimmten Standards oder einer bestimmten Vorschrift geprüft werden kann oder nicht, und die Wichtigkeit des Dienstes (unabhängig davon, ob der Service oder die Anwendung geschäftskritisch ist), um angemessene Kontrollen und Kontrollen wie Genehmigungen, Richtlinien und Überwachung anwenden zu können. + **Betrieb** und **Entwicklung** müssen den Workload-Lebenszyklus, die Implementierungsphasen ihrer unterstützten Produkte und das Management der Release-Phasen (z. B. Entwicklung, Test, Produktionsaufteilung) sowie die damit verbundenen Support-Priorisierungen und die Anforderungen an das Stakeholder-Management verstehen. Aufgaben wie Backups, Patches, Observability und Deprecation müssen ebenfalls definiert und verstanden werden. + **Informationssicherheit (InfoSec)** und **Sicherheitsoperationen (SecOps)** beschreiben, welche Kontrollen angewendet werden müssen und welche empfohlen werden. InfoSec definiert normalerweise die Implementierung der Kontrollen und SecOps ist im Allgemeinen für die Verwaltung dieser Kontrollen verantwortlich. Abhängig von Ihrem Anwendungsfall, Ihren Prioritäten, der Größe Ihres Unternehmens und den betrieblichen Abläufen benötigen Sie möglicherweise Unterstützung durch verschiedene Teams innerhalb der Organisation, z. B. in den Bereichen Finanzen (einschließlich Beschaffung), Informationssicherheit, Cloud-Aktivierung und Cloud-Betrieb. Für Funktionen wie Patchen, Sicherung und Wiederherstellung, Überwachung, Jobplanung und Disaster Recovery benötigen Sie außerdem die Unterstützung der Anwendungs- und Prozessverantwortlichen. Diese Mitarbeiter unterstützen Sie bei der Definition und Implementierung der Tagging-Strategie und messen deren Wirksamkeit. Sie sollten [https://www.youtube.com/watch?v=aFdpBqmDpzM](https://www.youtube.com/watch?v=aFdpBqmDpzM) Interessengruppen und ihren Anwendungsfällen einen funktionsübergreifenden Workshop durchführen. In dem Workshop haben sie die Möglichkeit, ihre Sichtweisen und Bedürfnisse auszutauschen und zur Entwicklung einer Gesamtstrategie beizutragen. Beispiele von Teilnehmern und ihre Beteiligung an verschiedenen Anwendungsfällen werden später in diesem Whitepaper beschrieben. Die Beteiligten definieren und validieren auch die Schlüssel für obligatorische Tags und können den Geltungsbereich für optionale Tags empfehlen. Beispielsweise müssen Finanzteams eine Ressource möglicherweise einer internen Kostenstelle, einer Geschäftseinheit oder beidem zuordnen. Daher können sie verlangen, dass bestimmte Tag-Schlüssel, wie z. B. `CostCenter` und`BusinessUnit`, verpflichtend sind. Einzelne Entwicklungsteams könnten beschließen, zusätzliche Tags für Automatisierungszwecke zu verwenden, z. B. `EnvironmentName``OptIn`, oder`OptOut`. Die wichtigsten Interessengruppen müssen sich auf den Ansatz der Tagging-Strategie einigen und die Antworten auf Fragen im Zusammenhang mit Compliance und Unternehmensführung dokumentieren, wie z. B.: + Welche Anwendungsfälle müssen angegangen werden? + Wer ist für die Kennzeichnung von Ressourcen verantwortlich (Implementierung)? + Wie werden Tags durchgesetzt und welche Methoden und Automatisierungen werden eingesetzt (proaktiv oder reaktiv)? + Wie werden die Effektivität und die Ziele von Tagging gemessen? + Wie oft sollte die Tagging-Strategie überprüft werden? + Wer treibt Verbesserungen voran? Wie wird das gemacht? Geschäftsfunktionen wie Cloud Enablement, Cloud Business Office und Cloud Platform Engineering können dann eine Rolle als Vermittler bei der Entwicklung der Tagging-Strategie übernehmen, deren Einführung vorantreiben und die Konsistenz der Anwendung sicherstellen, indem sie den Fortschritt messen, Hindernisse beseitigen und Doppelarbeit reduzieren. # Definition und Veröffentlichung eines Tagging-Schemas Verwenden Sie beim Taggen Ihrer AWS Ressourcen einen konsistenten Ansatz, sowohl für obligatorische als auch für optionale Tags. Ein umfassendes Tagging-Schema hilft Ihnen dabei, diese Konsistenz zu erreichen. Die folgenden Beispiele können Ihnen den Einstieg erleichtern: + Vereinbaren Sie die obligatorischen Tag-Schlüssel + Definieren Sie akzeptable Werte und Benennungskonventionen für Tags (Groß- oder Kleinschreibung, Bindestriche oder Unterstriche, Hierarchie usw.) + Bestätigen Sie, dass Werte keine persönlich identifizierbaren Informationen (PII) darstellen + Entscheiden Sie, wer neue Tag-Schlüssel definieren und erstellen kann + Vereinbaren Sie, wie Sie neue obligatorische Tag-Werte hinzufügen und wie optionale Tags verwaltet werden Sehen Sie sich die folgende Tabelle mit den [Tag-Kategorien](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html) an, die als Grundlage dafür dienen kann, was Sie in Ihr Tagging-Schema aufnehmen könnten. Sie müssen noch festlegen, welche Konvention Sie für den Tag-Schlüssel verwenden werden und welche Werte jeweils zulässig sind. Das Tagging-Schema ist das Dokument, in dem Sie dies für Ihre Umgebung definieren. *Tabelle 6 — Beispiel für ein definitives Tagging-Schema* | Anwendungsfall | Tag-Schlüssel | Begründung | Zulässige Werte (Aufgeführt oder Wertpräfix/suλx) | Wird für die Kostenzuweisung verwendet | Ressourcentypen | Scope | Erforderlich | | --- | --- | --- | --- | --- | --- | --- | --- | | Kostenzuweisung | example-inc:cost-allocation:ApplicationId | Verfolgen Sie die Kosten im Vergleich zum in den einzelnen Geschäftsbereichen generierten Wert | DataLakeX, RetailSiteX | Y | Alle | Alle | zwingend erforderlich | | Verteilung der Kosten | example-inc:cost-allocation:BusinessUnitId | Überwachen Sie die Kosten nach Geschäftsbereichen | Architecture, DevOps, Finance | Y | Alle | Alle | zwingend erforderlich | | Verteilung der Kosten | example-inc:cost-allocation:CostCenter | Überwachen Sie die Kosten nach Kostenstellen | 123-\$1 | Y | Alle | Alle | zwingend erforderlich | | Kostenzuweisung | example-inc:cost-allocation:Owner | Welcher Haushaltsinhaber ist für diesen Arbeitsaufwand verantwortlich | Marketing, RetailSupport | Y | Alle | Alle | zwingend erforderlich | | Zugriffskontrolle | example-inc:access-control:LayerId | Identifizieren Sie die Ebene SubComponent //, um je nach Rolle Zugriff auf Ressourcen zu gewähren | DB\$1Layer, Web\$1Layer, App\$1Layer | N | Alle | Alle | Optional | | Automatisierung | example-inc:automation:EnvironmentId | Implementieren Sie die Planung von Test- und Entwicklungsumgebungen, die auch als Phase des Softwareentwicklungslebenszyklus (SDLC) bezeichnet wird | Prod, Dev, Test, Sandbox | N | EC2, RDS, EBS | Alle | zwingend erforderlich | | DevOps | example-inc:operations:Owner | Welches team/squad ist für die Erstellung und Wartung der Ressource verantwortlich | Squad01 | N | Alle | Alle | zwingend erforderlich | | Notfallwiederherstellung | example-inc:disaster-recovery:rpo | Definieren Sie das Recovery Point Objective (RPO) für eine Ressource | 6h, 24h | N | S3, EBS | Prod | zwingend erforderlich | | Klassifizierung von Daten | example-inc:data:classification | Klassifizieren Sie Daten aus Gründen der Einhaltung von Vorschriften und Unternehmensführung | Public, Private, Confidential, Restricted | N | S3, EBS | Alle | zwingend erforderlich | | Compliance | example-inc:compliance:framework | Identifiziert das Compliance-Framework, dem die Arbeitslast unterliegt | PCI-DSS, HIPAA | N | Alle | Prod | zwingend erforderlich | Nachdem das Tagging-Schema definiert wurde, verwalten Sie das Schema in einem versionskontrollierten Repository, auf das alle relevanten Beteiligten zugreifen können, sodass sie leicht nachschlagen und Aktualisierungen nachverfolgen können. Dieser Ansatz verbessert die Effizienz und ermöglicht Agilität. # AWS Organizations — Tag-Richtlinien AWS Organizations Mit den darin enthaltenen Richtlinien können Sie zusätzliche Arten der Unternehmensführung AWS-Konten in Ihrer Organisation anwenden. Mit einer [https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies.html](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies.html) können Sie Ihr Tagging-Schema in JSON-Form ausdrücken, sodass die Plattform das Schema in Ihrer AWS Umgebung melden und optional durchsetzen kann. Die Tag-Richtlinie definiert die Werte, die für einen Tag-Schlüssel bei bestimmten Ressourcentypen zulässig sind. Diese Richtlinie kann in Form einer Werteliste oder eines Präfixes, gefolgt von einem Platzhalterzeichen (`*`), vorliegen. Der einfache Präfix-Ansatz ist weniger streng als eine diskrete Werteliste, erfordert jedoch weniger Wartung. Die folgenden Beispiele zeigen, wie eine Tagging-Richtlinie definiert wird, um die Werte zu überprüfen, die für einen bestimmten Schlüssel akzeptabel sind. Ausgehend von der benutzerfreundlichen tabellarischen Definition des Schemas können Sie diese Informationen in eine oder mehrere Tag-Richtlinien umwandeln. Separate Richtlinien können verwendet werden, um delegiertes Eigentum zu unterstützen, oder einige Richtlinien gelten möglicherweise nur in bestimmten Szenarien. ## ExampleInc- .json CostAllocation Im Folgenden finden Sie ein Beispiel für eine Tag-Richtlinie, die über Tags zur Kostenzuweisung berichtet: ``` { "tags": { "example-inc:cost-allocation:ApplicationId": { "tag_key": { "@@assign": "example-inc:cost-allocation:ApplicationId" }, "tag_value": { "@@assign": [ "DataLakeX", "RetailSiteX" ] } }, "example-inc:cost-allocation:BusinessUnitId": { "tag_key": { "@@assign": "example-inc:cost-allocation:BusinessUnitId" }, "tag_value": { "@@assign": [ "Architecture", "DevOps", "FinanceDataLakeX" ] } }, "example-inc:cost-allocation:CostCenter": { "tag_key": { "@@assign": "example-inc:cost-allocation:CostCenter" }, "tag_value": { "@@assign": [ "123-*" ] } } } } ``` ## ExampleInc- DisasterRecovery .json Im Folgenden finden Sie ein Beispiel für eine Tag-Richtlinie, die über Disaster Recovery-Tags berichtet: ``` { "tags": { "example-inc:disaster-recovery:rpo": { "tag_key": { "@@assign": "example-inc:disaster-recovery:rpo" }, "tag_value": { "@@assign": [ "6h", "24h" ] } } } } ``` In diesem Beispiel ist die `ExampleInc-CostAllocation` Tag-Richtlinie an die `Workloads` Organisationseinheit angehängt und gilt daher für alle Konten sowohl in der Organisationseinheit als auch im `Prod` `Test` untergeordneten Konto OUs. In ähnlicher Weise ist die `ExampleInc-DisasterRecovery` Tag-Richtlinie an die `Prod` Organisationseinheit angehängt und gilt daher nur für Konten unter dieser Organisationseinheit. Das Whitepaper [Organizing Your Environment Using Multiple Accounts](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html) befasst sich eingehender mit den empfohlenen OU-Strukturen. ![\[Diagramm, das die Zuordnung von Tag-Richtlinien zu einer OU-Struktur und die effektive Richtlinie zeigt\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/tagging-best-practices/images/adding-tagging-to-policies-in-ou-structure.png) Betrachtet man das `marketing-prod` Konto im Diagramm, so gelten beide Tag-Richtlinien für dieses Konto. Wir haben also das Konzept einer *effektiven Richtlinie*, d. h. die Zusammenfassung der Richtlinien eines bestimmten Typs, die für ein Konto gelten. Wenn Sie Ihre Ressourcen hauptsächlich manuell verwalten, können Sie die geltende Richtlinie überprüfen, indem Sie in der Konsole den Abschnitt [Resource Groups und Tag-Editor:Tag-Richtlinien](https://console.aws.amazon.com/resource-groups/tag-policies) aufrufen. Wenn Sie Infrastructure as Code (IaC) oder Scripting zur Verwaltung Ihrer Ressourcen verwenden, können Sie den API-Aufruf verwenden. [https://docs.aws.amazon.com/organizations/latest/APIReference/API_DescribeEffectivePolicy.html](https://docs.aws.amazon.com/organizations/latest/APIReference/API_DescribeEffectivePolicy.html) # Tagging implementieren und durchsetzen In diesem Abschnitt stellen wir Ihnen die Tools vor, die für die folgenden Ressourcenmanagement-Strategien verfügbar sind: manuell, Infrastructure as Code (IaC) und Continuous integration/continuous Delivery (CI/CD). Die Schlüsseldimension dieser Ansätze ist eine immer häufigere Implementierungsrate. ## Manuell verwaltete Ressourcen Dabei handelt es sich in der Regel um Workloads, die in die [Grundlagenphase oder die Migrationsphase der Einführung](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-program-implementation/reviewing-frameworks.html) fallen. *Oft handelt es sich dabei um einfache, weitgehend statische Workloads, die mithilfe herkömmlicher schriftlicher Verfahren erstellt wurden, oder um Workloads, die mit Tools migriert wurden, z. B. AWS Application Migration Service aus einer lokalen Umgebung.* Migrationstools wie Migration Hub und Application Migration Service können im Rahmen des Migrationsprozesses Tags anwenden. Wenn jedoch bei der ursprünglichen Migration keine Tags angewendet wurden oder sich das Tagging-Schema seitdem geändert hat, können Sie mit dem [Tag-Editor](https://docs.aws.amazon.com/ARG/latest/userguide/tag-editor.html) (eine Funktion von AWS-Managementkonsole) anhand einer Vielzahl von Suchkriterien nach Ressourcen suchen und Tags gleichzeitig hinzufügen, ändern oder löschen. Zu den Suchkriterien können Ressourcen mit oder ohne das Vorhandensein eines bestimmten Tags oder Werts gehören. Mit der AWS Resource Tagging API können Sie diese Funktionen programmgesteuert ausführen. Im Zuge der Modernisierung dieser Workloads werden Ressourcentypen wie Auto Scaling Scaling-Gruppen eingeführt. Diese Ressourcentypen ermöglichen eine höhere Elastizität und eine verbesserte Widerstandsfähigkeit. Die Auto Scaling-Gruppe verwaltet Amazon EC2 EC2-Instances in Ihrem Namen. Möglicherweise möchten Sie jedoch trotzdem, dass die EC2-Instances konsistent mit den manuell erstellten Ressourcen gekennzeichnet werden. Eine [https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-templates.html](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-templates.html) bietet die Möglichkeit, die Tags anzugeben, die Auto Scaling auf die von ihm erstellten Instances anwenden soll. Wenn die Ressourcen eines Workloads manuell verwaltet werden, kann es hilfreich sein, das Tagging von Ressourcen zu automatisieren. Es stehen verschiedene Lösungen zur Verfügung. Ein Ansatz ist die Verwendung AWS-Config-Regeln, mit der nach einer Lambda-Funktion gesucht `required_tags` und diese dann gestartet werden kann, um sie anzuwenden. AWS-Config-Regeln wird später in diesem Whitepaper ausführlicher beschrieben. ## Verwaltete Ressourcen mit Infrastruktur als Code (IaC) AWS CloudFormation bietet eine gemeinsame Sprache für die Bereitstellung aller Infrastrukturressourcen in Ihrer AWS Umgebung. CloudFormation Vorlagen sind JSON- oder YAML-Dateien, mit denen AWS Ressourcen automatisiert erstellt werden. Wenn Sie AWS Ressourcen mithilfe von CloudFormation Vorlagen erstellen, können Sie die Eigenschaft CloudFormation Resource Tags verwenden, um bei der Erstellung Tags auf unterstützte Ressourcentypen anzuwenden. Die Verwaltung der Tags sowie der Ressourcen mit IaC trägt zur Sicherstellung der Konsistenz bei. Wenn Ressourcen von erstellt werden AWS CloudFormation, wendet der Service automatisch eine Reihe AWS definierter Tags auf die mit der AWS CloudFormation Vorlage erstellten Ressourcen an. Dies sind: ``` aws:cloudformation:stack-name aws:cloudformation:stack-id aws:cloudformation:logical-id ``` Sie können auf einfache Weise eine Ressourcengruppe auf der Grundlage des AWS CloudFormation Stacks definieren. Diese AWS definierten Tags werden von den Ressourcen vererbt, die vom Stack erstellt wurden. Für Amazon EC2 EC2-Instances innerhalb einer Auto Scaling Scaling-Gruppe [`AWS::AutoScaling::AutoScalingGroup` TagProperty](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-as-tags.html)muss dies jedoch in der Definition der Auto Scaling Scaling-Gruppe in Ihrer AWS CloudFormation Vorlage festgelegt werden. Wenn Sie eine [EC2-Startvorlage](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ec2-launchtemplate.html) mit der Auto Scaling Scaling-Gruppe verwenden, können Sie die Tags alternativ in ihrer Definition definieren. Es wird empfohlen, [EC2 Launch Templates](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ec2-launchtemplate.html) mit Auto Scaling Scaling-Gruppen oder mit einem AWS Container-Service zu verwenden. Diese Services können dazu beitragen, dass Ihre Amazon EC2 EC2-Instances konsistent gekennzeichnet werden. Außerdem unterstützen sie [Auto Scaling für mehrere Instance-Typen und Kaufoptionen](https://aws.amazon.com/blogs/aws/new-ec2-auto-scaling-groups-with-multiple-instance-types-purchase-options/), wodurch die Ausfallsicherheit verbessert und Ihre Rechenkosten optimiert werden können. [AWS CloudFormation Hooks](https://aws.amazon.com/blogs/mt/proactively-keep-resources-secure-and-compliant-with-aws-cloudformation-hooks/) bieten Entwicklern die Möglichkeit, wichtige Aspekte ihrer Anwendung mit den Standards ihrer Organisation in Einklang zu bringen. Hooks können so konfiguriert werden, dass sie eine *Warnung* ausgeben oder die *Bereitstellung verhindern*. Diese Funktion eignet sich am besten, um wichtige Konfigurationselemente in Ihren Vorlagen zu überprüfen, z. B. ob eine Auto Scaling Scaling-Gruppe so konfiguriert ist, dass sie kundenspezifische Tags auf alle von ihr gestarteten Amazon EC2 EC2-Instances anwendet, oder um sicherzustellen, dass alle Amazon S3 S3-Buckets mit den erforderlichen Verschlüsselungseinstellungen erstellt werden. In beiden Fällen wird die Bewertung der Einhaltung der Vorschriften auf die frühere Phase des Implementierungsprozesses verschoben, wobei vor der Bereitstellung ein AWS CloudFormation Haken gesetzt wird. AWS CloudFormation bietet die Möglichkeit zu erkennen, wenn eine über eine Vorlage bereitgestellte Ressource (siehe [Ressourcen, die die Drift-Erkennung unterstützen](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/resource-import-supported-resources.html)) geändert wurde und Ressourcen nicht mehr ihren erwarteten Vorlagenkonfigurationen entsprechen. Dies wird als *Drift* bezeichnet. Wenn Sie mithilfe von Automatisierung Tags auf Ressourcen anwenden, die über IaC verwaltet werden, ändern Sie sie und führen zu Drift. Bei der Verwendung von IaC wird derzeit empfohlen, alle Tagging-Anforderungen als Teil der IaC-Vorlagen zu verwalten, AWS CloudFormation Hooks zu implementieren und AWS CloudFormation Guard-Regelsätze zu veröffentlichen, die für die Automatisierung verwendet werden können. ## Von der CI/CD-Pipeline verwaltete Ressourcen Je ausgereifter ein Workload wird, desto wahrscheinlicher ist es, dass Techniken wie Continuous Integration und Continuous Deployment (CI/CD) eingeführt werden. Diese Techniken tragen dazu bei, das Implementierungsrisiko zu verringern, indem sie es einfacher machen, kleine Änderungen häufiger zu implementieren und die Tests stärker zu automatisieren. Eine Beobachtungsstrategie, die unerwartetes, durch eine Bereitstellung verursachtes Verhalten erkennt, kann die Bereitstellung automatisch und mit minimaler Auswirkung auf die Benutzer rückgängig machen. In der Phase, in der Sie täglich zehnmal am Tag bereitstellen müssen, ist die rückwirkende Anwendung von Tags einfach nicht mehr praktikabel. Alles muss als Code oder Konfiguration ausgedrückt, versionskontrolliert und, wo immer möglich, getestet und bewertet werden, bevor es in der Produktion eingesetzt wird. Beim kombinierten [Modell für Entwicklung und Betrieb (DevOps) behandeln](https://aws.amazon.com/devops/what-is-devops/) viele der Methoden betriebliche Überlegungen in Form von Code und validieren sie zu Beginn des Bereitstellungszyklus. Idealerweise sollten Sie diese Prüfungen so früh wie möglich durchführen (wie mit AWS CloudFormation Hooks dargestellt), sodass Sie sicher sein können, dass Ihre AWS CloudFormation Vorlage Ihren Richtlinien entspricht, bevor sie den Computer des Entwicklers verlassen. [AWS CloudFormation Guard 2.0](https://aws.amazon.com/blogs/mt/introducing-aws-cloudformation-guard-2-0/) bietet die Möglichkeit, präventive Compliance-Regeln für alles, was Sie definieren können, zu CloudFormation schreiben. Die Vorlage wird anhand der Regeln in der Entwicklungsumgebung validiert. Natürlich hat diese Funktion eine Reihe von Anwendungen, aber in diesem Whitepaper werden wir uns nur einige Beispiele ansehen, um sicherzustellen, dass sie immer verwendet wird. [`AWS::AutoScaling::AutoScalingGroup` TagProperty](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-as-tags.html) Im Folgenden finden Sie ein Beispiel für eine CloudFormation Guard-Regel: ``` let all_asgs = Resources.*[ Type == 'AWS::AutoScaling::AutoScalingGroup' ] rule tags_asg_automation_EnvironmentId when %all_asgs !empty { let required_tags = %all_asgs.Properties.Tags.*[ Key == 'example-inc:automation:EnvironmentId' ] %required_tags[*] { PropagateAtLaunch == 'true' Value IN ['Prod', 'Dev', 'Test', 'Sandbox'] <> } } rule tags_asg_costAllocation_CostCenter when %all_asgs !empty { let required_tags = %all_asgs.Properties.Tags.*[ Key == 'example-inc:cost-allocation:CostCenter' ] %required_tags[*] { PropagateAtLaunch == 'true' Value == /^123-/ <> } } ``` Im Codebeispiel filtern wir die Vorlage nach allen Ressourcen dieses Typs `AutoScalingGroup` und haben dann zwei Regeln: + **`tags_asg_automation_EnvironmentId`**- Überprüft, ob ein Tag mit diesem Schlüssel existiert, dass es einen Wert in der Liste der zulässigen Werte gibt und dass dieser Wert auf gesetzt `PropagateAtLaunch` ist `true` + **`tags_asg_costAllocation_CostCenter`**- Überprüft, ob ein Tag mit diesem Schlüssel existiert, dass es einen Wert hat, der mit dem definierten Präfixwert beginnt und auf gesetzt `PropagateAtLaunch` ist `true` ## Durchsetzung Wie bereits beschrieben, bietet **Resource Groups & Tag Editor** die Möglichkeit, festzustellen, wo Ihre Ressourcen die Tagging-Anforderungen nicht erfüllen, die in den für die Organisation geltenden Tag-Richtlinien definiert sind. OUs Wenn Sie von einem Mitgliedskonto einer Organisation aus auf das Konsolentool **Resource Groups & Tag Editor** zugreifen, werden Ihnen die Richtlinien angezeigt, die für dieses Konto gelten, und die Ressourcen innerhalb des Kontos, die die Anforderungen der Tag-Richtlinie nicht erfüllen. Wenn der Zugriff über das Verwaltungskonto erfolgt (und wenn **für Tag-Richtlinien** der *Zugriff in den Diensten unter aktiviert* ist AWS Organizations), ist es möglich, die [Einhaltung der Tag-Richtlinien für alle verknüpften Konten in der Organisation einzusehen](https://docs.aws.amazon.com/ARG/latest/userguide/tag-policies-orgs-evaluating-org-wide-compliance.html). In der Tag-Richtlinie selbst können Sie die Durchsetzung für bestimmte Ressourcentypen aktivieren. Im folgenden Richtlinienbeispiel haben wir die Durchsetzung hinzugefügt, sodass alle Ressourcen der `ec2:volume` Typen `ec2:instance` und der Richtlinie entsprechen müssen. Es gibt einige bekannte Einschränkungen, z. B. muss eine Ressource mit einem Tag versehen sein, damit sie anhand der Tag-Richtlinie ausgewertet werden kann. Eine Liste finden Sie unter [Ressourcen, die die Durchsetzung von Tag-Richtlinien unterstützen](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_supported-resources-enforcement.html). ### ExampleInc-cost-allocation.json Im Folgenden finden Sie ein Beispiel für eine Tag-Richtlinie, die in Berichten and/or die Durchsetzung von Kostenzuweisungs-Tags vorschreibt: ``` { "tags": { "example-inc:cost-allocation:ApplicationId": { "tag_key": { "@@assign": "example-inc:cost-allocation:ApplicationId" }, "tag_value": { "@@assign": [ "DataLakeX", "RetailSiteX" ] }, "enforced_for": { "@@assign": [ "ec2:instance", "ec2:volume" ] } }, "example-inc:cost-allocation:BusinessUnitId": { "tag_key": { "@@assign": "example-inc:cost-allocation:BusinessUnitId" }, "tag_value": { "@@assign": [ "Architecture", "DevOps", "FinanceDataLakeX" ] }, "enforced_for": { "@@assign": [ "ec2:instance", "ec2:volume" ] } }, "example-inc:cost-allocation:CostCenter": { "tag_key": { "@@assign": "example-inc:cost-allocation:CostCenter" }, "tag_value": { "@@assign": [ "123-*" ] }, "enforced_for": { "@@assign": [ "ec2:instance", "ec2:volume" ] } } } } ``` **AWS Config (`required_tag`)** AWS Config ist ein Service, mit dem Sie die Konfigurationen Ihrer AWS Ressourcen beurteilen, prüfen und auswerten können (siehe [Ressourcentypen, die von unterstützt werden AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/resource-config-reference.html)). Im Fall von Tagging können wir damit mithilfe der `required_tags` Regel Ressourcen identifizieren, denen Tags mit bestimmten Schlüsseln fehlen (siehe [Ressourcentypen, die von required\$1tags unterstützt werden](https://docs.aws.amazon.com/config/latest/developerguide/required-tags.html)). Ausgehend vom vorherigen Beispiel könnten wir testen, ob der Schlüssel auf allen Amazon EC2 EC2-Instances vorhanden ist. In Fällen, in denen der Schlüssel nicht existiert, wird die Instance als nicht konform registriert. Diese AWS CloudFormation Vorlage beschreibt eine AWS Config Regel, mit der das Vorhandensein der in der Tabelle beschriebenen obligatorischen Schlüssel auf Amazon S3-Buckets, Amazon EC2 EC2-Instances und Amazon EBS-Volumes getestet werden soll. ``` Resources: MandatoryTags: Type: AWS::Config::ConfigRule Properties: ConfigRuleName: ExampleIncMandatoryTags Description: These tags should be in place InputParameters: tag1Key: example-inc:cost-allocation:ApplicationId tag2Key: example-inc:cost-allocation:BusinessUnitId tag3Key: example-inc:cost-allocation:CostCenter tag4Key: example-inc:automation:EnvironmentId Scope: ComplianceResourceTypes: - "AWS::S3::Bucket" - "AWS::EC2::Instance" - "AWS::EC2::Volume" Source: Owner: AWS SourceIdentifier: REQUIRED_TAGS ``` In Umgebungen, in denen Ressourcen manuell verwaltet werden, kann eine AWS Config Regel dahingehend erweitert werden, dass der fehlende Tag-Schlüssel mithilfe einer automatischen Problembehebung über eine Funktion automatisch zu den Ressourcen hinzugefügt wird. AWS Lambda Das funktioniert zwar gut für statische Workloads, ist aber zunehmend weniger effektiv, wenn Sie beginnen, Ihre Ressourcen über IaC und Deployment-Pipelines zu verwalten. **AWS Organizations — Dienststeuerungsrichtlinien (SCPs)** sind eine Art von Organisationsrichtlinie, mit der Sie Berechtigungen in Ihrer Organisation verwalten können. SCPsbieten eine zentrale Kontrolle über die maximal verfügbaren Berechtigungen für alle Konten in Ihrer Organisation oder Organisationseinheit (OU). SCPs wirkt sich nur auf Benutzer und Rollen aus, die von Konten verwaltet werden, die Teil der Organisation sind. Sie wirken sich zwar nicht direkt auf Ressourcen aus, schränken jedoch die Berechtigungen von Benutzern und Rollen ein, was auch die Berechtigungen für Tagging-Aktionen einschließt. Was das Tagging angeht, SCPs kann sie zusätzlich zu dem, was Tag-Richtlinien bieten können, zusätzliche Granularität bei der Durchsetzung von Tags bieten. Im folgenden Beispiel lehnt die Richtlinie `ec2:RunInstances` Anfragen ab, bei denen das `example-inc:cost-allocation:CostCenter` Tag nicht vorhanden ist. Das Folgende ist ein Deny-SCP: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "DenyRunInstanceWithNoCostCenterTag", "Effect": "Deny", "Action": "ec2:RunInstances", "Resource": [ "arn:aws:ec2:*:*:instance/*" ], "Condition": { "Null": { "aws:RequestTag/example-inc:cost-allocation:CostCenter": "true" } } } ] } ``` ------ Es ist nicht möglich, die effektive Dienststeuerungsrichtlinie abzurufen, die standardmäßig für ein verknüpftes Konto gilt. Wo Sie das Tagging mit erzwingen SCPs, muss Entwicklern die Dokumentation zur Verfügung stehen, damit sie sicherstellen können, dass ihre Ressourcen den Richtlinien entsprechen, die für ihre Konten gelten. Wenn Sie nur Lesezugriff auf CloudTrail Ereignisse in ihrem Konto gewähren, können Entwickler bei der Aufgabe des Debuggings unterstützt werden, wenn ihre Ressourcen nicht den Anforderungen entsprechen. # Messung der Effektivität von Tagging und Förderung von Verbesserungen Nachdem Sie eine Tagging-Strategie implementiert haben, ist es wichtig, ihre Wirksamkeit anhand der Zielanwendungsfälle zu messen. Das Maß der Effektivität wird je nach Anwendungsfall variieren. Beispiel: + **Kostenzuweisung** — Mithilfe von Tools wie dem Kosten- [und Nutzungsbericht](https://aws.amazon.com/aws-cost-management/aws-cost-and-usage-reporting/) könnten Sie den Umfang der Tagging von Ressourcen anhand der Ausgaben messen. [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/)AWS Sie könnten beispielsweise den *Prozentsatz der Ressourcen mit oder ohne Tags verfolgen, für die Gebühren anfallen, insbesondere durch die Überwachung bestimmter Tag-Schlüssel*. + **Automatisierung** — Möglicherweise möchten Sie überprüfen, ob das gewünschte Ergebnis erzielt wurde. Zum Beispiel, ob Amazon EC2 EC2-Instances außerhalb der Geschäftszeiten angehalten werden, ob die Start- und Stoppzeiten von Instances geprüft werden. Der [Resource Groups & Tag Editor](https://docs.aws.amazon.com/ARG/latest/userguide/resource-groups.html) innerhalb des Verwaltungskontos bietet zusätzliche Funktionen zur Analyse der Einhaltung der Tag-Richtlinien für alle verknüpften Konten in Ihrer Organisation. Ermitteln Sie anhand der Ergebnisse der Messung Ihrer Tagging-Effektivität, ob bei einem der Schritte, z. B. bei der Definition eines Anwendungsfalls, der Implementierung oder Durchsetzung des Tagging-Schemas, Verbesserungen oder Änderungen erforderlich sind. Nehmen Sie die erforderlichen Änderungen vor und wiederholen Sie den Zyklus, bis die gewünschte Effektivität erreicht ist. Im Beispiel mit der Kostenzuweisung können Sie sich die prozentuale Verbesserung ansehen. Da es die Entwickler und Betreiber sind, die das eigentliche Tagging von Ressourcen durchführen müssen, ist es wichtig, dass sie die Verantwortung dafür übernehmen. Dies ist nicht die einzige zusätzliche Verantwortung, die Teams normalerweise auf ihrem Weg AWS zur Einführung übernehmen. Eine größere Verantwortung für die Sicherheit und die Kosten für die Entwicklung und den Betrieb ihrer Anwendung sind ebenfalls wichtig. Organizations verwenden häufig Ziele und Vorgaben, um die Einführung neuer Praktiken zu motivieren, sodass dies auch hier zutreffen kann.