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. # Planung Ihres CloudWatch Einsatzes Die Komplexität und der Umfang einer Protokollierungs- und Überwachungslösung hängen von mehreren Faktoren ab, darunter: + Wie viele Umgebungen, Regionen und Konten verwendet werden und wie sich diese Zahl erhöhen könnte. + Die Vielfalt und Typen Ihrer vorhandenen Workloads und Architekturen. + Die Rechenarten und OSs das müssen protokolliert und überwacht werden. + Ob es sowohl lokale Standorte als auch AWS Infrastruktur gibt. + Die Aggregations- und Analyseanforderungen mehrerer Systeme und Anwendungen. + Sicherheitsanforderungen, die die unbefugte Offenlegung von Protokollen und Metriken verhindern. + Produkte und Lösungen, die zur Unterstützung betrieblicher Prozesse in Ihre Protokollierungs- und Überwachungslösung integriert werden müssen. Sie müssen Ihre Protokollierungs- und Überwachungslösung regelmäßig überprüfen und mit neuen oder aktualisierten Workload-Bereitstellungen aktualisieren. Aktualisierungen Ihrer Protokollierungs-, Überwachungs- und Warnmeldungen sollten identifiziert und angewendet werden, wenn Probleme auftreten. Diese Probleme können dann proaktiv identifiziert und in future verhindert werden. Sie müssen sicherstellen, dass Sie Software und Dienste für die Erfassung und Erfassung von Protokollen und Messdaten konsistent installieren und konfigurieren. Ein etablierter Protokollierungs- und Überwachungsansatz verwendet Dienste und Lösungen mehrerer AWS oder unabhängiger Softwareanbieter (ISV) für verschiedene Bereiche (z. B. Sicherheit, Leistung, Netzwerke oder Analysen). Jede Domäne hat ihre eigenen Bereitstellungs- und Konfigurationsanforderungen. Wir empfehlen CloudWatch die Verwendung zum Erfassen und Ingestieren von Protokollen und Metriken für mehrere Typen OSs und Rechenarten. Viele AWS Dienste werden verwendet, CloudWatch um Logs und Metriken zu protokollieren, zu überwachen und zu veröffentlichen, ohne dass eine weitere Konfiguration erforderlich ist. CloudWatch stellt einen [Softwareagenten](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html) bereit, der für verschiedene Umgebungen installiert OSs und konfiguriert werden kann. In den folgenden Abschnitten wird beschrieben, wie der CloudWatch Agent für mehrere Konten, Regionen und Konfigurationen bereitgestellt, installiert und konfiguriert wird: **Topics** + [ # Verwendung CloudWatch in zentralisierten oder verteilten Konten ](cloudwatch-centralized-distributed-accounts.md) + [ # Verwaltung von CloudWatch Agenten-Konfigurationsdateien ](create-store-cloudwatch-configurations.md) # Verwendung CloudWatch in zentralisierten oder verteilten Konten Obwohl CloudWatch es für die Überwachung von AWS Diensten oder Ressourcen in einem Konto und einer Region konzipiert ist, können Sie ein zentrales Konto verwenden, um Protokolle und Metriken aus mehreren Konten und Regionen zu erfassen. Wenn Sie mehr als ein Konto oder eine Region verwenden, sollten Sie abwägen, ob Sie den zentralisierten Kontoansatz oder ein einzelnes Konto zur Erfassung von Protokollen und Metriken verwenden möchten. In der Regel ist für Bereitstellungen mit mehreren Konten und mehreren Regionen ein hybrider Ansatz erforderlich, um die Anforderungen von Sicherheits-, Analyse-, Betriebs- und Workload-Eigentümern zu erfüllen. Die folgende Tabelle enthält Bereiche, die Sie bei der Wahl eines zentralisierten, verteilten oder hybriden Ansatzes berücksichtigen sollten. **** | | | | --- |--- | | Kontostrukturen | Ihr Unternehmen verfügt möglicherweise über mehrere separate Konten (z. B. Konten für Nicht-Produktions- und Produktionsworkloads) oder Tausende von Konten für einzelne Anwendungen in bestimmten Umgebungen. Wir empfehlen, dass Sie Anwendungsprotokolle und Metriken in dem Konto verwalten, auf dem der Workload ausgeführt wird, sodass Workload-Besitzer auf die Protokolle und Metriken zugreifen können. Dadurch können sie eine aktive Rolle bei der Protokollierung und Überwachung spielen. Wir empfehlen außerdem, ein separates Protokollierungskonto zu verwenden, um alle Workload-Protokolle für Analysen, Aggregation, Trends und zentralisierte Operationen zu aggregieren. Separate Protokollierungskonten können auch für Sicherheit, Archivierung und Überwachung sowie für Analysen verwendet werden. | | Anforderungen für den Zugriff | Teammitglieder (z. B. Workload-Besitzer oder Entwickler) benötigen Zugriff auf Protokolle und Metriken, um Fehler zu beheben und Verbesserungen vorzunehmen. Die Protokolle sollten im Konto des Workloads gespeichert werden, um den Zugriff und die Fehlerbehebung zu erleichtern. Wenn Protokolle und Metriken in einem vom Workload getrennten Konto verwaltet werden, müssen Benutzer möglicherweise regelmäßig zwischen den Konten wechseln. Durch die Verwendung eines zentralen Kontos werden Protokollinformationen für autorisierte Benutzer bereitgestellt, ohne dass Zugriff auf das Workload-Konto gewährt wird. Dies kann die Zugriffsanforderungen für analytische Workloads vereinfachen, bei denen eine Aggregation von Workloads erforderlich ist, die in mehreren Konten ausgeführt werden. Das zentralisierte Logging-Konto kann auch alternative Such- und Aggregationsoptionen haben, z. B. einen Amazon OpenSearch Service-Cluster. Amazon OpenSearch Service [bietet eine detaillierte Zugriffskontrolle](https://docs.aws.amazon.com//opensearch-service/latest/developerguide/fgac.html) bis auf Feldebene für Ihre Protokolle. Eine detaillierte Zugriffskontrolle ist wichtig, wenn Sie über sensible oder vertrauliche Daten verfügen, für die spezielle Zugriffs- und Genehmigungen erforderlich sind. | | Operationen | Viele Unternehmen verfügen über ein zentrales Betriebs- und Sicherheitsteam oder eine externe Organisation für den operativen Support, die zur Überwachung Zugriff auf Protokolle benötigt. Zentralisierte Protokollierung und Überwachung können es einfacher machen, Trends zu erkennen, zu suchen, zu aggregieren und Analysen für alle Konten und Workloads durchzuführen. Wenn Ihre Organisation den Ansatz „[Sie erstellen, Sie führen es aus](https://aws.amazon.com//blogs/enterprise-strategy/enterprise-devops-why-you-should-run-what-you-build/)“ verwendet DevOps, benötigen Workload-Besitzer Protokollierungs- und Überwachungsinformationen in ihrem Konto. Neben der Verantwortung für verteilte Workloads kann ein hybrider Ansatz erforderlich sein, um zentralen Abläufen und Analysen gerecht zu werden. | | Umgebung | Je nach Sicherheitsanforderungen und Kontoarchitektur können Sie Protokolle und Messwerte für Produktionskonten an einem zentralen Ort hosten und Protokolle und Metriken für andere Umgebungen (z. B. Entwicklungs- oder Testumgebungen) in denselben oder separaten Konten speichern. Auf diese Weise wird verhindert, dass sensible Daten, die während der Produktion erstellt wurden, von einem breiteren Publikum abgerufen werden. | CloudWatch bietet [mehrere Optionen](https://docs.aws.amazon.com//AmazonCloudWatch/latest/logs/Subscriptions.html) zur Verarbeitung von Protokollen in Echtzeit mit CloudWatch Abonnementfiltern. Sie können Abonnementfilter verwenden, um Protokolle in Echtzeit an AWS Dienste zu streamen, um sie dort individuell zu verarbeiten, zu analysieren und in andere Systeme zu laden. Dies kann besonders hilfreich sein, wenn Sie einen hybriden Ansatz verfolgen, bei dem Ihre Protokolle und Metriken zusätzlich zu einem zentralisierten Konto und einer Region auch in einzelnen Konten und Regionen verfügbar sind. Die folgende Liste enthält Beispiele für AWS Dienste, die dafür verwendet werden können: + [Amazon Data Firehose — Firehose](https://docs.aws.amazon.com//firehose/latest/dev/what-is-this-service.html) bietet eine Streaming-Lösung, die automatisch auf der Grundlage des produzierten Datenvolumens skaliert und in der Größe angepasst wird. Sie müssen die Anzahl der Shards in einem Amazon Kinesis Kinesis-Datenstream nicht verwalten und können sich ohne zusätzliche Codierung direkt mit Amazon Simple Storage Service (Amazon S3), Amazon OpenSearch Service oder Amazon Redshift verbinden. Firehose ist eine effektive Lösung, wenn Sie Ihre Protokolle in diesen AWS Diensten zentralisieren möchten. + [Amazon Kinesis Data Streams](https://docs.aws.amazon.com//streams/latest/dev/introduction.html) — Kinesis Data Streams ist eine geeignete Lösung, wenn Sie eine Integration in einen Service benötigen, den Firehose nicht unterstützt, und zusätzliche Verarbeitungslogik implementieren müssen. Sie können in Ihren Konten und Regionen ein Amazon CloudWatch Logs-Ziel erstellen, das einen Kinesis-Datenstream in einem zentralen Konto und eine AWS Identity and Access Management (IAM) -Rolle angibt, die ihm die Erlaubnis erteilt, Datensätze im Stream zu platzieren. Kinesis Data Streams bietet eine flexible, offene landing zone für Ihre Protokolldaten, die dann von verschiedenen Optionen genutzt werden können. Sie können die Kinesis Data Streams Streams-Protokolldaten in Ihr Konto einlesen, eine Vorverarbeitung durchführen und die Daten an das von Ihnen gewählte Ziel senden. Sie müssen die Shards für den Stream jedoch so konfigurieren, dass er die richtige Größe für die erzeugten Protokolldaten hat. Kinesis Data Streams fungiert als temporärer Vermittler oder als Warteschlange für Ihre Protokolldaten, und Sie können die Daten zwischen einem und 365 Tagen im Kinesis-Stream speichern. Kinesis Data Streams unterstützt auch die Wiedergabefunktion, d. h. Sie können Daten wiedergeben, die nicht verbraucht wurden. + [Amazon OpenSearch Service](https://docs.aws.amazon.com//opensearch-service/latest/developerguide/what-is.html) — CloudWatch Logs können Protokolle in einer Protokollgruppe in einen OpenSearch Cluster in einem individuellen oder zentralen Konto streamen. Wenn Sie eine Protokollgruppe so konfigurieren, dass sie Daten in einen OpenSearch Cluster streamt, wird eine Lambda-Funktion in demselben Konto und derselben Region wie Ihre Protokollgruppe erstellt. Die Lambda-Funktion muss über eine Netzwerkverbindung mit dem OpenSearch Cluster verfügen. Sie können die Lambda-Funktion so anpassen, dass sie zusätzlich zur Anpassung der Aufnahme in Amazon Service zusätzliche Vorverarbeitung durchführt. OpenSearch Die zentrale Protokollierung mit Amazon OpenSearch Service erleichtert die Analyse, Suche und Behebung von Problemen in mehreren Komponenten Ihrer Cloud-Architektur. + [Lambda](https://docs.aws.amazon.com//lambda/latest/dg/welcome.html) — Wenn Sie Kinesis Data Streams verwenden, müssen Sie Rechenressourcen bereitstellen und verwalten, die Daten aus Ihrem Stream verbrauchen. Um dies zu vermeiden, können Sie Protokolldaten zur Verarbeitung direkt an Lambda streamen und sie an ein Ziel senden, das Ihrer Logik entspricht. Das bedeutet, dass Sie keine Rechenressourcen bereitstellen und verwalten müssen, um eingehende Daten zu verarbeiten. Wenn Sie Lambda verwenden möchten, stellen Sie sicher, dass Ihre Lösung mit [Lambda-Kontingenten](https://docs.aws.amazon.com//lambda/latest/dg/gettingstarted-limits.html) kompatibel ist. Möglicherweise müssen Sie Protokolldaten verarbeiten oder weitergeben, die in CloudWatch Logs im Dateiformat gespeichert sind. Sie können eine Exportaufgabe erstellen, um [eine Protokollgruppe für ein bestimmtes Datum oder einen bestimmten Zeitraum nach Amazon S3 zu exportieren](https://docs.aws.amazon.com//AmazonCloudWatch/latest/logs/S3Export.html). Sie können sich beispielsweise dafür entscheiden, Protokolle täglich zur Analyse und Prüfung nach Amazon S3 zu exportieren. Lambda kann verwendet werden, um diese Lösung zu automatisieren. Sie können diese Lösung auch mit der Amazon S3 S3-Replikation kombinieren, um Ihre Protokolle aus mehreren Konten und Regionen zu versenden und zu einem zentralen Konto und einer Region zu zentralisieren. In der CloudWatch Agentenkonfiguration kann auch ein `credentials` Feld in dem [`agent`Abschnitt](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-Configuration-File-Details.html#CloudWatch-Agent-Configuration-File-Agentsection) angegeben werden. Dies gibt eine IAM-Rolle an, die beim Senden von Metriken und Protokollen an ein anderes Konto verwendet werden soll. Falls angegeben, enthält dieses Feld den `role_arn` Parameter. Dieses Feld kann verwendet werden, wenn Sie nur eine zentrale Protokollierung und Überwachung für ein bestimmtes zentralisiertes Konto und eine bestimmte Region benötigen. Sie können [AWS das SDK](https://aws.amazon.com/developer/tools/) auch verwenden, um Ihre eigene benutzerdefinierte Verarbeitungsanwendung in einer Sprache Ihrer Wahl zu schreiben, Protokolle und Metriken aus Ihren Konten zu lesen und Daten zur weiteren Verarbeitung und Überwachung an ein zentrales Konto oder ein anderes Ziel zu senden. # Verwaltung von CloudWatch Agenten-Konfigurationsdateien Wir empfehlen Ihnen, eine standardmäßige CloudWatch Amazon-Agentenkonfiguration zu erstellen, die die Systemprotokolle und Metriken enthält, die Sie für all Ihre Amazon Elastic Compute Cloud (Amazon EC2) -Instances und lokalen Server erfassen möchten. Sie können den [Assistenten für die CloudWatch Agentenkonfigurationsdatei](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/create-cloudwatch-agent-configuration-file-wizard.html) verwenden, um Ihnen bei der Erstellung der Konfigurationsdatei zu helfen. Sie können den Konfigurationsassistenten mehrmals ausführen, um eindeutige Konfigurationen für verschiedene Systeme und Umgebungen zu generieren. Sie können die Konfigurationsdatei auch ändern oder Varianten erstellen, indem Sie [das Konfigurationsdateischema verwenden](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-Configuration-File-Details.html). Die CloudWatch Agentenkonfigurationsdatei kann in den Parametern des [AWS Systems Manager Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html) gespeichert werden.  Sie können separate Parameter Store-Parameter erstellen, wenn Sie über [mehrere CloudWatch Agenten-Konfigurationsdateien](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-common-scenarios.html#CloudWatch-Agent-multiple-config-files) verfügen. Wenn Sie mehrere AWS-Konten oder AWS-Regionen verwenden, müssen Sie die Parameter Store-Parameter in jedem Konto und jeder Region verwalten und aktualisieren. Alternativ können Sie Ihre CloudWatch Konfigurationen zentral als Dateien in Amazon S3 oder einem Versionskontrolltool Ihrer Wahl verwalten.  Mit dem im CloudWatch Agenten enthaltenen `amazon-cloudwatch-agent-ctl` Skript können Sie eine Konfigurationsdatei, einen Parameter Store-Parameter oder die Standardkonfiguration des Agenten angeben. Die Standardkonfiguration richtet sich nach dem grundlegenden, vordefinierten Metriksatz und konfiguriert den Agenten so, dass er Speicher- und Festplattenspeicher-Metriken an sie meldet. CloudWatch Sie enthält jedoch keine Protokolldateikonfigurationen. Die Standardkonfiguration wird auch angewendet, wenn Sie [Systems Manager Quick Setup](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-quick-setup.html) für den CloudWatch Agenten verwenden. Da die Standardkonfiguration keine Protokollierung beinhaltet und nicht an Ihre Anforderungen angepasst ist, empfehlen wir Ihnen, Ihre eigenen, an Ihre Anforderungen angepassten CloudWatch Konfigurationen zu erstellen und anzuwenden. ## CloudWatch Konfigurationen verwalten Standardmäßig können CloudWatch Konfigurationen als Parameter Store-Parameter oder als CloudWatch Konfigurationsdateien gespeichert und angewendet werden. Die beste Wahl hängt von Ihren Anforderungen ab. In diesem Abschnitt besprechen wir die Vor- und Nachteile dieser beiden Optionen. Eine repräsentative Lösung für die Verwaltung von CloudWatch Konfigurationsdateien für mehrere AWS-Konten und AWS-Regionen wird ebenfalls detailliert beschrieben. **Systems Manager Parameter speichern** Die Verwendung von Parameter Store-Parametern zur Verwaltung von CloudWatch Konfigurationen funktioniert gut, wenn Sie über eine einzige Standardkonfigurationsdatei für CloudWatch Agenten verfügen, die Sie in einer kleinen Gruppe von AWS-Konten und Regionen anwenden und verwalten möchten. Wenn Sie Ihre CloudWatch Konfigurationen als Parameter Store-Parameter speichern, können Sie das CloudWatch Agent-Konfigurationstool (`amazon-cloudwatch-agent-ctl`unter Linux) verwenden, um die Konfiguration aus dem Parameter Store zu lesen und anzuwenden, ohne dass Sie die Konfigurationsdatei in Ihre Instance kopieren müssen. Sie können das Dokument **AmazonCloudWatch- ManageAgent ** Systems Manager Command verwenden, um die CloudWatch Konfiguration auf mehreren EC2-Instances in einem einzigen Lauf zu aktualisieren. Da Parameter Store-Parameter regional sind, müssen Sie Ihre CloudWatch Parameter Store-Parameter in jeder AWS-Region und jedem AWS-Konto aktualisieren und verwalten. Wenn Sie mehrere CloudWatch Konfigurationen haben, die Sie auf jede Instance anwenden möchten, müssen Sie das Dokument **AmazonCloudWatch- ManageAgent** Command so anpassen, dass**** es diese Parameter enthält. **CloudWatch Konfigurationsdateien** Die Verwaltung Ihrer CloudWatch Konfigurationen als Dateien funktioniert möglicherweise gut, wenn Sie viele AWS-Konten und Regionen haben und mehrere CloudWatch Konfigurationsdateien verwalten. Mit diesem Ansatz können Sie sie in einer Ordnerstruktur durchsuchen, organisieren und verwalten.  Sie können Sicherheitsregeln auf einzelne Ordner oder Dateien anwenden, um den Zugriff einzuschränken und zu gewähren, z. B. Aktualisierungs- und Leseberechtigungen. Sie können sie teilen und zur Zusammenarbeit außerhalb von AWS übertragen. Sie können die Dateien versionieren, um Änderungen nachzuverfolgen und zu verwalten. Sie können CloudWatch Konfigurationen gemeinsam anwenden, indem Sie die Konfigurationsdateien in das CloudWatch Agentenkonfigurationsverzeichnis kopieren, ohne jede Konfigurationsdatei einzeln anzuwenden. Für Linux befindet sich das CloudWatch Konfigurationsverzeichnis unter`/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.d`. Für Windows befindet sich das Konfigurationsverzeichnis unter`C:\ProgramData\Amazon\AmazonCloudWatchAgent\Configs`. Wenn Sie den CloudWatch Agenten starten, hängt der Agent automatisch jede Datei in diesen Verzeichnissen an, um eine CloudWatch zusammengesetzte Konfigurationsdatei zu erstellen. Die Konfigurationsdateien sollten an einem zentralen Ort (z. B. in einem S3-Bucket) gespeichert werden, auf den Ihre erforderlichen Konten und Regionen zugreifen können. Eine Beispiellösung, die diesen Ansatz verwendet, wird bereitgestellt. ** CloudWatch Konfigurationen organisieren** Organisieren Sie Ihre Konfigurationen unabhängig von der Methode, die Sie zur Verwaltung Ihrer CloudWatch CloudWatch Konfigurationen verwenden. Sie können Ihre Konfigurationen mithilfe eines Ansatzes wie dem folgenden in Datei- oder Parameterspeicherpfaden organisieren. | | | | --- |--- | | */config/standard/windows/ec2* | Speichern Sie standardmäßige Windows-spezifische CloudWatch Konfigurationsdateien für Amazon EC2. In diesem Ordner können Sie Ihre Standardbetriebssystemkonfigurationen (OS) für verschiedene Windows-Versionen, EC2-Instance-Typen und Umgebungen weiter kategorisieren. | | */config/standard/windows/onpremises* | Speichern Sie standardmäßige Windows-spezifische CloudWatch Konfigurationsdateien für lokale Server. In diesem Ordner können Sie auch Ihre Standard-Betriebssystemkonfigurationen für verschiedene Windows-Versionen, Servertypen und Umgebungen weiter kategorisieren. | | */2 config/standard/linux/ec* | Speichern Sie Ihre Linux-spezifischen CloudWatch Standardkonfigurationsdateien für Amazon EC2. In diesem Ordner können Sie Ihre Standard-Betriebssystemkonfiguration für verschiedene Linux-Distributionen, EC2-Instance-Typen und Umgebungen weiter kategorisieren. | | */config/standard/linux/onpremises* | Speichern Sie Ihre Linux-spezifischen CloudWatch Standardkonfigurationsdateien für lokale Server. In diesem Ordner können Sie Ihre Standard-Betriebssystemkonfiguration für verschiedene Linux-Distributionen, Servertypen und Umgebungen weiter kategorisieren. | | */config/ecs* | Speichern Sie CloudWatch Konfigurationsdateien, die für Amazon Elastic Container Service (Amazon ECS) spezifisch sind, wenn Sie Amazon ECS-Container-Instances verwenden. Diese Konfigurationen können an die Amazon EC2-Standardkonfigurationen für Amazon ECS-spezifische Protokollierung und Überwachung auf Systemebene angehängt werden. | | */config/* | Speichern Sie Ihre anwendungsspezifischen Konfigurationsdateien CloudWatch . Sie können Ihre Anwendungen mit zusätzlichen Ordnern und Präfixen für Umgebungen und Versionen weiter kategorisieren. | ## Beispiel: Speichern von CloudWatch Konfigurationsdateien in einem S3-Bucket Dieser Abschnitt enthält ein Beispiel für die Verwendung von Amazon S3 zum Speichern von CloudWatch Konfigurationsdateien und ein benutzerdefiniertes Systems Manager Manager-Runbook zum Abrufen und Anwenden der CloudWatch Konfigurationsdateien. Mit diesem Ansatz können einige der Herausforderungen gelöst werden, die mit der Verwendung von Systems Manager Parameter Store-Parametern für eine CloudWatch skalierbare Konfiguration verbunden sind: + Wenn Sie mehrere Regionen verwenden, müssen Sie die CloudWatch Konfigurationsupdates im Parameterspeicher jeder Region synchronisieren. Der Parameterspeicher ist ein regionaler Dienst, und derselbe Parameter muss in jeder Region aktualisiert werden, die den CloudWatch Agenten verwendet. + Wenn Sie über mehrere CloudWatch Konfigurationen verfügen, müssen Sie den Abruf und die Anwendung jeder Parameter Store-Konfiguration initiieren. Sie müssen jede CloudWatch Konfiguration einzeln aus dem Parameterspeicher abrufen und auch die Abrufmethode aktualisieren, wenn Sie eine neue Konfiguration hinzufügen. Im Gegensatz dazu CloudWatch stellt es ein Konfigurationsverzeichnis zum Speichern von Konfigurationsdateien bereit und wendet jede Konfiguration im Verzeichnis an, ohne dass sie einzeln angegeben werden müssen. + Wenn Sie mehrere Konten verwenden, müssen Sie sicherstellen, dass jedes neue Konto die erforderlichen CloudWatch Konfigurationen in seinem Parameterspeicher hat. Sie müssen außerdem sicherstellen, dass alle Konfigurationsänderungen in future auf diese Konten und ihre Regionen angewendet werden. Sie können CloudWatch Konfigurationen in einem S3-Bucket speichern, auf den von all Ihren Konten und Regionen aus zugegriffen werden kann. Anschließend können Sie diese Konfigurationen mithilfe von Systems Manager Automation-Runbooks und Systems Manager State Manager aus dem S3-Bucket in das CloudWatch Konfigurationsverzeichnis kopieren. Sie können die CloudFormation AWS-Vorlage [cloudwatch-config-s3-bucket.yaml](https://github.com/aws-samples/logging-monitoring-apg-guide-examples/blob/main/cloudwatch-config-s3-bucket.yaml) verwenden, um einen S3-Bucket zu erstellen, auf den von mehreren Konten innerhalb einer Organisation in AWS Organizations aus zugegriffen werden kann. [Die Vorlage enthält einen `OrganizationID` Parameter, der Lesezugriff auf alle Konten innerhalb Ihrer Organisation gewährt.](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html) Das erweiterte Systems Manager Manager-Beispiel-Runbook, das im Abschnitt [Setup up State Manager and Distributor for CloudWatch Agent Deployment and Configuration](https://docs.aws.amazon.com/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/install-cloudwatch-systems-manager.html#set-up-systems-manager-distributor) dieses Handbuchs bereitgestellt wird, ist so konfiguriert, dass Dateien mithilfe des S3-Buckets abgerufen werden, der mit der AWS-Vorlage [cloudwatch-config-s3-bucket.yaml](https://github.com/aws-samples/logging-monitoring-apg-guide-examples/blob/main/cloudwatch-config-s3-bucket.yaml) erstellt wurde. CloudFormation Alternativ können Sie (z. B. GitHub) ein Versionskontrollsystem verwenden, um Ihre Konfigurationsdateien zu speichern. Wenn Sie die in einem Versionskontrollsystem gespeicherten Konfigurationsdateien automatisch abrufen möchten, müssen Sie den Anmeldeinformationsspeicher verwalten oder zentralisieren und das Systems Manager Automation-Runbook aktualisieren, das zum Abrufen der Anmeldeinformationen für Ihre Konten und verwendet wird. AWS-Regionen