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. # Anwendungsfälle taggen **Topics** + [Tags für die Kostenzuweisung und das Finanzmanagement](tags-for-cost-allocation-and-financial-management.md) + [Tags für Betrieb und Support](tags-for-operations-and-support.md) + [Tags für Datensicherheit, Risikomanagement und Zugriffskontrolle](tags-for-data-security-risk-management-and-access-control.md) # Tags für die Kostenzuweisung und das Finanzmanagement Einer der ersten Anwendungsfälle, mit denen sich Unternehmen häufig befassen, ist die Transparenz und Verwaltung von Kosten und Nutzung. In der Regel gibt es dafür mehrere Gründe: + **In der Regel handelt es sich um ein gut verstandenes Szenario, und die Anforderungen sind allgemein bekannt.** Finanzteams möchten beispielsweise die Gesamtkosten von Workloads und Infrastruktur sehen, die sich über mehrere Dienste, Funktionen, Konten oder Teams erstrecken. Eine Möglichkeit, diese Kostentransparenz zu erreichen, ist die konsistente Kennzeichnung von Ressourcen. + **Tags und ihre Werte sind klar definiert.** In der Regel gibt es in den Finanzsystemen einer Organisation bereits Mechanismen zur Kostenverteilung, z. B. die Erfassung nach Kostenstelle, Geschäftseinheit, Team oder Organisationsfunktion. + **Schnelle, nachweisbare Kapitalrendite.** Es ist möglich, Trends zur Kostenoptimierung im Laufe der Zeit zu verfolgen, wenn Ressourcen einheitlich gekennzeichnet werden, z. B. für Ressourcen, die richtig dimensioniert, automatisch skaliert oder in einen Zeitplan aufgenommen wurden. Wenn Sie wissen, wie Ihnen Kosten entstehen, AWS können Sie fundierte finanzielle Entscheidungen treffen. Wenn Sie wissen, wo Ihnen Kosten auf Ressourcen-, Arbeitslast-, Team- oder Organisationsebene entstanden sind, können Sie besser verstehen, welchen Nutzen Sie auf der jeweiligen Ebene im Vergleich zu den erzielten Geschäftsergebnissen erzielt haben. Die Entwicklungsteams haben möglicherweise keine Erfahrung mit dem Finanzmanagement ihrer Ressourcen. Die Einstellung einer Person mit Spezialkenntnissen im AWS Finanzmanagement, die Ingenieur- und Entwicklungsteams in den Grundlagen des AWS Finanzmanagements schulen und eine Beziehung zwischen Finanzen und Technik herstellen kann, um die Unternehmenskultur zu fördern, trägt FinOps dazu bei, messbare Ergebnisse für das Unternehmen zu erzielen und Teams zu ermutigen, kostenbewusst zu bauen. Die Festlegung guter Finanzpraktiken wird in der [Säule Kostenoptimierung](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/welcome.html) des Well-Architected Framework ausführlich behandelt, aber wir werden in diesem Whitepaper auf einige der grundlegenden Prinzipien eingehen. # Kostenzuordnungs-Tags Die Kostenzuweisung bezieht sich auf die Zuweisung oder Verteilung der angefallenen Kosten an die Nutzer oder Begünstigten dieser Kosten nach einem festgelegten Prozess. *Im Rahmen dieses Whitepapers unterteilen wir die Kostenzuweisung in zwei Typen: *Showback* und Chargeback.* *Showback-Tools* und -Mechanismen tragen dazu bei, das Kostenbewusstsein zu stärken. *Chargeback* hilft bei der Kostendeckung und fördert das Kostenbewusstsein. Bei *Showback* geht es um die Darstellung, Berechnung und Meldung der Gebühren, die für eine bestimmte Einheit anfallen, z. B. für eine Geschäftseinheit, eine Anwendung, einen Benutzer oder eine Kostenstelle. Zum Beispiel: „Das Team für Infrastrukturtechnik war im letzten Monat für AWS Ausgaben in Höhe von X \$1 verantwortlich“. Bei der *Rückbuchung* geht es um die tatsächliche Verbuchung der entstandenen Kosten durch die internen Buchhaltungsprozesse eines Unternehmens, wie z. B. Finanzsysteme oder Journalbelege. Zum Beispiel: „X \$1 wurden vom Budget des Infrastruktur-Engineering-Teams abgezogen.“ AWS In beiden Fällen kann eine angemessene Kennzeichnung der Ressourcen dazu beitragen, die Kosten einer Entität zuzuweisen. Der einzige Unterschied besteht darin, ob von jemandem eine Zahlung erwartet wird oder nicht. Die Finanzverwaltung Ihres Unternehmens erfordert möglicherweise eine transparente Abrechnung der anfallenden Kosten auf Anwendungs-, Geschäftsbereichs-, Kostenstellen- und Teamebene. Die durch Cost [Allocation Tags unterstützte Kostenzuweisung](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html) liefert Ihnen die Daten, die Sie benötigen, um die Kosten, die einer Entität entstanden sind, anhand entsprechend gekennzeichneter Ressourcen genau zuzuordnen. + **Rechenschaftspflicht** — Stellen Sie sicher, dass die Kosten denjenigen zugewiesen werden, die für die Ressourcennutzung verantwortlich sind. Eine einzige Servicestelle oder Gruppe kann für Ausgabenprüfungen und Berichte verantwortlich sein. + **Finanzielle Transparenz** — Verschaffen Sie sich einen klaren Überblick über die Mittelzuweisungen für die IT, indem Sie effektive Dashboards und aussagekräftige Kostenanalysen für Führungskräfte erstellen. + **Informierte IT-Investitionen** — Verfolgen Sie den ROI je nach Projekt, Anwendung oder Geschäftsbereich und versetzen Sie Teams in die Lage, bessere Geschäftsentscheidungen zu treffen, z. B. mehr Mittel für umsatzgenerierende Anwendungen bereitzustellen. Zusammenfassend können Ihnen die Tags zur Kostenzuweisung dabei helfen, Ihnen folgende Informationen zu geben: + Wem gehören die Ausgaben und wer ist für deren Optimierung verantwortlich? + Für welchen Workload, welche Anwendung oder welches Produkt fallen die Ausgaben an? Welche Umgebung oder Phase? + Welche Ausgabenbereiche wachsen am schnellsten? + Wie viele Ausgaben können aufgrund vergangener Trends von einem AWS Budget abgezogen werden? + Wie wirkten sich die Bemühungen zur Kostenoptimierung bei bestimmten Workloads, Anwendungen oder Produkten aus? Die Aktivierung von Ressourcen-Tags für die Kostenzuweisung hilft bei der Definition von Messmethoden innerhalb der Organisation, anhand derer die AWS Nutzung transparent gemacht und die Rechenschaftspflicht für Ausgaben erhöht wird. Ein weiterer Schwerpunkt liegt auf der Schaffung eines angemessenen Grads an Granularität in Bezug auf Kosten- und Nutzungstransparenz sowie auf der Beeinflussung des Cloud-Nutzungsverhaltens durch Berichte zur Kostenzuweisung und KPI-Tracking. # Aufbau einer Strategie zur Kostenverteilung ## Definition und Implementierung eines Kostenverteilungsmodells Erstellen Sie eine Konto- und Kostenstruktur für die Ressourcen, in denen sie eingesetzt werden AWS. Stellen Sie das Verhältnis zwischen den AWS Ausgaben, der Art und Weise, wie diese Kosten entstanden sind, und der Person oder dem, was diese Kosten verursacht hat, fest. Gängige Kostenstrukturen basieren auf AWS Organizations Umgebungen und Entitäten innerhalb Ihrer Organisation, z. B. einem Geschäftsbereich oder einer Arbeitslast. AWS-Konten Kostenstrukturen können auf mehreren Attributen basieren, sodass die Kosten auf unterschiedliche Weise oder mit unterschiedlichen Granularitätsebenen untersucht werden können, z. B. indem die Kosten einzelner Workloads dem Geschäftsbereich zugeordnet werden, für den sie zuständig sind. *Bei der Auswahl einer Kostenstruktur, die sich an den gewünschten Ergebnissen orientiert, sollten Sie die Mechanismen zur Kostenverteilung anhand der *Einfachheit der Implementierung im Vergleich zur* gewünschten Genauigkeit bewerten.* Dies könnte Überlegungen in Bezug auf Rechenschaftspflicht, Verfügbarkeit von Tools und kulturelle Veränderungen beinhalten. Drei beliebte Kostenverteilungsmodelle, von denen AWS Kunden in der Regel ausgehen, sind: + **Kontobasiert** — Dieses Modell erfordert den geringsten Aufwand und bietet eine hohe Genauigkeit bei Showbacks und Chargebacks. Es eignet sich für Unternehmen mit einer definierten Kontostruktur (und entspricht den Empfehlungen des Whitepapers [Organizing Your AWS Environment Using](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html) Multiple Accounts). Dies ermöglicht eine klare Kostentransparenz auf Kontobasis. Für Kostentransparenz und Kostenzuweisung können Sie [Kosten [AWS Cost Explorer](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ce-what-is.html)- und Nutzungsberichte](https://docs.aws.amazon.com/cur/latest/userguide/what-is-cur.html) sowie [AWS Budgets](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html) für die Kostenüberwachung und -verfolgung verwenden. Diese Tools bieten Filter- und Gruppierungsoptionen nach AWS-Konten. Aus Sicht der Kostenzuweisung muss sich dieses Modell nicht auf eine genaue Kennzeichnung einzelner Ressourcen verlassen. + **Geschäftsbereich- oder teambasiert** — Kosten, die Teams, Geschäftseinheiten oder Organisationen innerhalb eines Unternehmens zugewiesen werden können. Dieses Modell erfordert einen moderaten Aufwand, bietet eine hohe Genauigkeit bei Showbacks und Chargebacks und eignet sich für Unternehmen mit einer definierten Kontostruktur (in der Regel mit AWS Organizations), bei der verschiedene Teams, Anwendungen und Workload-Typen getrennt sind. Dies sorgt für eine klare Kostentransparenz zwischen Teams und Anwendungen und reduziert als zusätzlicher Vorteil das Risiko, dass [AWS Servicequoten innerhalb eines einzigen Pakets](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) erreicht werden. AWS-Konto Beispielsweise kann jedes Team über fünf Konten (`prod`,,`staging`, `test``dev`,`sandbox`) verfügen, und keine zwei Teams und Anwendungen teilen sich dasselbe Konto. Mit einer solchen Struktur bieten [AWS Cost Categories](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/manage-cost-categories.html) dann die Funktionalität, Konten oder andere Tags („Meta-Tagging“) in Kategorien zu gruppieren, die in den im vorherigen Beispiel genannten Tools nachverfolgt werden können. Es ist wichtig zu beachten, dass dies das Taggen von Konten und Organisationseinheiten (OUs) AWS Organizations ermöglicht. Diese Tags sind jedoch nicht für die Kostenzuweisung und die Fakturierung relevant (d. h. Sie können Ihre Kosten nicht nach Organisationseinheiten gruppieren oder filtern). AWS Cost Explorer AWS Zu diesem Zweck sollten Cost Categories verwendet werden. + **Tag-basiert** — Dieses Modell erfordert im Vergleich zu den beiden vorherigen Modellen mehr Aufwand und bietet je nach Anforderungen und Endziel eine hohe Genauigkeit bei Showbacks und Chargebacks. Wir empfehlen Ihnen zwar dringend, die im Whitepaper [Organizing Your AWS Environment Using Multiple Accounts](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html) beschriebenen Verfahren anzuwenden, aber realistischerweise haben Kunden oft gemischte und komplexe Kontostrukturen, von denen die Migration einige Zeit in Anspruch nimmt. Die Implementierung einer rigorosen und effektiven Tagging-Strategie ist der Schlüssel in diesem Szenario, gefolgt von der [Aktivierung relevanter Tags für die Kostenzuweisung](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/activating-tags.html) in der Billing and Cost Management Kostenmanagement-Konsole (in AWS Organizations, Tags können für die Kostenzuweisung nur über das Management Payer-Konto aktiviert werden). Nachdem die Tags für die Kostenzuweisung aktiviert wurden, können die in den vorherigen Methoden erwähnten Tools für Kostentransparenz und Kostenzuweisung für Showbacks und Rückbuchungen verwendet werden. Beachten Sie, dass Tags für die Kostenzuweisung nicht rückwirkend sind und erst in den Tools für Rechnungsberichte und Kostenverfolgung angezeigt werden, nachdem sie für die Kostenzuweisung aktiviert wurden. Zusammenfassend lässt sich sagen, dass Sie, wenn Sie die Kosten nach Geschäftsbereichen verfolgen möchten, [AWS Cost Categories](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/manage-cost-categories.html) verwenden können, um verknüpfte Konten innerhalb der AWS Organisation entsprechend zu gruppieren und diese Gruppierung in Abrechnungsberichten anzuzeigen. [Wenn Sie separate Konten für Produktions- und Nichtproduktionsumgebungen erstellen, können Sie die Kosten für Umgebungen auch in Tools wie filtern oder diese Kosten [AWS Cost Explorer](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ce-what-is.html)mithilfe von Budgets verfolgen.AWS](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html) Und wenn Ihr Anwendungsfall eine detailliertere Kostenverfolgung erfordert, z. B. nach einzelnen Workloads oder Anwendungen, können Sie Ressourcen innerhalb dieser Konten entsprechend taggen, [diese Tagschlüssel für die Kostenzuweisung auf dem Verwaltungskonto aktivieren](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/activating-tags.html) und diese Kosten dann in den Tools für die Rechnungsberichterstattung nach Tagschlüsseln filtern. ## Einrichtung von Prozessen zur Kostenberichterstattung und -überwachung Identifizieren Sie zunächst die Arten von Kosten, die für interne Stakeholder wichtig sind (z. B. tägliche Ausgaben, Kosten pro Konto, Kosten pro X, amortisierte Kosten). Auf diese Weise können Sie die mit unerwarteten oder ungewöhnlichen Ausgaben verbundenen Haushaltsrisiken schneller minimieren, als wenn Sie auf die endgültige Rechnung warten müssen. AWS Tags bieten die Zuordnung, die diese Berichtsszenarien ermöglicht. Die aus der Berichterstattung gewonnenen Erkenntnisse können als Grundlage für Ihre Maßnahmen zur Minderung der Auswirkungen ungewöhnlicher und unerwarteter Ausgaben auf Finanzbudgets dienen. Wenn es zu einem unerwarteten Anstieg der Kosten kommt, ist es wichtig, zu bewerten, ob es zu einem unerwarteten Anstieg des erzielten Nutzens gekommen ist, damit Sie feststellen können, ob und welche Maßnahmen erforderlich sind. Beachten Sie bei der Entwicklung einer Tagging-Strategie zur Unterstützung der Kostenzuweisung die folgenden Elemente: + **AWS Organizations**- Die Kostenzuweisung innerhalb mehrerer Konten kann nach Konten, Kontogruppen oder Gruppen von Stichwörtern erfolgen, die für Ressourcen auf diesen Konten erstellt wurden. Tags, die für Ressourcen erstellt wurden, die sich in einzelnen Konten befinden, AWS Organizations können nur vom Verwaltungskonto aus für die Kostenzuweisung verwendet werden. + **AWS Konto** — Die Kostenzuweisung innerhalb eines Kontos AWS-Konto kann durch zusätzliche Dimensionen wie Dienste oder Regionen erfolgen. Es ist möglich, Ressourcen innerhalb eines Accounts weiter zu taggen und mit den Gruppen solcher Ressourcen-Tags zu arbeiten. + **Tags für die Kostenzuweisung** — Sowohl von Benutzern erstellte als auch AWS generierte Tags können bei Bedarf für die Kostenzuweisung aktiviert werden. Die Aktivierung von Tags für die Kostenzuweisung in der Abrechnungskonsole (des Verwaltungskontos in AWS Organizations) hilft bei Showbacks und Rückbuchungen. + **Cost AWS Categories** — Cost Categories ermöglichen das Gruppieren von Konten und das Gruppieren von Tags („Metatagging“) innerhalb einer AWS Organisation. Dadurch können die mit diesen Kategorien verbundenen Kosten mithilfe von Tools wie AWS Cost Explorer AWS Budgets und Kosten- und AWS Nutzungsbericht weiter analysiert werden. ## Durchführung von Showback- und Chargeback-Aktionen für Geschäftsbereiche, Teams oder Organisationen innerhalb des Unternehmens Ordnen Sie Kosten mithilfe Ihres Kostenzuordnungsprozesses zu, der durch Ihre Kostenstruktur- und Kostenzuweisungs-Tags unterstützt wird. Mithilfe von Stichwörtern können Teams, die zwar nicht direkt für die Bezahlung der Kosten verantwortlich sind, aber dafür verantwortlich sind, dass diese Kosten entstanden sind, als Vorzeigeobjekt dienen. Durch diesen Ansatz wird ein Bewusstsein dafür geschaffen, welchen Beitrag sie zu den Ausgaben leisten und wie diese Kosten entstehen. Führen Sie Rückbuchungen an die Teams durch, die direkt für die Kosten verantwortlich sind, um die Kosten für die verbrauchten Ressourcen zu decken und ihnen bewusst zu machen, welche Kosten und wie sie entstanden sind. ## Messung und Verbreitung von Effizienz oder Wert KPIs Vereinbaren Sie eine Reihe von Stückkosten- oder KPI-Metriken, um die Auswirkungen Ihrer Investitionen in das Cloud-Finanzmanagement zu messen. Diese Übung schafft eine gemeinsame Sprache für Technologie- und Geschäftsakteure und erzählt eine Geschichte, die auf der Wissenschaft basiert, und nicht eine Geschichte, die sich ausschließlich auf absolute Gesamtausgaben konzentriert. Weitere Informationen finden Sie in diesem Blog, in dem es darum geht, [wie Einheitenkennzahlen dazu beitragen können, die Geschäftsfunktionen aufeinander abzustimmen](https://aws.amazon.com/blogs/aws-cloud-financial-management/unit-metrics-help-create-alignment-between-business-functions/). ## Zuweisung nicht zuweisbarer Ausgaben Je nach den Rechnungslegungspraktiken der Organisation müssen unterschiedliche Gebührenarten möglicherweise unterschiedlich behandelt werden. Identifizieren Sie die Ressourcen oder Kostenkategorien, die nicht gekennzeichnet werden können. Vereinbaren Sie je nach den in Anspruch genommenen und geplanten Diensten die Mechanismen, wie solche nicht zuweisbaren Ausgaben behandelt und gemessen werden sollen. Schauen Sie sich zum Beispiel die Liste der Ressourcen an, die von [AWS -Ressourcengruppen und Tag Editor unterstützt werden, im *AWS -Ressourcengruppen und Tags-Benutzerhandbuch*](https://docs.aws.amazon.com/ARG/latest/userguide/supported-resources.html). Ein gängiges Beispiel für eine Kostenkategorie, die nicht gekennzeichnet werden kann, sind Gebühren für Rabatte auf Basis von Verpflichtungen wie Reserved Instances (RI) und Savings Plans (SP). Abonnementgebühren und ungenutzte SP- und RI-Gebühren können zwar nicht markiert werden, bevor sie in den Tools zur Rechnungsberichterstattung erscheinen, aber Sie können nachträglich verfolgen, wie RI- und SP-Rabatte auf Konten, Ressourcen und deren Tags angewendet werden. AWS Organizations Beispielsweise ist AWS Cost Explorer es möglich, sich die amortisierten Kosten anzusehen, diese Ausgaben nach den entsprechenden Tag-Schlüsseln zu gruppieren und Filter anzuwenden, die für Ihren Anwendungsfall relevant sind. Im AWS Kosten- und Nutzungsbericht (CUR) können Sie Zeilen herausfiltern, die der Nutzung entsprechen, die durch RI- und SP-Rabatte abgedeckt ist (weitere Informationen finden Sie im Abschnitt Anwendungsfälle der [CUR-Dokumentation](https://docs.aws.amazon.com/cur/latest/userguide/use-cases.html)) und die Spalten auswählen, die nur für Sie relevant sind. Jeder für die Kostenzuweisung aktivierte Tagschlüssel wird am Ende des CUR-Berichts in einer eigenen Spalte angezeigt, ähnlich wie er in anderen älteren Abrechnungsberichten, z. B. dem [monatlichen Kostenzuordnungsbericht](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/configurecostallocreport.html), dargestellt wird. Weitere Informationen finden Sie in den [AWS Well-Architected Labs](https://www.wellarchitectedlabs.com/cost/300_labs/300_cur_queries/). Dort finden Sie Beispiele für die Gewinnung von Kosten- und Nutzungsinformationen aus CUR-Daten. ## Berichterstellung Zusätzlich zu den verfügbaren AWS Tools zur Unterstützung bei Showbacks und Chargebacks gibt es eine Reihe anderer AWS Lösungen von Drittanbietern, mit denen Sie die Kosten für markierte Ressourcen überwachen und die Effektivität der Tagging-Strategie messen können. Je nach den Anforderungen und dem Endziel des Unternehmens könnte man entweder Zeit und Ressourcen in die Entwicklung maßgeschneiderter Lösungen investieren oder Tools erwerben, die von einem der Kompetenzpartner für [AWS Cloud Management-Tools](https://aws.amazon.com/products/management-tools/partner-solutions/?partner-solutions-cards.sort-by=item.additionalFields.partnerNameLower&partner-solutions-cards.sort-order=asc&awsf.partner-solutions-filter-partner-type=%2Aall&awsf.Filter%20Name%3A%20partner-solutions-filter-partner-use-case=%2Aall&awsf.partner-solutions-filter-partner-location=%2Aall) bereitgestellt werden. *Wenn Sie sich dafür entscheiden, Ihr eigenes Tool zur Kostenzuweisung mit kontrollierten, für das Unternehmen relevanten Parametern zu erstellen, bietet der AWS Cost and Usage Report (CUR) detaillierteste Kosten- und Nutzungsdaten und ermöglicht die Erstellung benutzerdefinierter Optimierungs-Dashboards, die das Filtern und Gruppieren nach Konten, Diensten, Kostenkategorien, Kostenzuordnungs-Tags und mehreren anderen Dimensionen ermöglichen.* Unter den von That entwickelten CUR-basierten Lösungen AWS , die als eines dieser Tools verwendet werden können, finden Sie [Cloud Intelligence Dashboards](https://www.wellarchitectedlabs.com/cost/200_labs/200_cloud_intelligence/) auf der Website von AWS Well-Architected Labs. # Tags für Betrieb und Support Eine AWS Umgebung wird über mehrere Konten, Ressourcen und Workloads mit unterschiedlichen betrieblichen Anforderungen verfügen. Stichwörter können verwendet werden, um den Betriebsteams Kontext und Anleitungen zur Verfügung zu stellen und die Verwaltung Ihrer Services zu verbessern. Tags können auch verwendet werden, um die betriebliche Steuerung der verwalteten Ressourcen transparent zu machen. Einige der wichtigsten Faktoren, die für eine einheitliche Definition operativer Tags sprechen, sind: + **Um Ressourcen bei automatisierten Infrastrukturaktivitäten zu filtern.** Zum Beispiel beim Bereitstellen, Aktualisieren oder Löschen von Ressourcen. Ein weiterer Grund ist die Skalierung von Ressourcen zur Kostenoptimierung und zur Reduzierung der Nutzung außerhalb der Geschäftszeiten. Ein funktionierendes [AWS Beispiel finden Sie in der Instance Scheduler-Lösung](https://aws.amazon.com/solutions/implementations/instance-scheduler/). + **Identifizieren isolierter oder veralteter Ressourcen.** Ressourcen, die ihre festgelegte Lebensdauer überschritten haben oder die aufgrund interner Mechanismen als isoliert gekennzeichnet wurden, sollten entsprechend gekennzeichnet werden, um das Support-Personal bei der Untersuchung zu unterstützen. Ressourcen, die nicht mehr aktuell sind, sollten vor der Isolierung, Archivierung und Löschung gekennzeichnet werden. + **Support-Anforderungen für eine Gruppe von Ressourcen.** Ressourcen haben oft unterschiedliche Support-Anforderungen. Diese Anforderungen können beispielsweise zwischen den Teams ausgehandelt oder als Teil der Wichtigkeit einer Anwendung festgelegt werden. Weitere Hinweise zu Betriebsmodellen finden Sie in der [Säule Operational Excellence](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/operating-model.html). + **Verbessern Sie den Prozess des Incident-Managements.** Durch die Kennzeichnung von Ressourcen mit Tags, die für mehr Transparenz im Incident-Management-Prozess sorgen, können Support-Teams und Techniker sowie Teams für Major Incident Management (MIM) Ereignisse effektiver verwalten. + **Backups.** Mithilfe von Tags können Sie auch ermitteln, wie häufig Ihre Ressourcen gesichert werden müssen und wo die Sicherungskopien abgelegt werden müssen oder wo die Backups wiederhergestellt werden sollen. [Präskriptive Leitlinien für Backup- und Wiederherstellungsansätze](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/welcome.html) auf. AWS + **Patchen.** Das Patchen veränderlicher Instances, in denen sie ausgeführt werden, AWS ist sowohl für Ihre übergreifende Patch-Strategie als auch für das Patchen von Zero-Day-Schwachstellen von entscheidender Bedeutung. [Ausführlichere Hinweise zur umfassenderen Patch-Strategie finden Sie in den präskriptiven Leitlinien.](https://docs.aws.amazon.com/prescriptive-guidance/latest/patch-management-hybrid-cloud/welcome.html) [Das Patchen von Zero-Day-Sicherheitslücken wird in diesem Blog behandelt.](https://aws.amazon.com/blogs/mt/avoid-zero-day-vulnerabilities-same-day-security-patching-aws-systems-manager/) + **Operative Beobachtbarkeit.** Wenn eine operative KPI-Strategie in Ressourcen-Tags übersetzt wird, können die Betriebsteams besser verfolgen, ob die Ziele erreicht werden, um die Geschäftsanforderungen zu verbessern. Die Entwicklung einer KPI-Strategie ist ein eigenständiges Thema, konzentriert sich jedoch in der Regel auf ein Unternehmen, das sich in einem stabilen Zustand befindet oder in dem die Auswirkungen und Ergebnisse von Veränderungen gemessen werden müssen. Die [KPI-Dashboards](https://wellarchitectedlabs.com/cost/200_labs/200_cloud_intelligence/cost-usage-report-dashboards/dashboards/2c_kpi_dashboard/) (AWS Well-Architected Labs) und der Operations KPI Workshop (ein [proaktiver Service von AWS Enterprise Support](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/)) befassen sich beide mit der Messung der Leistung in einem stabilen Zustand. Der Blogartikel [Measuring the Success of Your Transformation](https://aws.amazon.com/blogs/enterprise-strategy/measuring-the-success-of-your-transformation/) zur AWS Unternehmensstrategie befasst sich mit der Messung von KPIs für ein Transformationsprogramm, wie z. B. IT-Modernisierung oder Migration von lokalen Systemen zu. AWS # Automatisierte Infrastrukturaktivitäten Tags können für eine Vielzahl von Automatisierungsaktivitäten bei der Verwaltung der Infrastruktur verwendet werden. Mit [AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/index.html) können Sie beispielsweise Automatisierungen und Runbooks auf Ressourcen verwalten, die durch das definierte Schlüssel-Wert-Paar, das Sie erstellen, spezifiziert sind. Für verwaltete Knoten könnten Sie eine Reihe von Tags definieren, um Knoten nach Betriebssystem und Umgebung zu verfolgen oder als Ziel festzulegen. Sie könnten dann ein Aktualisierungsskript für alle Knoten in einer Gruppe ausführen oder den Status dieser Knoten überprüfen. [Systems Manager Manager-Ressourcen](https://docs.aws.amazon.com/systems-manager/latest/userguide/taggable-resources.html) können auch mit Tags versehen werden, um Ihre automatisierten Aktivitäten weiter zu verfeinern und zu verfolgen. Die Automatisierung des Start- und Stopp-Lebenszyklus von Umgebungsressourcen kann für jedes Unternehmen zu einer erheblichen Kostensenkung führen. [Instance Scheduler on AWS](https://aws.amazon.com/solutions/implementations/instance-scheduler/) ist ein Beispiel für eine Lösung, mit der Amazon EC2- und Amazon RDS-Instances gestartet und gestoppt werden können, wenn sie nicht benötigt werden. Beispielsweise nutzen Entwicklerumgebungen, die Amazon EC2- oder Amazon RDS-Instances verwenden und nicht an Wochenenden laufen müssen, das Kosteneinsparungspotenzial, das das Herunterfahren dieser Instances bieten kann, nicht aus. Indem Sie die Bedürfnisse der Teams und ihrer Umgebungen analysieren und diese Ressourcen richtig kennzeichnen, um ihr Management zu automatisieren, können Sie Ihr Budget effektiv einsetzen. *Ein Beispiel für ein Schedule-Tag, das vom Instance Scheduler auf einer Amazon EC2 EC2-Instance verwendet wird:* ``` { "Tags": [ { "Key": "Schedule", "ResourceId": "i-1234567890abcdef8", "ResourceType": "instance", "Value": "mon-9am-fri-5pm" } ] } ``` # Workload-Lebenszyklus **Überprüfen Sie die Genauigkeit der unterstützenden Betriebsdaten.** Stellen Sie sicher, dass die Tags, die mit Ihrem Workload-Lebenszyklus verknüpft sind, regelmäßig überprüft werden und dass die entsprechenden Beteiligten an diesen Überprüfungen beteiligt sind. *Tabelle 7 — Überprüfen Sie die operativen Tags im Rahmen des Workload-Lebenszyklus* | Anwendungsfall | Tag-Schlüssel | Begründung | Beispielwerte | | --- | --- | --- | --- | | Kontoinhaber | example-inc:account-owner:owner | Der Besitzer des Kontos und der darin enthaltenen Ressourcen. | ops-center, dev-ops, app-team | | Bewertung des Kontoinhabers | example-inc:account-owner:review | Überprüfung der Angaben zur Kontoinhaberschaft auf dem neuesten Stand und korrekt. | | | Eigentümer der Daten | example-inc:data-owner:owner | Der Dateneigentümer der Konten, in denen Daten gespeichert sind. | bi-team, logistics, security | | Bewertung des Dateninhabers | example-inc:data-owner:review | Überprüfung der Aktualität und Richtigkeit der Angaben zum Dateneigentum. | | ## Zuweisen von Tags zu gesperrten Konten vor der Migration zur gesperrten Organisationseinheit Bevor Sie ein Konto sperren und in die gesperrte Organisationseinheit wechseln, wie im Whitepaper [Organizing Your AWS Environment Using Multiple Accounts](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html) beschrieben, sollten Sie dem Konto Tags hinzufügen, um Sie bei der internen Rückverfolgung und Prüfung des Lebenszyklus eines Accounts zu unterstützen. Zum Beispiel eine relative URL oder Ticketreferenz im ITSM-Ticketsystem einer Organisation, die den Prüfpfad für eine Anwendung anzeigt, die gesperrt wurde. *Tabelle 8 — Fügen Sie Betriebs-Tags hinzu, wenn der Workload-Lebenszyklus in eine neue Phase eintritt* | Anwendungsfall | Tag-Schlüssel | Begründung | Beispielwerte | | --- | --- | --- | --- | | Kontoinhaber | example-inc:account-owner:owner | Der Besitzer des Kontos und der darin enthaltenen Ressourcen. | ops-center, dev-ops, app-team | | Eigentümer der Daten | example-inc:data-owner:owner | Der Dateneigentümer der Konten, in denen Daten gespeichert sind. | bi-team, logistics, security | | Datum der Sperrung | example-inc:suspension:date | Das Datum, an dem das Konto gesperrt wurde | | | Genehmigung zur Aussetzung | example-inc:suspension:approval | Der Link zur Genehmigung der Kontosperrung | workload/deprecation | # Vorfallmanagement Tags können in allen Phasen des Vorfallmanagements eine wichtige Rolle spielen, angefangen bei der Protokollierung, Priorisierung, Untersuchung, Kommunikation, Lösung bis hin zur Schließung von Vorfällen. Mithilfe von Tags können detailliert beschrieben werden, wo ein Vorfall protokolliert werden soll, welches Team oder welche Teams über den Vorfall informiert werden sollen und welche Eskalationspriorität festgelegt wurde. Es ist wichtig, sich daran zu erinnern, dass Tags nicht verschlüsselt sind. Überlegen Sie sich also, welche Informationen Sie darin speichern. Außerdem ändern sich die Zuständigkeiten in Organisationen, Teams und Berichtslinien. Erwägen Sie daher, einen Link zu einem sicheren Portal zu speichern, über das diese Informationen effektiver verwaltet werden können. Diese Tags müssen nicht exklusiv sein. Die Anwendungs-ID könnte beispielsweise verwendet werden, um die Eskalationspfade in einem IT-Servicemanagement-Portal nachzuschlagen. Stellen Sie sicher, dass aus Ihren betrieblichen Definitionen eindeutig hervorgeht, dass dieses Tag für mehrere Zwecke verwendet wird. Die Tags für betriebliche Anforderungen können ebenfalls detailliert sein, damit Störfallmanager und Betriebspersonal ihre Ziele als Reaktion auf einen Vorfall oder ein Ereignis weiter verfeinern können. Relative Links (zur Knowledge-System-Basis-URL) für [Runbooks](https://wa.aws.amazon.com/wellarchitected/2020-07-02T19-33-23/wat.concept.runbook.en.html) und [Playbooks](https://wa.aws.amazon.com/wellarchitected/2020-07-02T19-33-23/wat.concept.playbook.en.html) können als Tags hinzugefügt werden, um die antwortenden Teams bei der Identifizierung der entsprechenden Prozesse, Verfahren und Unterlagen zu unterstützen. *Tabelle 9 — Verwenden Sie betriebliche Kennzeichnungen als Grundlage für das Incident Management* | Anwendungsfall | Tag-Schlüssel | Begründung | Beispielwerte | | --- | --- | --- | --- | | Vorfallmanagement | example-inc:incident-management:escalationlog | Das System, das vom Support-Team zur Protokollierung von Vorfällen verwendet wird | jira, servicenow, zendesk | | Vorfallmanagement | example-inc:incident-management:escalationpath | Pfad der Eskalation | ops-center, dev-ops, app-team | | Kostenverteilung und Vorfallmanagement | example-inc:cost-allocation:CostCenter | Überwachen Sie die Kosten nach Kostenstellen. Dies ist ein Beispiel für ein Tag mit doppeltem Verwendungszweck, bei dem die Kostenstelle als Anwendungscode für die Vorfallprotokollierung verwendet wird | 123-\$1 | | Sicherungsplan | example-inc:backup:schedule | Backup-Zeitplan der Ressource | Daily | | Spielbuch//Vorfallmanagement | example-inc:incident-management:playbook | Dokumentiertes Playbook | webapp/incident/playbook | # Patchen Organizations können ihre Patching-Strategie für veränderliche Computerumgebungen automatisieren und dafür sorgen, dass veränderbare Instanzen mit der definierten Patch-Baseline dieser Anwendungsumgebung Schritt halten, indem sie AWS Systems Manager Patch Manager und verwenden. AWS Lambda****Eine Tagging-Strategie für veränderbare Instanzen in diesen Umgebungen kann verwaltet werden, indem diese Instanzen Patchgruppen und Wartungsfenstern zugewiesen werden.**** In den folgenden Beispielen finden Sie eine Aufteilung von Dev → Test → Prod. AWS Für das [Patch-Management](https://docs.aws.amazon.com/prescriptive-guidance/latest/patch-management-hybrid-cloud/welcome.html) veränderlicher Instances sind präskriptive Anleitungen verfügbar. *Tabelle 10 — Betriebs-Tags können umgebungsspezifisch sein* | Entwicklung | Staging | Produktion | | --- | --- | --- | | 
{
"Tags": [
{
"Key": "Maintenance Window",
"ResourceId": "i-012345678ab9ab111",
"ResourceType": "instance",
"Value": "cron(30 23 ? * TUE#1 *)"
},
{
"Key": "Name",
"ResourceId": "i-012345678ab9ab222",
"ResourceType": "instance",
"Value": "WEBAPP"
},
{
"Key": "Patch Group",
"ResourceId": "i-012345678ab9ab333",
"ResourceType": "instance",
"Value": "WEBAPP-DEV-AL2"
}
]
}
| 
{
"Tags": [
{
"Key": "Maintenance Window",
"ResourceId": "i-012345678ab9ab444",
"ResourceType": "instance",
"Value": "cron(30 23 ? * TUE#2 *)"
},
{
"Key": "Name",
"ResourceId": "i-012345678ab9ab555",
"ResourceType": "instance",
"Value": "WEBAPP"
},
{
"Key": "Patch Group",
"ResourceId": "i-012345678ab9ab666",
"ResourceType": "instance",
"Value": "WEBAPP-TEST-AL2"
}
]
}
| 
{
"Tags": [
{
"Key": "Maintenance Window",
"ResourceId": "i-012345678ab9ab777",
"ResourceType": "instance",
"Value": "cron(30 23 ? * TUE#3 *)"
},
{
"Key": "Name",
"ResourceId": "i-012345678ab9ab888",
"ResourceType": "instance",
"Value": "WEBAPP"
},
{
"Key": "Patch Group",
"ResourceId": "i-012345678ab9ab999",
"ResourceType": "instance",
"Value": "WEBAPP-PROD-AL2"
}
]
}
| Zero-Day-Schwachstellen können auch behoben werden, indem Tags definiert werden, die Ihre Patch-Strategie ergänzen. Eine ausführliche Anleitung finden Sie unter [Vermeiden von Zero-Day-Sicherheitslücken mit Sicherheitspatches am selben Tag mithilfe von AWS Systems Manager](https://aws.amazon.com/blogs/mt/avoid-zero-day-vulnerabilities-same-day-security-patching-aws-systems-manager/). # Operative Beobachtbarkeit Beobachtbarkeit ist erforderlich, um umsetzbare Erkenntnisse über die Leistung Ihrer Umgebungen zu gewinnen und Probleme zu erkennen und zu untersuchen. Sie hat auch einen sekundären Zweck, der es Ihnen ermöglicht, wichtige Leistungsindikatoren (KPIs) und Service-Level-Ziele (SLOs) wie die Verfügbarkeit zu definieren und zu messen. Für die meisten Unternehmen KPIs sind die Mean Time to Detect (MTTD) und die Mean Time to Recovery (MTTR) nach einem Vorfall wichtige Operationen. Bei der Beobachtbarkeit ist der Kontext wichtig, da Daten gesammelt und anschließend die zugehörigen Tags gesammelt werden. Unabhängig davon, auf welche Service-, Anwendungs- oder Anwendungsebene Sie sich konzentrieren, können Sie nach diesem bestimmten Datensatz filtern und analysieren. Mithilfe von Stichwörtern können Sie das Onboarding von CloudWatch Alarmen automatisieren, sodass die richtigen Teams benachrichtigt werden können, wenn bestimmte Messwerte überschritten werden. Beispielsweise könnten ein Tag-Schlüssel `example-inc:ops:alarm-tag` und der darauf stehende Wert darauf hinweisen, dass der Alarm ausgelöst wurde. CloudWatch Eine Lösung, die dies demonstriert, ist unter [Verwenden von Tags zur Erstellung und Verwaltung von CloudWatch Amazon-Alarmen für Amazon EC2-Instances](https://aws.amazon.com/blogs/mt/use-tags-to-create-and-maintain-amazon-cloudwatch-alarms-for-amazon-ec2-instances-part-1/) beschrieben. Wenn zu viele Alarme konfiguriert sind, kann dies leicht zu einem Alarmsturm führen — wenn eine große Anzahl von Alarmen oder Benachrichtigungen die Bediener schnell überfordert und ihre Gesamteffizienz beeinträchtigt, während die Bediener einzelne Alarme manuell auswählen und priorisieren. Zusätzlicher Kontext für die Alarme kann in Form von Tags bereitgestellt werden, was bedeutet, dass Regeln innerhalb von Amazon definiert werden können, EventBridge um sicherzustellen, dass der Fokus auf das vorgelagerte Problem und nicht auf nachgelagerte Abhängigkeiten gelegt wird. Die Rolle des Nebenbetriebs DevOps wird oft übersehen, aber in vielen Unternehmen leisten die zentralen Betriebsteams auch außerhalb der normalen Geschäftszeiten immer noch eine wichtige Erstreaktion. (Weitere Einzelheiten zu diesem Modell finden Sie im [Whitepaper Operational Excellence](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/separated-aeo-ieo-with-cent-gov-and-partner.html).) Im Gegensatz zu dem DevOps Team, das für den Workload verantwortlich ist, verfügen sie in der Regel nicht über die gleiche Tiefe an Wissen, sodass der Kontext, den Tags in Dashboards und Benachrichtigungen bereitstellen, sie zum richtigen Runbook für das Problem weiterleiten oder ein automatisiertes Runbook initiieren kann (weitere Informationen finden Sie im Blogbeitrag [Automating Amazon CloudWatch ](https://aws.amazon.com/blogs/mt/automating-amazon-cloudwatch-alarms-with-aws-systems-manager/) Alarms with). AWS Systems Manager # Tags für Datensicherheit, Risikomanagement und Zugriffskontrolle Organizations haben unterschiedliche Bedürfnisse und Verpflichtungen in Bezug auf den angemessenen Umgang mit der Datenspeicherung und -verarbeitung zu erfüllen. Die Datenklassifizierung ist ein wichtiger Vorläufer für verschiedene Anwendungsfälle wie Zugriffskontrolle, Datenspeicherung, Datenanalyse und Einhaltung von Vorschriften. # Datensicherheit und Risikomanagement In einer AWS Umgebung werden Sie wahrscheinlich Konten mit unterschiedlichen Compliance- und Sicherheitsanforderungen haben. Beispielsweise verfügen Sie möglicherweise über eine Entwickler-Sandbox und ein Konto, das die Produktionsumgebung für stark regulierte Arbeitslasten hostet, z. B. für die Verarbeitung von Zahlungen. Indem Sie sie auf verschiedene Konten isolieren, können Sie [unterschiedliche Sicherheitskontrollen anwenden](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/benefits-of-using-multiple-aws-accounts.html#apply-distinct-security-controls-by-environment), den [Zugriff auf vertrauliche Daten einschränken](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/benefits-of-using-multiple-aws-accounts.html#constrain-access-to-sensitive-data) und den Prüfungsumfang für regulierte Workloads reduzieren. Die Einführung eines einzigen Standards für alle Workloads kann zu Herausforderungen führen. Während viele Kontrollen in der gesamten Umgebung gleichermaßen gelten, sind einige Kontrollen übertrieben oder irrelevant für Konten, die keine spezifischen rechtlichen Rahmenbedingungen erfüllen müssen, und für Konten, bei denen niemals personenbezogene Daten vorhanden sein werden (z. B. eine Entwickler-Sandbox oder Konten für Workload-Entwicklung). Dies führt in der Regel zu falsch positiven Sicherheitsergebnissen, die geprüft und geschlossen werden müssen, ohne dass Maßnahmen ergriffen werden, was den Aufwand der Ergebnisse, die untersucht werden sollten, überflüssig macht. *Tabelle 11 — Beispiele für Tags für Datensicherheit und Risikomanagement* | Anwendungsfall | Tag-Schlüssel | Begründung | Beispielwerte | | --- | --- | --- | --- | | Vorfallmanagement | example-inc:incident- management:escalationlog | Das System, das vom Support-Team zur Protokollierung von Vorfällen verwendet wird | jira, servicenow, zendesk | | Vorfallmanagement | example-inc:incident- management:escalationpath | Pfad der Eskalation | ops-center, dev-ops, app-team | | Datenklassifizierung | example-inc:data:classification | Klassifizieren Sie Daten aus Gründen der Einhaltung von Vorschriften und Unternehmensführung | Public, Private, Confidential, Restricted | | Compliance | example-inc:compliance:framework | Identifiziert das Compliance-Framework, dem die Arbeitslast unterliegt | PCI-DSS, HIPAA | Die manuelle Verwaltung verschiedener Kontrollen in einer AWS Umgebung ist sowohl zeitaufwändig als auch fehleranfällig. Der nächste Schritt besteht darin, die Implementierung geeigneter Sicherheitskontrollen zu automatisieren und die Überprüfung der Ressourcen auf der Grundlage der Klassifizierung dieses Kontos zu konfigurieren. Durch das Anwenden von Tags auf die Konten und die darin enthaltenen Ressourcen kann die Implementierung von Kontrollen automatisiert und entsprechend der Arbeitslast konfiguriert werden. **Beispiel: ** Ein Workload umfasst einen Amazon S3 S3-Bucket mit dem Tag `example-inc:data:classification` mit dem Wert`Private`. Die Automatisierung der Sicherheitstools stellt eine AWS Config Regel bereit`s3-bucket-public-read-prohibited`, die die Block Public Access-Einstellungen des Amazon S3 S3-Buckets, die Bucket-Richtlinie und die Bucket-Zugriffskontrollliste (ACL) überprüft und bestätigt, dass die Konfiguration des Buckets für seine Datenklassifizierung geeignet ist. Um sicherzustellen, dass der Inhalt des Buckets mit der Klassifizierung übereinstimmt, [kann Amazon Macie so konfiguriert werden, dass nach personenbezogenen Daten (PII) gesucht](https://aws.amazon.com/about-aws/whats-new/2021/05/amazon-macie-supports-criteria-based-bucket-selection-sensitive-data-discovery-jobs/) wird. Der Blog [Using Amazon Macie to Validate S3 Bucket Data Classification](https://aws.amazon.com/blogs/architecture/using-amazon-macie-to-validate-s3-bucket-data-classification/) untersucht dieses Muster eingehender. Bestimmte regulatorische Rahmenbedingungen, wie z. B. Versicherungen und Gesundheitswesen, unterliegen möglicherweise verbindlichen Richtlinien zur Aufbewahrung von Daten. Die Datenspeicherung mithilfe von Tags in Kombination mit Amazon S3 Lifecycle-Richtlinien kann eine effektive und einfache Möglichkeit sein, Objektübergänge auf eine andere Speicherebene zu regeln. Amazon S3 S3-Lebenszyklusregeln können auch verwendet werden, um Objekte für die Datenlöschung nach Ablauf der obligatorischen Aufbewahrungsfrist ablaufen zu lassen. Eine ausführliche Anleitung zu diesem Prozess finden Sie unter [Vereinfachen Sie Ihren Datenlebenszyklus durch die Verwendung von Objekt-Tags mit Amazon S3 Lifecycle](https://aws.amazon.com/blogs/storage/simplify-your-data-lifecycle-by-using-object-tags-with-amazon-s3-lifecycle/). Darüber hinaus können Tags dem Prüfer bei der Suche oder Behebung von Sicherheitslücken wichtigen Kontext liefern, der ihm hilft, das Risiko einzuschätzen, und hilft dabei, die entsprechenden Teams mit der Untersuchung oder Abschwächung der Ergebnisse zu beauftragen. # Tags für Identitätsmanagement und Zugriffskontrolle Bei der Verwaltung der Zugriffskontrolle in einer AWS Umgebung mit AWS IAM Identity Center können Tags verschiedene Skalierungsmuster ermöglichen. Es gibt mehrere Delegierungsmuster, die angewendet werden können. Einige basieren auf Tagging. Wir werden sie einzeln behandeln und Links zu weiterführenden Informationen zu jedem Thema bereitstellen. # ABAC für einzelne Ressourcen IAM Identity Center-Benutzer und IAM-Rollen unterstützen die attributebasierte Zugriffskontrolle (ABAC), mit der Sie den Zugriff auf Operationen und Ressourcen anhand von Tags definieren können. ABAC reduziert die Notwendigkeit, die Berechtigungsrichtlinien zu aktualisieren, und unterstützt Sie dabei, den Zugriff auf Mitarbeiterattribute aus Ihrem Unternehmensverzeichnis zu stützen. Wenn Sie bereits eine Strategie für mehrere Konten verwenden, kann ABAC zusätzlich zur rollenbasierten Zugriffskontrolle (RBAC) verwendet werden, um mehreren Teams, die mit demselben Konto arbeiten, granularen Zugriff auf verschiedene Ressourcen zu ermöglichen. Beispielsweise können IAM Identity Center-Benutzer oder IAM-Rollen Bedingungen zur Beschränkung des Zugriffs auf bestimmte Amazon EC2 EC2-Instances enthalten, die andernfalls explizit in jeder Richtlinie aufgeführt werden müssten, um auf sie zugreifen zu können. Da ein ABAC-Autorisierungsmodell für den Zugriff auf Operationen und Ressourcen von Tags abhängt, ist es wichtig, Schutzmaßnahmen vorzusehen, um unbeabsichtigten Zugriff zu verhindern. SCPs kann verwendet werden, um Tags in Ihrer gesamten Organisation zu schützen, indem Tags nur unter bestimmten Bedingungen geändert werden dürfen. Informationen zur Implementierung finden Sie [in den Blogs Sicherung von Ressourcen-Tags, die für die Autorisierung mithilfe einer Dienststeuerungsrichtlinie verwendet](https://aws.amazon.com/blogs/security/securing-resource-tags-used-for-authorization-using-service-control-policy-in-aws-organizations/) werden, AWS Organizations und [Zugriffsgrenzen für IAM-Entitäten](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html). Wenn langlebige Amazon EC2-Instances zur Unterstützung traditionellerer Betriebspraktiken verwendet werden, kann dieser Ansatz verwendet werden. Im Blog [Configure IAM Identity Center ABAC for Amazon EC2 Instances and Systems Manager Session Manager](https://aws.amazon.com/blogs/security/configure-aws-sso-abac-for-ec2-instances-and-systems-manager-session-manager/) wird diese Form der attributbasierten Zugriffskontrolle ausführlicher beschrieben. Wie bereits erwähnt, unterstützen nicht alle Ressourcentypen das Tagging, und von denen, die dies tun, unterstützen nicht alle die Durchsetzung mithilfe von Tag-Richtlinien. Daher ist es ratsam, dies zu überprüfen, bevor Sie mit der Implementierung dieser Strategie auf einem beginnen AWS-Konto. Weitere Informationen zu Diensten, die ABAC unterstützen, finden Sie unter [AWS Dienste, die mit IAM funktionieren](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html).