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.
# Automatisieren Sie Backups mit Amazon Data Lifecycle Manager
Sie können Amazon Data Lifecycle Manager verwenden, um die Erstellung, Aufbewahrung und Löschung von EBS-Snapshots und EBS-gestützten zu automatisieren. AMIs Wenn Sie die Snapshot- und AMI-Verwaltung automatisieren, können Sie Folgendes tun:
+ Wertvolle Daten zu schützen, indem ein regelmäßiger Backup-Plan eingehalten wird.
+ Erstellen Sie standardisierte Dateien AMIs , die in regelmäßigen Abständen aktualisiert werden können.
+ Backups aufzubewahren, die für Prüfer oder interne Compliance-Vorschriften benötigt werden.
+ Speicherkosten zu reduzieren, indem veraltete Backups gelöscht werden.
+ Erstellen Sie Backup-Richtlinien für die Notfallwiederherstellung, die Daten in isolierten Regionen oder Konten sichern.
In Kombination mit den Überwachungsfunktionen von Amazon EventBridge und AWS CloudTrail bietet Amazon Data Lifecycle Manager eine komplette Backup-Lösung für Amazon EC2 EC2-Instances und einzelne EBS-Volumes ohne zusätzliche Kosten.
**Wichtig**
Amazon Data Lifecycle Manager kann keine Snapshots verwalten oder auf andere Weise AMIs erstellt wurden.
Amazon Data Lifecycle Manager kann die Erstellung, Aufbewahrung und Löschung von Instance AMIs Store-Backed nicht automatisieren.
Amazon Data Lifecycle Manager wird als Servicefähigkeit von Amazon Elastic Block Store (Amazon EBS) bewertet. Alle [AWS Services im Rahmen des Compliance-Programms](https://aws.amazon.com/compliance/services-in-scope/) (FedRAMP, HIPAA BAA, SOC usw.), in denen Amazon EBS aufgeführt ist, gelten auch für Amazon Data Lifecycle Manager.
**Topics**
+ [Kontingente](#dlm-quotas)
+ [Funktionsweise](dlm-elements.md)
+ [Standardrichtlinien im Vergleich zu benutzerdefinierten Richtlinien](policy-differences.md)
+ [Standardrichtlinien erstellen](default-policies.md)
+ [Erstellen Sie eine benutzerdefinierte Richtlinie für Snapshots](snapshot-ami-policy.md)
+ [Erstellen Sie eine benutzerdefinierte Richtlinie für AMIs](ami-policy.md)
+ [Kontoübergreifende Snapshot-Kopien automatisieren](event-policy.md)
+ [Richtlinien ändern](modify.md)
+ [Löschen von Richtlinien](delete.md)
+ [Kontrollieren des Zugriffs](dlm-prerequisites.md)
+ [Überwachen Sie die Richtlinien](dlm-monitor-lifecycle.md)
+ [Service-Endpunkte](dlm-service-endpoints.md)
+ [Schnittstellen-VPC-Endpunkte](dlm-vpc-endpoints.md)
+ [Fehlerbehebung](dlm-troubleshooting.md)
## Kontingente
Ihr AWS Konto hat die folgenden Kontingente für Amazon Data Lifecycle Manager:
| Description | Kontingent |
| --- | --- |
| Benutzerdefinierte Lebenszyklusrichtlinien nach Region | 100 |
| Standardrichtlinien für EBS-Snapshots nach Region | 1 |
| Standardrichtlinien für AMIs EBS-gestützte Produkte pro Region | 1 |
| Tags pro Ressource | 45 |
# Funktionsweise von Amazon Data Lifecycle Manager
Im Folgenden werden die Schlüsselelemente von Amazon Data Lifecycle Manager beschrieben.
**Topics**
+ [Richtlinien](#dlm-policies)
+ [Zeitpläne von Richtlinien](#dlm-lifecycle-schedule)
+ [Target resource Tags (Zielressourcen-Tags (Markierungen))](#dlm-tagging-volumes)
+ [-Snapshots](#dlm-ebs-snapshots)
+ [EBS-unterstützt AMIs](#dlm-ebs-amis)
+ [Amazon-Data-Lifecycle-Manager-Tags (Markierungen)](#dlm-tagging-snapshots)
## Richtlinien
Mit Amazon Data Lifecycle Manager erstellen Sie Richtlinien, um Ihre Anforderungen an die Erstellung und Aufbewahrung von Backups zu definieren. In diesen Richtlinien sind in der Regel folgende Angaben enthalten:
+ **Richtlinientyp** — Definiert die Art der Backup-Ressourcen, die die Richtlinie verwaltet (Snapshots oder EBS-gestützt AMIs).
+ **Zielressourcen** – definiert den Typ der Ressourcen, für die die Richtlinien gelten (Instances oder EBS-Volumes).
+ **Erstellungshäufigkeit** — Definiert, wie oft die Richtlinie ausgeführt wird und Snapshots erstellt oder. AMIs
+ **Aufbewahrungsschwellenwert** — Definiert, wie lange die Richtlinie Snapshots aufbewahrt oder AMIs nach der Erstellung.
+ **Zusätzliche Aktionen** – definiert zusätzliche Aktionen, die die Richtlinie ausführen soll, wie z. B. regionsübergreifendes Kopieren, Archivieren oder Ressourcen-Tagging.
Amazon Data Lifecycle Manager bietet Standardrichtlinien und benutzerdefinierte Richtlinien.
**Standardrichtlinien**
Standardrichtlinien sichern alle Volumes und Instances in einer Region, für die es keine aktuellen Backups gibt. Sie können Volumes und Instances optional ausschließen, indem Sie Ausschlussparameter angeben.
Amazon Data Lifecycle Manager unterstützt die folgenden Standardrichtlinien:
+ Standardrichtlinie für EBS-Snapshots – zielt auf Volumes ab und automatisiert die Erstellung, Aufbewahrung und Löschung von Snapshots.
+ Standardrichtlinie für EBS-gestützte Instanzen AMIs — Zielt auf Instances ab und automatisiert die Erstellung, Aufbewahrung und Deregistrierung von EBS-gestützten. AMIs
Sie können in jedem Konto und in jeder AWS -Region nur eine Standardrichtlinie pro Ressourcentyp festlegen.
**Benutzerdefinierte Richtlinien**
Benutzerdefinierte Richtlinien zielen auf der Grundlage der zugewiesenen Tags auf bestimmte Ressourcen ab und unterstützen erweiterte Features wie die schnelle Snapshot-Wiederherstellung, die Snapshot-Archivierung, kontoübergreifendes Kopieren und Vor- und Nach-Skripte. Eine benutzerdefinierte Richtlinie kann bis zu 4 Zeitpläne enthalten, wobei jeder Zeitplan eine eigene Erstellungshäufigkeit, einen eigenen Aufbewahrungsschwellenwert und eine erweiterte Featurekonfiguration aufweisen kann.
Amazon Data Lifecycle Manager unterstützt die folgenden benutzerdefinierten Richtlinien:
+ Richtlinie für EBS-Snapshots – zielt auf Volumes oder Instances ab und automatisiert die Erstellung, Aufbewahrung und Löschung von EBS-Snapshots.
+ EBS-gestützte AMI-Richtlinie — Zielt auf Instances ab und automatisiert die Erstellung, Aufbewahrung und Deregistrierung von EBS-gestützten. AMIs
+ Richtlinie für kontoübergreifende Kopierereignisse – automatisiert regionsübergreifende Kopieraktionen für Snapshots, die mit Ihnen geteilt werden.
Weitere Informationen finden Sie unter [Amazon Data Lifecycle Manager Manager-Standardrichtlinien im Vergleich zu benutzerdefinierten Richtlinien](policy-differences.md).
## Zeitpläne von Richtlinien (*nur benutzerdefinierte Richtlinien*)
In Richtlinienzeitplänen wird festgelegt, wann Snapshots erstellt werden oder wann diese durch die Richtlinie erstellt werden. AMIs Richtlinien können bis zu vier Zeitpläne umfassen—einen obligatorischen Zeitplan und bis zu drei optionale Zeitpläne.
Durch das Hinzufügen mehrerer Zeitpläne zu einer einzelnen Richtlinie können Sie Snapshots oder mit unterschiedlichen AMIs Intervallen mithilfe derselben Richtlinie erstellen. Sie können beispielsweise eine einzelne Richtlinie erstellen, die tägliche, wöchentliche, monatliche und jährliche Snapshots erstellt. Dadurch entfällt die Notwendigkeit, mehrere Richtlinien zu verwalten.
Für jeden Zeitplan können Sie die Häufigkeit, Einstellungen für die schnelle Snapshot-Wiederherstellung (nur Snapshot-Lebenszyklusrichtlinien), regionsübergreifende Kopierregeln und Tags (Markierungen) definieren. Die Tags, die einem Zeitplan zugewiesen sind, werden den Snapshots automatisch zugewiesen oder sie werden erstellt AMIs , wenn der Zeitplan initiiert wird. Darüber hinaus weist Amazon Data Lifecycle Manager jedem Snapshot oder AMI basierend auf der Häufigkeit des Zeitplans automatisch einen vom System generierten Tag (Markierung) zu.
Jeder Zeitplan wird individuell basierend auf seiner Häufigkeit ausgelöst. Wenn mehrere Zeitpläne gleichzeitig ausgelöst werden, erstellt Amazon Data Lifecycle Manager nur einen Snapshot oder AMI und verwendet die Aufbewahrungseinstellungen des Zeitplans, der den höchsten Aufbewahrungszeitraum aufweist. Die Tags (Markierungen) aller ausgelösten Zeitpläne werden auf den Snapshot oder AMI angewendet.
+ (Nur Snapshot-Lebenszyklusrichtlinien) Wenn für mehr als einen der ausgelösten Zeitpläne eine schnelle Snapshot-Wiederherstellung aktiviert ist, wird für den Snapshot die schnelle Snapshot-Wiederherstellung in allen Availability Zones aktiviert, die in allen ausgelösten Zeitplänen angegeben sind. Die höchsten Aufbewahrungseinstellungen der ausgelösten Zeitpläne werden für jede Availability Zone verwendet.
+ Wenn für mehr als einen der ausgelösten Zeitpläne eine bereichsübergreifenden Kopie aktiviert ist, wird der Snapshot oder AMI in alle Regionen kopiert, die allen ausgelösten Zeitplänen angegeben sind. Die höchste Aufbewahrungsdauer der ausgelösten Zeitpläne wird angewendet.
## Zielressourcen-Tags (*nur benutzerdefinierte Richtlinien*)
Benutzerdefinierte Richtlinien von Amazon Data Lifecycle Manager verwenden Ressourcen-Tags für die Identifizierung der zu sichernden Ressourcen. Wenn Sie eine Snapshot- oder EBS-gestützte AMI-Richtlinie erstellen, können Sie mehrere Zielressourcen-Tags angeben. Alle Ressourcen des festgelegten Typs (Instance oder Volume), die mindestens eines der angegebenen Zielressourcen-Tags haben, werden von der Richtlinie erfasst. Wenn Sie beispielsweise eine Snapshot-Richtlinie erstellen, die auf Volumes abzielt, und Sie `purpose=prod`, `costcenter=prod` und `environment=live` als Zielressourcen-Tags angeben, dann zielt die Richtlinie auf alle Volumes ab, die eines dieser Tag-Schlüsselwert-Paare haben.
Wenn Sie mehrere Richtlinien für eine Ressource anwenden möchten, können Sie der Zielressource mehrere Tags zuweisen und dann separate Richtlinien erstellen, die jeweils auf ein bestimmtes Ressourcen-Tag abzielen.
Die Zeichen `\` und `=` können Sie in einem Tag-Schlüssel nicht verwenden. Bei Zielressourcen-Tags muss die Groß-/Kleinschreibung beachtet werden. Weitere Informationen finden Sie unter [Taggen Ihrer Ressourcen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html).
## -Snapshots
Snapshots sind die primäre Methode, Daten von Ihren EBS-Volumes zu sichern. Um Speicherkosten zu sparen, sind aufeinanderfolgende Snapshots inkrementell und enthalten nur die Volume-Daten, die sich seit dem vorherigen Snapshot geändert haben. Wenn Sie einen Snapshot in einer Reihe von Snapshots für ein Volume löschen, werden nur die Daten entfernt, die nur in diesem Snapshot vorhanden sind. Der Rest des erfassten Volume-Verlaufs wird beibehalten. Weitere Informationen finden Sie unter [Amazon EBS-Snapshots](ebs-snapshots.md).
## EBS-unterstützt AMIs
Ein Amazon Machine Image (AMI) stellt die Informationen zur Verfügung, die zum Starten einer Instance erforderlich sind. Sie können mehrere Instances aus einem einzigen AMI starten, wenn Sie mehrere Instances mit derselben Konfiguration benötigen. Amazon Data Lifecycle Manager unterstützt nur EBS-gestützt. AMIs EBS-gestützt AMIs beinhalten einen Snapshot für jedes EBS-Volume, das an die Quell-Instance angehängt ist. Weitere Informationen finden Sie unter [Amazon Machine Images (AMI)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html).
## Amazon-Data-Lifecycle-Manager-Tags (Markierungen)
Amazon Data Lifecycle Manager wendet die folgenden System-Tags auf alle Snapshots an, die im Rahmen einer Richtlinie AMIs erstellt wurden, um sie von Snapshots zu unterscheiden, die auf andere Weise AMIs erstellt wurden:
+ `aws:dlm:lifecycle-policy-id`
+ `aws:dlm:lifecycle-schedule-name`
+ `aws:dlm:expirationTime` – Für Snapshots, die nach einem altersbasierten Zeitplan erstellt wurden. Gibt an, wann der Snapshot aus der Standardstufe gelöscht werden muss.
+ `dlm:managed`
+ `aws:dlm:archived` – Für Snapshots, die nach einem Zeitplan archiviert wurden.
+ `aws:dlm:pre-script` – für Snapshots, die mit Vor-Skripten erstellt wurden.
+ `aws:dlm:post-script` – für Snapshots, die mit Nach-Skripten erstellt wurden.
Sie können auch benutzerdefinierte Tags angeben, die auf Snapshots und AMIs bei der Erstellung angewendet werden sollen. Die Zeichen `\` und `=` können Sie in einem Tag-Schlüssel nicht verwenden.
Die Ziel-Tags (Markierungen), die Amazon Data Lifecycle Manager zum Zuordnen der Volumes zu einer Snapshot-Richtlinie verwendet, können optional auf Snapshots angewendet werden, die von der Richtlinie erstellt wurden. In ähnlicher Weise können die Ziel-Tags, die verwendet werden, um Instances mit einer AMI-Richtlinie zu verknüpfen, optional auf von der Richtlinie AMIs erstellte Tags angewendet werden.
# Amazon Data Lifecycle Manager Manager-Standardrichtlinien im Vergleich zu benutzerdefinierten Richtlinien
In diesem Abschnitt werden Standardrichtlinien und benutzerdefinierte Richtlinien verglichen und ihre Gemeinsamkeiten und Unterschiede hervorgehoben.
**Topics**
+ [Vergleich der EBS-Snapshot-Richtlinien](#snapshot-policy-diffs)
+ [Vergleich EBS-gestützter AMI-Richtlinien](#ami-policy-diffs)
## Vergleich der EBS-Snapshot-Richtlinien
In der folgenden Tabelle werden die Unterschiede zwischen der Standardrichtlinie für EBS-Snapshots und benutzerdefinierten EBS-Snapshot-Richtlinien hervorgehoben.
| Feature | Standardrichtlinie für EBS-Snapshots | Benutzerdefinierte Richtlinie für EBS-Snapshot |
| --- | --- | --- |
| Verwaltete Backup-Ressource | EBS Snapshot | EBS Snapshot |
| Typen von Zielressourcen | Datenträger | Volumes oder Instances |
| Ausrichtung auf Ressourcen | Zielt auf alle Volumes in der Region ab, für die keine aktuellen Snapshots vorhanden sind. Sie können Ausschlussparameter angeben, um bestimmte Volumes auszuschließen. | Zielt nur auf Volumes oder Instances ab, die über bestimmte Tags verfügen. |
| Ausschlussparameter | Ja, kann Startvolumes, bestimmte Volume-Typen und Volumes mit bestimmten Tags ausschließen. | Ja, kann bei der Ausrichtung auf Instances Startvolumes und Volumes mit bestimmten Tags ausschließen. |
| Support AWS Outposts | Nein | Ja |
| Unterstützung mehrerer Zeitpläne | Nein | Ja, bis zu 4 Zeitpläne pro Richtlinie |
| Unterstützte Aufbewahrungsarten | Nur altersbasierte Aufbewahrung | Alters- und anzahlbasierte Aufbewahrung |
| Häufigkeit der Erstellung von Snapshots | Alle 1 bis 7 Tage. | Tägliche, wöchentliche, monatliche, jährliche oder benutzerdefinierte Häufigkeit unter Verwendung eines Cron-Ausdrucks. |
| Snapshot-Aufbewahrung | 2 bis 14 Tage. | Bis zu 1 000 Snapshots (anzahlbasiert) oder bis zu 100 Jahre (altersbasiert). |
| Unterstützung für anwendungskonsistente Snapshots | Nein | Ja, bei Vor- und Nach-Skripten |
| Unterstützung der Snapshot-Archivierung | Nein | Ja |
| Unterstützung der schnellen Snapshot-Wiederherstellung | Nein | Ja |
| Unterstützung für regionsübergreifendes Kopieren | Ja, mit den Standardeinstellungen 1 | Ja, mit benutzerdefinierten Einstellungen |
| Unterstützung der kontoübergreifenden Freigabe | Nein | Ja |
| Unterstützung für erweitertes Löschen 2 | Ja | Nein |
1 Für Standardrichtlinien:
+ Sie können keine Tags in regionsübergreifende Kopien kopieren.
+ Für Kopien gilt der gleiche Aufbewahrungszeitraum wie für den Quell-Snapshot.
+ Kopien erhalten den gleichen Verschlüsselungsstatus wie der Quell-Snapshot. Wenn die Zielregion standardmäßig für die Verschlüsselung aktiviert ist, werden Kopien immer verschlüsselt, auch wenn die Quell-Snapshots unverschlüsselt sind. Kopien werden immer mit dem standardmäßigen KMS-Schlüssel für die Zielregion verschlüsselt.
2 Für Standard- und benutzerdefinierte Richtlinien:
+ Wenn eine Ziel-Instance oder ein Zielvolume gelöscht wird, löscht Amazon Data Lifecycle Manager auf Grundlage des Aufbewahrungszeitraums weiterhin Snapshots bis zum letzten Snapshot, jedoch nicht einschließlich dieses Snapshots. Bei Standardrichtlinien können Sie den Löschvorgang auf den letzten Snapshot ausweiten.
+ Wenn eine Richtlinie gelöscht oder in den Status „Fehler“ oder „Deaktiviert“ versetzt wird, beendet Amazon Data Lifecycle Manager das Löschen von Snapshots. Bei Standardrichtlinien können Sie den Löschvorgang ausweiten und weiterhin Snapshots löschen, einschließlich des letzten.
## Vergleich EBS-gestützter AMI-Richtlinien
In der folgenden Tabelle werden die Unterschiede zwischen der Standardrichtlinie für EBS-gestützte AMIs und benutzerdefinierte EBS-gestützte AMI-Richtlinien hervorgehoben.
| Feature | Standardrichtlinie für EBS-gestützte AMIs | Benutzerdefinierte EBS-gestützte AMI-Richtlinie |
| --- | --- | --- |
| Verwaltete Backup-Ressource | EBS-unterstützt AMIs | EBS-unterstützt AMIs |
| Typen von Zielressourcen | Instances | Instances |
| Ausrichtung auf Ressourcen | Zielt auf alle Instances in der Region ab, für die es keine aktuellen Versionen gibt. AMIs Sie können Ausschlussparameter angeben, um bestimmte Instances auszuschließen. | Zielt nur auf Instances ab, die über bestimmte Tags verfügen. |
| Instances vor der AMI-Erstellung neu starten | Nein | Ja |
| Ausschlussparameter | Ja, kann Instances mit bestimmten Tags ausschließen. | Nein |
| Unterstützung mehrerer Zeitpläne | Nein | Ja, bis zu 4 Zeitpläne pro Richtlinie. |
| Häufigkeit der AMI-Erstellung | Alle 1 bis 7 Tage. | Tägliche, wöchentliche, monatliche, jährliche oder benutzerdefinierte Häufigkeit unter Verwendung eines Cron-Ausdrucks. |
| Unterstützte Aufbewahrungsarten | Nur altersbasierte Aufbewahrung. | Alters- und anzahlbasierte Aufbewahrung. |
| AMIs Aufbewahrung | 2 bis 14 Tage. | Bis zu 1000 AMIs (zählungsabhängig) oder bis zu 100 Jahre (altersabhängig). |
| Unterstützung für AMI-Veralterung | Nein | Ja |
| Unterstützung für regionsübergreifendes Kopieren | Ja, mit den Standardeinstellungen 1 | Ja, mit benutzerdefinierten Einstellungen |
| Unterstützung für erweitertes Löschen 2 | Ja | Nein |
1 Für Standardrichtlinien:
+ Sie können keine Tags in regionsübergreifende Kopien kopieren.
+ Für Kopien gilt der gleiche Aufbewahrungszeitraum wie für das Quell-AMI.
+ Kopien erhalten den gleichen Verschlüsselungsstatus wie das Quell-AMI. Wenn die Zielregion standardmäßig für die Verschlüsselung aktiviert ist, werden Kopien immer verschlüsselt, auch wenn die Quelle AMIs unverschlüsselt ist. Kopien werden immer mit dem standardmäßigen KMS-Schlüssel für die Zielregion verschlüsselt.
2 Für Standard- und benutzerdefinierte Richtlinien:
+ Wenn eine Ziel-Instance beendet wird, setzt Amazon Data Lifecycle Manager die Abmeldung AMIs bis zur letzten Instance fort, schließt diese jedoch nicht ein, basierend auf der Aufbewahrungsfrist. Bei Standardrichtlinien können Sie die Abmeldung auf das letzte AMI ausweiten.
+ Wenn eine Richtlinie gelöscht wird oder in den Status Fehler oder Deaktiviert wechselt, beendet Amazon Data Lifecycle Manager die Abmeldung AMIs. Bei Standardrichtlinien können Sie den Löschvorgang verlängern, um mit der Abmeldung fortzufahren AMIs, einschließlich der letzten.
# Standardrichtlinien für Amazon Data Lifecycle Manager erstellen
Verwenden Sie die Standardrichtlinie für EBS-gestützte Instances, um regelmäßige AMIs EBS-gestützte Instanzen zu erstellen. AMIs Verwenden Sie die Standardrichtlinie für EBS-Snapshots, um unabhängig von ihrem Anhangsstatus Snapshots aller Volumes zu erstellen oder bestimmte Volumes auszuschließen.
In diesem Abschnitt wird beschrieben, wie Standardrichtlinien erstellt werden.
**Topics**
+ [Überlegungen zu Standardrichtlinien](#default-policy-considerations)
+ [Standardrichtlinie für Amazon EBS-Snapshots erstellen](#default-snapshot-policy)
+ [Erstellen Sie eine Standardrichtlinie für EBS-gestützte AMIs](#default-ami-policy)
+ [Aktivieren Sie Standardrichtlinien für Konten und Regionen](dlm-stacksets.md)
## Überlegungen zu Standardrichtlinien
Bedenken Sie bei der Arbeit mit Standardrichtlinien Folgendes:
+ Mit Standardrichtlinien werden keine Zielressourcen (Instances oder Volumes) gesichert, für die aktuelle Backups (Snapshots oder AMIs) vorhanden sind. Die Häufigkeit der Erstellung bestimmt, welche Ressourcen gesichert werden. Ein Volume oder eine Instance wird nur gesichert, wenn der letzte Snapshot oder das letzte AMI älter als die Erstellungshäufigkeit der Richtlinie ist. Wenn Sie beispielsweise eine Erstellungshäufigkeit von 3 Tagen angeben, erstellt die Standardrichtlinie für EBS-Snapshots nur dann einen Snapshot eines Volumes, wenn der letzte Snapshot älter als 3 Tage ist.
+ Standardmäßig zielen Standardrichtlinien auf alle Instances oder Volumes in der Region ab, sofern keine Ausschlussparameter angegeben sind.
+ Durch Standardrichtlinien wird ein Mindestsatz an eindeutigen Snapshots erstellt. Wenn Sie beispielsweise die Richtlinie für EBS-gestützte AMIs und die Richtlinie für EBS-Snapshots aktivieren, dupliziert die Snapshot-Richtlinie keine Snapshots von Volumes, die bereits durch die Richtlinie für EBS-gestützte AMIs gesichert wurden.
+ Standardrichtlinien zielen zunächst nur auf Ressourcen ab, die mindestens 24 Stunden alt sind.
+ Wenn Sie ein Volume löschen oder eine Instance beenden, für die eine Standardrichtlinie vorgesehen ist, löscht Amazon Data Lifecycle Manager weiterhin die zuvor erstellten Backups (Snapshots oder AMIs) entsprechend dem Aufbewahrungszeitraum bis zum letzten Backup, jedoch nicht einschließlich,. Sie müssen diese Sicherung manuell löschen, wenn sie nicht benötigt wird.
Wenn Sie möchten, dass Amazon Data Lifecycle Manager die letzte Sicherung löscht, können Sie *Löschen verlängern* aktivieren.
+ Wenn eine Standardrichtlinie gelöscht wird oder in den Status Fehler oder Deaktiviert wechselt, beendet Amazon Data Lifecycle Manager das Löschen der zuvor erstellten Backups (Snapshots oder AMIs). Wenn Sie möchten, dass Amazon Data Lifecycle Manager weiterhin Sicherungen löscht, einschließlich der letzten, müssen Sie *Löschen verlängern* aktivieren, bevor Sie die Richtlinie löschen oder bevor der Status der Richtlinie zu „Deaktiviert“ oder „Gelöscht“ wechselt.
+ Wenn Sie eine Standardrichtlinie erstellen und aktivieren, weist Amazon Data Lifecycle Manager einem Zeitfenster von vier Stunden nach dem Zufallsprinzip zielgerichtete Ressourcen zu. Zielgerichtete Ressourcen werden während des ihnen zugewiesenen Zeitfensters mit der angegebenen Erstellungshäufigkeit gesichert. Wenn eine Richtlinie beispielsweise eine Erstellungshäufigkeit von 3 Tagen umfasst und eine Zielressource dem Fenster von 12:00 bis 16:00 Uhr zugewiesen ist, wird diese Ressource alle 3 Tage zwischen 12:00 und 16:00 Uhr gesichert.
## Standardrichtlinie für Amazon EBS-Snapshots erstellen
Das folgende Verfahren zeigt, wie Sie eine Standardrichtlinie für EBS-Snapshots erstellen.
------
#### [ Console ]
**So erstellen Sie eine Standardrichtlinie für EBS-Snapshots**
1. Öffnen Sie die Amazon-EC2-Konsole unter [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. Wählen Sie im Navigationsbereich **Lifecycle Manager** und dann **Lebenszyklusrichtlinie erstellen** aus.
1. Wählen Sie als **Richtlinientyp** die Option **Standardrichtlinie** und dann **EBS-Snapshot-Richtlinie** aus.
1. Geben Sie unter **Description (Beschreibung)** eine kurze Beschreibung der Richtlinie ein.
1. Wählen Sie für die **IAM-Rolle** die IAM-Rolle aus, die über Berechtigungen zum Verwalten von Snapshots verfügt.
Wir empfehlen die Auswahl von **Standardrolle**, um die von Amazon Data Lifecycle Manager bereitgestellte Standard-IAM-Rolle zu verwenden. Sie können jedoch auch eine benutzerdefinierte IAM-Rolle verwenden, die Sie zuvor erstellt haben.
1. Geben Sie unter **Erstellungshäufigkeit** an, wie oft die Richtlinie ausgeführt werden und Snapshots Ihrer Volumes erstellen soll.
Die von Ihnen angegebene Häufigkeit bestimmt auch, welche Volumes gesichert werden. Über die Richtlinie werden nur Volumes gesichert, die nicht innerhalb der angegebenen Häufigkeit auf andere Weise gesichert wurden. Wenn Sie beispielsweise eine Erstellungshäufigkeit von 3 Tagen angeben, erstellt die Richtlinie nur Snapshots von Volumes, die in den letzten 3 Tagen nicht gesichert wurden.
1. Geben Sie unter **Aufbewahrungsfrist** an, wie lange die Richtlinie die von ihr erstellten Snapshots aufbewahren soll. Wenn ein Snapshot den Aufbewahrungs-Schwellenwert erreicht, wird er automatisch gelöscht. Die Aufbewahrungsfrist muss mindestens so groß wie die Erstellungshäufigkeit sein.
1. (*Optional*) Konfigurieren Sie die **Ausschlussparameter**, um bestimmte Volumes von den geplanten Sicherungen auszuschließen. Ausgeschlossene Volumes werden nicht gesichert, wenn die Richtlinie ausgeführt wird.
1. Um Startvolumes auszuschließen, wählen Sie **Startvolumes ausschließen**. Wenn Sie Startvolumes ausschließen, werden nur Datenvolumes (keine Startvolumes) durch die Richtlinie gesichert. Mit anderen Worten: Es werden keine Snapshots von Volumes erstellt, die als Startvolume an Instances angehängt sind.
1. Um bestimmte Volume-Typen auszuschließen, wählen Sie **Bestimmte Volume-Typen ausschließen** und anschließend die auszuschließenden Volume-Typen aus. Nur Volumes der verbleibenden Typen werden durch die Richtlinie gesichert.
1. Um Volumes mit bestimmten Tags auszuschließen, wählen Sie **Tag hinzufügen** aus und geben Sie dann die Tag-Schlüssel und -Werte an. Die Richtlinie erstellt keine Snapshots von Volumes, die über eines der angegebenen Tags verfügen.
1. (*Optional*) Geben Sie in den **erweiterten Einstellungen** zusätzliche Aktionen an, die die Richtlinie ausführen soll.
1. Um zugewiesene Tags automatisch vom Quell-Volume auf die Snapshots zu kopieren, wählen Sie **Kopieren von Tags aus den Volumes**.
1. Wenn **Löschen verlängern** deaktiviert ist:
+ Wenn eine Quell-Instance gelöscht wird, löscht Amazon Data Lifecycle Manager auf Grundlage des Aufbewahrungszeitraums weiterhin zuvor erstellte Snapshots bis zum letzten Snapshot, jedoch nicht einschließlich dieses Snapshots. Wenn Amazon Data Lifecycle Manager alle Snapshots, einschließlich des letzten, löschen soll, wählen Sie **Löschen verlängern**.
+ Wenn eine Richtlinie gelöscht oder in den Status „`error`“ oder „`disabled`“ versetzt wird, beendet Amazon Data Lifecycle Manager das Löschen von Snapshots. Wenn Amazon Data Lifecycle Manager weiterhin alle Snapshots, einschließlich des letzten, löschen soll, wählen Sie **Löschen verlängern** aus.
**Anmerkung**
Wenn Sie „Löschen verlängern“ aktivieren, überschreiben Sie beide oben beschriebenen Verhaltensweisen gleichzeitig.
1. Um mit der Richtlinie erstellte Snapshots in andere Regionen zu kopieren, wählen Sie **Regionsübergreifende Kopien erstellen** und anschließend bis zu 3 Zielregionen aus.
+ Wenn der Quell-Snapshot verschlüsselt ist oder die Verschlüsselung standardmäßig für die Zielregion aktiviert ist, werden die Snapshots-Kopien mit dem standardmäßigen KMS-Schlüssel für die EBS-Verschlüsselung in der Zielregion verschlüsselt.
+ Wenn der Quell-Snapshot unverschlüsselt ist und die Verschlüsselung standardmäßig für die Zielregion deaktiviert ist, werden die Snapshots-Kopien nicht verschlüsselt.
1. (*Optional*) Sie können der Richtlinie ein neues Tag hinzufügen, indem Sie **Tag hinzufügen** auswählen und dann den Tag-Schlüssel und das Wert-Paar angeben.
1. Wählen Sie **Standardrichtlinie erstellen**.
**Anmerkung**
Falls Sie den Fehler `Role with name AWSDataLifecycleManagerDefaultRole already exists` erhalten, finden Sie weitere Informationen unter [Probleme mit Amazon Data Lifecycle Manager beheben](dlm-troubleshooting.md).
------
#### [ AWS CLI ]
**So erstellen Sie eine Standardrichtlinie für EBS-Snapshots**
Verwenden Sie den Befehl [ create-lifecycle-policy](https://docs.aws.amazon.com/cli/latest/reference/dlm/create-lifecycle-policy.html). Sie können die Anfrageparameter je nach Anwendungsfall oder Einstellungen mit einer von zwei Methoden angeben:
+ **Methode 1**
```
$ aws dlm create-lifecycle-policy \
--state ENABLED | DISABLED \
--description "policy_description" \
--execution-role-arn role_arn \
--default-policy VOLUME \
--create-interval creation_frequency_in_days (1-7) \
--retain-interval retention_period_in_days (2-14) \
--copy-tags | --no-copy-tags \
--extend-deletion | --no-extend-deletion \
--cross-region-copy-targets TargetRegion=destination_region_code \
--exclusions ExcludeBootVolumes=true | false, ExcludeTags=[{Key=tag_key,Value=tag_value}], ExcludeVolumeTypes="standard | gp2 | gp3 | io1 | io2 | st1 | sc1"
```
Um beispielsweise eine Standardrichtlinie für EBS-Snapshots zu erstellen, die auf alle Volumes in der Region abzielt, die Standard-IAM-Rolle verwendet, täglich ausgeführt wird (Standard) und Snapshots 7 Tage lang aufbewahrt (Standard), müssen Sie die folgenden Parameter angeben:
```
$ aws dlm create-lifecycle-policy \
--state ENABLED \
--description "Daily default snapshot policy" \
--execution-role-arn arn:aws:iam::account_id:role/AWSDataLifecycleManagerDefaultRole \
--default-policy VOLUME
```
+ **Methode 2**
```
$ aws dlm create-lifecycle-policy \
--state ENABLED | DISABLED \
--description "policy_description" \
--execution-role-arn role_arn \
--default-policy VOLUME \
--policy-details file://policyDetails.json
```
Wenn `policyDetails.json` Folgendes umfasst:
```
{
"PolicyLanguage": "SIMPLIFIED",
"PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
"ResourceType": "VOLUME",
"CopyTags": true | false,
"CreateInterval": creation_frequency_in_days (1-7),
"RetainInterval": retention_period_in_days (2-14),
"ExtendDeletion": true | false,
"CrossRegionCopyTargets": [{"TargetRegion":"destination_region_code"}],
"Exclusions": {
"ExcludeBootVolume": true | false,
"ExcludeVolumeTypes": ["standard | gp2 | gp3 | io1 | io2 | st1 | sc1"],
"ExcludeTags": [{
"Key": "exclusion_tag_key",
"Value": "exclusion_tag_value"
}]
}
}
```
------
## Erstellen Sie eine Standardrichtlinie für EBS-gestützte AMIs
Das folgende Verfahren zeigt Ihnen, wie Sie eine Standardrichtlinie für EBS-gestützt erstellen. AMIs
------
#### [ Console ]
**So erstellen Sie eine Standardrichtlinie für EBS-gestützte AMIs**
1. Öffnen Sie die Amazon-EC2-Konsole unter [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. Wählen Sie im Navigationsbereich **Lifecycle Manager** und dann **Lebenszyklusrichtlinie erstellen** aus.
1. Wählen Sie als **Richtlinientyp** die Option **Standardrichtlinie** und dann **EBS-gestützte AMI-Richtlinie** aus.
1. Geben Sie unter **Description (Beschreibung)** eine kurze Beschreibung der Richtlinie ein.
1. Wählen Sie für die **IAM-Rolle** die IAM-Rolle aus, die über Verwaltungsberechtigungen verfügt. AMIs
Wir empfehlen die Auswahl von **Standardrolle**, um die von Amazon Data Lifecycle Manager bereitgestellte Standard-IAM-Rolle zu verwenden. Sie können jedoch auch eine benutzerdefinierte IAM-Rolle verwenden, die Sie zuvor erstellt haben.
1. Geben Sie unter **Erstellungshäufigkeit** an, wie oft die Richtlinie auf Ihren Instances ausgeführt und erstellt AMIs werden soll.
Die von Ihnen angegebene Häufigkeit bestimmt auch, welche Instances gesichert werden. Über die Richtlinie werden nur Instances gesichert, die nicht innerhalb der angegebenen Häufigkeit auf andere Weise gesichert wurden. Wenn Sie beispielsweise eine Erstellungshäufigkeit von 3 Tagen angeben, werden mit der Richtlinie nur Instances erstellt AMIs , die in den letzten 3 Tagen nicht gesichert wurden.
1. Geben Sie **unter Aufbewahrungszeitraum** an, wie lange die Richtlinie die von ihr erstellten AMIs Daten beibehalten soll. Wenn ein AMI den Aufbewahrungsschwellenwert erreicht, wird es automatisch abgemeldet und die zugeordneten Snapshots werden gelöscht. Die Aufbewahrungsfrist muss mindestens so groß wie die Erstellungshäufigkeit sein.
1. (*Optional*) Konfigurieren Sie die **Ausschlussparameter**, um bestimmte Instances von den geplanten Sicherungen auszuschließen. Ausgeschlossene Instances werden nicht gesichert, wenn die Richtlinie ausgeführt wird.
1. Um Instances mit bestimmten Tags auszuschließen, wählen Sie **Tag hinzufügen** aus und geben Sie dann die Tag-Schlüssel und -Werte an. Die Richtlinie wird nicht AMIs aus Instances erstellt, die über eines der angegebenen Tags verfügen.
1. (*Optional*) Geben Sie in den **erweiterten Einstellungen** zusätzliche Aktionen an, die die Richtlinie ausführen soll.
1. Um zugewiesene Tags von den Quell-Instances auf ihre zu kopieren AMIs, wählen Sie **Tags aus Instances kopieren aus**.
1. Wenn **Löschen verlängern** deaktiviert ist:
+ Wenn eine Quell-Instance beendet wird, setzt Amazon Data Lifecycle Manager die Abmeldung der zuvor erstellten Instance fort, AMIs schließt jedoch die letzte Instance basierend auf der Aufbewahrungsfrist ab, schließt diese jedoch nicht ein. Wenn Sie möchten, dass Amazon Data Lifecycle Manager alle AMIs, einschließlich der letzten, abmeldet, wählen Sie Löschen **verlängern** aus.
+ Wenn eine Richtlinie gelöscht wird oder in den `disabled` Status `error` oder wechselt, beendet Amazon Data Lifecycle Manager die Abmeldung AMIs. Wenn Sie möchten, dass Amazon Data Lifecycle Manager die Abmeldung fortsetzt AMIs, einschließlich der letzten, wählen Sie Löschen **verlängern** aus.
**Anmerkung**
Wenn Sie das verlängerte Löschen aktivieren, überschreiben Sie beide oben beschriebenen Verhaltensweisen gleichzeitig.
1. Um die durch die Richtlinie AMIs erstellten Dateien in andere Regionen zu kopieren, wählen Sie „**Regionsübergreifende Kopie erstellen**“ und wählen Sie dann bis zu 3 Zielregionen aus.
+ Wenn das Quell-AMI verschlüsselt ist oder wenn die Verschlüsselung standardmäßig für die Zielregion aktiviert ist, AMIs werden die kopierten Dateien mit dem Standard-KMS-Schlüssel für die EBS-Verschlüsselung in der Zielregion verschlüsselt.
+ Wenn das Quell-AMI unverschlüsselt ist und die Verschlüsselung standardmäßig für die Zielregion deaktiviert ist, AMIs sind die kopierten Dateien unverschlüsselt.
1. (*Optional*) Sie können der Richtlinie ein neues Tag hinzufügen, indem Sie **Tag hinzufügen** auswählen und dann den Tag-Schlüssel und das Wert-Paar angeben.
1. Wählen Sie **Standardrichtlinie erstellen**.
**Anmerkung**
Falls Sie den Fehler `Role with name AWSDataLifecycleManagerDefaultRoleForAMIManagement already exists` erhalten, finden Sie weitere Informationen unter [Probleme mit Amazon Data Lifecycle Manager beheben](dlm-troubleshooting.md).
------
#### [ AWS CLI ]
**So erstellen Sie eine Standardrichtlinie für EBS-gestütztes AMIs**
Verwenden Sie den Befehl [ create-lifecycle-policy](https://docs.aws.amazon.com/cli/latest/reference/dlm/create-lifecycle-policy.html). Sie können die Anfrageparameter je nach Anwendungsfall oder Einstellungen mit einer von zwei Methoden angeben:
+ **Methode 1**
```
$ aws dlm create-lifecycle-policy \
--state ENABLED | DISABLED \
--description "policy_description" \
--execution-role-arn role_arn \
--default-policy INSTANCE \
--create-interval creation_frequency_in_days (1-7) \
--retain-interval retention_period_in_days (2-14) \
--copy-tags | --no-copy-tags \
--extend-deletion | --no-extend-deletion \
--cross-region-copy-targets TargetRegion=destination_region_code \
--exclusions ExcludeTags=[{Key=tag_key,Value=tag_value}]
```
Um beispielsweise eine Standardrichtlinie für EBS-gestützt zu erstellen, AMIs die auf alle Instances in der Region abzielt, die Standard-IAM-Rolle verwendet, täglich ausgeführt wird (Standard) und 7 Tage AMIs lang aufbewahrt wird (Standard), müssen Sie die folgenden Parameter angeben:
```
$ aws dlm create-lifecycle-policy \
--state ENABLED \
--description "Daily default AMI policy" \
--execution-role-arn arn:aws:iam::account_id:role/AWSDataLifecycleManagerDefaultRoleForAMIManagement \
--default-policy INSTANCE
```
+ **Methode 2**
```
$ aws dlm create-lifecycle-policy \
--state ENABLED | DISABLED \
--description "policy_description" \
--execution-role-arn role_arn \
--default-policy INSTANCE \
--policy-details file://policyDetails.json
```
Wenn `policyDetails.json` Folgendes umfasst:
```
{
"PolicyLanguage": "SIMPLIFIED",
"PolicyType": "IMAGE_MANAGEMENT",
"ResourceType": "INSTANCE",
"CopyTags": true | false,
"CreateInterval": creation_frequency_in_days (1-7),
"RetainInterval": retention_period_in_days (2-14),
"ExtendDeletion": true | false,
"CrossRegionCopyTargets": [{"TargetRegion":"destination_region_code"}],
"Exclusions": {
"ExcludeTags": [{
"Key": "exclusion_tag_key",
"Value": "exclusion_tag_value"
}]
}
}
```
------
# Aktivieren Sie die Data Lifecycle Manager-Standardrichtlinien für Konten und Regionen
Mithilfe CloudFormation StackSets können Sie die Standardrichtlinien von Amazon Data Lifecycle Manager für mehrere Konten und AWS Regionen mit einem einzigen Vorgang aktivieren.
Sie können Stack-Sets verwenden, um Standardrichtlinien auf eine der folgenden Arten zu aktivieren:
+ ** AWS Unternehmensübergreifend** — Stellt sicher, dass Standardrichtlinien in der gesamten AWS Organisation oder in bestimmten Organisationseinheiten einer Organisation einheitlich aktiviert und konfiguriert werden. Dies erfolgt mithilfe von vom *Service verwalteten Berechtigungen*. CloudFormation StackSets erstellt die erforderlichen IAM-Rollen in Ihrem Namen.
+ ** AWS Kontenübergreifend** — Stellt sicher, dass Standardrichtlinien für bestimmte Zielkonten konsistent aktiviert und konfiguriert werden. Dies erfordert *selbstverwaltete Berechtigungen*. Sie erstellen die IAM-Rollen, die erforderlich sind, um die Vertrauensstellung zwischen dem Stackset-Administratorkonto und den Zielkonten herzustellen.
Weitere Informationen finden Sie unter [Berechtigungsmodelle für Stack-Sets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html#stacksets-concepts-stackset-permission-models) im *AWS CloudFormation Benutzerhandbuch*.
Verwenden Sie die folgenden Verfahren, um die Standardrichtlinien von Amazon Data Lifecycle Manager für eine gesamte AWS Organisation, für bestimmte OUs oder für bestimmte Zielkonten zu aktivieren.
**Voraussetzungen**
Führen Sie je nachdem, wie Sie die Standardrichtlinien aktivieren, einen der folgenden Schritte aus:
+ ( AWS Organisationsübergreifend) Sie müssen [alle Funktionen in Ihrer Organisation](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_org_support-all-features.html) [aktivieren und den vertrauenswürdigen Zugriff mit](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-orgs-activate-trusted-access.html) aktivieren AWS Organizations. Sie müssen auch das Verwaltungskonto der Organisation oder ein [delegiertes Administratorkonto](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-orgs-delegated-admin.html) verwenden.
+ (Für bestimmte Zielkonten) Sie müssen [selbstverwaltete Berechtigungen gewähren](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-prereqs-self-managed.html), indem Sie die Rollen erstellen, die erforderlich sind, um eine vertrauenswürdige Beziehung zwischen dem Stackset-Administratorkonto und den Zielkonten herzustellen.
------
#### [ Console ]
**Um Standardrichtlinien unternehmensweit oder für bestimmte Zielkonten zu aktivieren AWS**
1. Öffnen Sie die CloudFormation Konsole unter [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/).
1. **Wählen Sie im Navigationsbereich die Option und anschließend **StackSets**Create aus. StackSet**
1. Führen Sie für **Berechtigungen** einen der folgenden Schritte aus, je nachdem, wie Sie die Standardrichtlinien aktivieren:
+ ( AWS Unternehmensübergreifend) Wählen Sie vom **Dienst verwaltete Berechtigungen** aus.
+ (Für bestimmte Zielkonten) Wählen Sie **Self-Service-Berechtigungen**. Wählen Sie dann für den **ARN der IAM-Administratorrolle** die IAM-Dienstrolle aus, die Sie für das Administratorkonto erstellt haben, und geben Sie für den Namen der **IAM-Ausführungsrolle den Namen** der IAM-Dienstrolle ein, die Sie in den Zielkonten erstellt haben.
1. Wählen **Sie für Vorlage vorbereiten die Option Beispielvorlage** **verwenden** aus.
1. Führen Sie für **Beispielvorlagen** einen der folgenden Schritte aus:
+ (Standardrichtlinie für EBS-Snapshots) Wählen Sie **Amazon Data Lifecycle Manager Manager-Standardrichtlinien für EBS-Snapshots erstellen** aus.
+ (Standardrichtlinie für EBS-gestützt AMIs) Wählen Sie **Amazon Data Lifecycle Manager Manager-Standardrichtlinien für EBS-gestützt erstellen** aus. AMIs
1. Wählen Sie **Weiter** aus.
1. Geben Sie für **StackSet Name** und **StackSet Beschreibung** einen aussagekräftigen Namen und eine kurze Beschreibung ein.
1. Konfigurieren Sie im Abschnitt **Parameter** die Standardrichtlinieneinstellungen nach Bedarf.
**Anmerkung**
Für kritische Workloads empfehlen wir **CreateInterval = 1 Tag** und **RetainInterval = 7 Tage**.
1. Wählen Sie **Weiter** aus.
1. (Optional) Geben Sie für **Tags Tags** an, die Ihnen helfen, die Ressourcen zu identifizieren StackSet und zu stapeln.
1. Wählen Sie für **Verwaltete Ausführung** die Option **Aktiv** aus.
1. Wählen Sie **Weiter** aus.
1. Wählen Sie für **Add stacks to stack set** (Stacks zum Stack-Set hinzufügen) **Deploy new stacks** (Neue Stacks bereitstellen).
1. Führen Sie je nachdem, wie Sie die Standardrichtlinien aktivieren, einen der folgenden Schritte aus:
+ ( AWS Unternehmensübergreifend) Wählen Sie für **Bereitstellungsziele** eine der folgenden Optionen aus:
+ Um die Bereitstellung in der gesamten AWS Organisation durchzuführen, wählen Sie In der **Organisation bereitstellen** aus.
+ Um die Bereitstellung für bestimmte Organisationseinheiten (OU) vorzunehmen, wählen Sie **Deploy to Organizational Units** (**OU) aus, und geben Sie dann als OU-ID** die OU-ID ein. Um weitere Organisationseinheiten hinzuzufügenOUs, wählen Sie **Weitere Organisationseinheit hinzufügen** aus.
+ (Für bestimmte Zielkonten) Führen Sie für **Konten** einen der folgenden Schritte aus:
+ Um die Bereitstellung für bestimmte Zielkonten durchzuführen, wählen Sie **Stapel in Konten bereitstellen** aus und geben Sie dann für **Kontonummern** die IDs der Zielkonten ein.
+ Um die Bereitstellung für alle Konten in einer bestimmten Organisationseinheit durchzuführen, wählen Sie **Stack für alle Konten in einer Organisationseinheit bereitstellen** und geben Sie dann für **Organisationsnummern** die ID der Ziel-OU ein.
1. Wählen Sie für **Automatische Bereitstellung** die Option **Aktiviert** aus.
1. Wählen Sie für **Verhalten beim Entfernen von Konten** die Option **Stacks beibehalten** aus.
1. Wählen **Sie unter Regionen angeben** bestimmte Regionen aus, in denen Standardrichtlinien aktiviert werden sollen, oder wählen Sie **Alle Regionen hinzufügen**, um Standardrichtlinien in allen Regionen zu aktivieren.
1. Wählen Sie **Weiter** aus.
1. Überprüfen Sie die Stackset-Einstellungen, wählen Sie **Ich bestätige, dass CloudFormation möglicherweise IAM-Ressourcen erstellt** werden, und klicken Sie dann auf **Senden**.
------
#### [ AWS CLI ]
**Um Standardrichtlinien in einer AWS Organisation zu aktivieren**
1. Erstellen Sie das Stack-Set. Verwenden Sie den Befehl [ create-stack-set](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/create-stack-set.html).
Legen Sie für `--permission-model` die Option `SERVICE_MANAGED` fest.
Geben Sie für `--template-url` eine der folgenden Vorlagen an URLs:
+ (Standardrichtlinien für AMIs EBS-gestützte Richtlinien) `https://s3.amazonaws.com/cloudformation-stackset-sample-templates-us-east-1/DataLifecycleManagerAMIDefaultPolicy.yaml`
+ (Standardrichtlinien für EBS-Snapshots) `https://s3.amazonaws.com/cloudformation-stackset-sample-templates-us-east-1/DataLifecycleManagerEBSSnapshotDefaultPolicy.yaml`
Geben Sie für `--parameters` die Einstellungen für die Standardrichtlinien an. Unterstützte Parameter, Parameterbeschreibungen und gültige Werte finden Sie, indem Sie die Vorlage über die URL herunterladen und die Vorlage anschließend in einem Texteditor anzeigen.
Legen Sie für `--auto-deployment` die Option `Enabled=true, RetainStacksOnAccountRemoval=true` fest.
```
$ aws cloudformation create-stack-set \
--stack-set-name stackset_name \
--permission-model SERVICE_MANAGED \
--template-url template_url \
--parameters "ParameterKey=param_name_1,ParameterValue=param_value_1" "ParameterKey=param_name_2,ParameterValue=param_value_2" \
--auto-deployment "Enabled=true, RetainStacksOnAccountRemoval=true"
```
1. Stellen Sie das Stack-Set bereit. Verwenden Sie den Befehl [ create-stack-instances](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/create-stack-instances.html).
Geben Sie für `--stack-set-name` den Namen des Stack-Sets an, das Sie im vorherigen Schritt erstellt haben.
Geben Sie für die ID der Stamm-OU an`--deployment-targets OrganizationalUnitIds`, die für eine gesamte Organisation bereitgestellt werden soll, oder der OU IDs , die für eine bestimmte OUs Organisationseinheit bereitgestellt werden soll.
Geben Sie für `--regions` die AWS Regionen an, in denen die Standardrichtlinien aktiviert werden sollen.
```
$ aws cloudformation create-stack-instances \
--stack-set-name stackset_name \
--deployment-targets OrganizationalUnitIds='["root_ou_id"]' | '["ou_id_1", "ou_id_2]' \
--regions '["region_1", "region_2"]'
```
**Um Standardrichtlinien für bestimmte Zielkonten zu aktivieren**
1. Erstellen Sie das Stack-Set. Verwenden Sie den Befehl [ create-stack-set](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/create-stack-set.html).
Geben Sie für `--template-url` eine der folgenden Vorlagen an URLs:
+ (Standardrichtlinien für AMIs EBS-gestützte Richtlinien) `https://s3.amazonaws.com/cloudformation-stackset-sample-templates-us-east-1/DataLifecycleManagerAMIDefaultPolicy.yaml`
+ (Standardrichtlinien für EBS-Snapshots) `https://s3.amazonaws.com/cloudformation-stackset-sample-templates-us-east-1/DataLifecycleManagerEBSSnapshotDefaultPolicy.yaml`
Geben Sie für `--administration-role-arn` den ARN der IAM-Dienstrolle an, die Sie zuvor für den Stackset-Administrator erstellt haben.
Geben Sie für `--execution-role-name` den Namen der IAM-Dienstrolle an, die Sie in den Zielkonten erstellt haben.
Geben Sie für `--parameters` die Einstellungen für die Standardrichtlinien an. Unterstützte Parameter, Parameterbeschreibungen und gültige Werte finden Sie, indem Sie die Vorlage über die URL herunterladen und die Vorlage anschließend in einem Texteditor anzeigen.
Legen Sie für `--auto-deployment` die Option `Enabled=true, RetainStacksOnAccountRemoval=true` fest.
```
$ aws cloudformation create-stack-set \
--stack-set-name stackset_name \
--template-url template_url \
--parameters "ParameterKey=param_name_1,ParameterValue=param_value_1" "ParameterKey=param_name_2,ParameterValue=param_value_2" \
--administration-role-arn administrator_role_arn \
--execution-role-name target_account_role \
--auto-deployment "Enabled=true, RetainStacksOnAccountRemoval=true"
```
1. Stellen Sie das Stack-Set bereit. Verwenden Sie den Befehl [ create-stack-instances](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/create-stack-instances.html).
Geben Sie für `--stack-set-name` den Namen des Stack-Sets an, das Sie im vorherigen Schritt erstellt haben.
Geben Sie für `--accounts` das IDs der AWS Zielkonten an.
Geben Sie für `--regions` die AWS Regionen an, in denen die Standardrichtlinien aktiviert werden sollen.
```
$ aws cloudformation create-stack-instances \
--stack-set-name stackset_name \
--accounts '["account_ID_1","account_ID_2"]' \
--regions '["region_1", "region_2"]'
```
------
# Benutzerdefinierte Amazon Data Lifecycle Manager Manager-Richtlinie für EBS-Snapshots erstellen
Das folgende Verfahren zeigt, wie Sie Amazon Data Lifecycle Manager verwenden, um Amazon-EBS-Snapshot-Lebenszyklen zu automatisieren.
**Topics**
+ [Erstellen einer Snapshot-Lebenszyklusrichtlinie](#create-snap-policy)
+ [Überlegungen zu Snapshot-Lebenszyklusrichtlinien](#snapshot-considerations)
+ [Weitere Ressourcen](#snapshot-additional-resources)
+ [Automatisieren Sie anwendungskonsistente Snapshots](automate-app-consistent-backups.md)
+ [Andere Anwendungsfälle für Vor- und Nach-Skripte](script-other-use-cases.md)
+ [Funktionsweise von Vor- und Nach-Skripten](script-flow.md)
+ [Identifizieren Sie Snapshots, die mit Vor- und Nachskripten erstellt wurden](dlm-script-tags.md)
+ [Überwachen Sie Vor- und Nachskripte](dlm-script-monitoring.md)
## Erstellen einer Snapshot-Lebenszyklusrichtlinie
Verwenden Sie eines der folgenden Verfahren, um eine Snapshot-Lebenszyklusrichtlinie zu erstellen.
------
#### [ Console ]
**So erstellen Sie eine Snapshot-Richtlinie**
1. Öffnen Sie die Amazon-EC2-Konsole unter [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. Wählen Sie im Navigationsbereich **Elastic Block Store** und **Lifecycle Manager** aus. Wählen Sie dann **Create lifecycle policy (Lebenszyklusrichtlinie erstellen)** aus.
1. Wählen Sie auf dem Bildschirm **Richtlinientyp auswählen** die Option **EBS-Snapshot-Richtlinie** und dann **Weiter** aus.
1. Gehen Sie im Abschnitt **Zielressourcen** wie folgt vor:
1. Wählen Sie für **Zielressourcentypen** den Typ der zu sichernden Ressource aus. Wählen Sie `Volume`, um Snapshots einzelner Volumes zu erstellen oder `Instance`, um Snapshots mit mehreren Volumes aus den Volumes zu erstellen, die an eine Instance angefügt sind.
1. (*Outpostund nur für Kunden mit lokaler Zone*) Geben Sie an, wo sich die Zielressourcen befinden.
Geben Sie unter **Zielressourcenspeicherort** an, wo sich die Zielressourcen befinden.
+ Um Ressourcen in einer Region als Ziel anzusprechen, wählen Sie **AWS Region** aus. Amazon Data Lifecycle Manager sichert alle Ressourcen des angegebenen Typs, die über übereinstimmende Ziel-Tags verfügen, nur in der aktuellen Region. Snapshots werden in derselben Region erstellt.
+ Um Ressourcen in lokalen Zonen als Ziel zu verwenden, wählen Sie **AWS Local Zones**. Amazon Data Lifecycle Manager sichert alle Ressourcen des angegebenen Typs, die über übereinstimmende Ziel-Tags verfügen, nur in allen Local Zones in der aktuellen Region. Snapshots können in derselben lokalen Zone wie die Quellressource oder in ihrer übergeordneten Region erstellt werden.
+ Um Ressourcen als Ziel zu verwendenOutpost, wählen Sie **AWS Outpost**. Amazon Data Lifecycle Manager sichert alle Ressourcen des angegebenen Typs, für die alle Outposts in Ihrem Konto übereinstimmende Ziel-Tags haben. Snapshots können auf derselben Ressource Outpost wie die Quellressource oder in ihrer übergeordneten Region erstellt werden.
1. Wählen Sie für **Zielressourcen-Tags** die Ressourcen-Tags aus, die die zu sichernden Volumes oder Instances identifizieren. Nur Ressourcen, die die angegebenen Tag (Markierung)-Schlüssel- und Wertepaare haben, werden von der Richtlinie gesichert.
1. Geben Sie unter **Description (Beschreibung)** eine kurze Beschreibung der Richtlinie ein.
1. Wählen Sie für **IAM-Rolle** die IAM-Rolle aus, die über Berechtigungen zum Verwalten von Snapshots und zum Beschreiben von Volumes und Instances verfügt. Um die von Amazon Data Lifecycle Manager bereitgestellte Standardrolle zu verwenden, wählen Sie **Standardrolle**. Um alternativ eine benutzerdefinierte IAM-Rolle zu verwenden, die Sie zuvor erstellt haben, wählen Sie **Andere Rolle auswählen** und dann die zu verwendende Rolle aus.
1. Fügen Sie für **Richtlinien-Tags** die Tags hinzu, die auf die Lebenszyklusrichtlinie angewendet werden sollen. Sie können diese Tags (Markierungen) verwenden, um Ihre Richtlinien zu identifizieren und zu kategorisieren.
1. Wählen Sie für **Policy status** (Richtlinienstatus) die Option **Enable** (Aktivieren) aus, um die Ausführung der Richtlinie zum nächsten geplanten Zeitpunkt zu starten oder **Disable policy** (Richtlinie deaktivieren), um die Ausführung der Richtlinie zu verhindern. Wenn Sie die Richtlinie jetzt nicht aktivieren, beginnt sie erst mit der Erstellung von Snapshots, wenn Sie sie nach der Erstellung manuell aktivieren.
1. (*Richtlinien, die nur auf Instances abzielen*) Schließen Sie Volumes aus Snapshot-Sets mit mehreren Volumes aus.
Standardmäßig erstellt Amazon Data Lifecycle Manager Snapshots aller Volumes, die an die Ziel-Instances angefügt sind. Sie können jedoch Snapshots einer Teilmenge der angehängten Volumes erstellen. Gehen Sie im Abschnitt **Parameters** (Parameter) wie folgt vor:
+ Wenn Sie keine Snapshots der Root-Volumes erstellen möchten, die den Ziel-Instances angefügt sind, wählen Sie **Exclude root volume** (Root-Volume ausschließen). Wenn Sie diese Option wählen, werden nur die Datenvolumes (Nicht-Root), die an die Ziel-Instances angefügt sind, in die Multi-Volume-Snapshot-Sets aufgenommen.
+ Wenn Sie Snapshots von einer Teilmenge der Daten-Volumes (Nicht-Root) erstellen möchten, die an die anvisierten Instances angefügt sind, wählen Sie **Exclude specific data volumes** (Bestimmte Daten-Volumes ausschließen) und geben Sie dann die Tags an, die verwendet werden sollen, um die Daten-Volumes zu identifizieren, die nicht in den Snapshot aufgenommen werden sollen. Amazon Data Lifecycle Manager erstellt keine Snapshots von Daten-Volumes, die über eines der angegebenen Tags verfügen. Amazon Data Lifecycle Manager erstellt nur Snapshots von Daten-Volumes, die keines der angegebenen Tags haben.
1. Wählen Sie **Weiter** aus.
1. Konfigurieren Sie auf dem Bildschirm **Zeitplan konfigurieren** die Richtlinienzeitpläne. Eine Richtlinie kann bis zu 4 Zeitpläne aufweisen. Zeitplan 1 ist obligatorisch. Die Zeitpläne 2, 3 und 4 sind optional. Gehen Sie für jeden Richtlinienzeitplan, den Sie hinzufügen, wie folgt vor:
1. Gehen Sie im Abschnitt **Zeitplandetails** wie folgt vor:
1. Geben Sie für **Zeitplanname** einen beschreibenden Namen für den Zeitplan an.
1. Konfigurieren Sie für **Häufigkeit** und die zugehörigen Felder das Intervall zwischen Richtlinienausführungen.
Sie können Richtlinienausführungen nach einem täglichen, wöchentlichen, monatlichen oder jährlichen Zeitplan konfigurieren. Alternativ können Sie **Custom cron expression (Benutzerdefinierter Cron-Ausdruck)** wählen, um ein Intervall von bis zu 1 Jahr anzugeben. Weitere Informationen finden Sie unter [Cron und Rate Expressions](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-scheduled-rule-pattern.html) im * EventBridge Amazon-Benutzerhandbuch*.
**Anmerkung**
Wenn Sie die **Snapshot-Archivierung** für den Zeitplan aktivieren müssen, müssen Sie als Häufigkeit **monthly** (monatlich) oder **yearly** (jährlich) auswählen oder einen Cron-Ausdruck mit einer Erstellungshäufigkeit von mindestens 28 Tagen angeben.
Wenn Sie eine monatliche Häufigkeit angeben, mit der Snapshots an einem bestimmten Tag in einer bestimmten Woche erstellt werden (z. B. am zweiten Donnerstag des Monats), muss für einen anzahlbasierten Zeitplan die Aufbewahrungsanzahl für die Archivstufe mindestens 4 betragen.
1. Geben Sie für **Starten um** die Uhrzeit an, zu der die Richtlinienausführungen für den Start geplant sind. Die erste Richtlinienausführung beginnt innerhalb einer Stunde nach der geplanten Zeit. Die Uhrzeit muss im `hh:mm` UTC-Format eingegeben werden.
1. Geben Sie für **Aufbewahrungstyp** die Aufbewahrungsrichtlinie für Schnappschüsse an, die vom Zeitplan erstellt wurden.
Sie können Snapshots basierend auf ihrer Gesamtzahl oder ihrem Alter aufbewahren.
+ Anzahlbasierte Aufbewahrung
+ Wenn die Snapshot-Archivierung deaktiviert ist, reicht der Bereich von `1` bis `1000`. Wenn der Aufbewahrungsschwellenwert erreicht ist, wird der älteste Snapshot dauerhaft gelöscht.
+ Bei aktivierter Snapshot-Archivierung reicht der Bereich von `0` (Archivierung sofort nach Erstellung) bis `1000`. Wenn der Aufbewahrungsschwellenwert erreicht ist, wird der älteste Snapshot in einen vollständigen Snapshot umgewandelt und in die Archivebene verschoben.
+ Altersbasierte Aufbewahrung
+ Wenn die Snapshot-Archivierung deaktiviert ist, reicht der Bereich von `1` Tagen bis `100` Jahren. Wenn der Aufbewahrungsschwellenwert erreicht ist, wird der älteste Snapshot dauerhaft gelöscht.
+ Bei aktivierter Snapshot-Archivierung reicht der Bereich von `0` Tagen (Archivierung sofort nach Erstellung) bis `100` Jahren. Wenn der Aufbewahrungsschwellenwert erreicht ist, wird der älteste Snapshot in einen vollständigen Snapshot umgewandelt und in die Archivebene verschoben.
**Anmerkung**
Alle Zeitpläne müssen denselben Aufbewahrungstyp aufweisen (alters- oder anzahlbasiert). Sie können den Aufbewahrungstyp nur für Zeitplan 1 angeben. Die Zeitpläne 2, 3 und 4 erben den Aufbewahrungstyp aus Plan 1. Jeder Zeitplan kann über eine eigene Aufbewahrungsanzahl oder einen eigenen Zeitraum verfügen.
Wenn Sie die schnelle Snapshot-Wiederherstellung, das regionsübergreifende Kopieren oder die Snapshot-Freigabe aktivieren, müssen Sie eine Aufbewahrungsanzahl von mindestens `1` oder einen Aufbewahrungszeitraum von mindestens `1` Tag angeben.
1. (*AWS Outposts und nur für Kunden in der lokalen Zone*) Geben Sie das Snapshot-Ziel an.
Geben Sie unter **Snapshot-Ziel ** das Ziel für Snapshots an, die von der Richtlinie erstellt wurden.
+ Wenn die Richtlinie auf Ressourcen in einer Region abzielt, müssen Snapshots in derselben Region erstellt werden. AWS Die Region ist für Sie ausgewählt.
+ Wenn die Richtlinie auf Ressourcen in einer lokalen Zone abzielt, können Sie Snapshots in derselben lokalen Zone wie die Quellressource oder in ihrer übergeordneten Region erstellen.
+ Wenn die Richtlinie auf Ressourcen in einer abzieltOutpost, können Sie Snapshots auf derselben Ressource Outpost wie die Quellressource oder in ihrer übergeordneten Region erstellen.
1. Konfigurieren Sie das Markieren von Snapshots.
Gehen Sie im Abschnitt **Tag (Markierung)** wie folgt vor:
1. Um alle benutzerdefinierten Tags vom Quell-Volume in die vom Zeitplan erstellten Schnappschüsse zu kopieren, wählen Sie **Tags aus Quelle kopieren**.
1. Um zusätzliche Tags (Markierungen) anzugeben, die Snapshots zugewiesen werden sollen, die von diesem Zeitplan erstellt wurden, wählen Sie **Tags (Markierungen) hinzufügen**.
1. Konfigurieren Sie Vor- und Nach-Skripte für anwendungskonsistente Snapshots.
Weitere Informationen finden Sie unter [Automatisieren Sie anwendungskonsistente Snapshots mit Data Lifecycle Manager](automate-app-consistent-backups.md).
1. (*Richtlinien, die nur auf Volumes abzielen*) Konfigurieren Sie die Snapshot-Archivierung.
Gehen Sie im Abschnitt **Snapshot-Archivierung** wie folgt vor:
**Anmerkung**
Die Snapshot-Archivierung lässt sich nur für einen Zeitplan in einer Richtlinie aktivieren.
1. Zum Aktivieren der Snapshot-Archivierung für den Zeitplan wählen Sie **Archive snapshots created by this schedule** (Mit diesem Zeitplan erstellte Snapshots archivieren) aus.
**Anmerkung**
Die Snapshot-Archivierung lässt sich nur aktivieren, wenn Snapshots monatlich oder jährlich erstellt werden oder wenn Sie einen Cron-Ausdruck mit einer Erstellungshäufigkeit von mindestens 28 Tagen angeben.
1. Geben Sie die Aufbewahrungsregel für Snapshots auf der Archivstufe an.
+ Geben Sie für **anzahlbasierte Zeitpläne** die Anzahl der Snapshots an, die auf der Archivstufe aufbewahrt werden sollen. Wenn der Aufbewahrungsschwellenwert erreicht ist, wird der älteste Snapshot dauerhaft aus der Archivstufe gelöscht. Wenn Sie beispielsweise drei angeben, behält der Zeitplan maximal drei Snapshots auf der Archivstufe bei. Bei Archivierung des vierten Snapshots wird der älteste der drei vorhandenen Snapshots auf der Archivstufe gelöscht.
+ Geben Sie für **altersbasierte Zeitpläne** den Zeitraum an, für den Snapshots auf der Archivstufe aufbewahrt werden sollen. Wenn der Aufbewahrungsschwellenwert erreicht ist, wird der älteste Snapshot dauerhaft aus der Archivstufe gelöscht. Wenn Sie beispielsweise 120 Tage angeben, werden Snapshots automatisch aus der Archivstufe gelöscht, wenn sie dieses Alter erreicht haben.
**Wichtig**
Der Mindestaufbewahrungszeitraum für archivierte Snapshots beträgt 90 Tage. Sie müssen eine Aufbewahrungsregel angeben, die den Snapshot mindestens 90 Tage lang aufbewahrt.
1. Aktivieren Sie die schnelle Snapshot-Wiederherstellung.
Um die schnelle Snapshot-Wiederherstellung für vom Zeitplan erstellte Snapshots zu aktivieren, wählen Sie im Abschnitt **Schnelle Snapshot-Wiederherstellung** die Option **Schnelle Snapshot-Wiederherstellung aktivieren** aus. Wenn Sie die schnelle Snapshot-Wiederherstellung aktivieren, müssen Sie die Availability Zones auswählen, in denen sie aktiviert werden soll. Wenn der Zeitplan einen altersbasierten Aufbewahrungszeitplan verwendet, müssen Sie den Zeitraum angeben, für den die schnelle Snapshot-Wiederherstellung für jeden Snapshot aktiviert werden soll. Wenn der Zeitplan eine zahlbasierte Aufbewahrung verwendet, müssen Sie die maximale Anzahl von Snapshots angeben, um die schnelle Snapshot-Wiederherstellung zu aktivieren.
Wenn der Zeitplan Snapshots auf einer erstelltOutpost, können Sie die schnelle Snapshot-Wiederherstellung nicht aktivieren. Die schnelle Snapshot-Wiederherstellung wird bei lokalen Snapshots, die auf einem gespeichert sind, nicht unterstützt. Outpost
**Anmerkung**
Es wird Ihnen jede Minute in Rechnung gestellt, in der die schnelle Snapshot-Wiederherstellung für einen Snapshot in einer bestimmten Availability Zone aktiviert ist. Die Gebühren werden mit mindestens einer Stunde anteilig bewertet.
1. Konfigurieren Sie das regionsübergreifende Kopieren.
Um nach dem Zeitplan erstellte Snapshots in eine Outpost oder in eine andere Region zu kopieren, wählen Sie im Abschnitt Regionsübergreifendes Kopieren die Option **Regionsübergreifendes Kopieren** **aktivieren** aus.
Wenn der Zeitplan Snapshots in einer Region erstellt, können Sie die Snapshots in bis zu drei weitere Regionen oder in Ihr Konto kopieren. Outposts Sie müssen für jede Zielregion oder eine separate Regel für regionsübergreifendes Kopieren angeben. Outpost
Für jede Region oder Outpost können Sie unterschiedliche Aufbewahrungsrichtlinien wählen und wählen, ob Sie alle oder keine Tags kopieren möchten. Wenn der Quell-Snapshot verschlüsselt ist oder wenn die Verschlüsselung standardmäßig aktiviert ist, werden die Snapshots-Kopien verschlüsselt. Wenn der Quell-Snapshot unverschlüsselt ist, können Sie die Verschlüsselung aktivieren. Wenn Sie keinen Verschlüsselung angeben, werden die Snapshots mit der Standard-Verschlüsselung für die EBS-Verschlüsselung in jeder Zielregion verschlüsselt. Wenn Sie einen Verschlüsselung für die Zielregion angeben, muss die ausgewählte IAM-Rolle Zugriff auf das Verschlüsselung haben.
**Anmerkung**
Sie müssen sicherstellen, dass Sie die Anzahl der gleichzeitigen Snapshot-Kopien pro Region nicht überschreiten.
Wenn die Richtlinie Snapshots für eine erstelltOutpost, können Sie die Snapshots nicht in eine Region oder in eine andere kopieren, Outpost und die Einstellungen für regionsübergreifendes Kopieren sind nicht verfügbar.
1. Konfigurieren Sie die kontoübergreifende gemeinsame Nutzung.
Konfigurieren Sie im Bereich **Kontoübergreifendes Teilen** die Richtlinie so, dass die nach dem Zeitplan erstellten Schnappschüsse automatisch mit anderen Konten geteilt werden. AWS Gehen Sie wie folgt vor:
1. Um das Teilen mit anderen AWS Konten zu aktivieren, wählen Sie **Kontoübergreifendes Teilen aktivieren** aus.
1. Um die Konten hinzuzufügen, mit denen die Schnappschüsse geteilt werden sollen, wählen Sie **Konto hinzufügen**, geben Sie die 12-stellige AWS -Konto-ID ein und wählen Sie **Hinzufügen**.
1. Um die Freigabe freigegebener Snapshots nach einem bestimmten Zeitraum automatisch aufzuheben, wählen Sie **Unshare automatically (Freigabe automatisch aufheben)**. Wenn Sie sich dafür entschieden haben, die Freigabe freigegebener Snapshots automatisch aufzuheben, kann der Zeitraum, nach dem die Snapshots automatisch aufgegeben werden, nicht länger sein als der Zeitraum, in dem die Richtlinie ihre Snapshots aufbewahrt. Wenn die Aufbewahrungskonfiguration der Richtlinie beispielsweise Snapshots für einen Zeitraum von 5 Tagen aufbewahrt, können Sie die Richtlinie nur so konfigurieren, dass freigegebene Snapshots automatisch nach Zeiträumen von bis zu 4 Tagen freigegeben werden. Dies gilt für Richtlinien mit alters- und anzahlbasierten Snapshot-Aufbewahrungskonfigurationen.
Wenn Sie die automatische Freigabe nicht aktivieren, wird der Snapshot freigegeben, bis er gelöscht wird.
**Anmerkung**
Sie können nur Snapshots freigeben, die unverschlüsselt oder mit einem Kundenverwalteter Schlüssel verschlüsselt sind. Sie können keine Snapshots freigeben, die mit dem standardmäßigen EBS-Verschlüsselungs-Verschlüsselung verschlüsselt sind. Wenn Sie verschlüsselte Snapshots teilen, müssen Sie auch den Verschlüsselung, der zum Verschlüsseln des Quell-Volumes verwendet wurde, mit den Zielkonten teilen. Weitere Informationen finden Sie unter [Benutzern in anderen Konten die Verwendung eines KMS-Schlüssels erlauben](https://docs.aws.amazon.com//kms/latest/developerguide/key-policy-modifying-external-accounts.html) im *AWS Key Management Service -Entwicklerhandbuch*.
1. Um weitere Zeitpläne hinzuzufügen, wählen Sie die Option **Weiteren Zeitplan hinzufügen**, die sich oben auf dem Bildschirm befindet. Füllen Sie für jeden zusätzlichen Zeitplan die Felder wie oben in diesem Thema beschrieben aus.
1. Nachdem Sie die erforderlichen Zeitpläne hinzugefügt haben, wählen Sie **Richtlinie überprüfen** aus.
1. Überprüfen Sie die Richtlinienzusammenfassung und wählen Sie dann **Richtlinie erstellen** aus.
**Anmerkung**
Falls Sie den Fehler `Role with name AWSDataLifecycleManagerDefaultRole already exists` erhalten, finden Sie weitere Informationen unter [Probleme mit Amazon Data Lifecycle Manager beheben](dlm-troubleshooting.md).
------
#### [ Command line ]
Verwenden Sie den [create-lifecycle-policy](https://docs.aws.amazon.com/cli/latest/reference/dlm/create-lifecycle-policy.html)Befehl, um eine Snapshot-Lebenszyklusrichtlinie zu erstellen. Legen Sie für `PolicyType` die Option `EBS_SNAPSHOT_MANAGEMENT` fest.
**Anmerkung**
Zur Vereinfachung der Syntax wird in den folgenden Beispielen eine JSON-Datei `policyDetails.json` verwendet, die die Richtliniendetails enthält.
**Beispiel 1 – Snapshot-Lebenszyklusrichtlinie mit zwei Zeitplänen**
In diesem Beispiel wird eine Snapshot-Lebenszyklusrichtlinie erstellt, die Snapshots aller Volumes erstellt, die einen Tag (Markierung)-Schlüssel `costcenter` mit dem Wert von `115` haben. Die Richtlinie enthält zwei Zeitpläne. Der erste Zeitplan erstellt jeden Tag um 03:00 Uhr UTC einen Snapshot. Der zweite Zeitplan erstellt jeden Freitag um 17:00 Uhr UTC einen wöchentlichen Snapshot.
```
aws dlm create-lifecycle-policy \
--description "My volume policy" \
--state ENABLED \
--execution-role-arn arn:aws:iam::12345678910:role/AWSDataLifecycleManagerDefaultRole \
--policy-details file://policyDetails.json
```
Das folgende Beispiel zeigt eine `policyDetails.json`-Datei.
```
{
"PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
"ResourceTypes": [
"VOLUME"
],
"TargetTags": [{
"Key": "costcenter",
"Value": "115"
}],
"Schedules": [{
"Name": "DailySnapshots",
"TagsToAdd": [{
"Key": "type",
"Value": "myDailySnapshot"
}],
"CreateRule": {
"Interval": 24,
"IntervalUnit": "HOURS",
"Times": [
"03:00"
]
},
"RetainRule": {
"Count": 5
},
"CopyTags": false
},
{
"Name": "WeeklySnapshots",
"TagsToAdd": [{
"Key": "type",
"Value": "myWeeklySnapshot"
}],
"CreateRule": {
"CronExpression": "cron(0 17 ? * FRI *)"
},
"RetainRule": {
"Count": 5
},
"CopyTags": false
}
]}
```
Wenn die Anforderung erfolgreich ist, gibt der Befehl die ID der neu erstellten Richtlinie zurück. Es folgt eine Beispielausgabe.
```
{
"PolicyId": "policy-0123456789abcdef0"
}
```
**Beispiel 2 – Snapshot-Lebenszyklusrichtlinie, die auf Instances abzielt und Snapshots einer Untergruppe von Datenvolumes (Nicht-Root) erstellt**
In diesem Beispiel wird eine Snapshot-Lebenszyklusrichtlinie erstellt, die Multi-Volume-Snapshot-Sets aus Instaces erstellt, die mit `code=production` gekennzeichnet sind. Die Richtlinie enthält nur einen Zeitplan. Der Zeitplan erstellt keine Snapshots von den Daten-Volumes, die mit `code=temp` gekennzeichnet sind.
```
aws dlm create-lifecycle-policy \
--description "My volume policy" \
--state ENABLED \
--execution-role-arn arn:aws:iam::12345678910:role/AWSDataLifecycleManagerDefaultRole \
--policy-details file://policyDetails.json
```
Das folgende Beispiel zeigt eine `policyDetails.json`-Datei.
```
{
"PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
"ResourceTypes": [
"INSTANCE"
],
"TargetTags": [{
"Key": "code",
"Value": "production"
}],
"Parameters": {
"ExcludeDataVolumeTags": [{
"Key": "code",
"Value": "temp"
}]
},
"Schedules": [{
"Name": "DailySnapshots",
"TagsToAdd": [{
"Key": "type",
"Value": "myDailySnapshot"
}],
"CreateRule": {
"Interval": 24,
"IntervalUnit": "HOURS",
"Times": [
"03:00"
]
},
"RetainRule": {
"Count": 5
},
"CopyTags": false
}
]}
```
Wenn die Anforderung erfolgreich ist, gibt der Befehl die ID der neu erstellten Richtlinie zurück. Es folgt eine Beispielausgabe.
```
{
"PolicyId": "policy-0123456789abcdef0"
}
```
**Beispiel 3 — Snapshot-Lifecycle-Richtlinie, die lokale Snapshots von Ressourcen automatisiert Outpost**
In diesem Beispiel wird eine Snapshot-Lifecycle-Richtlinie erstellt, die Snapshots von Volumes erstellt, die mit `team=dev` markiert sind. Outposts Die Richtlinie erstellt die Snapshots auf denselben Volumes Outposts wie die Quellvolumes. Die Richtlinie erstellt alle `12` Stunden Snapshots bei `00:00` UTC.
```
aws dlm create-lifecycle-policy \
--description "My local snapshot policy" \
--state ENABLED \
--execution-role-arn arn:aws:iam::12345678910:role/AWSDataLifecycleManagerDefaultRole \
--policy-details file://policyDetails.json
```
Das folgende Beispiel zeigt eine `policyDetails.json`-Datei.
```
{
"PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
"ResourceTypes": "VOLUME",
"ResourceLocations": "OUTPOST",
"TargetTags": [{
"Key": "team",
"Value": "dev"
}],
"Schedules": [{
"Name": "on-site backup",
"CreateRule": {
"Interval": 12,
"IntervalUnit": "HOURS",
"Times": [
"00:00"
],
"Location": [
"OUTPOST_LOCAL"
]
},
"RetainRule": {
"Count": 1
},
"CopyTags": false
}
]}
```
**Beispiel 4 — Snapshot-Lifecycle-Richtlinie, die Snapshots in einer Region erstellt und sie in eine kopiert Outpost**
Die folgende Beispielrichtlinie erstellt Snapshots von Volumes, die mit `team=dev` markiert sind. Die Snapshots werden in der gleichen Region erstellt wie das Quell-Volume. Snapshots werden alle `12` Stunden bei `00:00` UTC erstellt und bewahren ein Maximum an Snapshots von `1`. Die Richtlinie kopiert auch die Snapshots in Outpost`arn:aws:outposts:us-east-1:123456789012:outpost/op-1234567890abcdef0`, verschlüsselt die kopierten Snapshots mit dem standardmäßigen KMS-Verschlüsselungsschlüssel und bewahrt die Kopien für einen Monat auf. `1`
```
aws dlm create-lifecycle-policy \
--description "Copy snapshots to Outpost" \
--state ENABLED \
--execution-role-arn arn:aws:iam::12345678910:role/AWSDataLifecycleManagerDefaultRole \
--policy-details file://policyDetails.json
```
Das folgende Beispiel zeigt eine `policyDetails.json`-Datei.
```
{
"PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
"ResourceTypes": "VOLUME",
"ResourceLocations": "CLOUD",
"TargetTags": [{
"Key": "team",
"Value": "dev"
}],
"Schedules": [{
"Name": "on-site backup",
"CopyTags": false,
"CreateRule": {
"Interval": 12,
"IntervalUnit": "HOURS",
"Times": [
"00:00"
],
"Location": "CLOUD"
},
"RetainRule": {
"Count": 1
},
"CrossRegionCopyRules" : [
{
"Target": "arn:aws:outposts:us-east-1:123456789012:outpost/op-1234567890abcdef0",
"Encrypted": true,
"CopyTags": true,
"RetainRule": {
"Interval": 1,
"IntervalUnit": "MONTHS"
}
}]
}
]}
```
**Beispiel 5 – Snapshot-Lebenszyklusrichtlinie mit einem archivfähigen, altersbasierten Zeitplan**
In diesem Beispiel wird eine Snapshot-Lebenszyklusrichtlinie erstellt, die für mit `Name=Prod` markierte Volumes gilt. Die Richtlinie hat einen altersbasierten Zeitplan, der Snapshots am ersten Tag eines jeden Monats um 09.00 Uhr erstellt. Der Zeitplan bewahrt alle Snapshots auf der Standardstufe einen Tag lang auf. Danach werden sie in die Archivstufe verschoben. Snapshots werden 90 Tage lang auf der Archivstufe gespeichert, bevor sie gelöscht werden.
```
aws dlm create-lifecycle-policy \
--description "Copy snapshots to Outpost" \
--state ENABLED \
--execution-role-arn arn:aws:iam::12345678910:role/AWSDataLifecycleManagerDefaultRole \
--policy-details file://policyDetails.json
```
Das folgende Beispiel zeigt eine `policyDetails.json`-Datei.
```
{
"ResourceTypes": [ "VOLUME"],
"PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
"Schedules" : [
{
"Name": "sched1",
"TagsToAdd": [
{"Key":"createdby","Value":"dlm"}
],
"CreateRule": {
"CronExpression": "cron(0 9 1 * ? *)"
},
"CopyTags": true,
"RetainRule":{
"Interval": 1,
"IntervalUnit": "DAYS"
},
"ArchiveRule": {
"RetainRule":{
"RetentionArchiveTier": {
"Interval": 90,
"IntervalUnit": "DAYS"
}
}
}
}
],
"TargetTags": [
{
"Key": "Name",
"Value": "Prod"
}
]
}
```
**Beispiel 6 – Snapshot-Lebenszyklusrichtlinie mit einem archivfähigen, anzahlbasierten Zeitplan**
In diesem Beispiel wird eine Snapshot-Lebenszyklusrichtlinie erstellt, die für mit `Purpose=Test` markierte Volumes gilt. Die Richtlinie hat einen anzahlbasierten Zeitplan, der Snapshots am ersten Tag eines jeden Monats um 09.00 Uhr erstellt. Der Zeitplan archiviert Snapshots unmittelbar nach der Erstellung und bewahrt maximal drei Snapshots auf der Archivstufe auf.
```
aws dlm create-lifecycle-policy \
--description "Copy snapshots to Outpost" \
--state ENABLED \
--execution-role-arn arn:aws:iam::12345678910:role/AWSDataLifecycleManagerDefaultRole \
--policy-details file://policyDetails.json
```
Das folgende Beispiel zeigt eine `policyDetails.json`-Datei.
```
{
"ResourceTypes": [ "VOLUME"],
"PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
"Schedules" : [
{
"Name": "sched1",
"TagsToAdd": [
{"Key":"createdby","Value":"dlm"}
],
"CreateRule": {
"CronExpression": "cron(0 9 1 * ? *)"
},
"CopyTags": true,
"RetainRule":{
"Count": 0
},
"ArchiveRule": {
"RetainRule":{
"RetentionArchiveTier": {
"Count": 3
}
}
}
}
],
"TargetTags": [
{
"Key": "Purpose",
"Value": "Test"
}
]
}
```
------
## Überlegungen zu Snapshot-Lebenszyklusrichtlinien
Die folgenden **allgemeinen Überlegungen** gelten für Snapshot-Lebenszyklusrichtlinien:
+ Snapshot-Lebenszyklusrichtlinien zielen nur auf Instances oder Volumes ab, die sich in derselben Region wie die Richtlinie befinden.
+ Der erste Snapshot-Erstellungsvorgang beginnt innerhalb einer Stunde nach der angegebenen Startzeit. Nachfolgende Snapshot-Erstellungsvorgänge beginnen innerhalb einer Stunde nach ihrer geplanten Zeit.
+ Sie können mehrere Richtlinien zum Sichern eines Volumes oder einer Instance erstellen. Wenn ein Volume zwei Tags hat, wobei Tag *A* das Ziel für Richtlinie *A* ist, alle 12 Stunden einen Snapshot zu erstellen, und Tag *B* das Ziel für Richtlinie *B*, alle 24 Stunden einen Snapshot zu erstellen, erstellt Amazon Data Lifecycle Manager Snapshots gemäß den Zeitplänen für beide Richtlinien. Alternativ können Sie dasselbe Ergebnis erzielen, indem Sie eine einzelne Richtlinie mit mehreren Zeitplänen erstellen. Sie können beispielsweise eine einzelne Richtlinie erstellen, die nur auf Tag (Markierung) *A*abzielt, und zwei Zeitpläne angeben – einen für alle 12 Stunden und einen für alle 24 Stunden.
+ Bei Zielressourcen-Tags muss die Groß-/Kleinschreibung beachtet werden.
+ Wenn Sie die Ziel-Tags von einer Ressource entfernen, auf die eine Richtlinie abzielt, verwaltet Amazon Data Lifecycle Manager die vorhandenen Snapshots im Standard-Tier und Archiv-Tier nicht mehr; Sie müssen sie manuell löschen, wenn sie nicht mehr benötigt werden.
+ Wenn Sie eine Richtlinie erstellen, die auf Instances abzielt, und neue Volumes an die Ziel-Instance angefügt werden, nachdem die Richtlinie erstellt wurde, werden die neu hinzugefügten Volumes bei der nächsten Richtlinienausführung in das Backup einbezogen. Alle Volumes, die zum Zeitpunkt der Richtlinienausführung mit der Instance verbunden sind, sind enthalten.
+ Wenn Sie eine Richtlinie mit einem benutzerdefinierten Cron-basierten Zeitplan so erstellen und konfigurieren, dass nur ein Snapshot erstellt wird, wird die Richtlinie diesen Snapshot nicht automatisch löschen, wenn der Aufbewahrungsschwellenwert erreicht ist. Sie müssen den Snapshot manuell löschen, wenn er nicht mehr länger benötigt wird.
+ Wenn Sie eine altersbasierte Richtlinie erstellen, bei der der Aufbewahrungszeitraum kürzer ist als die Erstellungshäufigkeit, behält Amazon Data Lifecycle Manager immer den letzten Snapshot bei, bis der nächste erstellt wird. Wenn zum Beispiel eine altersbasierte Richtlinie jeden Monat einen Snapshot mit einer Aufbewahrungsfrist von sieben Tagen erstellt, behält Amazon Data Lifecycle Manager jeden Snapshot einen Monat lang bei, obwohl die Aufbewahrungsfrist sieben Tage beträgt.
Die folgenden Überlegungen beziehen sich auf die **[Snapshot-Archivierung](snapshot-archive.md)**:
+ Die Snapshot-Archivierung lässt sich nur für Snapshot-Richtlinien aktivieren, die für Volumes gelten.
+ Pro Richtlinie können Sie nur eine Archivierungsregel für einen Zeitplan angeben.
+ Bei Verwendung der Konsole lässt sich die Snapshot-Archivierung nur aktivieren, wenn der Zeitplan eine monatliche oder jährliche Erstellungshäufigkeit oder einen Cron-Ausdruck mit einer Erstellungshäufigkeit von mindestens 28 Tagen aufweist.
Wenn Sie die AWS API oder das AWS SDK verwenden AWS CLI, können Sie die Snapshot-Archivierung nur aktivieren, wenn der Zeitplan einen Cron-Ausdruck mit einer Erstellungshäufigkeit von mindestens 28 Tagen enthält.
+ Der Mindestaufbewahrungszeitraum auf der Archivstufe beträgt 90 Tage.
+ Wenn ein Snapshot archiviert wird, wird er beim Verschieben in die Archivstufe in einen vollständigen Snapshot konvertiert. Dies kann zu höheren Kosten für die Snapshot-Speicherung führen. Weitere Informationen finden Sie unter [Preise und Abrechnung für die Archivierung von Amazon EBS-Snapshots](snapshot-archive-pricing.md).
+ Die schnelle Snapshot-Wiederherstellung und die Snapshot-Freigabe werden für Snapshots deaktiviert, wenn sie archiviert werden.
+ Wenn Ihre Aufbewahrungsregel in einem Schaltjahr zu einem Archivierungszeitraum von weniger als 90 Tagen führt, stellt Amazon Data Lifecycle Manager sicher, dass Snapshots mindestens 90 Tage lang aufbewahrt werden.
+ Wenn Sie einen von Amazon Data Lifecycle Manager erstellten Snapshot manuell archivieren und der Snapshot bei Erreichen des Aufbewahrungsschwellenwerts des Zeitplans immer noch archiviert ist, wird dieser Snapshot nicht mehr von Amazon Data Lifecycle Manager verwaltet. Wenn Sie den Snapshot jedoch vor Erreichen des Aufbewahrungsschwellenwerts des Zeitplans wieder in die Standardstufe verschieben, wird er vom Zeitplan weiterhin gemäß den Aufbewahrungsregeln verwaltet.
+ Wenn Sie einen von Amazon Data Lifecycle Manager archivierten Snapshot dauerhaft oder temporär wieder in die Standardstufe verschieben und der Snapshot sich bei Erreichen des Aufbewahrungsschwellenwerts des Zeitplans immer noch auf der Standardstufe befindet, wird dieser Snapshot nicht mehr von Amazon Data Lifecycle Manager verwaltet. Wenn Sie den Snapshot jedoch vor Erreichen des Aufbewahrungsschwellenwerts des Zeitplans erneut archivieren, wird er vom Zeitplan gelöscht, sobald der Aufbewahrungsschwellenwert erreicht ist.
+ Von Amazon Data Lifecycle Manager archivierte Snapshots werden auf Ihre `Archived snapshots per volume`- und `In-progress snapshot archives per account`-Kontingente angerechnet.
+ Wenn ein Zeitplan einen Snapshot nicht archivieren kann, nachdem dies 24 Stunden lang immer wieder versucht wurde, verbleibt der Snapshot auf der Standardstufe. Seine Löschung wird dann zu dem Zeitpunkt geplant, zu dem er aus der Archivstufe gelöscht worden wäre. Wenn der Zeitplan Snapshots beispielsweise 120 Tage lang archiviert, bleibt der Snapshot nach der fehlgeschlagenen Archivierung 120 Tage lang auf der Standardstufe, bevor er endgültig gelöscht wird. Bei anzahlbasierten Zeitplänen wird der Snapshot nicht auf die Aufbewahrungsanzahl des Zeitplans angerechnet.
+ Snapshots müssen in derselben Region archiviert werden, in der sie erstellt wurden. Wenn Sie das regionsübergreifende Kopieren und die Snapshot-Archivierung aktiviert haben, wird die Snapshot-Kopie von Amazon Data Lifecycle Manager nicht archiviert.
+ Von Amazon Data Lifecycle Manager archivierte Snapshots werden mit dem System-Tag `aws:dlm:archived=true` markiert. Darüber hinaus werden Snapshots, die nach einem für die Archivierung aktivierten, altersbasierten Zeitplan erstellt wurden, mit dem System-Tag `aws:dlm:expirationTime` markiert, das das Datum und die Uhrzeit für die geplante Archivierung des Snapshots angibt.
Die folgenden Überlegungen gelten für das **Ausschließen von Root-Volumes und Daten-Volumes (Nicht-Root)**:
+ Wenn Sie Startvolumes ausschließen und Tags angeben, die folglich alle zusätzlichen Datenvolumes ausschließen, die an eine Instance angehängt sind, erstellt Amazon Data Lifecycle Manager keine Snapshots für die betroffene Instance und gibt eine `SnapshotsCreateFailed` CloudWatch Metrik aus. Weitere Informationen finden Sie unter [Überwachen Sie Richtlinien mithilfe von CloudWatch](monitor-dlm-cw-metrics.md).
Die folgenden Überlegungen gelten für das **Löschen von Volumes oder das Beenden von Instances, die von Snapshot-Lebenszyklus-Richtlinien betroffen sind**:
+ Wenn Sie ein Volume löschen oder eine Instance beenden, für das oder die eine Richtlinie mit einem anzahlbasierten Aufbewahrungszeitplan gilt, werden die Snapshots auf der Standard- und Archivstufe, die von dem gelöschten Volume oder der beendeten Instance erstellt wurden, nicht mehr von Amazon Data Lifecycle Manager verwaltet. Sie müssen diese früheren Snapshots manuell löschen, wenn sie nicht mehr benötigt werden.
+ Wenn Sie ein Volume löschen oder eine Instance beenden, für das oder die eine Richtlinie mit einem altersbasierten Aufbewahrungszeitplan gilt, werden die Snapshots, die von dem gelöschten Volume oder der beendeten Instance erstellt wurden, von der Richtlinie weiterhin nach dem definierten Zeitplan gelöscht, und zwar bis zum letzten Snapshot, aber nicht einschließlich. Sie müssen den letzten Snapshot manuell löschen, wenn er nicht mehr benötigt wird.
Die folgenden Überlegungen gelten für Snapshot-Lebenszyklusrichtlinien und ** [fast snapshot restore](ebs-fast-snapshot-restore.md)** (schnelle Snapshot-Wiederherstellung):
+ Amazon Data Lifecycle Manager kann die schnelle Snapshot-Wiederherstellung nur für Snapshots mit einer Größe von 16 TiB oder weniger ermöglichen. Weitere Informationen finden Sie unter [Schnelle Amazon EBS-Snapshot-Wiederherstellung](ebs-fast-snapshot-restore.md).
+ Ein Snapshot, der für die schnelle Snapshot-Wiederherstellung aktiviert ist, bleibt auch dann aktiviert, wenn Sie die Richtlinie löschen oder deaktivieren, die schnelle Snapshot-Wiederherstellung für die Richtlinie deaktivieren oder die schnelle Snapshot-Wiederherstellung für die Availability Zone deaktivieren. Sie müssen die schnelle Snapshot-Wiederherstellung für diese Snapshots manuell deaktivieren.
+ Wenn Sie die schnelle Snapshot-Wiederherstellung für eine Richtlinie aktivieren und die maximale Anzahl von Snapshots überschreiten, die für die schnelle Snapshot-Wiederherstellung aktiviert werden können, erstellt Amazon Data Lifecycle Manager Snapshots wie geplant, aktiviert sie aber nicht für die schnelle Snapshot-Wiederherstellung. Nachdem ein Snapshot, der zur einer schnellen Snapshot-Wiederherstellung fähig ist, gelöscht wurde, wird der nächste von Amazon Data Lifecycle Manager erstellte Snapshot für die schnelle Snapshot-Wiederherstellung aktiviert.
+ Wenn die schnelle Snapshot-Wiederherstellung für einen Snapshot aktiviert wird, dauert es 60 Minuten pro TiB, bis der Snapshot optimiert ist. Wir empfehlen Ihnen die Konfiguration Ihrer Zeitpläne, sodass jeder Snapshot vollständig optimiert ist, bevor Amazon Data Lifecycle Manager den nächsten Snapshot erstellt.
+ Wenn Sie die schnelle Snapshot-Wiederherstellung für eine Richtlinie aktivieren, die auf Instances abzielt, aktiviert Amazon Data Lifecycle Manager die schnelle Snapshot-Wiederherstellung individuell für jeden Snapshot im Satz von Multi-Volume-Snapshots. Wenn Amazon Data Lifecycle Manager die schnelle Snapshot-Wiederherstellung für einen der Snapshots im Satz von Multi-Volume-Snapshots nicht aktiviert, wird er weiterhin versuchen, die schnelle Snapshot-Wiederherstellung für die verbleibenden Snapshots im Snapshot-Satz zu aktivieren.
+ Es wird Ihnen jede Minute in Rechnung gestellt, in der die schnelle Snapshot-Wiederherstellung für einen Snapshot in einer bestimmten Availability Zone aktiviert ist. Die Gebühren werden mit mindestens einer Stunde anteilig bewertet. Weitere Informationen finden Sie unter [Preise und Fakturierung](ebs-fast-snapshot-restore.md#fsr-pricing).
**Anmerkung**
Abhängig von der Konfiguration Ihrer Lebenszyklusrichtlinien können mehrere Snapshots aktiviert werden, um gleichzeitig eine schnelle Snapshot-Wiederherstellung in mehreren Availability Zones zu ermöglichen.
Die folgenden Überlegungen gelten für Snapshot-Lebenszyklusrichtlinien und für ** [Multi-Attach](ebs-volumes-multi.md)-fähige Volumes**:
+ Wenn Sie eine Lebenszyklusrichtlinie erstellen, die auf Instances abzielt, die über dasselbe Multi-Attach-fähige Volume verfügen, initiiert Amazon Data Lifecycle Manager für jede angefügte Instance einen Snapshot des Volumes. Verwenden Sie das *timestamp*-Tag, um die Menge zeitkonsistenter Snapshots zu bestimmen, die von den angefügten Instances erstellt wurden.
Die folgenden Überlegungen gelten für die **kontoübergreifende Freigabe von Snapshots**:
+ Sie können nur Snapshots freigeben, die unverschlüsselt oder mit einem Kundenverwalteter Schlüssel verschlüsselt sind.
+ Sie können keine Snapshots freigeben, die mit dem standardmäßigen EBS-Verschlüsselungs-Verschlüsselung verschlüsselt sind.
+ Wenn Sie verschlüsselte Snapshots freigeben, müssen Sie auch den KMS-Schlüssel, der zum Verschlüsseln des Quell-Volumes verwendet wurde, für die Zielkonten freigeben. Weitere Informationen finden Sie unter [Benutzern in anderen Konten die Verwendung eines KMS-Schlüssels erlauben](https://docs.aws.amazon.com//kms/latest/developerguide/key-policy-modifying-external-accounts.html) im *AWS Key Management Service -Entwicklerhandbuch*.
Die folgenden Überlegungen gelten für Snapshot-Richtlinien und die ** [Snapshot–Archivierung](snapshot-archive.md)**:
+ Wenn Sie einen Snapshot, der von einer Richtlinie erstellt wurde, manuell archivieren und sich dieser Snapshot auf der Archivstufe befindet, wenn der Aufbewahrungsschwellenwert der Richtlinie erreicht wird, löscht Amazon Data Lifecycle Manager den Snapshot nicht. Amazon Data Lifecycle Manager verwaltet keine Snapshots, während sie auf der Archivstufe gespeichert sind. Wenn Sie auf der Archivstufe gespeicherte Snapshots nicht mehr benötigen, müssen Sie sie manuell löschen.
Die folgenden Überlegungen gelten für Snapshot-Richtlinien und den [Papierkorb](recycle-bin.md):
+ Wenn Amazon Data Lifecycle Manager einen Snapshot löscht und ihn an den Papierkorb sendet, wenn der Aufbewahrungsschwellenwert der Richtlinie erreicht wird, und Sie den Snapshot manuell aus dem Papierkorb wiederherstellen, müssen Sie diesen Snapshot manuell löschen, wenn er nicht mehr benötigt wird. Amazon Data Lifecycle Manager verwaltet den Snapshot nicht mehr.
+ Wenn Sie einen Snapshot, der von einer Richtlinie erstellt wurde, manuell löschen und sich dieser Snapshot im Papierkorb befindet, wenn der Aufbewahrungsschwellenwert der Richtlinie erreicht wird, löscht Amazon Data Lifecycle Manager den Snapshot nicht. Amazon Data Lifecycle Manager verwaltet die Snapshots nicht, während sie im Papierkorb gespeichert sind.
Wenn der Snapshot aus dem Papierkorb wiederhergestellt wird, bevor der Aufbewahrungsschwellenwert der Richtlinie erreicht wird, löscht Amazon Data Lifecycle Manager den Snapshot, sobald der Aufbewahrungsschwellenwert der Richtlinie erreicht wird.
Wenn der Snapshot aus dem Papierkorb wiederhergestellt wird, nachdem der Aufbewahrungsschwellenwert der Richtlinie erreicht wurde, löscht Amazon Data Lifecycle Manager den Snapshot nicht mehr. Sie müssen den Snapshot manuell löschen, wenn er nicht mehr benötigt wird.
Die folgenden Überlegungen gelten für Snapshot-Lebenszyklusrichtlinien, die sich im **error**-Status befinden:
+ Bei Richtlinien mit altersbasierten Aufbewahrungszeitplänen werden Snapshots, deren Aufbewahrungszeiträume ablaufen, während sich die Richtlinie im `error`-Status befindet, auf unbestimmte Zeit aufbewahrt. Die Snapshots müssen Sie manuell löschen. Wenn Sie die Richtlinie erneut aktivieren, setzt Amazon Data Lifecycle Manager das Löschen von Snapshots fort, wenn ihre Aufbewahrungszeiträume ablaufen.
+ Bei Richtlinien mit anzahlbasierten Aufbewahrungszeitplänen stoppt die Richtlinie das Erstellen und Löschen von Snapshots, während sie sich im `error`-Status befindet. Wenn Sie die Richtlinie erneut aktivieren, setzt Amazon Data Lifecycle Manager das Erstellen von Snapshots sowie das Löschen von Snapshots bei Erreichen des Aufbewahrungsschwellenwerts fort.
Die folgenden Überlegungen gelten für Snapshot-Richtlinien und das **[Sperren von Snapshots](ebs-snapshot-lock.md)**:
+ Wenn Sie einen von Amazon Data Lifecycle Manager erstellten Snapshot manuell sperren und dieser Snapshot bei Erreichen des Aufbewahrungsschwellenwerts des Zeitplans immer noch gesperrt ist, wird dieser Snapshot nicht mehr von Amazon Data Lifecycle Manager verwaltet. Sie müssen den Snapshot manuell löschen, wenn er nicht mehr länger benötigt wird.
+ Wenn Sie einen von Amazon Data Lifecycle Manager erstellten und für die schnelle Snapshot-Wiederherstellung aktivierten Snapshot manuell sperren und der Snapshot bei Erreichen des Aufbewahrungsschwellenwerts immer noch gesperrt ist, wird Amazon Data Lifecycle Manager die schnelle Snapshot-Wiederherstellung nicht deaktivieren oder den Snapshot löschen. Sie müssen die schnelle Snapshot-Wiederherstellung manuell deaktivieren und den Snapshot löschen, wenn er nicht mehr länger benötigt wird.
+ Wenn Sie einen Snapshot, der von Amazon Data Lifecycle Manager mit einem AMI erstellt wurde, manuell anmelden, diesen Snapshot dann sperren und er immer noch gesperrt und dem AMI zugeordnet ist, wenn der Aufbewahrungsschwellenwert erreicht wird, versucht Amazon Data Lifecycle Manager weiterhin, diesen Snapshot zu löschen. Wenn das AMI abgemeldet ist und der Snapshot entsperrt wurde, löscht Amazon Data Lifecycle Manager den Snapshot automatisch.
## Weitere Ressourcen
Weitere Informationen finden Sie im Blog [Automating Amazon EBS snapshot and AMI management using Amazon Data Lifecycle Manager](https://aws.amazon.com/blogs/storage/automating-amazon-ebs-snapshot-and-ami-management-using-amazon-dlm/) AWS storage.
# Automatisieren Sie anwendungskonsistente Snapshots mit Data Lifecycle Manager
Sie können anwendungskonsistente Snapshots mit Amazon Data Lifecycle Manager automatisieren, indem Sie in Ihren Snapshot-Lebenszyklusrichtlinien Vor- und Nach-Skripts aktivieren, die auf Instances abzielen.
Amazon Data Lifecycle Manager ist in AWS Systems Manager (Systems Manager) integriert, um anwendungskonsistente Snapshots zu unterstützen. Amazon Data Lifecycle Manager verwendet Systems-Manager-Befehlsdokumente (SSM-Befehlsdokumente), die Vor- und Nach-Skripte enthalten, um die Aktionen zu automatisieren, die für die Erstellung anwendungskonsistenter Snapshots erforderlich sind. Bevor Amazon Data Lifecycle Manager die Snapshot-Erstellung initiiert, führt er die Befehle im Pre-Skript zum Einfrieren und Leeren aus. I/O. After Amazon Data Lifecycle Manager initiates snapshot creation, it runs the commands in the post script to thaw I/O
Amazon Data Lifecycle Manager ermöglicht die Automatisierung anwendungskonsistenter Snapshots der folgenden Elemente:
+ Windows-Anwendungen unter Verwendung von Volume Shadow Copy Service (VSS)
+ SAP HANA verwendet ein AWS verwaltetes SSDM-Dokument. Weitere Informationen finden Sie unter [Amazon-EBS-Snapshots für SAP HANA](https://docs.aws.amazon.com/sap/latest/sap-hana/ebs-sap-hana.html).
+ Selbstverwaltete Datenbanken wie MySQL, PostgreSQL oder InterSystems IRIS mit SSM-Dokumentvorlagen
**Topics**
+ [Anforderungen an die Verwendung von Vor- und Nach-Skripten](#app-consistent-prereqs)
+ [Erste Schritte mit anwendungskonsistenten Snapshots](#app-consistent-get-started)
+ [Überlegungen zu VSS-Backups mit Amazon Data Lifecycle Manager](#app-consistent-vss)
+ [Geteilte Verantwortlichkeit für anwendungskonsistente Snapshots](#shared-responsibility)
## Anforderungen an die Verwendung von Vor- und Nach-Skripten
In der folgenden Tabelle werden die Anforderungen an die Verwendung von Vor- und Nach-Skripten mit Amazon Data Lifecycle Manager beschrieben.
| | Anwendungskonsistente Snapshots | |
| --- |--- |--- |
| Anforderung | VSS-Backup | Benutzerdefiniertes SSM-Dokument | Andere Anwendungsfälle |
| --- |--- |--- |--- |
| SSM Agent ist auf Ziel-Instances installiert und wird dort ausgeführt | ✓ | ✓ | ✓ |
| Die VSS-Systemanforderungen auf den Zielinstanzen wurden erfüllt | ✓ | | |
| VSS-fähiges Instanzprofil, das den Zielinstanzen zugeordnet ist | ✓ | | |
| Auf Zielinstanzen installierte VSS-Komponenten | ✓ | | |
| Bereiten Sie das SSM-Dokument mit Pre- und Post-Skriptbefehlen vor | | ✓ | ✓ |
| Vorbereiten der Amazon Data Lifecycle Manager Manager-IAM-Rolle, Ausführen von Vor- und Nachskripten | ✓ | ✓ | ✓ |
| Erstellen Sie eine Snapshot-Richtlinie, die auf Instances abzielt und für Vor- und Nachskripte konfiguriert ist | ✓ | ✓ | ✓ |
## Erste Schritte mit anwendungskonsistenten Snapshots
In diesem Abschnitt werden die Schritte erläutert, die Sie ausführen müssen, um anwendungskonsistente Snapshots mit Amazon Data Lifecycle Manager zu automatisieren.
### Schritt 1: Vorbereiten der Ziel-Instances
Sie müssen die Ziel-Instances für anwendungskonsistente Snapshots mit Amazon Data Lifecycle Manager vorbereiten. Führen Sie je nach Anwendungsfall einen der folgenden Schritte durch.
------
#### [ Prepare for VSS Backups ]
**Zur Vorbereitung Ihrer Ziel-Instances für VSS-Backups**
1. Installieren Sie den SSM-Agent auf Ihren Ziel-Instances, falls noch nicht geschehen. Wenn der SSM-Agent bereits auf Ihren Ziel-Instances installiert ist, überspringen Sie diesen Schritt.
Weitere Informationen finden Sie unter [Arbeiten mit SSM Agent auf EC2-Instances für Windows Server](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-windows.html).
1. Stellen Sie sicher, dass der SSM-Agent ausgeführt wird. Weitere Informationen finden Sie unter [Prüfen des Status des SSM-Agents und Starten des Agenten](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-status-and-restart.html).
1. Richten Sie Systems Manager für Amazon-EC2-Instances ein. Weitere Informationen finden Sie unter [Einrichtung von Systems Manager für Amazon-EC2-Instances](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-setting-up-ec2.html) im *AWS Systems Manager -Benutzerhandbuch*.
1. [ Stellen Sie sicher, dass die Systemanforderungen für VSS-Backups erfüllt sind](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/application-consistent-snapshots-prereqs.html).
1. [ Hängen Sie ein VSS-fähiges Instance-Profil an die Ziel-Instances an](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/vss-iam-reqs.html).
1. [ Installieren Sie die VSS-Komponenten](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/application-consistent-snapshots-getting-started.html).
------
#### [ Prepare for SAP HANA backups ]
**Zur Vorbereitung Ihrer Ziel-Instances für SAP–HANA-Backups**
1. Bereiten Sie die SAP-HANA-Umgebung auf Ihre Ziel-Instances vor.
1. Richten Sie Ihre Instance mit SAP HANA ein. Wenn Sie noch nicht über eine bestehende SAP-HANA-Umgebung verfügen, finden Sie unter [Einrichtung einer SAP-HANA-Umgebung auf AWS](https://docs.aws.amazon.com/sap/latest/sap-hana/std-sap-hana-environment-setup.html) weitere Informationen.
1. Melden Sie sich als geeigneter Administratorbenutzer bei der SystemDB an.
1. Erstellen Sie einen Datenbank-Backup-Benutzer, der mit Amazon Data Lifecycle Manager verwendet werden soll.
```
CREATE USER username PASSWORD password NO FORCE_FIRST_PASSWORD_CHANGE;
```
Mit dem folgenden Befehl wird beispielsweise ein Benutzer mit dem Namen `dlm_user` und dem Passwort `password` erstellt.
```
CREATE USER dlm_user PASSWORD password NO FORCE_FIRST_PASSWORD_CHANGE;
```
1. Weisen Sie die `BACKUP OPERATOR`-Rolle dem Datenbank-Backup-Benutzer zu, den Sie im vorherigen Schritt erstellt haben.
```
GRANT BACKUP OPERATOR TO username
```
Mit dem folgenden Befehl wird die Rolle beispielsweise einem Benutzer mit dem Namen `dlm_user` zugewiesen.
```
GRANT BACKUP OPERATOR TO dlm_user
```
1. Melden Sie sich als Administrator beim Betriebssystem an, beispielsweise `sidadm`.
1. Erstellen Sie einen `hdbuserstore`-Eintrag zum Speichern von Verbindungsinformationen, sodass das SAP-HANA-SSM-Dokument eine Verbindung zu SAP HANA herstellen kann, ohne dass Benutzer die Informationen eingeben müssen.
```
hdbuserstore set DLM_HANADB_SNAPSHOT_USER localhost:3hana_instance_number13 username password
```
Beispiel:
```
hdbuserstore set DLM_HANADB_SNAPSHOT_USER localhost:30013 dlm_user password
```
1. Testen Sie die Verbindung.
```
hdbsql -U DLM_HANADB_SNAPSHOT_USER "select * from dummy"
```
1. Installieren Sie den SSM-Agent auf Ihren Ziel-Instances, falls noch nicht geschehen. Wenn der SSM-Agent bereits auf Ihren Ziel-Instances installiert ist, überspringen Sie diesen Schritt.
Weitere Informationen finden Sie unter [Manuelles Installieren des SSM-Agenten auf EC2-Instances](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-linux.html) für Linux.
1. Stellen Sie sicher, dass der SSM-Agent ausgeführt wird. Weitere Informationen finden Sie unter [Prüfen des Status des SSM-Agents und Starten des Agenten](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-status-and-restart.html).
1. Richten Sie Systems Manager für Amazon-EC2-Instances ein. Weitere Informationen finden Sie unter [Einrichtung von Systems Manager für Amazon-EC2-Instances](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-setting-up-ec2.html) im *AWS Systems Manager -Benutzerhandbuch*.
------
#### [ Prepare for custom SSM documents ]
**Vorbereitung benutzerdefinierter SSM-Dokumente für Ihre Ziel-Instances**
1. Installieren Sie den SSM-Agent auf Ihren Ziel-Instances, falls noch nicht geschehen. Wenn der SSM-Agent bereits auf Ihren Ziel-Instances installiert ist, überspringen Sie diesen Schritt.
+ (Linux-Instances) [Manuelles Installieren des SSM-Agenten auf EC2-Instances](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-linux.html) für Linux
+ (Windows-Instanzen) [Arbeiten mit SSM Agent auf EC2-Instances](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-windows.html) für Windows Server
1. Stellen Sie sicher, dass der SSM-Agent ausgeführt wird. Weitere Informationen finden Sie unter [Prüfen des Status des SSM-Agents und Starten des Agenten](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-status-and-restart.html).
1. Richten Sie Systems Manager für Amazon-EC2-Instances ein. Weitere Informationen finden Sie unter [Einrichtung von Systems Manager für Amazon-EC2-Instances](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-setting-up-ec2.html) im *AWS Systems Manager -Benutzerhandbuch*.
------
### Schritt 2: Vorbereiten des SSM-Dokuments
**Anmerkung**
Dieser Schritt ist nur für benutzerdefinierte SSM-Dokumente erforderlich. Für VSS-Backup oder SAP HANA ist er nicht erforderlich. Für VSS-Backups und SAP HANA verwendet Amazon Data Lifecycle Manager das AWS verwaltete SSM-Dokument.
Wenn Sie anwendungskonsistente Snapshots für eine selbstverwaltete Datenbank wie MySQL, PostgreSQL oder InterSystems IRIS automatisieren, müssen Sie ein SSM-Befehlsdokument erstellen, das ein Pre-Skript zum Einfrieren und Leeren enthält, I/O bevor die Snapshot-Erstellung initiiert wird, und ein Post-Skript zum Auftauen nach der Snapshot-Erstellung. I/O
Wenn Ihre MySQL-, PostgreSQL- oder InterSystems IRIS-Datenbank Standardkonfigurationen verwendet, können Sie mithilfe des folgenden SSM-Beispieldokuments ein SSM-Befehlsdokument erstellen. Wenn Ihre MySQL-, PostgreSQL- oder InterSystems IRIS-Datenbank eine nicht standardmäßige Konfiguration verwendet, können Sie den folgenden Beispielinhalt als Ausgangspunkt für Ihr SSM-Befehlsdokument verwenden und es dann an Ihre Anforderungen anpassen. Wenn Sie ein SSM-Dokument von Grund auf neu erstellen möchten, können Sie alternativ die leere SSM-Dokumentvorlage unten verwenden und Ihre Vor- und Nach-Befehle in den entsprechenden Dokumentabschnitten hinzufügen.
**Beachten Sie Folgendes:**
Sie müssen sicherstellen, dass das SSM-Dokument die richtigen und erforderlichen Aktionen für Ihre Datenbankkonfiguration ausführt.
Snapshots sind nur dann garantiert anwendungskonsistent, wenn die Vor- und Nach-Skripte in Ihrem SSM-Dokument die I/O erfolgreich einfrieren, leeren und wieder auftauen können.
Das SSM-Dokument muss die erforderlichen Felder für `allowedValues` enthalten, einschließlich `pre-script`, `post-script` und `dry-run`. Amazon Data Lifecycle Manager führt Befehle auf Ihrer Instance basierend auf den Inhalten dieser Abschnitte aus. Wenn Ihr SSM-Dokument diese Abschnitte nicht enthält, behandelt Amazon Data Lifecycle Manager dies als fehlgeschlagene Ausführung.
------
#### [ MySQL sample document content ]
```
###===============================================================================###
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# Permission is hereby granted, free of charge, to any person obtaining a copy of this
# software and associated documentation files (the "Software"), to deal in the Software
# without restriction, including without limitation the rights to use, copy, modify,
# merge, publish, distribute, sublicense, and/or sell copies of the Software, and to
# permit persons to whom the Software is furnished to do so.
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED,
# INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
# PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
# HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
# OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
# SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
###===============================================================================###
schemaVersion: '2.2'
description: Amazon Data Lifecycle Manager Pre/Post script for MySQL databases
parameters:
executionId:
type: String
default: None
description: (Required) Specifies the unique identifier associated with a pre and/or post execution
allowedPattern: ^(None|[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12})$
command:
# Data Lifecycle Manager will trigger the pre-script and post-script actions during policy execution.
# 'dry-run' option is intended for validating the document execution without triggering any commands
# on the instance. The following allowedValues will allow Data Lifecycle Manager to successfully
# trigger pre and post script actions.
type: String
default: 'dry-run'
description: (Required) Specifies whether pre-script and/or post-script should be executed.
allowedValues:
- pre-script
- post-script
- dry-run
mainSteps:
- action: aws:runShellScript
description: Run MySQL Database freeze/thaw commands
name: run_pre_post_scripts
precondition:
StringEquals:
- platformType
- Linux
inputs:
runCommand:
- |
#!/bin/bash
###===============================================================================###
### Error Codes
###===============================================================================###
# The following Error codes will inform Data Lifecycle Manager of the type of error
# and help guide handling of the error.
# The Error code will also be emitted via AWS Eventbridge events in the 'cause' field.
# 1 Pre-script failed during execution - 201
# 2 Post-script failed during execution - 202
# 3 Auto thaw occurred before post-script was initiated - 203
# 4 Pre-script initiated while post-script was expected - 204
# 5 Post-script initiated while pre-script was expected - 205
# 6 Application not ready for pre or post-script initiation - 206
###=================================================================###
### Global variables
###=================================================================###
START=$(date +%s)
# For testing this script locally, replace the below with OPERATION=$1.
OPERATION={{ command }}
FS_ALREADY_FROZEN_ERROR='freeze failed: Device or resource busy'
FS_ALREADY_THAWED_ERROR='unfreeze failed: Invalid argument'
FS_BUSY_ERROR='mount point is busy'
# Auto thaw is a fail safe mechanism to automatically unfreeze the application after the
# duration specified in the global variable below. Choose the duration based on your
# database application's tolerance to freeze.
export AUTO_THAW_DURATION_SECS="60"
# Add all pre-script actions to be performed within the function below
execute_pre_script() {
echo "INFO: Start execution of pre-script"
# Check if filesystem is already frozen. No error code indicates that filesystem
# is not currently frozen and that the pre-script can proceed with freezing the filesystem.
check_fs_freeze
# Execute the DB commands to flush the DB in preparation for snapshot
snap_db
# Freeze the filesystem. No error code indicates that filesystem was succefully frozen
freeze_fs
echo "INFO: Schedule Auto Thaw to execute in ${AUTO_THAW_DURATION_SECS} seconds."
$(nohup bash -c execute_schedule_auto_thaw >/dev/null 2>&1 &)
}
# Add all post-script actions to be performed within the function below
execute_post_script() {
echo "INFO: Start execution of post-script"
# Unfreeze the filesystem. No error code indicates that filesystem was successfully unfrozen.
unfreeze_fs
thaw_db
}
# Execute Auto Thaw to automatically unfreeze the application after the duration configured
# in the AUTO_THAW_DURATION_SECS global variable.
execute_schedule_auto_thaw() {
sleep ${AUTO_THAW_DURATION_SECS}
execute_post_script
}
# Disable Auto Thaw if it is still enabled
execute_disable_auto_thaw() {
echo "INFO: Attempting to disable auto thaw if enabled"
auto_thaw_pgid=$(pgrep -f execute_schedule_auto_thaw | xargs -i ps -hp {} -o pgid)
if [ -n "${auto_thaw_pgid}" ]; then
echo "INFO: execute_schedule_auto_thaw process found with pgid ${auto_thaw_pgid}"
sudo pkill -g ${auto_thaw_pgid}
rc=$?
if [ ${rc} != 0 ]; then
echo "ERROR: Unable to kill execute_schedule_auto_thaw process. retval=${rc}"
else
echo "INFO: Auto Thaw has been disabled"
fi
fi
}
# Iterate over all the mountpoints and check if filesystem is already in freeze state.
# Return error code 204 if any of the mount points are already frozen.
check_fs_freeze() {
for target in $(lsblk -nlo MOUNTPOINTS)
do
# Freeze of the root and boot filesystems is dangerous and pre-script does not freeze these filesystems.
# Hence, we will skip the root and boot mountpoints while checking if filesystem is in freeze state.
if [ $target == '/' ]; then continue; fi
if [[ "$target" == *"/boot"* ]]; then continue; fi
error_message=$(sudo mount -o remount,noatime $target 2>&1)
# Remount will be a no-op without a error message if the filesystem is unfrozen.
# However, if filesystem is already frozen, remount will fail with busy error message.
if [ $? -ne 0 ];then
# If the filesystem is already in frozen, return error code 204
if [[ "$error_message" == *"$FS_BUSY_ERROR"* ]];then
echo "ERROR: Filesystem ${target} already frozen. Return Error Code: 204"
exit 204
fi
# If the check filesystem freeze failed due to any reason other than the filesystem already frozen, return 201
echo "ERROR: Failed to check_fs_freeze on mountpoint $target due to error - $errormessage"
exit 201
fi
done
}
# Iterate over all the mountpoints and freeze the filesystem.
freeze_fs() {
for target in $(lsblk -nlo MOUNTPOINTS)
do
# Freeze of the root and boot filesystems is dangerous. Hence, skip filesystem freeze
# operations for root and boot mountpoints.
if [ $target == '/' ]; then continue; fi
if [[ "$target" == *"/boot"* ]]; then continue; fi
echo "INFO: Freezing $target"
error_message=$(sudo fsfreeze -f $target 2>&1)
if [ $? -ne 0 ];then
# If the filesystem is already in frozen, return error code 204
if [[ "$error_message" == *"$FS_ALREADY_FROZEN_ERROR"* ]]; then
echo "ERROR: Filesystem ${target} already frozen. Return Error Code: 204"
sudo mysql -e 'UNLOCK TABLES;'
exit 204
fi
# If the filesystem freeze failed due to any reason other than the filesystem already frozen, return 201
echo "ERROR: Failed to freeze mountpoint $targetdue due to error - $errormessage"
thaw_db
exit 201
fi
echo "INFO: Freezing complete on $target"
done
}
# Iterate over all the mountpoints and unfreeze the filesystem.
unfreeze_fs() {
for target in $(lsblk -nlo MOUNTPOINTS)
do
# Freeze of the root and boot filesystems is dangerous and pre-script does not freeze these filesystems.
# Hence, will skip the root and boot mountpoints during unfreeze as well.
if [ $target == '/' ]; then continue; fi
if [[ "$target" == *"/boot"* ]]; then continue; fi
echo "INFO: Thawing $target"
error_message=$(sudo fsfreeze -u $target 2>&1)
# Check if filesystem is already unfrozen (thawed). Return error code 204 if filesystem is already unfrozen.
if [ $? -ne 0 ]; then
if [[ "$error_message" == *"$FS_ALREADY_THAWED_ERROR"* ]]; then
echo "ERROR: Filesystem ${target} is already in thaw state. Return Error Code: 205"
exit 205
fi
# If the filesystem unfreeze failed due to any reason other than the filesystem already unfrozen, return 202
echo "ERROR: Failed to unfreeze mountpoint $targetdue due to error - $errormessage"
exit 202
fi
echo "INFO: Thaw complete on $target"
done
}
snap_db() {
# Run the flush command only when MySQL DB service is up and running
sudo systemctl is-active --quiet mysqld.service
if [ $? -eq 0 ]; then
echo "INFO: Execute MySQL Flush and Lock command."
sudo mysql -e 'FLUSH TABLES WITH READ LOCK;'
# If the MySQL Flush and Lock command did not succeed, return error code 201 to indicate pre-script failure
if [ $? -ne 0 ]; then
echo "ERROR: MySQL FLUSH TABLES WITH READ LOCK command failed."
exit 201
fi
sync
else
echo "INFO: MySQL service is inactive. Skipping execution of MySQL Flush and Lock command."
fi
}
thaw_db() {
# Run the unlock command only when MySQL DB service is up and running
sudo systemctl is-active --quiet mysqld.service
if [ $? -eq 0 ]; then
echo "INFO: Execute MySQL Unlock"
sudo mysql -e 'UNLOCK TABLES;'
else
echo "INFO: MySQL service is inactive. Skipping execution of MySQL Unlock command."
fi
}
export -f execute_schedule_auto_thaw
export -f execute_post_script
export -f unfreeze_fs
export -f thaw_db
# Debug logging for parameters passed to the SSM document
echo "INFO: ${OPERATION} starting at $(date) with executionId: ${EXECUTION_ID}"
# Based on the command parameter value execute the function that supports
# pre-script/post-script operation
case ${OPERATION} in
pre-script)
execute_pre_script
;;
post-script)
execute_post_script
execute_disable_auto_thaw
;;
dry-run)
echo "INFO: dry-run option invoked - taking no action"
;;
*)
echo "ERROR: Invalid command parameter passed. Please use either pre-script, post-script, dry-run."
exit 1 # return failure
;;
esac
END=$(date +%s)
# Debug Log for profiling the script time
echo "INFO: ${OPERATION} completed at $(date). Total runtime: $((${END} - ${START})) seconds."
```
------
#### [ PostgreSQL sample document content ]
```
###===============================================================================###
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# Permission is hereby granted, free of charge, to any person obtaining a copy of this
# software and associated documentation files (the "Software"), to deal in the Software
# without restriction, including without limitation the rights to use, copy, modify,
# merge, publish, distribute, sublicense, and/or sell copies of the Software, and to
# permit persons to whom the Software is furnished to do so.
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED,
# INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
# PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
# HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
# OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
# SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
###===============================================================================###
schemaVersion: '2.2'
description: Amazon Data Lifecycle Manager Pre/Post script for PostgreSQL databases
parameters:
executionId:
type: String
default: None
description: (Required) Specifies the unique identifier associated with a pre and/or post execution
allowedPattern: ^(None|[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12})$
command:
# Data Lifecycle Manager will trigger the pre-script and post-script actions during policy execution.
# 'dry-run' option is intended for validating the document execution without triggering any commands
# on the instance. The following allowedValues will allow Data Lifecycle Manager to successfully
# trigger pre and post script actions.
type: String
default: 'dry-run'
description: (Required) Specifies whether pre-script and/or post-script should be executed.
allowedValues:
- pre-script
- post-script
- dry-run
mainSteps:
- action: aws:runShellScript
description: Run PostgreSQL Database freeze/thaw commands
name: run_pre_post_scripts
precondition:
StringEquals:
- platformType
- Linux
inputs:
runCommand:
- |
#!/bin/bash
###===============================================================================###
### Error Codes
###===============================================================================###
# The following Error codes will inform Data Lifecycle Manager of the type of error
# and help guide handling of the error.
# The Error code will also be emitted via AWS Eventbridge events in the 'cause' field.
# 1 Pre-script failed during execution - 201
# 2 Post-script failed during execution - 202
# 3 Auto thaw occurred before post-script was initiated - 203
# 4 Pre-script initiated while post-script was expected - 204
# 5 Post-script initiated while pre-script was expected - 205
# 6 Application not ready for pre or post-script initiation - 206
###===============================================================================###
### Global variables
###===============================================================================###
START=$(date +%s)
OPERATION={{ command }}
FS_ALREADY_FROZEN_ERROR='freeze failed: Device or resource busy'
FS_ALREADY_THAWED_ERROR='unfreeze failed: Invalid argument'
FS_BUSY_ERROR='mount point is busy'
# Auto thaw is a fail safe mechanism to automatically unfreeze the application after the
# duration specified in the global variable below. Choose the duration based on your
# database application's tolerance to freeze.
export AUTO_THAW_DURATION_SECS="60"
# Add all pre-script actions to be performed within the function below
execute_pre_script() {
echo "INFO: Start execution of pre-script"
# Check if filesystem is already frozen. No error code indicates that filesystem
# is not currently frozen and that the pre-script can proceed with freezing the filesystem.
check_fs_freeze
# Execute the DB commands to flush the DB in preparation for snapshot
snap_db
# Freeze the filesystem. No error code indicates that filesystem was succefully frozen
freeze_fs
echo "INFO: Schedule Auto Thaw to execute in ${AUTO_THAW_DURATION_SECS} seconds."
$(nohup bash -c execute_schedule_auto_thaw >/dev/null 2>&1 &)
}
# Add all post-script actions to be performed within the function below
execute_post_script() {
echo "INFO: Start execution of post-script"
# Unfreeze the filesystem. No error code indicates that filesystem was successfully unfrozen
unfreeze_fs
}
# Execute Auto Thaw to automatically unfreeze the application after the duration configured
# in the AUTO_THAW_DURATION_SECS global variable.
execute_schedule_auto_thaw() {
sleep ${AUTO_THAW_DURATION_SECS}
execute_post_script
}
# Disable Auto Thaw if it is still enabled
execute_disable_auto_thaw() {
echo "INFO: Attempting to disable auto thaw if enabled"
auto_thaw_pgid=$(pgrep -f execute_schedule_auto_thaw | xargs -i ps -hp {} -o pgid)
if [ -n "${auto_thaw_pgid}" ]; then
echo "INFO: execute_schedule_auto_thaw process found with pgid ${auto_thaw_pgid}"
sudo pkill -g ${auto_thaw_pgid}
rc=$?
if [ ${rc} != 0 ]; then
echo "ERROR: Unable to kill execute_schedule_auto_thaw process. retval=${rc}"
else
echo "INFO: Auto Thaw has been disabled"
fi
fi
}
# Iterate over all the mountpoints and check if filesystem is already in freeze state.
# Return error code 204 if any of the mount points are already frozen.
check_fs_freeze() {
for target in $(lsblk -nlo MOUNTPOINTS)
do
# Freeze of the root and boot filesystems is dangerous and pre-script does not freeze these filesystems.
# Hence, we will skip the root and boot mountpoints while checking if filesystem is in freeze state.
if [ $target == '/' ]; then continue; fi
if [[ "$target" == *"/boot"* ]]; then continue; fi
error_message=$(sudo mount -o remount,noatime $target 2>&1)
# Remount will be a no-op without a error message if the filesystem is unfrozen.
# However, if filesystem is already frozen, remount will fail with busy error message.
if [ $? -ne 0 ];then
# If the filesystem is already in frozen, return error code 204
if [[ "$error_message" == *"$FS_BUSY_ERROR"* ]];then
echo "ERROR: Filesystem ${target} already frozen. Return Error Code: 204"
exit 204
fi
# If the check filesystem freeze failed due to any reason other than the filesystem already frozen, return 201
echo "ERROR: Failed to check_fs_freeze on mountpoint $target due to error - $errormessage"
exit 201
fi
done
}
# Iterate over all the mountpoints and freeze the filesystem.
freeze_fs() {
for target in $(lsblk -nlo MOUNTPOINTS)
do
# Freeze of the root and boot filesystems is dangerous. Hence, skip filesystem freeze
# operations for root and boot mountpoints.
if [ $target == '/' ]; then continue; fi
if [[ "$target" == *"/boot"* ]]; then continue; fi
echo "INFO: Freezing $target"
error_message=$(sudo fsfreeze -f $target 2>&1)
if [ $? -ne 0 ];then
# If the filesystem is already in frozen, return error code 204
if [[ "$error_message" == *"$FS_ALREADY_FROZEN_ERROR"* ]]; then
echo "ERROR: Filesystem ${target} already frozen. Return Error Code: 204"
exit 204
fi
# If the filesystem freeze failed due to any reason other than the filesystem already frozen, return 201
echo "ERROR: Failed to freeze mountpoint $targetdue due to error - $errormessage"
exit 201
fi
echo "INFO: Freezing complete on $target"
done
}
# Iterate over all the mountpoints and unfreeze the filesystem.
unfreeze_fs() {
for target in $(lsblk -nlo MOUNTPOINTS)
do
# Freeze of the root and boot filesystems is dangerous and pre-script does not freeze these filesystems.
# Hence, will skip the root and boot mountpoints during unfreeze as well.
if [ $target == '/' ]; then continue; fi
if [[ "$target" == *"/boot"* ]]; then continue; fi
echo "INFO: Thawing $target"
error_message=$(sudo fsfreeze -u $target 2>&1)
# Check if filesystem is already unfrozen (thawed). Return error code 204 if filesystem is already unfrozen.
if [ $? -ne 0 ]; then
if [[ "$error_message" == *"$FS_ALREADY_THAWED_ERROR"* ]]; then
echo "ERROR: Filesystem ${target} is already in thaw state. Return Error Code: 205"
exit 205
fi
# If the filesystem unfreeze failed due to any reason other than the filesystem already unfrozen, return 202
echo "ERROR: Failed to unfreeze mountpoint $targetdue due to error - $errormessage"
exit 202
fi
echo "INFO: Thaw complete on $target"
done
}
snap_db() {
# Run the flush command only when PostgreSQL DB service is up and running
sudo systemctl is-active --quiet postgresql
if [ $? -eq 0 ]; then
echo "INFO: Execute Postgres CHECKPOINT"
# PostgreSQL command to flush the transactions in memory to disk
sudo -u postgres psql -c 'CHECKPOINT;'
# If the PostgreSQL Command did not succeed, return error code 201 to indicate pre-script failure
if [ $? -ne 0 ]; then
echo "ERROR: Postgres CHECKPOINT command failed."
exit 201
fi
sync
else
echo "INFO: PostgreSQL service is inactive. Skipping execution of CHECKPOINT command."
fi
}
export -f execute_schedule_auto_thaw
export -f execute_post_script
export -f unfreeze_fs
# Debug logging for parameters passed to the SSM document
echo "INFO: ${OPERATION} starting at $(date) with executionId: ${EXECUTION_ID}"
# Based on the command parameter value execute the function that supports
# pre-script/post-script operation
case ${OPERATION} in
pre-script)
execute_pre_script
;;
post-script)
execute_post_script
execute_disable_auto_thaw
;;
dry-run)
echo "INFO: dry-run option invoked - taking no action"
;;
*)
echo "ERROR: Invalid command parameter passed. Please use either pre-script, post-script, dry-run."
exit 1 # return failure
;;
esac
END=$(date +%s)
# Debug Log for profiling the script time
echo "INFO: ${OPERATION} completed at $(date). Total runtime: $((${END} - ${START})) seconds."
```
------
#### [ InterSystems IRIS sample document content ]
```
###===============================================================================###
# MIT License
#
# Copyright (c) 2024 InterSystems
#
# Permission is hereby granted, free of charge, to any person obtaining a copy
# of this software and associated documentation files (the "Software"), to deal
# in the Software without restriction, including without limitation the rights
# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
# copies of the Software, and to permit persons to whom the Software is
# furnished to do so, subject to the following conditions:
#
# The above copyright notice and this permission notice shall be included in all
# copies or substantial portions of the Software.
#
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
# SOFTWARE.
###===============================================================================###
schemaVersion: '2.2'
description: SSM Document Template for Amazon Data Lifecycle Manager Pre/Post script feature for InterSystems IRIS.
parameters:
executionId:
type: String
default: None
description: Specifies the unique identifier associated with a pre and/or post execution
allowedPattern: ^(None|[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12})$
command:
type: String
# Data Lifecycle Manager will trigger the pre-script and post-script actions. You can also use this SSM document with 'dry-run' for manual testing purposes.
default: 'dry-run'
description: (Required) Specifies whether pre-script and/or post-script should be executed.
#The following allowedValues will allow Data Lifecycle Manager to successfully trigger pre and post script actions.
allowedValues:
- pre-script
- post-script
- dry-run
mainSteps:
- action: aws:runShellScript
description: Run InterSystems IRIS Database freeze/thaw commands
name: run_pre_post_scripts
precondition:
StringEquals:
- platformType
- Linux
inputs:
runCommand:
- |
#!/bin/bash
###===============================================================================###
### Global variables
###===============================================================================###
DOCKER_NAME=iris
LOGDIR=./
EXIT_CODE=0
OPERATION={{ command }}
START=$(date +%s)
# Check if Docker is installed
# By default if Docker is present, script assumes that InterSystems IRIS is running in Docker
# Leave only the else block DOCKER_EXEC line, if you run InterSystems IRIS non-containerised (and Docker is present).
# Script assumes irissys user has OS auth enabled, change the OS user or supply login/password depending on your configuration.
if command -v docker &> /dev/null
then
DOCKER_EXEC="docker exec $DOCKER_NAME"
else
DOCKER_EXEC="sudo -i -u irissys"
fi
# Add all pre-script actions to be performed within the function below
execute_pre_script() {
echo "INFO: Start execution of pre-script"
# find all iris running instances
iris_instances=$($DOCKER_EXEC iris qall 2>/dev/null | tail -n +3 | grep '^up' | cut -c5- | awk '{print $1}')
echo "`date`: Running iris instances $iris_instances"
# Only for running instances
for INST in $iris_instances; do
echo "`date`: Attempting to freeze $INST"
# Detailed instances specific log
LOGFILE=$LOGDIR/$INST-pre_post.log
#check Freeze status before starting
$DOCKER_EXEC irissession $INST -U '%SYS' "##Class(Backup.General).IsWDSuspendedExt()"
freeze_status=$?
if [ $freeze_status -eq 5 ]; then
echo "`date`: ERROR: $INST IS already FROZEN"
EXIT_CODE=204
else
echo "`date`: $INST is not frozen"
# Freeze
# Docs: https://docs.intersystems.com/irislatest/csp/documatic/%25CSP.Documatic.cls?LIBRARY=%25SYS&CLASSNAME=Backup.General#ExternalFreeze
$DOCKER_EXEC irissession $INST -U '%SYS' "##Class(Backup.General).ExternalFreeze(\"$LOGFILE\",,,,,,600,,,300)"
status=$?
case $status in
5) echo "`date`: $INST IS FROZEN"
;;
3) echo "`date`: $INST FREEZE FAILED"
EXIT_CODE=201
;;
*) echo "`date`: ERROR: Unknown status code: $status"
EXIT_CODE=201
;;
esac
echo "`date`: Completed freeze of $INST"
fi
done
echo "`date`: Pre freeze script finished"
}
# Add all post-script actions to be performed within the function below
execute_post_script() {
echo "INFO: Start execution of post-script"
# find all iris running instances
iris_instances=$($DOCKER_EXEC iris qall 2>/dev/null | tail -n +3 | grep '^up' | cut -c5- | awk '{print $1}')
echo "`date`: Running iris instances $iris_instances"
# Only for running instances
for INST in $iris_instances; do
echo "`date`: Attempting to thaw $INST"
# Detailed instances specific log
LOGFILE=$LOGDIR/$INST-pre_post.log
#check Freeze status befor starting
$DOCKER_EXEC irissession $INST -U '%SYS' "##Class(Backup.General).IsWDSuspendedExt()"
freeze_status=$?
if [ $freeze_status -eq 5 ]; then
echo "`date`: $INST is in frozen state"
# Thaw
# Docs: https://docs.intersystems.com/irislatest/csp/documatic/%25CSP.Documatic.cls?LIBRARY=%25SYS&CLASSNAME=Backup.General#ExternalFreeze
$DOCKER_EXEC irissession $INST -U%SYS "##Class(Backup.General).ExternalThaw(\"$LOGFILE\")"
status=$?
case $status in
5) echo "`date`: $INST IS THAWED"
$DOCKER_EXEC irissession $INST -U%SYS "##Class(Backup.General).ExternalSetHistory(\"$LOGFILE\")"
;;
3) echo "`date`: $INST THAW FAILED"
EXIT_CODE=202
;;
*) echo "`date`: ERROR: Unknown status code: $status"
EXIT_CODE=202
;;
esac
echo "`date`: Completed thaw of $INST"
else
echo "`date`: ERROR: $INST IS already THAWED"
EXIT_CODE=205
fi
done
echo "`date`: Post thaw script finished"
}
# Debug logging for parameters passed to the SSM document
echo "INFO: ${OPERATION} starting at $(date) with executionId: ${EXECUTION_ID}"
# Based on the command parameter value execute the function that supports
# pre-script/post-script operation
case ${OPERATION} in
pre-script)
execute_pre_script
;;
post-script)
execute_post_script
;;
dry-run)
echo "INFO: dry-run option invoked - taking no action"
;;
*)
echo "ERROR: Invalid command parameter passed. Please use either pre-script, post-script, dry-run."
# return failure
EXIT_CODE=1
;;
esac
END=$(date +%s)
# Debug Log for profiling the script time
echo "INFO: ${OPERATION} completed at $(date). Total runtime: $((${END} - ${START})) seconds."
exit $EXIT_CODE
```
[Weitere Informationen finden Sie im Repository. GitHub ](https://github.com/intersystems-community/aws/blob/master/README.md)
------
#### [ Empty document template ]
```
###===============================================================================###
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# Permission is hereby granted, free of charge, to any person obtaining a copy of this
# software and associated documentation files (the "Software"), to deal in the Software
# without restriction, including without limitation the rights to use, copy, modify,
# merge, publish, distribute, sublicense, and/or sell copies of the Software, and to
# permit persons to whom the Software is furnished to do so.
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED,
# INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
# PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
# HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
# OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
# SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
###===============================================================================###
schemaVersion: '2.2'
description: SSM Document Template for Amazon Data Lifecycle Manager Pre/Post script feature
parameters:
executionId:
type: String
default: None
description: (Required) Specifies the unique identifier associated with a pre and/or post execution
allowedPattern: ^(None|[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12})$
command:
# Data Lifecycle Manager will trigger the pre-script and post-script actions during policy execution.
# 'dry-run' option is intended for validating the document execution without triggering any commands
# on the instance. The following allowedValues will allow Data Lifecycle Manager to successfully
# trigger pre and post script actions.
type: String
default: 'dry-run'
description: (Required) Specifies whether pre-script and/or post-script should be executed.
allowedValues:
- pre-script
- post-script
- dry-run
mainSteps:
- action: aws:runShellScript
description: Run Database freeze/thaw commands
name: run_pre_post_scripts
precondition:
StringEquals:
- platformType
- Linux
inputs:
runCommand:
- |
#!/bin/bash
###===============================================================================###
### Error Codes
###===============================================================================###
# The following Error codes will inform Data Lifecycle Manager of the type of error
# and help guide handling of the error.
# The Error code will also be emitted via AWS Eventbridge events in the 'cause' field.
# 1 Pre-script failed during execution - 201
# 2 Post-script failed during execution - 202
# 3 Auto thaw occurred before post-script was initiated - 203
# 4 Pre-script initiated while post-script was expected - 204
# 5 Post-script initiated while pre-script was expected - 205
# 6 Application not ready for pre or post-script initiation - 206
###===============================================================================###
### Global variables
###===============================================================================###
START=$(date +%s)
# For testing this script locally, replace the below with OPERATION=$1.
OPERATION={{ command }}
# Add all pre-script actions to be performed within the function below
execute_pre_script() {
echo "INFO: Start execution of pre-script"
}
# Add all post-script actions to be performed within the function below
execute_post_script() {
echo "INFO: Start execution of post-script"
}
# Debug logging for parameters passed to the SSM document
echo "INFO: ${OPERATION} starting at $(date) with executionId: ${EXECUTION_ID}"
# Based on the command parameter value execute the function that supports
# pre-script/post-script operation
case ${OPERATION} in
pre-script)
execute_pre_script
;;
post-script)
execute_post_script
;;
dry-run)
echo "INFO: dry-run option invoked - taking no action"
;;
*)
echo "ERROR: Invalid command parameter passed. Please use either pre-script, post-script, dry-run."
exit 1 # return failure
;;
esac
END=$(date +%s)
# Debug Log for profiling the script time
echo "INFO: ${OPERATION} completed at $(date). Total runtime: $((${END} - ${START})) seconds."
```
------
Sobald Sie über den Inhalt Ihres SSM-Dokuments verfügen, verwenden Sie eines der folgenden Verfahren, um das benutzerdefinierte SSM-Dokument zu erstellen.
------
#### [ Console ]
**Erstellen eines SSM-Befehlsdokuments**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com//systems-manager/](https://console.aws.amazon.com//systems-manager/).
1. Wählen Sie im Navigationsbereich **Dokumente** und dann **Dokument erstellen**, **Befehl oder Sitzung** aus.
1. Geben Sie unter **Name** einen aussagekräftigen Namen für das Dokument ein.
1. Wählen Sie als **Zieltyp** die Option**/**ausAWS::EC2::Instance.
1. Wählen Sie als **Dokumenttyp** **Befehl**.
1. Wählen Sie im Feld **Inhalt** die Option **YAML** aus und fügen Sie dann den Inhalt des Dokuments ein.
1. Fügen Sie im Abschnitt **Dokument-Tags** ein Tag mit einem Tag-Schlüssel von `DLMScriptsAccess` und einem Tag-Wert von `true` hinzu.
**Wichtig**
Das `DLMScriptsAccess:true` Tag ist für die in *Schritt 3: Vorbereiten der Amazon Data Lifecycle AWS Manager-IAM-Rolle verwendete **AWSDataLifecycleManagerSSMFullAccess** Manager-Richtlinie* erforderlich. Die Richtlinie verwendet den `aws:ResourceTag`-Bedingungsschlüssel, um den Zugriff auf SSM-Dokumente mit diesem Tag einzuschränken.
1. Wählen Sie **Create document** (Dokument erstellen) aus.
------
#### [ AWS CLI ]
**Erstellen eines SSM-Befehlsdokuments**
Verwenden Sie den Befehl [create-document](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-document.html). Geben Sie für `--name` einen beschreibenden Namen für das Dokument ein. Legen Sie für `--document-type` die Option `Command` fest. Geben Sie für `--content` den Pfad zur .yaml-Datei mit dem SSM-Dokumentinhalt an. Legen Sie für `--tags` die Option `"Key=DLMScriptsAccess,Value=true"` fest.
```
$ aws ssm create-document \
--content file://path/to/file/documentContent.yaml \
--name "document_name" \
--document-type "Command" \
--document-format YAML \
--tags "Key=DLMScriptsAccess,Value=true"
```
------
### Schritt 3: Vorbereiten der IAM-Rolle für Amazon Data Lifecycle Manager
**Anmerkung**
Dieser Schritt ist erforderlich, wenn:
Sie erstellen oder aktualisieren eine pre/post skriptfähige Snapshot-Richtlinie, die eine benutzerdefinierte IAM-Rolle verwendet.
Sie verwenden die Befehlszeile, um eine pre/post skriptfähige Snapshot-Richtlinie zu erstellen oder zu aktualisieren, die den Standard verwendet.
Wenn Sie die Konsole verwenden, um eine pre/post skriptfähige Snapshot-Richtlinie zu erstellen oder zu aktualisieren, die die Standardrolle für die Verwaltung von Snapshots (**AWSDataLifecycleManagerDefaultRole**) verwendet, überspringen Sie diesen Schritt. In diesem Fall hängen wir die **AWSDataLifecycleManagerSSMFullZugriffsrichtlinie** automatisch an diese Rolle an.
Sie müssen sicherstellen, dass die für die Richtlinie verwendete IAM-Rolle Amazon Data Lifecycle Manager die Erlaubnis erteilt, die SSM-Aktionen auszuführen, die für die Ausführung von Vor- und Nach-Skripten auf Instances, auf die die Richtlinie abzielt, erforderlich sind.
Amazon Data Lifecycle Manager bietet eine verwaltete Richtlinie (**AWSDataLifecycleManagerSSMFullAccess**), die die erforderlichen Berechtigungen beinhaltet. Sie können diese Richtlinie an Ihre IAM-Rolle für die Verwaltung von Snapshots anhängen, um sicherzustellen, dass sie die entsprechenden Berechtigungen beinhaltet.
**Wichtig**
Die verwaltete AWSData LifecycleManager SSMFull Access-Richtlinie verwendet den `aws:ResourceTag` Bedingungsschlüssel, um den Zugriff auf bestimmte SSM-Dokumente einzuschränken, wenn Pre- und Post-Skripte verwendet werden. Damit Amazon Data Lifecycle Manager auf die SSM-Dokumente zugreifen kann, müssen Sie sicherstellen, dass Ihre SSM-Dokumente das Tag `DLMScriptsAccess:true` enthalten.
Alternativ können Sie manuell eine benutzerdefinierte Richtlinie erstellen oder die erforderlichen Berechtigungen direkt der von Ihnen verwendeten IAM-Rolle zuweisen. Sie können dieselben Berechtigungen verwenden, die in der verwalteten AWSData LifecycleManager SSMFull Access-Richtlinie definiert sind, der `aws:ResourceTag` Bedingungsschlüssel ist jedoch optional. Wenn Sie sich dafür entscheiden, diesen Bedingungsschlüssel nicht zu verwenden, müssen Sie Ihre SSM-Dokumente nicht mit `DLMScriptsAccess:true` markieren.
Verwenden Sie eine der folgenden Methoden, um die **AWSDataLifecycleManagerSSMFullAccess-Richtlinie** zu Ihrer IAM-Rolle hinzuzufügen.
------
#### [ Console ]
**So hängen Sie die verwaltete Richtlinie an Ihre benutzerdefinierte Rolle an**
1. Öffnen Sie unter [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) die IAM-Konsole.
1. Wählen Sie im Navigationspanel **Rollen** aus.
1. Suchen Sie nach Ihrer benutzerdefinierten Rolle zur Verwaltung von Snapshots und wählen Sie sie aus.
1. Wählen Sie auf der Registerkarte **Berechtigungen** **Berechtigungen hinzufügen** und dann **Richtlinien anfügen** aus.
1. Suchen Sie nach der verwalteten **AWSDataLifecycleManagerSSMFullAccess-Richtlinie**, wählen Sie sie aus und klicken Sie dann auf **Berechtigungen hinzufügen**.
------
#### [ AWS CLI ]
**So hängen Sie die verwaltete Richtlinie an Ihre benutzerdefinierte Rolle an**
Verwenden Sie den Befehl [ attach-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-role-policy.html). Geben Sie für `---role-name` den Namen Ihrer benutzerdefinierten Rolle an. Legen Sie für `--policy-arn` die Option `arn:aws:iam::aws:policy/AWSDataLifecycleManagerSSMFullAccess` fest.
```
$ aws iam attach-role-policy \
--policy-arn arn:aws:iam::aws:policy/AWSDataLifecycleManagerSSMFullAccess \
--role-name your_role_name
```
------
### Schritt 4: Erstellen der Snapshot-Lebenszyklusrichtlinie
Um anwendungskonsistente Snapshots zu automatisieren, müssen Sie eine Snapshot-Lebenszyklusrichtlinie für Instances erstellen und Vor- und Nach-Skripte für diese Richtlinie konfigurieren.
------
#### [ Console ]
**So erstellen Sie die Snapshot-Lebenszyklusrichtlinie**
1. Öffnen Sie die Amazon-EC2-Konsole unter [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. Wählen Sie im Navigationsbereich **Elastic Block Store** und **Lifecycle Manager** aus. Wählen Sie dann **Create lifecycle policy (Lebenszyklusrichtlinie erstellen)** aus.
1. Wählen Sie auf dem Bildschirm **Richtlinientyp auswählen** die Option **EBS-Snapshot-Richtlinie** und dann **Weiter** aus.
1. Gehen Sie im Abschnitt **Zielressourcen** wie folgt vor:
1. Wählen Sie für **Ziel-Ressourcentypen** die Option `Instance`.
1. Geben Sie für **Zielressourcen-Tags** die Ressourcen-Tags an, die die zu sichernden Instances identifizieren. Nur Ressourcen mit den angegebenen Tags werden gesichert.
1. Wählen Sie für die **IAM-Rolle** entweder **AWSDataLifecycleManagerDefaultRole**(die Standardrolle für die Verwaltung von Snapshots) oder eine benutzerdefinierte Rolle, die Sie für Vor- und Nachskripte erstellt und vorbereitet haben.
1. Konfigurieren Sie die Zeitpläne und zusätzlichen Optionen nach Bedarf. Wir empfehlen Ihnen, die Snapshot-Erstellung für Zeiträume einzuplanen, die Ihrem Workload entsprechen, z. B. während Wartungsfenstern.
Für SAP HANA empfehlen wir, die schnelle Snapshot-Wiederherstellung zu aktivieren.
**Anmerkung**
Wenn Sie einen Zeitplan für VSS-Backups aktivieren, können Sie die Optionen **Ausschließen bestimmter Daten-Volumes** oder **Tags aus der Quelle kopieren** nicht aktivieren.
1. Wählen Sie im Abschnitt **Vor- und Nach-Skripte** die Option **Vor- und Nach-Skripte aktivieren** aus und gehen Sie dann je nach Workload wie folgt vor:
+ Um anwendungskonsistente Snapshots Ihrer Windows-Anwendungen zu erstellen, wählen Sie **VSS-Backup**.
+ Um anwendungskonsistente Snapshots Ihrer SAP-HANA-Workloads zu erstellen, wählen Sie **SAP HANA**.
+ **Um mithilfe eines benutzerdefinierten SSM-Dokuments anwendungskonsistente Snapshots aller anderen Datenbanken und Workloads zu erstellen, einschließlich Ihrer selbstverwalteten MySQL-, PostgreSQL- oder InterSystems IRIS-Datenbanken, wählen Sie Benutzerdefiniertes SSM-Dokument aus.**
1. Wählen Sie für **Option automatisieren** **Vor- und Nach-Skripte** aus.
1. Wählen Sie unter **SSM-Dokument** das SSM-Dokument aus, das Sie vorbereitet haben.
1. Konfigurieren Sie je nach der ausgewählten Option die folgenden zusätzlichen Optionen:
+ **Timeout für das Skript** – (*nur benutzerdefiniertes SSM-Dokument*) Der Timeout-Zeitraum, nach dem Amazon Data Lifecycle Manager die versuchte Skriptausführung als fehlgeschlagen behandelt, wenn sie nicht abgeschlossen wurde. Wenn ein Skript nicht innerhalb des Timeout-Zeitraums abgeschlossen wird, schlägt der Versuch von Amazon Data Lifecycle Manager fehl. Der Timeout-Zeitraum gilt für die Vor- und Nach-Skripte einzeln. Der Minimal- und Standardwert für den Timeout beträgt 10 Sekunden. Die maximale Timeout-Zeit beträgt 120 Sekunden.
+ **Fehlgeschlagene Skripte erneut versuchen** – Wählen Sie diese Option, um Skripte zu wiederholen, die nicht innerhalb ihres Timeouts abgeschlossen werden. Wenn das Vor-Skript fehlschlägt, wiederholt Amazon Data Lifecycle Manager den gesamten Snapshot-Erstellungsprozess, einschließlich der Ausführung der Vor- und Nach-Skripte. Wenn das Nach-Skript fehlschlägt, wiederholt Amazon Data Lifecycle Manager nur das Nach-Skript. In diesem Fall ist das Vor-Skript abgeschlossen und der Snapshot wurde möglicherweise erstellt.
+ **Standardmäßig absturzkonsistente Snapshots** – Wählen Sie diese Option, um standardmäßig absturzkonsistente Snapshots zu verwenden, falls das Vor-Skript nicht ausgeführt werden kann. Dies ist das Standardverhalten bei der Snapshot-Erstellung für Amazon Data Lifecycle Manager, wenn Vor- und Nach-Skripte nicht aktiviert sind. Wenn Sie Wiederholungen aktiviert haben, verwendet Amazon Data Lifecycle Manager standardmäßig nur dann absturzkonsistente Snapshots, wenn alle Wiederholungsversuche ausgeschöpft sind. Wenn das Vor-Skript fehlschlägt und Sie nicht standardmäßig absturzkonsistente Snapshots verwenden, erstellt Amazon Data Lifecycle Manager während dieser geplanten Ausführung keine Snapshots für die Instance.
**Anmerkung**
Wenn Sie Snapshots für SAP HANA erstellen, sollten Sie diese Option unter Umständen deaktivieren. Absturzkonsistente Snapshots von SAP-HANA-Workloads können nicht auf dieselbe Weise wiederhergestellt werden.
1. Wählen Sie **Standardrichtlinie erstellen**.
**Anmerkung**
Falls Sie den Fehler `Role with name AWSDataLifecycleManagerDefaultRole already exists` erhalten, finden Sie weitere Informationen unter [Probleme mit Amazon Data Lifecycle Manager beheben](dlm-troubleshooting.md).
------
#### [ AWS CLI ]
**So erstellen Sie die Snapshot-Lebenszyklusrichtlinie**
Verwenden Sie den Befehl und fügen Sie die Parameter in ein. [create-lifecycle-policy](https://docs.aws.amazon.com/cli/latest/reference/dlm/create-lifecycle-policy.html)`Scripts``CreateRule` Weitere Informationen finden Sie in der [https://docs.aws.amazon.com/dlm/latest/APIReference/API_Script.html](https://docs.aws.amazon.com/dlm/latest/APIReference/API_Script.html).
```
$ aws dlm create-lifecycle-policy \
--description "policy_description" \
--state ENABLED \
--execution-role-arn iam_role_arn \
--policy-details file://policyDetails.json
```
Wenn `policyDetails.json` einen der folgenden Aspekte beinhaltet, gehen Sie je nach Anwendungsfall wie folgt vor:
+ **VSS-Backup**
```
{
"PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
"ResourceTypes": [
"INSTANCE"
],
"TargetTags": [{
"Key": "tag_key",
"Value": "tag_value"
}],
"Schedules": [{
"Name": "schedule_name",
"CreateRule": {
"CronExpression": "cron_for_creation_frequency",
"Scripts": [{
"ExecutionHandler":"AWS_VSS_BACKUP",
"ExecuteOperationOnScriptFailure":true|false,
"MaximumRetryCount":retries (0-3)
}]
},
"RetainRule": {
"Count": retention_count
}
}]
}
```
+ **SAP-HANA-Backups**
```
{
"PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
"ResourceTypes": [
"INSTANCE"
],
"TargetTags": [{
"Key": "tag_key",
"Value": "tag_value"
}],
"Schedules": [{
"Name": "schedule_name",
"CreateRule": {
"CronExpression": "cron_for_creation_frequency",
"Scripts": [{
"Stages": ["PRE","POST"],
"ExecutionHandlerService":"AWS_SYSTEMS_MANAGER",
"ExecutionHandler":"AWSSystemsManagerSAP-CreateDLMSnapshotForSAPHANA",
"ExecuteOperationOnScriptFailure":true|false,
"ExecutionTimeout":timeout_in_seconds (10-120),
"MaximumRetryCount":retries (0-3)
}]
},
"RetainRule": {
"Count": retention_count
}
}]
}
```
+ **Benutzerdefiniertes SSM-Dokument**
```
{
"PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
"ResourceTypes": [
"INSTANCE"
],
"TargetTags": [{
"Key": "tag_key",
"Value": "tag_value"
}],
"Schedules": [{
"Name": "schedule_name",
"CreateRule": {
"CronExpression": "cron_for_creation_frequency",
"Scripts": [{
"Stages": ["PRE","POST"],
"ExecutionHandlerService":"AWS_SYSTEMS_MANAGER",
"ExecutionHandler":"ssm_document_name|arn",
"ExecuteOperationOnScriptFailure":true|false,
"ExecutionTimeout":timeout_in_seconds (10-120),
"MaximumRetryCount":retries (0-3)
}]
},
"RetainRule": {
"Count": retention_count
}
}]
}
```
------
## Überlegungen zu VSS-Backups mit Amazon Data Lifecycle Manager
Mit Amazon Data Lifecycle Manager können Sie VSS-fähige Windows-Anwendungen (Volume Shadow Copy Service), die auf Amazon-EC2-Instances ausgeführt werden, sichern und wiederherstellen. Wenn für die Anwendung ein VSS-Schreiber bei Windows VSS registriert ist, erstellt Amazon Data Lifecycle Manager einen Snapshot, der für diese Anwendung anwendungskonsistent ist.
**Anmerkung**
Amazon Data Lifecycle Manager unterstützt derzeit nur anwendungskonsistente Snapshots von Ressourcen, die auf Amazon EC2 ausgeführt werden, insbesondere für Sicherungsszenarien, in denen Anwendungsdaten wiederhergestellt werden können, indem eine bestehende Instance durch eine neue, aus der Sicherung erstellte Instance ersetzt wird. Nicht alle Instance-Typen oder Anwendungen werden für VSS-Backups unterstützt. Weitere Informationen finden Sie unter [Anwendungskonsistente Windows VSS-Snapshots](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/application-consistent-snapshots.html) im *Amazon* EC2 EC2-Benutzerhandbuch.
**Nicht unterstützte Instance-Typen**
Die folgenden Instance-Typen von Amazon EC2 werden für VSS-Backups nicht unterstützt. Wenn Ihre Richtlinie auf einen dieser Instance-Typen abzielt, erstellt Amazon Data Lifecycle Manager möglicherweise trotzdem VSS-Backups, aber die Snapshots sind unter Umständen nicht mit den erforderlichen System-Tags gekennzeichnet. Ohne diese Tags werden die Snapshots nach der Erstellung nicht von Amazon Data Lifecycle Manager verwaltet. Sie müssen diese Snapshots möglicherweise manuell löschen.
+ T3: `t3.nano` \$1 `t3.micro`
+ T3a: `t3a.nano` \$1 `t3a.micro`
+ T2: `t2.nano` \$1 `t2.micro`
## Geteilte Verantwortlichkeit für anwendungskonsistente Snapshots
**Sie müssen Folgendes sicherstellen:**
+ Der SSM-Agent ist installiert und wird auf Ihren Ziel-Instances up-to-date ausgeführt
+ Systems Manager verfügt über Berechtigungen zum Ausführen der erforderlichen Aktionen auf den Ziel-Instances.
+ Amazon Data Lifecycle Manager ist berechtigt, die Systems-Manager-Aktionen auszuführen, die für die Ausführung von Vor- und Nach-Skripten auf den Ziel-Instances erforderlich sind.
+ Für benutzerdefinierte Workloads, wie z. B. selbstverwaltete MySQL-, PostgreSQL- oder InterSystems IRIS-Datenbanken, enthält das von Ihnen verwendete SSM-Dokument die richtigen und erforderlichen Aktionen zum Einfrieren, Leeren und Auftauen für Ihre Datenbankkonfiguration. I/O
+ Die Zeiten für die Snapshot-Erstellung richten sich nach Ihrem Workload-Zeitplan. Versuchen Sie beispielsweise, die Snapshot-Erstellung für geplante Wartungsfenster einzuplanen.
**Amazon Data Lifecycle Manager stellt sicher, dass:**
+ Die Snapshot-Erstellung wird innerhalb von 60 Minuten nach der geplanten Snapshot-Erstellung initiiert.
+ Vor-Skripte werden ausgeführt, bevor die Snapshot-Erstellung initiiert wird.
+ Nach-Skripte werden ausgeführt, nachdem das Vor-Skript erfolgreich war und die Snapshot-Erstellung initiiert wurde. Amazon Data Lifecycle Manager führt das Nach-Skript nur aus, wenn das Vor-Skript erfolgreich war. Wenn das Vor-Skript fehlschlägt, führt Amazon Data Lifecycle Manager das Nach-Skript nicht aus.
+ Snapshots werden bei der Erstellung mit den passenden Tags versehen.
+ CloudWatch Metriken und Ereignisse werden ausgegeben, wenn Skripts initiiert werden und wenn sie fehlschlagen oder erfolgreich sind.
# Andere Anwendungsfälle für Data Lifecycle Manager vor und nach Skripten
Neben der Verwendung von Vor- und Nach-Skripten zur Automatisierung anwendungskonsistenter Snapshots können Sie Vor- und Nach-Skripte zusammen oder einzeln verwenden, um andere Verwaltungsaufgaben vor oder nach der Snapshot-Erstellung zu automatisieren. Beispiel:
+ Verwenden Sie ein Vor-Skript, um Patches vor dem Erstellen von Snapshots anzuwenden. Dies ist hilfreich bei der Snapshot-Erstellung, nachdem Sie Ihre regulären wöchentlichen oder monatlichen Softwareupdates installiert haben.
**Anmerkung**
Wenn Sie nur ein Vor-Skript ausführen möchten, ist die Option **Standardmäßig absturzkonsistente Snapshots** standardmäßig aktiviert.
+ Verwenden eines Nach-Skripts zum Anwenden von Patches nach der Snapshot-Erstellung Dies ist bei der Snapshot-Erstellung hilfreich, bevor Sie Ihre regulären wöchentlichen oder monatlichen Softwareupdates installieren.
## Erste Schritte für andere Anwendungsfälle
In diesem Abschnitt werden die Schritte erläutert, die Sie ausführen müssen, wenn Sie and/or Pre-Post-Skripte für **andere Anwendungsfälle als anwendungskonsistente** Snapshots verwenden.
### Schritt 1: Vorbereiten der Ziel-Instances
**So bereiten Sie Ihre Ziel-Instances für Pre-Post-Skripte vor and/or**
1. Installieren Sie den SSM-Agent auf Ihren Ziel-Instances, falls noch nicht geschehen. Wenn der SSM-Agent bereits auf Ihren Ziel-Instances installiert ist, überspringen Sie diesen Schritt.
+ (Linux-Instances) [Manuelles Installieren des SSM-Agenten auf EC2-Instances](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-linux.html) für Linux
+ (Windows-Instanzen) [Arbeiten mit SSM Agent auf EC2-Instances](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-windows.html) für Windows Server
1. Stellen Sie sicher, dass der SSM-Agent ausgeführt wird. Weitere Informationen finden Sie unter [Prüfen des Status des SSM-Agents und Starten des Agenten](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-status-and-restart.html).
1. Richten Sie Systems Manager für Amazon-EC2-Instances ein. Weitere Informationen finden Sie unter [Einrichtung von Systems Manager für Amazon-EC2-Instances](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-setting-up-ec2.html) im *AWS Systems Manager -Benutzerhandbuch*.
### Schritt 2: Vorbereiten des SSM-Dokuments
Sie müssen ein SSM-Befehlsdokument erstellen, das die and/or Pre-Post-Skripts mit den Befehlen enthält, die Sie ausführen möchten.
Sie können mithilfe der unten stehenden leeren SSM-Dokumentvorlage ein SSM-Dokument erstellen und Ihre Vor- und Nach-Skriptbefehle in den entsprechenden Dokumentabschnitten hinzufügen.
**Beachten Sie Folgendes:**
Sie müssen sicherstellen, dass das SSM-Dokument die richtigen und erforderlichen Aktionen für Ihren Workload ausführt.
Das SSM-Dokument muss die erforderlichen Felder für `allowedValues` enthalten, einschließlich `pre-script`, `post-script` und `dry-run`. Amazon Data Lifecycle Manager führt Befehle auf Ihrer Instance basierend auf den Inhalten dieser Abschnitte aus. Wenn Ihr SSM-Dokument diese Abschnitte nicht enthält, behandelt Amazon Data Lifecycle Manager dies als fehlgeschlagene Ausführung.
```
###===============================================================================###
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# Permission is hereby granted, free of charge, to any person obtaining a copy of this
# software and associated documentation files (the "Software"), to deal in the Software
# without restriction, including without limitation the rights to use, copy, modify,
# merge, publish, distribute, sublicense, and/or sell copies of the Software, and to
# permit persons to whom the Software is furnished to do so.
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED,
# INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
# PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
# HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
# OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
# SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
###===============================================================================###
schemaVersion: '2.2'
description: SSM Document Template for Amazon Data Lifecycle Manager Pre/Post script feature
parameters:
executionId:
type: String
default: None
description: (Required) Specifies the unique identifier associated with a pre and/or post execution
allowedPattern: ^(None|[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12})$
command:
# Data Lifecycle Manager will trigger the pre-script and post-script actions during policy execution.
# 'dry-run' option is intended for validating the document execution without triggering any commands
# on the instance. The following allowedValues will allow Data Lifecycle Manager to successfully
# trigger pre and post script actions.
type: String
default: 'dry-run'
description: (Required) Specifies whether pre-script and/or post-script should be executed.
allowedValues:
- pre-script
- post-script
- dry-run
mainSteps:
- action: aws:runShellScript
description: Run Database freeze/thaw commands
name: run_pre_post_scripts
precondition:
StringEquals:
- platformType
- Linux
inputs:
runCommand:
- |
#!/bin/bash
###===============================================================================###
### Error Codes
###===============================================================================###
# The following Error codes will inform Data Lifecycle Manager of the type of error
# and help guide handling of the error.
# The Error code will also be emitted via AWS Eventbridge events in the 'cause' field.
# 1 Pre-script failed during execution - 201
# 2 Post-script failed during execution - 202
# 3 Auto thaw occurred before post-script was initiated - 203
# 4 Pre-script initiated while post-script was expected - 204
# 5 Post-script initiated while pre-script was expected - 205
# 6 Application not ready for pre or post-script initiation - 206
###===============================================================================###
### Global variables
###===============================================================================###
START=$(date +%s)
# For testing this script locally, replace the below with OPERATION=$1.
OPERATION={{ command }}
# Add all pre-script actions to be performed within the function below
execute_pre_script() {
echo "INFO: Start execution of pre-script"
}
# Add all post-script actions to be performed within the function below
execute_post_script() {
echo "INFO: Start execution of post-script"
}
# Debug logging for parameters passed to the SSM document
echo "INFO: ${OPERATION} starting at $(date) with executionId: ${EXECUTION_ID}"
# Based on the command parameter value execute the function that supports
# pre-script/post-script operation
case ${OPERATION} in
pre-script)
execute_pre_script
;;
post-script)
execute_post_script
;;
dry-run)
echo "INFO: dry-run option invoked - taking no action"
;;
*)
echo "ERROR: Invalid command parameter passed. Please use either pre-script, post-script, dry-run."
exit 1 # return failure
;;
esac
END=$(date +%s)
# Debug Log for profiling the script time
echo "INFO: ${OPERATION} completed at $(date). Total runtime: $((${END} - ${START})) seconds."
```
### Schritt 3: Vorbereiten der IAM-Rolle für Amazon Data Lifecycle Manager
**Anmerkung**
Dieser Schritt ist erforderlich, wenn:
Sie erstellen oder aktualisieren eine pre/post skriptfähige Snapshot-Richtlinie, die eine benutzerdefinierte IAM-Rolle verwendet.
Sie verwenden die Befehlszeile, um eine pre/post skriptfähige Snapshot-Richtlinie zu erstellen oder zu aktualisieren, die den Standard verwendet.
Wenn Sie die Konsole verwenden, um eine pre/post skriptfähige Snapshot-Richtlinie zu erstellen oder zu aktualisieren, die die Standardrolle für die Verwaltung von Snapshots (**AWSDataLifecycleManagerDefaultRole**) verwendet, überspringen Sie diesen Schritt. In diesem Fall hängen wir die **AWSDataLifecycleManagerSSMFullZugriffsrichtlinie** automatisch an diese Rolle an.
Sie müssen sicherstellen, dass die für die Richtlinie verwendete IAM-Rolle Amazon Data Lifecycle Manager die Erlaubnis erteilt, die SSM-Aktionen auszuführen, die für die Ausführung von Vor- und Nach-Skripten auf Instances, auf die die Richtlinie abzielt, erforderlich sind.
Amazon Data Lifecycle Manager bietet eine verwaltete Richtlinie (**AWSDataLifecycleManagerSSMFullAccess**), die die erforderlichen Berechtigungen beinhaltet. Sie können diese Richtlinie an Ihre IAM-Rolle für die Verwaltung von Snapshots anhängen, um sicherzustellen, dass sie die entsprechenden Berechtigungen beinhaltet.
**Wichtig**
Die verwaltete AWSData LifecycleManager SSMFull Access-Richtlinie verwendet den `aws:ResourceTag` Bedingungsschlüssel, um den Zugriff auf bestimmte SSM-Dokumente einzuschränken, wenn Pre- und Post-Skripte verwendet werden. Damit Amazon Data Lifecycle Manager auf die SSM-Dokumente zugreifen kann, müssen Sie sicherstellen, dass Ihre SSM-Dokumente das Tag `DLMScriptsAccess:true` enthalten.
Alternativ können Sie manuell eine benutzerdefinierte Richtlinie erstellen oder die erforderlichen Berechtigungen direkt der von Ihnen verwendeten IAM-Rolle zuweisen. Sie können dieselben Berechtigungen verwenden, die in der verwalteten AWSData LifecycleManager SSMFull Access-Richtlinie definiert sind, der `aws:ResourceTag` Bedingungsschlüssel ist jedoch optional. Wenn Sie sich dafür entscheiden, diesen Bedingungsschlüssel nicht zu verwenden, müssen Sie Ihre SSM-Dokumente nicht mit `DLMScriptsAccess:true` markieren.
Verwenden Sie eine der folgenden Methoden, um die **AWSDataLifecycleManagerSSMFullAccess-Richtlinie** zu Ihrer IAM-Rolle hinzuzufügen.
------
#### [ Console ]
**So hängen Sie die verwaltete Richtlinie an Ihre benutzerdefinierte Rolle an**
1. Öffnen Sie unter [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) die IAM-Konsole.
1. Wählen Sie im Navigationspanel **Rollen** aus.
1. Suchen Sie nach Ihrer benutzerdefinierten Rolle zur Verwaltung von Snapshots und wählen Sie sie aus.
1. Wählen Sie auf der Registerkarte **Berechtigungen** **Berechtigungen hinzufügen** und dann **Richtlinien anfügen** aus.
1. Suchen Sie nach der verwalteten **AWSDataLifecycleManagerSSMFullAccess-Richtlinie**, wählen Sie sie aus und klicken Sie dann auf **Berechtigungen hinzufügen**.
------
#### [ AWS CLI ]
**So hängen Sie die verwaltete Richtlinie an Ihre benutzerdefinierte Rolle an**
Verwenden Sie den Befehl [ attach-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-role-policy.html). Geben Sie für `---role-name` den Namen Ihrer benutzerdefinierten Rolle an. Legen Sie für `--policy-arn` die Option `arn:aws:iam::aws:policy/AWSDataLifecycleManagerSSMFullAccess` fest.
```
$ aws iam attach-role-policy \
--policy-arn arn:aws:iam::aws:policy/AWSDataLifecycleManagerSSMFullAccess \
--role-name your_role_name
```
------
### Snapshot-Lebenszyklusrichtlinie erstellen
------
#### [ Console ]
**So erstellen Sie die Snapshot-Lebenszyklusrichtlinie**
1. Öffnen Sie die Amazon-EC2-Konsole unter [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. Wählen Sie im Navigationsbereich **Elastic Block Store** und **Lifecycle Manager** aus. Wählen Sie dann **Create lifecycle policy (Lebenszyklusrichtlinie erstellen)** aus.
1. Wählen Sie auf dem Bildschirm **Richtlinientyp auswählen** die Option **EBS-Snapshot-Richtlinie** und dann **Weiter** aus.
1. Gehen Sie im Abschnitt **Zielressourcen** wie folgt vor:
1. Wählen Sie für **Ziel-Ressourcentypen** die Option `Instance`.
1. Geben Sie für **Zielressourcen-Tags** die Ressourcen-Tags an, die die zu sichernden Instances identifizieren. Nur Ressourcen mit den angegebenen Tags werden gesichert.
1. Wählen Sie für die **IAM-Rolle** entweder **AWSDataLifecycleManagerDefaultRole**(die Standardrolle für die Verwaltung von Snapshots) oder eine benutzerdefinierte Rolle, die Sie für Vor- und Nachskripte erstellt und vorbereitet haben.
1. Konfigurieren Sie die Zeitpläne und zusätzlichen Optionen nach Bedarf. Wir empfehlen Ihnen, die Snapshot-Erstellung für Zeiträume einzuplanen, die Ihrem Workload entsprechen, z. B. während Wartungsfenstern.
1. Wählen Sie im Abschnitt **Vor- und Nach-Skripte** die Option **Vor- und Nach-Skripte aktivieren** und gehen Sie dann wie folgt vor:
1. Wählen Sie **Benutzerdefiniertes SSM-Dokument**.
1. Wählen Sie unter **Option automatisieren** die Option aus, die den auszuführenden Skripten entspricht.
1. Wählen Sie unter **SSM-Dokument** das SSM-Dokument aus, das Sie vorbereitet haben.
1. Konfigurieren Sie bei Bedarf die folgenden zusätzlichen Optionen:
+ **Timeout für das Skript** – Der Timeout-Zeitraum, nach dem Amazon Data Lifecycle Manager die versuchte Skriptausführung als fehlgeschlagen behandelt, wenn sie nicht abgeschlossen wurde. Wenn ein Skript nicht innerhalb des Timeout-Zeitraums abgeschlossen wird, schlägt der Versuch von Amazon Data Lifecycle Manager fehl. Der Timeout-Zeitraum gilt für die Vor- und Nach-Skripte einzeln. Der Minimal- und Standardwert für den Timeout beträgt 10 Sekunden. Die maximale Timeout-Zeit beträgt 120 Sekunden.
+ **Fehlgeschlagene Skripte erneut versuchen** – Wählen Sie diese Option, um Skripte zu wiederholen, die nicht innerhalb ihres Timeouts abgeschlossen werden. Wenn das Vor-Skript fehlschlägt, wiederholt Amazon Data Lifecycle Manager den gesamten Snapshot-Erstellungsprozess, einschließlich der Ausführung der Vor- und Nach-Skripte. Wenn das Nach-Skript fehlschlägt, wiederholt Amazon Data Lifecycle Manager nur das Nach-Skript. In diesem Fall ist das Vor-Skript abgeschlossen und der Snapshot wurde möglicherweise erstellt.
+ **Standardmäßig absturzkonsistente Snapshots** – Wählen Sie diese Option, um standardmäßig absturzkonsistente Snapshots zu verwenden, falls das Vor-Skript nicht ausgeführt werden kann. Dies ist das Standardverhalten bei der Snapshot-Erstellung für Amazon Data Lifecycle Manager, wenn Vor- und Nach-Skripte nicht aktiviert sind. Wenn Sie Wiederholungen aktiviert haben, verwendet Amazon Data Lifecycle Manager standardmäßig nur dann absturzkonsistente Snapshots, wenn alle Wiederholungsversuche ausgeschöpft sind. Wenn das Vor-Skript fehlschlägt und Sie nicht standardmäßig absturzkonsistente Snapshots verwenden, erstellt Amazon Data Lifecycle Manager während dieser geplanten Ausführung keine Snapshots für die Instance.
1. Wählen Sie **Standardrichtlinie erstellen**.
**Anmerkung**
Falls Sie den Fehler `Role with name AWSDataLifecycleManagerDefaultRole already exists` erhalten, finden Sie weitere Informationen unter [Probleme mit Amazon Data Lifecycle Manager beheben](dlm-troubleshooting.md).
------
#### [ AWS CLI ]
**So erstellen Sie die Snapshot-Lebenszyklusrichtlinie**
Verwenden Sie den [create-lifecycle-policy](https://docs.aws.amazon.com/cli/latest/reference/dlm/create-lifecycle-policy.html)Befehl und fügen Sie die `Scripts` Parameter in ein. `CreateRule` Weitere Informationen finden Sie in der [https://docs.aws.amazon.com/dlm/latest/APIReference/API_Script.html](https://docs.aws.amazon.com/dlm/latest/APIReference/API_Script.html).
```
$ aws dlm create-lifecycle-policy \
--description "policy_description" \
--state ENABLED \
--execution-role-arn iam_role_arn \
--policy-details file://policyDetails.json
```
Wenn `policyDetails.json` Folgendes umfasst.
```
{
"PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
"ResourceTypes": [
"INSTANCE"
],
"TargetTags": [{
"Key": "tag_key",
"Value": "tag_value"
}],
"Schedules": [{
"Name": "schedule_name",
"CreateRule": {
"CronExpression": "cron_for_creation_frequency",
"Scripts": [{
"Stages": ["PRE" | "POST" | "PRE","POST"],
"ExecutionHandlerService":"AWS_SYSTEMS_MANAGER",
"ExecutionHandler":"ssm_document_name|arn",
"ExecuteOperationOnScriptFailure":true|false,
"ExecutionTimeout":timeout_in_seconds (10-120),
"MaximumRetryCount":retries (0-3)
}]
},
"RetainRule": {
"Count": retention_count
}
}]
}
```
------
# So funktionieren Vor- und Nachskripte für Amazon Data Lifecycle Manager
Die folgende Abbildung zeigt den Prozessablauf für Vor- und Nach-Skripte bei der Verwendung benutzerdefinierter SSM-Dokumente. Dies gilt nicht für VSS-Backups.
![\[Prozessablauf für Vor- und Nach-Skripte für Amazon Data Lifecycle Manager\]](http://docs.aws.amazon.com/de_de/ebs/latest/userguide/images/dlm-scripts.png)
Zum geplanten Zeitpunkt der Snapshot-Erstellung finden die folgenden Aktionen und dienstübergreifenden Interaktionen statt.
1. Amazon Data Lifecycle Manager initiiert die Vor-Skript-Aktion durch Aufrufen des SSM-Dokuments und Übergeben des Parameters `pre-script`.
**Anmerkung**
Die Schritte 1 bis 3 finden nur statt, wenn Sie Vor-Skripte ausführen. Wenn Sie nur Nach-Skripte ausführen, werden die Schritte 1 bis 3 übersprungen.
1. Systems Manager sendet Vor-Skript-Befehle an den SSM-Agent, der auf den Ziel-Instances ausgeführt wird. Der SSM-Agent führt die Befehle auf der Instance aus und sendet Statusinformationen zurück an Systems Manager.
Wenn das SSM-Dokument beispielsweise verwendet wird, um anwendungskonsistente Snapshots zu erstellen, kann das Pre-Skript einfrieren und geleert werden, I/O um sicherzustellen, dass alle gepufferten Daten auf das Volume geschrieben werden, bevor der Snapshot erstellt wird.
1. Systems Manager sendet Statusaktualisierungen zu dem Vor-Skript-Befehl an Amazon Data Lifecycle Manager. Wenn das Vor-Skript fehlschlägt, führt Amazon Data Lifecycle Manager je nachdem, wie Sie die Optionen vor und nach dem Skript konfigurieren, eine der folgenden Aktionen aus:
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/ebs/latest/userguide/script-flow.html)
1. Amazon Data Lifecycle Manager initiiert die Snapshot-Erstellung.
1. Amazon Data Lifecycle Manager initiiert die Nach-Skript-Aktion durch Aufrufen des SSM-Dokuments und Übergeben des Parameters `post-script`.
**Anmerkung**
Die Schritte 5 bis 7 finden nur statt, wenn Sie Vor-Skripte ausführen. Wenn Sie nur Nach-Skripte ausführen, werden die Schritte 1 bis 3 übersprungen.
1. Systems Manager sendet Nach-Skript-Befehle an den SSM-Agent, der auf den Ziel-Instances ausgeführt wird. Der SSM-Agent führt die Befehle auf der Instance aus und sendet Statusinformationen zurück an Systems Manager.
Wenn das SSM-Dokument beispielsweise anwendungskonsistente Snapshots ermöglicht, kann dieses Post-Skript auftauen, I/O um sicherzustellen, dass Ihre Datenbanken nach der Erstellung des Snapshots wieder normale I/O-Operationen aufnehmen.
1. Wenn Sie ein Nach-Skript ausführen und Systems Manager anzeigt, dass es erfolgreich abgeschlossen wurde, ist der Vorgang abgeschlossen.
Wenn das Nach-Skript fehlschlägt, führt Amazon Data Lifecycle Manager je nachdem, wie Sie die Optionen vor und nach dem Skript konfigurieren, eine der folgenden Aktionen aus:
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/ebs/latest/userguide/script-flow.html)
Hinweis: Wenn das Nach-Skript fehlschlägt, wurde das Vor-Skript (falls aktiviert) erfolgreich abgeschlossen und die Snapshots wurden möglicherweise erstellt. Unter Umständen müssen Sie weitere Maßnahmen für die Instance ergreifen, um sicherzustellen, dass sie wie erwartet funktioniert. Zum Beispiel, wenn das Pre-Skript angehalten und geleert wurde. I/O, but the post script failed to thaw I/O, you might need to configure your database to auto-thaw I/O or you need to manually thaw I/O
1. Der Snapshot-Erstellungsprozess wird möglicherweise abgeschlossen, nachdem das Nach-Skript abgeschlossen ist. Wie viel Zeit das Abschließen des Snapshots in Anspruch nimmt, hängt von der Snapshot-Größe ab.
# Identifizieren Sie Snapshots, die mit Data Lifecycle Manager-Vor- und Nachskripten erstellt wurden
Amazon Data Lifecycle Manager weist Snapshots, die mit Vor- und Nach-Skripten erstellt wurden, automatisch die folgenden System-Tags zu.
+ Schlüssel: `aws:dlm:pre-script`; Wert: `SUCCESS`\$1`FAILED`
Der Tag-Wert von `SUCCESS` gibt an, dass das Vor-Skript erfolgreich ausgeführt wurde. Der Tag-Wert von `FAILED` gibt an, dass das Vor-Skript nicht erfolgreich ausgeführt wurde.
+ Schlüssel: `aws:dlm:post-script`; Wert: `SUCCESS`\$1`FAILED`
Der Tag-Wert von `SUCCESS` gibt an, dass das Nach-Skript erfolgreich ausgeführt wurde. Der Tag-Wert von `FAILED` gibt an, dass das Nach-Skript nicht erfolgreich ausgeführt wurde.
Bei benutzerdefinierten SSM-Dokumenten und SAP HANA-Sicherungen können Sie auf eine erfolgreiche anwendungskonsistente Snapshot-Erstellung schließen, wenn der Snapshot sowohl mit `aws:dlm:pre-script:SUCCESS` als auch `aws:dlm:post-script:SUCCESS` getaggt ist.
Darüber hinaus werden anwendungskonsistente Snapshots, die mit VSS-Backup erstellt wurden, automatisch mit folgenden Tags versehen:
+ Schlüssel: `AppConsistent tag`; Wert: `true`\$1`false`
Ein Tag-Wert von `true` gibt an, dass das VSS-Backup erfolgreich war und die Snapshots anwendungskonsistent sind. Ein Tag-Wert von `false` gibt an, dass das VSS-Backup nicht erfolgreich war und die Snapshots nicht anwendungskonsistent sind.
# Vor- und Nachskripte von Amazon Data Lifecycle Manager überwachen
**CloudWatch Amazon-Metriken**
Amazon Data Lifecycle Manager veröffentlicht die folgenden CloudWatch Metriken, wenn Vor- und Nachskripte fehlschlagen und erfolgreich sind und wenn VSS-Backups fehlschlagen und erfolgreich sind.
+ `PreScriptStarted`
+ `PreScriptCompleted`
+ `PreScriptFailed`
+ `PostScriptStarted`
+ `PostScriptCompleted`
+ `PostScriptFailed`
+ `VSSBackupStarted`
+ `VSSBackupCompleted`
+ `VSSBackupFailed`
Weitere Informationen finden Sie unter [Überwachen Sie die Data Lifecycle Manager-Richtlinien mit CloudWatch](monitor-dlm-cw-metrics.md).
**Amazon EventBridge**
Amazon Data Lifecycle Manager gibt das folgende EventBridge Amazon-Ereignis aus, wenn ein Pre- oder Post-Skript initiiert wird, erfolgreich ist oder fehlschlägt
+ `DLM Pre Post Script Notification`
Weitere Informationen finden Sie unter [Überwachen Sie die Data Lifecycle Manager-Richtlinien mit EventBridge](monitor-cloudwatch-events.md).
# Erstellen Sie eine benutzerdefinierte Amazon Data Lifecycle Manager Manager-Richtlinie für EBS-gestützte AMIs
Das folgende Verfahren zeigt, wie Sie Amazon Data Lifecycle Manager verwenden, um EBS-AMI-Lebenszyklen zu automatisieren.
**Topics**
+ [Erstellen einer AMI-Lebenszyklusrichtlinie](#create-ami-policy)
+ [Überlegungen zu AMI-Lebenszyklusrichtlinien](#ami-considerations)
+ [Weitere Ressourcen](#ami-additional-resources)
## Erstellen einer AMI-Lebenszyklusrichtlinie
Verwenden Sie eines der folgenden Verfahren, um eine AMI-Lebenszyklusrichtlinie zu erstellen.
------
#### [ Console ]
**So erstellen Sie eine AMI-Richtlinie**
1. Öffnen Sie die Amazon-EC2-Konsole unter [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. Wählen Sie im Navigationsbereich **Elastic Block Store** und **Lifecycle Manager** aus. Wählen Sie dann **Create lifecycle policy (Lebenszyklusrichtlinie erstellen)** aus.
1. Wählen Sie auf dem Bildschirm **Richtlinientyp auswählen** die Option **EBS-unterstützte AMI-Richtlinie** und dann **Weiter** aus.
1. Wählen Sie im Abschnitt **Zielressourcen** für **Zielressourcen-Tags** die Ressourcen-Tags aus, die die zu sichernden Volumes oder Instances identifizieren. Die Richtlinie sichert nur die Ressourcen mit den angegebenen Tag (Markierung)-Schlüssel-Wert-Paaren.
1. Geben Sie unter **Description (Beschreibung)** eine kurze Beschreibung der Richtlinie ein.
1. Wählen Sie für die **IAM-Rolle** die IAM-Rolle aus, die über Berechtigungen zum Verwalten, Erstellen von Snapshots AMIs und zur Beschreibung von Instances verfügt. Um die von Amazon Data Lifecycle Manager bereitgestellte Standardrolle zu verwenden, wählen Sie **Standardrolle**. Um alternativ eine benutzerdefinierte IAM-Rolle zu verwenden, die Sie zuvor erstellt haben, wählen Sie **Andere Rolle auswählen** und dann die zu verwendende Rolle aus.
1. Fügen Sie für **Richtlinien-Tags** die Tags hinzu, die auf die Lebenszyklusrichtlinie angewendet werden sollen. Sie können diese Tags (Markierungen) verwenden, um Ihre Richtlinien zu identifizieren und zu kategorisieren.
1. Wählen Sie für **Richtlinienstatus nach der Erstellung** die Option **Richtlinie aktivieren**, um die Ausführungen der Richtlinie zum nächsten eingeplanten Zeitpunkt zu starten oder **Richtlinie deaktivieren**, um zu verhindern, dass die Richtlinie ausgeführt wird. Wenn Sie die Richtlinie jetzt nicht aktivieren, wird sie AMIs erst erstellt, wenn Sie sie nach der Erstellung manuell aktivieren.
1. Geben Sie im Abschnitt **Instance-Neustart** an, ob Instances vor der AMI-Erstellung neu gestartet werden sollen. Um zu verhindern, dass die Zielinstances neu gestartet werden, wählen Sie **Nein**. Die Auswahl von **Nein** kann zu Problemen mit der Datenkonsistenz führen. Um Instances vor der AMI-Erstellung neu zu starten, wählen Sie **Ja**. Die Wahl dieser Option gewährleistet die Datenkonsistenz, könnte jedoch dazu führen, dass mehrere abgezielte Instances gleichzeitig neu gestartet werden.
1. Wählen Sie **Weiter** aus.
1. Konfigurieren Sie auf dem Bildschirm **Zeitplan konfigurieren** die Richtlinienzeitpläne. Eine Richtlinie kann bis zu vier Zeitpläne aufweisen. Zeitplan 1 ist obligatorisch. Die Zeitpläne 2, 3 und 4 sind optional. Gehen Sie für jeden Richtlinienzeitplan, den Sie hinzufügen, wie folgt vor:
1. Gehen Sie im Abschnitt **Zeitplandetails** wie folgt vor:
1. Geben Sie für **Zeitplanname** einen beschreibenden Namen für den Zeitplan an.
1. Konfigurieren Sie für **Häufigkeit** und die zugehörigen Felder das Intervall zwischen Richtlinienausführungen.
Sie können Richtlinienausführungen nach einem täglichen, wöchentlichen, monatlichen oder jährlichen Zeitplan konfigurieren. Alternativ können Sie **Custom cron expression (Benutzerdefinierter Cron-Ausdruck)** wählen, um ein Intervall von bis zu 1 Jahr anzugeben. Weitere Informationen finden Sie unter [Cron und Rate Expressions](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-scheduled-rule-pattern.html) im * EventBridge Amazon-Benutzerhandbuch*.
1. Geben Sie für **Starten um** die Zeit an, zu der die Richtlinienausführungen gestartet werden sollen. Die erste Richtlinienausführung beginnt innerhalb einer Stunde nach der geplanten Zeit. Die Uhrzeit muss im `hh:mm` UTC-Format eingegeben werden.
1. Geben Sie unter **Aufbewahrungstyp** die Aufbewahrungsrichtlinie an, die nach dem Zeitplan AMIs erstellt wurde.
Sie können die Aufbewahrung entweder auf der AMIs Grundlage ihrer Gesamtzahl oder ihres Alters vornehmen.
Für die anzahlbasierte Aufbewahrung liegt der Bereich zwischen `1` und `1000`. Nach Erreichen der maximalen Anzahl wird die Registrierung des ältesten Snapshotes oder des ältesten AMIs aufgehoben, wenn ein neuer oder ein neues erstellt wird.
Für die auf dem Alter basierende Aufbewahrung reicht die Spanne von `1` Tag bis `100` Jahre. Nach Ablauf des Aufbewahrungszeitraums des Snapshots oder AMI wird die Registrierung aufgehoben.
**Anmerkung**
Alle Zeitpläne müssen denselben Aufbewahrungstyp haben. Sie können den Aufbewahrungstyp nur für Zeitplan 1 angeben. Die Zeitpläne 2, 3 und 4 erben den Aufbewahrungstyp aus Plan 1. Jeder Zeitplan kann über eine eigene Aufbewahrungsanzahl oder einen eigenen Zeitraum verfügen.
1. Konfigurieren Sie das Tagging für AMIs.
Gehen Sie im Abschnitt **Tag (Markierung)** wie folgt vor:
1. Um alle benutzerdefinierten Tags aus der Quellinstanz in die nach dem Zeitplan AMIs erstellte zu kopieren, wählen Sie **Tags aus Quelle kopieren aus**.
1. Standardmäßig werden nach dem Zeitplan AMIs erstellte Instances automatisch mit der ID der Quellinstanz gekennzeichnet. Um dieses automatische Markieren zu verhindern, entfernen Sie bei **Variablen-Tags (Markierungen)** die `instance-id:$(instance-id)`-Kachel.
1. Um zusätzliche Tags anzugeben, die nach diesem Zeitplan AMIs erstellt wurden, wählen Sie **Tags hinzufügen**.
1. Konfigurieren Sie die AMI-Veralterung.
Um zu verwerfen, AMIs wann sie nicht mehr verwendet werden sollen, wählen Sie im Abschnitt **AMI-Verfall die Option AMI-Veraltete** Version **für diesen Zeitplan aktivieren aus und geben Sie dann die AMI-Verfallsregel** an. Die AMI-Verfallsregel gibt an, wann sie als veraltet AMIs gelten sollen.
Wenn der Zeitplan die zählbasierte AMI-Aufbewahrung verwendet, müssen Sie die Anzahl der ältesten, die veraltet sein sollen AMIs , angeben. Die Anzahl der Veraltungszeiten muss kleiner oder gleich der AMI-Aufbewahrungsanzahl des Zeitplans sein und darf nicht größer als 1000 sein. Wenn der Zeitplan beispielsweise so konfiguriert ist, dass maximal 5 gespeichert werden, können Sie den Zeitplan so konfigurieren AMIs, dass die ältesten 5 alten Werte als veraltet gelten. AMIs
Wenn der Zeitplan eine altersabhängige AMI-Aufbewahrung verwendet, müssen Sie den Zeitraum angeben, nach dessen Ablauf nicht AMIs mehr unterstützt werden soll. Die Anzahl der Veraltungszeiten muss kleiner oder gleich dem AMI-Aufbewahrungszeitraum des Zeitplans sein und darf nicht größer als 10 Jahre sein (120 Monate, 520 Wochen oder 3650 Tage). Wenn der Zeitplan beispielsweise so konfiguriert ist, dass er AMIs für 10 Tage aufbewahrt wird, können Sie den Zeitplan so konfigurieren, dass er nach einem Zeitraum von bis zu 10 Tagen AMIs nach seiner Erstellung als veraltet gilt.
1. Konfigurieren Sie das regionsübergreifende Kopieren.
Um nach dem Zeitplan AMIs erstellte Dateien in verschiedene Regionen zu kopieren, wählen Sie im Abschnitt **Regionsübergreifendes Kopieren die Option Regionsübergreifendes Kopieren** **aktivieren** aus. Sie können in Ihrem Konto in AMIs bis zu drei weitere Regionen kopieren. Sie müssen für jede Zielregion eine separate regionsübergreifende Kopierregel angeben.
Sie können für jede Zielregion Folgendes angeben:
+ Eine Aufbewahrungsregel für die AMI-Kopie. Wenn der Aufbewahrungszeitraum abgläuft, wird die Kopie in der Zielregion automatisch aufgehoben.
+ Verschlüsselungsstatus für die AMI Kopie. Wenn das Quell-AMI verschlüsselt ist oder wenn die Verschlüsselung standardmäßig aktiviert ist, AMIs werden die kopierten Dateien immer verschlüsselt. Wenn der Quell-AMI unverschlüsselt ist und die Verschlüsselung standardmäßig deaktiviert ist, können Sie optional die Verschlüsselung aktivieren. Wenn Sie keinen KMS-Schlüssel angeben, AMIs werden sie mit dem Standard-KMS-Schlüssel für die EBS-Verschlüsselung in jeder Zielregion verschlüsselt. Wenn Sie einen Verschlüsselung für die Zielregion angeben, muss die ausgewählte IAM-Rolle Zugriff auf das Verschlüsselung haben.
+ Eine Veraltungsregel für die AMI Kopie. Wenn die Veraltungsperiode abgelaufen ist, wird die AMI-Kopie automatisch veraltet. Die Veraltungsfrist muss kleiner oder gleich dem Kopieraufbewahrungszeitraum sein und darf nicht länger als 10 Jahre sein.
+ Ob alle Tags oder keine Tags aus dem Quell-AMI kopiert werden sollen.
**Anmerkung**
Überschreiten Sie nicht die Anzahl gleichzeitiger AMI-Kopien pro Region.
1. Um weitere Zeitpläne hinzuzufügen, wählen Sie die Option **Weiteren Zeitplan hinzufügen**, die sich oben auf dem Bildschirm befindet. Füllen Sie für jeden zusätzlichen Zeitplan die Felder wie oben in diesem Thema beschrieben aus.
1. Nachdem Sie die erforderlichen Zeitpläne hinzugefügt haben, wählen Sie **Richtlinie überprüfen** aus.
1. Überprüfen Sie die Richtlinienzusammenfassung und wählen Sie dann **Richtlinie erstellen** aus.
**Anmerkung**
Falls Sie den Fehler `Role with name AWSDataLifecycleManagerDefaultRoleForAMIManagement already exists` erhalten, finden Sie weitere Informationen unter [Probleme mit Amazon Data Lifecycle Manager beheben](dlm-troubleshooting.md).
------
#### [ Command line ]
Verwenden Sie den [create-lifecycle-policy](https://docs.aws.amazon.com/cli/latest/reference/dlm/create-lifecycle-policy.html)Befehl, um eine AMI-Lebenszyklusrichtlinie zu erstellen. Legen Sie für `PolicyType` die Option `IMAGE_MANAGEMENT` fest.
**Anmerkung**
Zur Vereinfachung der Syntax wird in den folgenden Beispielen eine JSON-Datei `policyDetails.json` verwendet, die die Richtliniendetails enthält.
**Beispiel 1: Altersbasierte Aufbewahrung und AMI Ablehnung**
In diesem Beispiel wird eine AMI-Lebenszyklusrichtlinie erstellt AMIs , die alle Instances mit einem Tag-Schlüssel von `purpose` mit dem Wert von erstellt, `production` ohne die Ziel-Instances neu zu starten. Die Richtlinie enthält einen Zeitplan, der jeden Tag um `01:00` Uhr UTC ein AMI erstellt. Die Richtlinie ist `2` tagelang AMIs gültig und wird von Tag zu Tag für ungültig erklärt. `1` Außerdem werden die Tags von der Quellinstanz in die Instanz kopiert, AMIs die sie erstellt.
```
aws dlm create-lifecycle-policy \
--description "My AMI policy" \
--state ENABLED \
--execution-role-arn arn:aws:iam::12345678910:role/AWSDataLifecycleManagerDefaultRoleForAMIManagement \
--policy-details file://policyDetails.json
```
Das folgende Beispiel zeigt eine `policyDetails.json`-Datei.
```
{
"PolicyType": "IMAGE_MANAGEMENT",
"ResourceTypes": [
"INSTANCE"
],
"TargetTags": [{
"Key": "purpose",
"Value": "production"
}],
"Schedules": [{
"Name": "DailyAMIs",
"TagsToAdd": [{
"Key": "type",
"Value": "myDailyAMI"
}],
"CreateRule": {
"Interval": 24,
"IntervalUnit": "HOURS",
"Times": [
"01:00"
]
},
RetainRule":{
"Interval" : 2,
"IntervalUnit" : "DAYS"
},
DeprecateRule": {
"Interval" : 1,
"IntervalUnit" : "DAYS"
},
"CopyTags": true
}
],
"Parameters" : {
"NoReboot":true
}
}
```
Wenn die Anforderung erfolgreich ist, gibt der Befehl die ID der neu erstellten Richtlinie zurück. Es folgt eine Beispielausgabe.
```
{
"PolicyId": "policy-9876543210abcdef0"
}
```
**Beispiel 2: Zählbasierte Aufbewahrung und AMI-Veraltung mit regionsübergreifender Kopie**
In diesem Beispiel wird eine AMI-Lebenszyklusrichtlinie erstellt AMIs , die alle Instances mit einem Tag-Schlüssel `purpose` mit dem Wert von erstellt `production` und die Ziel-Instances neu startet. Die Richtlinie enthält einen Zeitplan, der täglich alle `6` Stunden, beginnend um `17:30` Uhr UTC, ein AMI erstellt. Die Richtlinie behält die älteste Version bei `3` AMIs und stellt sie automatisch als veraltet dar. `2` AMIs Es verfügt auch über eine regionsübergreifende Kopierregel`us-east-1`, AMIs mit der `2` AMI-Kopien kopiert, gespeichert und automatisch als veraltet eingestuft werden.
```
aws dlm create-lifecycle-policy \
--description "My AMI policy" \
--state ENABLED \
--execution-role-arn arn:aws:iam::12345678910:role/AWSDataLifecycleManagerDefaultRoleForAMIManagement \
--policy-details file://policyDetails.json
```
Das folgende Beispiel zeigt eine `policyDetails.json`-Datei.
```
{
"PolicyType": "IMAGE_MANAGEMENT",
"ResourceTypes" : [
"INSTANCE"
],
"TargetTags": [{
"Key":"purpose",
"Value":"production"
}],
"Parameters" : {
"NoReboot": true
},
"Schedules" : [{
"Name" : "Schedule1",
"CopyTags": true,
"CreateRule" : {
"Interval": 6,
"IntervalUnit": "HOURS",
"Times" : ["17:30"]
},
"RetainRule":{
"Count" : 3
},
"DeprecateRule":{
"Count" : 2
},
"CrossRegionCopyRules": [{
"TargetRegion": "us-east-1",
"Encrypted": true,
"RetainRule":{
"IntervalUnit": "DAYS",
"Interval": 2
},
"DeprecateRule":{
"IntervalUnit": "DAYS",
"Interval": 1
},
"CopyTags": true
}]
}]
}
```
------
## Überlegungen zu AMI-Lebenszyklusrichtlinien
Die folgenden **allgemeinen Überlegungen** gelten für die Erstellung von AMI-Lebenzyklusrichtlinien:
+ AMI-Lebenszyklusrichtlinien zielen nur auf Instances ab, die sich in derselben Region wie die Richtlinie befinden.
+ Der erste AMI-Erstellungsvorgang beginnt innerhalb einer Stunde nach der angegebenen Startzeit. Nachfolgende AMI-Erstellungsvorgänge beginnen innerhalb einer Stunde nach ihrer geplanten Zeit.
+ Wenn Amazon Data Lifecycle Manager ein AMI abmeldet, löscht er es automatisch mit Snapshots zum Backup.
+ Bei Zielressourcen-Tags muss die Groß-/Kleinschreibung beachtet werden.
+ Wenn Sie die Ziel-Tags aus einer Instance entfernen, für die eine Richtlinie gilt, verwaltet Amazon Data Lifecycle Manager keine AMIs im Standard vorhandenen Tags mehr. Sie müssen sie manuell löschen, wenn sie nicht mehr benötigt werden.
+ Sie können mehrere Richtlinien zum Sichern einer Instance erstellen. *Wenn eine Instance beispielsweise zwei Tags hat, wobei Tag *A das Ziel für Richtlinie A* ist, alle 12 Stunden ein AMI zu erstellen, und Tag *B das Ziel für Richtlinie *B** ist, um alle 24 Stunden ein AMI zu erstellen, erstellt Amazon Data Lifecycle Manager AMIs gemäß den Zeitplänen für beide Richtlinien.* Alternativ können Sie dasselbe Ergebnis erzielen, indem Sie eine einzelne Richtlinie mit mehreren Zeitplänen erstellen. Sie können beispielsweise eine einzelne Richtlinie erstellen, die nur auf Tag (Markierung) *A*abzielt, und zwei Zeitpläne angeben – einen für alle 12 Stunden und einen für alle 24 Stunden.
+ Neue Volumes, die an eine Ziel-Instance angehängt werden, nachdem die Richtlinie erstellt wurde, werden bei der nächsten Richtlinienausführung automatisch in das Backup einbezogen. Alle Volumes, die zum Zeitpunkt der Richtlinienausführung mit der Instance verbunden sind, sind enthalten.
+ Wenn Sie eine Richtlinie mit einem benutzerdefinierten Cron-basierten Zeitplan so erstellen und konfigurieren, dass nur ein AMI erstellt wird, wird die Richtlinie dieses AMI nicht automatisch abmelden, wenn der Aufbewahrungsschwellenwert erreicht ist. Sie müssen das AMI manuell abmelden, wenn es nicht mehr benötigt wird.
+ Wenn Sie eine altersbasierte Richtlinie erstellen, bei der der Aufbewahrungszeitraum kürzer ist als die Erstellungshäufigkeit, behält Amazon Data Lifecycle Manager immer den letzten AMI bei, bis der nächste erstellt wird. Wenn zum Beispiel eine altersbasierte Richtlinie jeden Monat einen AMI mit einer Aufbewahrungsfrist von sieben Tagen erstellt, behält Amazon Data Lifecycle Manager jeden AMI einen Monat lang bei, obwohl die Aufbewahrungsfrist sieben Tage beträgt.
+ Bei zählungsbasierten Richtlinien erstellt Amazon Data Lifecycle Manager immer AMIs entsprechend der Erstellungshäufigkeit, bevor versucht wird, das älteste AMI gemäß der Aufbewahrungsrichtlinie abzumelden.
+ Es kann mehrere Stunden dauern, bis ein AMI erfolgreich aus der Registrierung abgemeldet wird und die zugehörigen Backup-Snapshots gelöscht sind. Wenn Amazon Data Lifecycle Manager das nächste AMI erstellt, bevor das zuvor erstellte AMI erfolgreich abgemeldet wurde, können Sie vorübergehend eine Zahl behalten, AMIs die höher ist als Ihre Aufbewahrungszahl.
Die folgenden Überlegungen gelten für das **Beenden von Instances, die Ziel einer Richtlinie sind:**
+ Wenn Sie eine Instance beenden, für die eine Richtlinie mit einem auf der Anzahl basierenden Aufbewahrungszeitplan vorgesehen war, verwaltet die Richtlinie nicht mehr die Instance, AMIs die sie zuvor aus der beendeten Instance erstellt hat. Sie müssen diese früher manuell abmelden, AMIs wenn sie nicht mehr benötigt werden.
+ Wenn Sie eine Instance beenden, auf die eine Richtlinie mit einem altersbasierten Aufbewahrungszeitplan abzielt, werden durch die Richtlinie weiterhin diejenigen, AMIs die zuvor nach dem definierten Zeitplan aus der beendeten Instance erstellt wurden, bis zum letzten AMI, aber nicht eingeschlossen, aufgehoben. Sie müssen das letzte AMI manuell abmelden, wenn es nicht mehr benötigt wird.
Die folgenden Überlegungen gelten für AMI-Richtlinien und **AMI-Veralterung**:
+ Wenn Sie die Anzahl veralteter AMIs für einen Zeitplan mit zählungsbasierter Aufbewahrung erhöhen, wird die Änderung auf alle AMIs (vorhandenen und neuen) angewendet, die durch den Zeitplan erstellt wurden.
+ Wenn Sie den AMI-Verfallszeitraum für einen Zeitplan mit altersabhängiger Aufbewahrung verlängern, gilt die Änderung nur für neue Versionen. AMIs Bestehende AMIs sind nicht betroffen.
+ Wenn Sie die AMI-Verfallsregel aus einem Zeitplan entfernen, storniert Amazon Data Lifecycle Manager keine veralteten Versionen für diejenigen, die zuvor in AMIs diesem Zeitplan als veraltet eingestuft wurden.
+ Wenn Sie die Anzahl oder den Zeitraum für veraltete AMIs für einen Zeitplan verringern, storniert Amazon Data Lifecycle Manager keine veralteten Versionen für diejenigen, die zuvor nach AMIs diesem Zeitplan als veraltet eingestuft wurden.
+ Wenn Sie ein AMI, das mit einer AMI-Richtlinie erstellt wurde, manuell verwerfen, überschreibt Amazon Data Lifecycle Manager die Veraltungsphase nicht.
+ Wenn Sie die Veraltung für ein AMI manuell abbrechen, das zuvor durch eine AMI-Richtlinie veraltet wurde, überschreibt Amazon Data Lifecycle Manager die Stornierung nicht.
+ Wenn ein AMI durch mehrere in Konflikt stehende Zeitpläne erstellt wird und für einen oder mehrere dieser Zeitpläne keine AMI-Veraltungsregel vorhanden ist, wird Amazon Data Lifecycle Manager dieses AMI nicht veraltet.
+ Wenn ein AMI durch mehrere in Konflikt stehende Zeitpläne erstellt wird und alle diese Zeitpläne über eine AMI-Ablehnungsregel verfügen, verwendet Amazon Data Lifecycle Manager die Veralterungsregel, die zum letzten Veralterungsdatum führt.
Die folgenden Überlegungen gelten für AMI-Richtlinien und den [Papierkorb](recycle-bin.md):
+ Wenn Amazon Data Lifecycle Manager ein AMI abmeldet und es an den Papierkorb sendet, wenn der Aufbewahrungsschwellenwert der Richtlinie erreicht ist, und Sie dieses AMI manuell aus dem Papierkorb wiederherstellen, müssen Sie das AMI manuell abmelden, wenn es nicht mehr benötigt wird. Amazon Data Lifecycle Manager verwaltet die AMI nicht mehr.
+ Wenn Sie eine AMI, die durch eine Richtlinie erstellt wurde, manuell abmelden und diese AMI sich im Papierkorb befindet, wenn der Aufbewahrungsschwellenwert der Richtlinie erreicht ist, wird Amazon Data Lifecycle Manager die AMI nicht abmelden. Amazon Data Lifecycle Manager verwaltet sie nicht, AMIs solange sie sich im Papierkorb befinden.
Wenn die AMI aus dem Papierkorb wiederhergestellt wird, bevor der Aufbewahrungsschwellenwert der Richtlinie erreicht wird, meldet Amazon Data Lifecycle Manager die AMI ab, sobald der Aufbewahrungsschwellenwert der Richtlinie erreicht wird.
Wenn die AMI aus dem Papierkorb wiederhergestellt wird, nachdem der Aufbewahrungsschwellenwert der Richtlinie erreicht wurde, meldet Amazon Data Lifecycle Manager die AMI nicht mehr ab. Sie müssen ihn manuell löschen, wenn er nicht mehr benötigt wird.
Die folgenden Überlegungen gelten für AMI-Richtlinien, die sich im **error**-Status befinden:
+ Bei Richtlinien mit altersabhängigen Aufbewahrungszeitplänen, AMIs die so eingestellt sind, dass sie ablaufen, solange die Richtlinie gültig ist, werden sie auf `error` unbestimmte Zeit aufbewahrt. Sie müssen die Registrierung manuell aufheben. AMIs Wenn Sie die Richtlinie wieder aktivieren, setzt Amazon Data Lifecycle Manager die Abmeldung fort, sobald die Aufbewahrungsfristen AMIs ablaufen.
+ Bei Richtlinien mit auf der Anzahl basierenden Aufbewahrungszeitplänen beendet die Richtlinie die Erstellung und Abmeldung AMIs , solange sie sich im Status befindet. `error` Wenn Sie die Richtlinie erneut aktivieren, setzt Amazon Data Lifecycle Manager die Erstellung fort und setzt die Abmeldung fort AMIs, AMIs sobald der Aufbewahrungsschwellenwert erreicht ist.
Die folgenden Überlegungen gelten für AMI-Richtlinien und die **[Deaktivierung AMIs](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/disable-an-ami.html)**:
+ Wenn Sie ein AMI, das von Amazon Data Lifecycle Manager erstellt wurde, deaktivieren und dieses AMI bei Erreichen des Aufbewahrungsschwellenwerts deaktiviert wird, meldet Amazon Data Lifecycle Manager das AMI ab und löscht die zugehörigen Snapshots.
+ Wenn Sie ein von Amazon Data Lifecycle Manager erstelltes AMI deaktivieren und die zugehörigen Snapshots manuell archivieren und diese Snapshots archiviert werden, wenn ihr Aufbewahrungsschwellenwert erreicht ist, löscht Amazon Data Lifecycle Manager diese Snapshots nicht und verwaltet sie nicht mehr.
Die folgenden Überlegungen gelten für AMI-Richtlinien und den Schutz vor der **[AMI-Abmeldung](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/deregister-ami.html#ami-deregistration-protection)**:
+ Wenn Sie den Abmeldeschutz für ein AMI, das von Amazon Data Lifecycle Manager erstellt wurde, manuell aktivieren und er immer noch aktiviert ist, wenn der AMI-Aufbewahrungsschwellenwert erreicht ist, verwaltet Amazon Data Lifecycle Manager dieses AMI nicht mehr. Sie müssen das AMI manuell deregistrieren und die zugrunde liegenden Snapshots löschen, falls es nicht mehr benötigt wird.
## Weitere Ressourcen
Weitere Informationen finden Sie im Blog [Automating Amazon EBS snapshot and AMI management using Amazon Data Lifecycle Manager](https://aws.amazon.com/blogs/storage/automating-amazon-ebs-snapshot-and-ami-management-using-amazon-dlm/) AWS storage.
# Automatisieren Sie kontenübergreifende Snapshot-Kopien mit Data Lifecycle Manager
Die Automatisierung kontoübergreifender Snapshot-Kopien ermöglicht es Ihnen, Ihre Amazon-EBS-Snapshots in bestimmte Regionen in einem isolierten Konto zu kopieren und diese Snapshots mit einem Verschlüsselungsschlüssel zu verschlüsseln. Auf diese Weise können Sie sich vor Datenverlust schützen, falls Ihr Konto kompromittiert wird.
Die Automatisierung von kontenübergreifenden Snapshots umfasst zwei Konten:
+ **Source account (Quellkonto)**—Das Quellkonto ist das Konto, das die Snapshots erstellt und mit dem Zielkonto teilt. In diesem Konto müssen Sie eine EBS-Snapshot-Richtlinie erstellen, die in festgelegten Intervallen Snapshots erstellt und diese dann mit anderen Konten teilt. AWS
+ **Target account (Zielkonto)**—Das Zielkonto ist das Konto mit dem Zielkonto, für das die Snapshots freigegeben werden, und es ist das Konto, das Kopien der freigegebenen Snapshots erstellt. In diesem Konto müssen Sie eine Richtlinie für kontoübergreifende Kopierereignisse erstellen, die automatisch Snapshots kopiert, die von einem oder mehreren angegebenen Quellkonten mit ihm geteilt werden.
**Anmerkung**
Sowohl die EBS-Snapshot-Richtlinie für das Quellkonto als auch die Richtlinie für kontoübergreifendes Kopieren von Ereignissen für das Zielkonto müssen in derselben Region erstellt werden. AWS Das Zielkonto kann dann bei Bedarf Snapshots in verschiedene Zielregionen kopieren.
**Topics**
+ [Kontoübergreifende Richtlinien für Snapshot-Kopierrichtlinien](#create-cac-policy)
+ [Festlegen von Snapshot-Beschreibungsfiltern](#snapshot-descr-filters)
+ [Überlegungen zu Richtlinien für das kontoübergreifende Kopieren von Snapshots](#event-policy-considerations)
+ [Weitere Ressourcen](#event-additional-resources)
## Kontoübergreifende Richtlinien für Snapshot-Kopierrichtlinien
Um die Quell- und Zielkonten für das kontoübergreifende Snapshot-Kopieren vorzubereiten, müssen Sie die folgenden Schritte ausführen:
**Topics**
### Schritt 1: Erstellen der EBS-Snapshot-Richtlinie (*Source account (Quellkonto)*)
Erstellen Sie im Quellkonto eine EBS-Snapshot-Richtlinie, die die Snapshots erstellt und mit den erforderlichen Zielkonten teilt.
Achten Sie bei der Erstellung der Richtlinie darauf, dass Sie die kontoübergreifende gemeinsame Nutzung aktivieren und die AWS Zielkonten angeben, für die die Snapshots freigegeben werden sollen. Dies sind die Konten, mit denen die Snapshots geteilt werden sollen. Wenn Sie verschlüsselte Snapshots freigeben, müssen Sie den ausgewählten Zielkonten die Berechtigung erteilen, das zum Verschlüsseln des Quell-Volume verwendeten Verschlüsselung zu verwenden. Weitere Informationen finden Sie unter [Schritt 2: Teilen Sie Kundenverwalteter Schlüssel (*Quellkonto*)](#share-cmk).
**Anmerkung**
Erstellen Sie diese Richtlinie in derselben AWS Region, in der Sie in Schritt 3 die Richtlinie für kontenübergreifendes Kopieren von Ereignissen für das Zielkonto erstellen werden. Beide Richtlinien müssen sich in derselben Region befinden, damit das kontoübergreifende Teilen von Snapshots ordnungsgemäß funktioniert.
Sie können nur Snapshots freigeben, die unverschlüsselt oder mit einem Kundenverwalteter Schlüssel verschlüsselt sind. Sie können keine Snapshots freigeben, die mit dem standardmäßigen EBS-Verschlüsselungs-Verschlüsselung verschlüsselt sind. Wenn Sie verschlüsselte Snapshots teilen, müssen Sie auch den Verschlüsselung, der zum Verschlüsseln des Quell-Volumes verwendet wurde, mit den Zielkonten teilen. Weitere Informationen finden Sie unter [Benutzern in anderen Konten die Verwendung eines KMS-Schlüssels erlauben](https://docs.aws.amazon.com//kms/latest/developerguide/key-policy-modifying-external-accounts.html) im *AWS Key Management Service -Entwicklerhandbuch*.
Weitere Informationen zum Erstellen einer EBS-Snapshot-Richtlinie finden Sie unter [Benutzerdefinierte Amazon Data Lifecycle Manager Manager-Richtlinie für EBS-Snapshots erstellen](snapshot-ami-policy.md).
Verwenden Sie eine der folgenden Methoden, um die EBS-Snapshot-Richtlinie zu erstellen.
### Schritt 2: Teilen Sie Kundenverwalteter Schlüssel (*Quellkonto*)
Wenn Sie verschlüsselte Snapshots freigeben, müssen Sie der IAM-Rolle und den Ziel- AWS -Konten (die Sie im vorherigen Schritt ausgewählt haben) Berechtigungen erteilen, um den vom Kunden verwalteten Schlüssel zu verwenden, der zum Verschlüsseln des Quell-Volumes verwendet wurde.
**Anmerkung**
Führen Sie diesen Schritt nur aus, wenn Sie verschlüsselte Snapshots freigeben. Wenn Sie unverschlüsselte Snapshots freigeben, überspringen Sie diesen Schritt.
------
#### [ Console ]
****
1. Öffnen Sie die AWS KMS Konsole unter [https://console.aws.amazon.com/kms](https://console.aws.amazon.com/kms).
1. Um das zu ändern AWS-Region, verwenden Sie die Regionsauswahl in der oberen rechten Ecke der Seite.
1. Wählen Sie im Navigationsbereich **Customer managed key** (Vom Kunden verwalteter Schlüssel) und dann den KMS-Schlüssel aus, den Sie für die Zielkonten freigeben müssen.
Notieren Sie sich den ARN des Verschlüsselung, den Sie später benötigen.
1. Scrollen Sie auf der Registerkarte **Key policy (Schlüsselrichtlinie)** nach unten zum Abschnitt **Key users (Schlüsselbenutzer)**. Wählen Sie **Hinzufügen**, geben Sie den Namen der IAM-Rolle ein, die Sie im vorherigen Schritt ausgewählt haben, und wählen Sie dann **Hinzufügen** aus.
1. Scrollen Sie auf der Registerkarte **Schlüsselrichtlinie** nach unten zum Abschnitt **Andere AWS -Konten**. Wählen **Sie Weitere AWS Konten hinzufügen** und fügen Sie dann alle AWS Zielkonten hinzu, für die Sie die Snapshots im vorherigen Schritt freigegeben haben.
1. Wählen Sie **Änderungen speichern ** aus.
------
#### [ Command line ]
Verwenden Sie den [get-key-policy](https://docs.aws.amazon.com/cli/latest/reference/kms/get-key-policy.html)Befehl, um die Schlüsselrichtlinie abzurufen, die derzeit mit dem KMS-Schlüssel verknüpft ist.
Der folgende Befehl ruft beispielsweise die Schlüsselrichtlinie für ein Verschlüsselung mit einer ID von `9d5e2b3d-e410-4a27-a958-19e220d83a1e` ab und schreibt sie in eine Datei namens `snapshotKey.json`.
```
$ aws kms get-key-policy \
--policy-name default \
--key-id 9d5e2b3d-e410-4a27-a958-19e220d83a1e \
--query Policy \
--output text > snapshotKey.json
```
Öffnen Sie die Schlüsselrichtlinie mit Ihrem bevorzugten Texteditor. Fügen Sie den ARN der IAM-Rolle hinzu, den Sie bei der Erstellung der Snapshot-Richtlinie angegeben haben, und den ARNs der Zielkonten, mit denen der KMS-Schlüssel gemeinsam genutzt werden soll.
In der folgenden Richtlinie haben wir beispielsweise den ARN der IAM-Standardrolle und den ARN des Root-Kontos für das Zielkonto `222222222222.` hinzugefügt
**Tipp**
Um den Grundsatz der Erteilung der geringsten erforderlichen Berechtigungen zu befolgen, lassen Sie den vollständigen Zugriff auf `kms:CreateGrant` nicht zu. Verwenden Sie stattdessen den `kms:GrantIsForAWSResource` Bedingungsschlüssel, damit der Benutzer nur dann Berechtigungen für den KMS-Schlüssel erstellen kann, wenn der Zuschuss im Namen des Benutzers von einem AWS Dienst erstellt wird, wie im folgenden Beispiel gezeigt.
```
{
"Sid" : "Allow use of the key",
"Effect" : "Allow",
"Principal" : {
"AWS" : [
"arn:aws:iam::111111111111:role/service-role/AWSDataLifecycleManagerDefaultRole",
"arn:aws:iam::222222222222:root"
]
},
"Action" : [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource" : "*"
},
{
"Sid" : "Allow attachment of persistent resources",
"Effect" : "Allow",
"Principal" : {
"AWS" : [
"arn:aws:iam::111111111111:role/service-role/AWSDataLifecycleManagerDefaultRole",
"arn:aws:iam::222222222222:root"
]
},
"Action" : [
"kms:CreateGrant",
"kms:ListGrants",
"kms:RevokeGrant"
],
"Resource" : "*",
"Condition" : {
"Bool" : {
"kms:GrantIsForAWSResource" : "true"
}
}
}
```
Speichern und schließen Sie die Datei. Verwenden Sie dann den [put-key-policy](https://docs.aws.amazon.com/cli/latest/reference/kms/put-key-policy.html)Befehl, um die aktualisierte Schlüsselrichtlinie an den KMS-Schlüssel anzuhängen.
```
$ aws kms put-key-policy \
--policy-name default \
--key-id 9d5e2b3d-e410-4a27-a958-19e220d83a1e \
--policy file://snapshotKey.json
```
------
### Schritt 3: Erstellen der Richtlinie für kontoübergreifende Kopierereignisse (*Target Account (Zielkonto)*)
Im Zielkonto müssen Sie eine Richtlinie für kontoübergreifende Kopierereignisse erstellen, die automatisch Snapshots kopiert, die von den erforderlichen Quellkonten freigegeben werden.
Diese Richtlinie wird nur auf dem Zielkonto ausgeführt, wenn eines der angegebenen Quellkonten Snapshots mit dem Konto teilt.
**Anmerkung**
Erstellen Sie diese Richtlinie in derselben AWS Region wie die in Schritt 1 erstellte EBS-Snapshot-Richtlinie des Quellkontos. Beide Richtlinien müssen sich in derselben Region befinden, damit die kontoübergreifende Snapshot-Freigabe ordnungsgemäß funktioniert. Sie können diese Richtlinie dann so konfigurieren, dass Snapshots nach Bedarf in verschiedene Zielregionen kopiert werden.
Verwenden Sie eine der folgenden Methoden, um die Richtlinie für kontoübergreifende Kopierereignisse zu erstellen.
------
#### [ Console ]
1. Öffnen Sie die Amazon-EC2-Konsole unter [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. Wählen Sie im Navigationsbereich **Elastic Block Store** und **Lifecycle Manager** aus. Wählen Sie dann **Create lifecycle policy (Lebenszyklusrichtlinie erstellen)** aus.
1. Wählen Sie auf dem Bildschirm **Richtlinientyp auswählen** die Option **Ereignisrichtlinie für kontoübergreifendes Kopieren** und dann **Weiter** aus.
1. Geben Sie unter **Richtlinienbeschreibung** eine kurze Beschreibung der Richtlinie ein.
1. Fügen Sie für **Richtlinien-Tags** die Tags hinzu, die auf die Lebenszyklusrichtlinie angewendet werden sollen. Sie können diese Tags (Markierungen) verwenden, um Ihre Richtlinien zu identifizieren und zu kategorisieren.
1. Definieren Sie im Abschnitt **Ereigniseinstellungen** das Snapshot-Freigabeereignis, das die Ausführung der Richtlinie bewirkt. Gehen Sie wie folgt vor:
1. Geben Sie für **Sharing-Konten** die AWS Quellkonten an, von denen Sie die geteilten Snapshots kopieren möchten. **Wählen Sie **Konto hinzufügen**, geben Sie die 12-stellige AWS Konto-ID ein und wählen Sie dann Hinzufügen.**
1. Geben Sie für **Snapshot-Beschreibungsfilter** die erforderliche Snapshot-Beschreibung mit einem regulären Ausdruck ein. Nur Snapshots, die von den angegebenen Quellkonten gemeinsam genutzt werden und Beschreibungen haben, die mit dem angegebenen Filter übereinstimmen, werden von der Richtlinie kopiert. Weitere Informationen finden Sie unter [Festlegen von Snapshot-Beschreibungsfiltern](#snapshot-descr-filters).
1. Wählen Sie für die **IAM-Rolle** die IAM-Rolle aus, die über Berechtigungen zum Durchführen der Aktion zum Kopieren von Snapshots verfügt. Um die von Amazon Data Lifecycle Manager bereitgestellte Standardrolle zu verwenden, wählen Sie **Standardrolle**. Um alternativ eine benutzerdefinierte IAM-Rolle zu verwenden, die Sie zuvor erstellt haben, wählen Sie **Andere Rolle auswählen** und dann die zu verwendende Rolle aus.
Wenn Sie verschlüsselte Snapshots kopieren, müssen Sie der ausgewählten IAM-Rolle Berechtigungen zur Verwendung des zur Verschlüsselung des Quell-Volumes verwendeten Verschlüsselungs-Verschlüsselung erteilen. Wenn Sie den Snapshot in der Zielregion mit einem anderen Verschlüsselung verschlüsseln, müssen Sie der IAM-Rolle die Berechtigung zur Verwendung des Ziel-Verschlüsselung erteilen. Weitere Informationen finden Sie unter [Schritt 4: Zulassen, dass IAM-Rolle die erforderlichen KMS-Schlüssel verwendet (*Target Account (Zielkonto)*)](#target_iam-role).
1. Definieren Sie im Abschnitt **Kopieraktion** die Snapshot-Kopieraktionen, die die Richtlinie ausführen soll, wenn sie aktiviert wird. Die Richtlinie kann Snapshots in bis zu drei Regionen kopieren. Sie müssen für jede Zielregion eine separate Kopierregel angeben. Gehen Sie für jede hinzugefügte Regel wie folgt vor:
1. Geben Sie unter **Name** einen aussagekräftigen Namen für die Kopieraktion ein.
1. Wählen Sie für **Target Region (Zielregion)** die Region aus, in die Sie die Snapshots kopieren möchten.
1. Geben Sie unter **Ablauf** an, wie lange die Snapshot-Kopien nach der Erstellung in der Zielregion aufbewahrt werden sollen.
1. Um die Snapshot-Kopie zu verschlüsseln, wählen Sie für **Verschlüsselung** die Option **Verschlüsselung aktivieren** aus. Wenn der Quell-Snapshot verschlüsselt ist oder wenn die Verschlüsselung standardmäßig für Ihr Konto aktiviert ist, wird die Snapshot-Kopie immer verschlüsselt, selbst wenn Sie hier keine Verschlüsselung aktivieren. Wenn der Quell-Snapshot unverschlüsselt ist und die Verschlüsselung für Ihr Konto standardmäßig nicht aktiviert ist, können Sie die Verschlüsselung aktivieren oder deaktivieren. Wenn Sie die Verschlüsselung aktivieren, aber keinVerschlüsselung angeben, werden die Snapshots in jeder Zielregion mit dem Standardverschlüsselungs-Verschlüsselung verschlüsselt. Wenn Sie einenVerschlüsselung für die Zielregion angeben, müssen Sie Zugriff auf den Verschlüsselung haben.
1. Um zusätzliche Snapshot-Kopieraktionen hinzuzufügen, wählen Sie **Neue Regionen hinzufügen**.
1. Wählen Sie für **Richtlinienstatus nach der Erstellung** die Option **Richtlinie aktivieren**, um die Ausführungen der Richtlinie zum nächsten eingeplanten Zeitpunkt zu starten oder **Richtlinie deaktivieren**, um zu verhindern, dass die Richtlinie ausgeführt wird. Wenn Sie die Richtlinie jetzt nicht aktivieren, beginnt sie erst mit dem Kopieren von Snapshots, wenn Sie sie nach der Erstellung manuell aktivieren.
1. Wählen Sie **Richtlinie erstellen** aus.
------
#### [ Command line ]
Verwenden Sie den [create-lifecycle-policy](https://docs.aws.amazon.com/cli/latest/reference/dlm/create-lifecycle-policy.html)Befehl, um eine Richtlinie zu erstellen. Um eine Richtlinie für kontoübergreifende Kopierereignisse `PolicyType` zu erstellen, geben Sie `EVENT_BASED_POLICY` an.
Mit dem folgenden Befehl wird beispielsweise eine Richtlinie für kontoübergreifende Kopierereignisse im Zielkonto `222222222222` erstellt. Die Richtlinie kopiert Snapshots, die vom Quellkonto `111111111111` freigegeben werden. Die Richtlinie kopiert Snapshots nach `sa-east-1` und `eu-west-2`. Snapshots, die in `sa-east-1` kopiert wurden, sind unverschlüsselt und werden 3 Tage lang aufbewahrt. Snapshots, die in `eu-west-2` kopiert werden, werden mit Verschlüsselung `8af79514-350d-4c52-bac8-8985e84171c7` verschlüsselt und 1 Monat lang aufbewahrt. Die Richtlinie verwendet die Standard-IAM-Rolle.
```
$ aws dlm create-lifecycle-policy \
--description "Copy policy" \
--state ENABLED \
--execution-role-arn arn:aws:iam::222222222222:role/service-role/AWSDataLifecycleManagerDefaultRole \
--policy-details file://policyDetails.json
```
Im Folgenden werden die Inhalte der `policyDetails.json`-Datei angezeigt.
```
{
"PolicyType" : "EVENT_BASED_POLICY",
"EventSource" : {
"Type" : "MANAGED_CWE",
"Parameters": {
"EventType" : "shareSnapshot",
"SnapshotOwner": ["111111111111"]
}
},
"Actions" : [{
"Name" :"Copy Snapshot to Sao Paulo and London",
"CrossRegionCopy" : [{
"Target" : "sa-east-1",
"EncryptionConfiguration" : {
"Encrypted" : false
},
"RetainRule" : {
"Interval" : 3,
"IntervalUnit" : "DAYS"
}
},
{
"Target" : "eu-west-2",
"EncryptionConfiguration" : {
"Encrypted" : true,
"CmkArn" : "arn:aws:kms:eu-west-2:222222222222:key/8af79514-350d-4c52-bac8-8985e84171c7"
},
"RetainRule" : {
"Interval" : 1,
"IntervalUnit" : "MONTHS"
}
}]
}]
}
```
Wenn die Anforderung erfolgreich ist, gibt der Befehl die ID der neu erstellten Richtlinie zurück. Es folgt eine Beispielausgabe.
```
{
"PolicyId": "policy-9876543210abcdef0"
}
```
------
### Schritt 4: Zulassen, dass IAM-Rolle die erforderlichen KMS-Schlüssel verwendet (*Target Account (Zielkonto)*)
Wenn Sie verschlüsselte Snapshots kopieren, müssen Sie der IAM-Rolle (die Sie im vorherigen Schritt ausgewählt haben) Berechtigungen erteilen, den Kundenverwalteter Schlüssel zu verwenden, der zur Verschlüsselung des Quell-Volumes verwendet wurde.
**Anmerkung**
Führen Sie diesen Schritt nur aus, wenn Sie verschlüsselte Snapshots kopieren. Wenn Sie unverschlüsselte Snapshots kopieren, überspringen Sie diesen Schritt.
Verwenden Sie eine der folgenden Methoden, um die erforderlichen Richtlinien zur IAM-Rolle hinzuzufügen.
------
#### [ Console ]
****
1. Öffnen Sie unter [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) die IAM-Konsole.
1. Wählen Sie im Navigationsbereich die Option **Roles (Rollen)** aus. Suchen Sie nach der IAM-Rolle, die Sie beim Erstellen der Richtlinie für kontoübergreifende Kopierereignisse im vorherigen Schritt ausgewählt haben, und wählen Sie sie aus. Wenn Sie sich für die Verwendung der Standardrolle entschieden haben, wird die Rolle benannt **AWSDataLifecycleManagerDefaultRole**.
1. Wählen Sie **Add inline policy (Inline-Richtlinie hinzufügen)** und anschließend die Registerkarte **JSON**.
1. Ersetzen Sie die vorhandene Richtlinie durch die folgende und geben Sie den ARN des KMS-Schlüssels an, mit dem die Quell-Volumes verschlüsselt wurden und der vom Quellkonto in Schritt 2 für Sie freigegeben wurde.
**Anmerkung**
Wenn Sie von mehreren Quellkonten kopieren, müssen Sie den entsprechenden KMS-Schlüssel-ARN jedes Quellkontos angeben.
Im folgenden Beispiel gewährt die Richtlinie der IAM-Rolle die Berechtigung, Verschlüsselung `1234abcd-12ab-34cd-56ef-1234567890ab` zu verwenden, das vom Quellkonto `111111111111` freigegeben wurde, und Verschlüsselung `4567dcba-23ab-34cd-56ef-0987654321yz`, das im Zielkonto `222222222222` vorhanden ist.
**Tipp**
Um den Grundsatz der Erteilung der geringsten erforderlichen Berechtigungen zu befolgen, lassen Sie den vollständigen Zugriff auf `kms:CreateGrant` nicht zu. Verwenden Sie stattdessen den `kms:GrantIsForAWSResource` Bedingungsschlüssel, damit der Benutzer nur dann Zuschüsse für den KMS-Schlüssel erstellen kann, wenn der Zuschuss im Namen des Benutzers von einem AWS Dienst erstellt wird, wie im folgenden Beispiel gezeigt.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kms:RevokeGrant",
"kms:CreateGrant",
"kms:ListGrants"
],
"Resource": [
"arn:aws:kms:us-east-1:111111111111:key/1234abcd-12ab-34cd-56ef-1234567890ab",
"arn:aws:kms:us-east-1:222222222222:key/4567dcba-23ab-34cd-56ef-0987654321yz"
],
"Condition": {
"Bool": {
"kms:GrantIsForAWSResource": "true"
}
}
},
{
"Effect": "Allow",
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": [
"arn:aws:kms:us-east-1:111111111111:key/1234abcd-12ab-34cd-56ef-1234567890ab",
"arn:aws:kms:us-east-1:222222222222:key/4567dcba-23ab-34cd-56ef-0987654321yz"
]
}
]
}
```
------
1. Wählen Sie **Review policy** (Richtlinie überprüfen) aus.
1. Geben Sie unter **Name** einen beschreibenden Namen für die Richtlinie ein, und wählen Sie dann **Create policy (Richtlinie erstellen)**.
------
#### [ Command line ]
Erstellen Sie mit Ihrem bevorzugten Texteditor eine neue JSON-Datei mit dem Namen `policyDetails.json`. Fügen Sie die folgende Richtlinie hinzu und geben Sie den ARN des KMS-Schlüssels an, mit dem die Quell-Volumes verschlüsselt wurden und der vom Quellkonto in Schritt 2 für Sie freigegeben wurde.
**Anmerkung**
Wenn Sie von mehreren Quellkonten kopieren, müssen Sie den entsprechenden KMS-Schlüssel-ARN jedes Quellkontos angeben.
Im folgenden Beispiel gewährt die Richtlinie der IAM-Rolle die Berechtigung, Verschlüsselung `1234abcd-12ab-34cd-56ef-1234567890ab` zu verwenden, das vom Quellkonto `111111111111` freigegeben wurde, und Verschlüsselung `4567dcba-23ab-34cd-56ef-0987654321yz`, das im Zielkonto `222222222222` vorhanden ist.
**Tipp**
Um den Grundsatz der Erteilung der geringsten erforderlichen Berechtigungen zu befolgen, lassen Sie den vollständigen Zugriff auf `kms:CreateGrant` nicht zu. Verwenden Sie stattdessen den `kms:GrantIsForAWSResource` Bedingungsschlüssel, damit der Benutzer nur dann Zuschüsse für den KMS-Schlüssel erstellen kann, wenn der Zuschuss im Namen des Benutzers von einem AWS Dienst erstellt wird, wie im folgenden Beispiel gezeigt.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kms:RevokeGrant",
"kms:CreateGrant",
"kms:ListGrants"
],
"Resource": [
"arn:aws:kms:us-east-1:111111111111:key/1234abcd-12ab-34cd-56ef-1234567890ab",
"arn:aws:kms:us-east-1:222222222222:key/4567dcba-23ab-34cd-56ef-0987654321yz"
],
"Condition": {
"Bool": {
"kms:GrantIsForAWSResource": "true"
}
}
},
{
"Effect": "Allow",
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": [
"arn:aws:kms:us-east-1:111111111111:key/1234abcd-12ab-34cd-56ef-1234567890ab",
"arn:aws:kms:us-east-1:222222222222:key/4567dcba-23ab-34cd-56ef-0987654321yz"
]
}
]
}
```
------
Speichern und schließen Sie die Datei. Verwenden Sie dann den [put-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-policy.html)Befehl, um die Richtlinie zur IAM-Rolle hinzuzufügen.
Beispiel
```
$ aws iam put-role-policy \
--role-name AWSDataLifecycleManagerDefaultRole \
--policy-name CopyPolicy \
--policy-document file://AdminPolicy.json
```
------
## Festlegen von Snapshot-Beschreibungsfiltern
Wenn Sie die Richtlinie für Snapshot-Kopien im Zielkonto erstellen, müssen Sie einen Snapshot-Beschreibungsfilter angeben. Mit dem Snapshot-Beschreibungsfilter können Sie eine zusätzliche Filterstufe angeben, mit der Sie steuern können, welche Snapshots von der Richtlinie kopiert werden. Dies bedeutet, dass ein Snapshot nur von der Richtlinie kopiert wird, wenn er von einem der angegebenen Quellkonten gemeinsam genutzt wird, und eine Snapshot-Beschreibung hat, die dem angegebenen Filter entspricht. Mit anderen Worten, wenn ein Snapshot von einem der angegebenen Kurskonten geteilt wird, aber keine Beschreibung hat, die dem angegebenen Filter entspricht, wird er nicht von der Richtlinie kopiert.
Die Beschreibung des Snapshot-Filters muss mit einem regulären Ausdruck angegeben werden. Dies ist ein Pflichtfeld beim Erstellen von Richtlinien für kontoübergreifende Kopierereignisse mit der Konsole und der Befehlszeile. Im Folgenden finden Sie reguläre Beispielausdrücke, die verwendet werden können:
+ `.*`—Dieser Filter entspricht allen Snapshot-Beschreibungen. Wenn Sie diesen Ausdruck verwenden, kopiert die Richtlinie alle Snapshots, die von einem der angegebenen Quellkonten gemeinsam genutzt werden.
+ `Created for policy: policy-0123456789abcdef0.*`—Dieser Filter stimmt nur mit Snapshots überein, die von einer Richtlinie mit der ID `policy-0123456789abcdef0` erstellt wurden. Wenn Sie einen Ausdruck wie diesen verwenden, werden nur Snapshots, die von einem der angegebenen Quellkonten mit Ihrem Konto geteilt werden und die von einer Richtlinie mit der angegebenen ID erstellt wurden, von der Richtlinie kopiert.
+ `.*production.*`—Dieser Filter entspricht jedem Snapshot, der das Wort `production` irgendwo in seiner Beschreibung enthält. Wenn Sie diesen Ausdruck verwenden, kopiert die Richtlinie alle Snapshots, die von einem der angegebenen Quellkonten gemeinsam genutzt werden und die den angegebenen Text in ihrer Beschreibung enthalten.
## Überlegungen zu Richtlinien für das kontoübergreifende Kopieren von Snapshots
Die folgenden Überlegungen gelten für Richtlinien für kontoübergreifende Kopierereignisse:
+ Die EBS-Snapshot-Richtlinie für das Quellkonto und die Richtlinie für das kontoübergreifende Kopieren von Ereignissen für das Zielkonto müssen in derselben Region erstellt werden. AWS Nachdem der Snapshot gemeinsam genutzt wurde, kann die Zielkonto-Richtlinie den Snapshot in verschiedene Zielregionen kopieren, wie in den Kopieraktionen angegeben.
+ Sie können nur Snapshots kopieren, die unverschlüsselt oder mit einem Kundenverwalteter Schlüssel verschlüsselt sind.
+ Sie können eine Richtlinie für kontoübergreifende Kopierereignisse erstellen, um Snapshots zu kopieren, die außerhalb von Amazon Data Lifecycle Manager freigegeben werden.
+ Wenn Sie Snapshots im Zielkonto verschlüsseln möchten, muss die IAM-Rolle, die für die Richtlinie für kontoübergreifende Kopierereignisse ausgewählt wurde, über die Berechtigung verfügen, den erforderlichen Verschlüsselung zu verwenden.
## Weitere Ressourcen
Weitere Informationen finden Sie im Blog [Automatisieren des Kopierens verschlüsselter Amazon EBS-Snapshots im gesamten AWSAWS Kontospeicher](https://aws.amazon.com/blogs/storage/automating-copying-encrypted-amazon-ebs-snapshots-across-aws-accounts/).
# Amazon Data Lifecycle Manager Manager-Richtlinien ändern
Beachten Sie Folgendes, wenn Sie die Amazon Data Lifecycle Manager Manager-Richtlinien ändern:
+ Wenn Sie eine AMI- oder Snapshot-Richtlinie ändern, indem Sie ihre Ziel-Tags (Markierungen) entfernen, werden die Volumes oder Instances mit diesen Tags (Markierungen) nicht mehr von der Richtlinie verwaltet.
+ Wenn Sie einen Zeitplannamen ändern, werden die Snapshots oder die unter dem alten Namen des Zeitplans AMIs erstellten Snapshots nicht mehr von der Richtlinie verwaltet.
+ Wenn Sie einen altersbasierten Aufbewahrungszeitplan so ändern, dass er ein neues Zeitintervall verwendet, wird das neue Intervall nur für neue Snapshots verwendet oder erst nach der Änderung AMIs erstellt. Der neue Zeitplan hat keinen Einfluss auf den Aufbewahrungszeitplan für Snapshots oder Snapshots, die vor der Änderung AMIs erstellt wurden.
+ Sie können den Aufbewahrungszeitplan einer Richtlinie nach der Erstellung nicht von anzahlbasiert auf altersbasiert ändern. Um diese Änderung vorzunehmen, müssen Sie eine neue Richtlinie anlegen.
+ Wenn Sie eine Richtlinie mit einem altersbasierten Aufbewahrungszeitplan deaktivieren, werden die Snapshots oder die Snapshots AMIs , die bei deaktivierter Richtlinie ablaufen, auf unbestimmte Zeit aufbewahrt. Sie müssen die Snapshots löschen oder die Registrierung manuell aufheben. AMIs Wenn Sie die Richtlinie wieder aktivieren, setzt Amazon Data Lifecycle Manager das Löschen von Snapshots oder die Abmeldung AMIs fort, wenn deren Aufbewahrungsfristen ablaufen.
+ Wenn Sie eine Richtlinie mit einem auf der Anzahl basierenden Aufbewahrungszeitplan deaktivieren, beendet die Richtlinie das Erstellen und Löschen von Snapshots oder. AMIs Wenn Sie die Richtlinie erneut aktivieren, setzt Amazon Data Lifecycle Manager die Erstellung von Snapshots fort und setzt das Löschen von Snapshots fort AMIs, oder wenn der Aufbewahrungsschwellenwert AMIs erreicht ist.
+ Wenn Sie eine Richtlinie deaktivieren, für die eine Snapshot-Archivierung aktiviert ist, werden Snapshots, die sich zum Zeitpunkt der Deaktivierung der Richtlinie auf der Archivstufe befinden, nicht mehr von Amazon Data Lifecycle Manager verwaltet. Sie müssen die Snapshots manuell löschen, wenn sie nicht mehr benötigt werden.
+ Wenn Sie die Snapshot-Archivierung nach einem anzahlbasierten Zeitplan aktivieren, gilt die Archivierungsregel für alle neuen Snapshots, die nach dem Zeitplan erstellt und archiviert werden. Sie gilt auch für vorhandene Snapshots, die zuvor nach dem Zeitplan erstellt und archiviert wurden.
+ Wenn Sie die Snapshot-Archivierung nach einem altersbasierten Zeitplan aktivieren, gilt die Archivierungsregel nur für neue Snapshots, die nach Aktivierung der Snapshot-Archivierung erstellt werden. Vorhandene Snapshots, die vor der Aktivierung der Snapshot-Archivierung erstellt wurden, werden weiterhin gemäß dem Zeitplan, der bei der ursprünglichen Erstellung und Archivierung dieser Snapshots galt, aus den entsprechenden Speicherstufen gelöscht.
+ Wenn Sie die Snapshot-Archivierung für einen anzahlbasierten Zeitplan deaktivieren, wird die Archivierung von Snapshots umgehend gestoppt. Snapshots, die zuvor nach dem Zeitplan archiviert wurden, verbleiben auf der Archivstufe und werden von Amazon Data Lifecycle Manager nicht gelöscht.
+ Wenn Sie die Snapshot-Archivierung für einen altersbasierten Zeitplan deaktivieren, werden die durch die Richtlinie erstellten Snapshots, deren Archivierung geplant ist, zum geplanten Archivierungsdatum und zur geplanten Archivierungszeit dauerhaft gelöscht, wie vom System-Tag `aws:dlm:expirationTime` angegeben.
+ Wenn Sie die Snapshot-Archivierung für einen Zeitplan deaktivieren, wird die Archivierung von Snapshots umgehend gestoppt. Snapshots, die zuvor nach dem Zeitplan archiviert wurden, verbleiben auf der Archivstufe und werden von Amazon Data Lifecycle Manager nicht gelöscht.
+ Wenn Sie die Archivaufbewahrungsanzahl für einen anzahlbasierten Zeitplan ändern, umfasst die neue Aufbewahrungsanzahl vorhandene Snapshots, die zuvor nach dem Zeitplan archiviert wurden.
+ Wenn Sie den Archivaufbewahrungszeitraum für einen altersbasierten Zeitplan ändern, gilt der neue Aufbewahrungszeitraum nur für Snapshots, die nach dem Ändern der Aufbewahrungsregel archiviert werden.
Verwenden Sie eines der folgenden Verfahren, um eine Lebenszyklusrichtlinie zu ändern.
------
#### [ Console ]
**Ändern einer Lebenszyklus-Richtlinie**
1. Öffnen Sie die Amazon-EC2-Konsole unter [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. Wählen Sie im Navigationsbereich **Elastic Block Store**, **Lifecycle Manager** aus.
1. Wählen Sie eine Lebenszyklus-Richtlinie aus der Liste aus.
1. Wählen Sie **Aktionen**, **Lebenszyklusrichtlinie ändern**.
1. Ändern Sie die Richtlinieneinstellungen nach Bedarf. Sie können beispielsweise den Zeitplan ändern, Tags (Markierungen) hinzufügen oder entfernen oder die Richtlinie aktivieren oder deaktivieren.
1. Wählen Sie **Richtlinie ändern** aus.
------
#### [ Command line ]
Verwenden Sie den [update-lifecycle-policy](https://docs.aws.amazon.com/cli/latest/reference/dlm/update-lifecycle-policy.html)Befehl, um die Informationen in einer Lebenszyklus-Richtlinie zu ändern. Um die Syntax zu vereinfachen, wird in diesem Beispiel eine JSON-Datei, `policyDetailsUpdated.json`, referenziert, die die Richtliniendetails enthält.
```
aws dlm update-lifecycle-policy \
--state DISABLED \
--execution-role-arn arn:aws:iam::12345678910:role/AWSDataLifecycleManagerDefaultRole" \
--policy-details file://policyDetailsUpdated.json
```
Das folgende Beispiel zeigt eine `policyDetailsUpdated.json`-Datei.
```
{
"ResourceTypes":[
"VOLUME"
],
"TargetTags":[
{
"Key": "costcenter",
"Value": "120"
}
],
"Schedules":[
{
"Name": "DailySnapshots",
"TagsToAdd": [
{
"Key": "type",
"Value": "myDailySnapshot"
}
],
"CreateRule": {
"Interval": 12,
"IntervalUnit": "HOURS",
"Times": [
"15:00"
]
},
"RetainRule": {
"Count" :5
},
"CopyTags": false
}
]
}
```
Verwenden Sie den Befehl `get-lifecycle-policy`, um die aktualisierte Richtlinie anzuzeigen. Sie sehen, dass der Status, der Wert des Tags (Markierung), das Snapshot-Intervall und die Snapshot-Startzeit geändert wurden.
------
# Amazon Data Lifecycle Manager Manager-Richtlinien löschen
Beachten Sie beim Löschen von Amazon Data Lifecycle Manager Manager-Richtlinien Folgendes:
+ Wenn Sie eine Richtlinie löschen, werden die Snapshots oder die mit dieser Richtlinie AMIs erstellten Snapshots nicht automatisch gelöscht. Wenn Sie die Snapshots nicht mehr benötigen oder AMIs müssen Sie sie manuell löschen.
+ Wenn Sie eine Richtlinie löschen, für die eine Snapshot-Archivierung aktiviert ist, werden Snapshots, die sich zum Zeitpunkt des Löschens der Richtlinie auf der Archivstufe befinden, nicht mehr von Amazon Data Lifecycle Manager verwaltet. Sie müssen die Snapshots manuell löschen, wenn sie nicht mehr benötigt werden.
+ Wenn Sie eine Richtlinie mit einem für die Archivierung aktivierten, altersbasierten Zeitplan löschen, werden die durch die Richtlinie erstellten Snapshots, deren Archivierung geplant ist, zum geplanten Archivierungsdatum und zur geplanten Archivierungszeit dauerhaft gelöscht, wie vom System-Tag `aws:dlm:expirationtime` angegeben.
Verwenden Sie eines der folgenden Verfahren, um eine Lebenszyklusrichtlinie zu löschen.
------
#### [ Console ]
**So löschen Sie eine Lebenszyklus-Richtlinie**
1. Öffnen Sie die Amazon-EC2-Konsole unter [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. Wählen Sie im Navigationsbereich **Elastic Block Store**, **Lifecycle Manager** aus.
1. Wählen Sie eine Lebenszyklus-Richtlinie aus der Liste aus.
1. Wählen Sie **Aktionen**, **Lebenszyklusrichtlinie löschen**.
1. Wenn Sie zur Bestätigung aufgefordert werden, wählen Sie **Richtlinie löschen**.
------
#### [ Command line ]
Verwenden Sie den [delete-lifecycle-policy](https://docs.aws.amazon.com/cli/latest/reference/dlm/delete-lifecycle-policy.html)Befehl, um eine Lebenszyklusrichtlinie zu löschen und die in der Richtlinie angegebenen Ziel-Tags für die Wiederverwendung freizugeben.
**Anmerkung**
Sie können Snapshots löschen, die nur von Amazon Data Lifecycle Manager erstellt wurden.
```
aws dlm delete-lifecycle-policy --policy-id policy-0123456789abcdef0
```
------
Die [Amazon Data Lifecycle Manager-API-Referenz](https://docs.aws.amazon.com/dlm/latest/APIReference/) enthält Beschreibungen und die Syntax für die einzelnen Aktionen und Datentypen der Amazon Data Lifecycle Manager-Abfrage-API.
Alternativ können Sie eine der verwenden, AWS SDKs um auf die API zuzugreifen, die auf die von Ihnen verwendete Programmiersprache oder Plattform zugeschnitten ist. Weitere Informationen finden Sie unter [AWS SDKs](https://aws.amazon.com/developer/tools/).
# Steuern Sie den Zugriff auf Amazon Data Lifecycle Manager mithilfe von IAM
Für den Zugriff auf Amazon Data Lifecycle Manager sind Anmeldeinformationen erforderlich. Diese Anmeldeinformationen müssen über Berechtigungen für den Zugriff auf AWS Ressourcen wie Instances, Volumes, Snapshots und verfügen. AMIs
Die folgenden IAM-Berechtigungen sind für die Verwendung von Amazon Data Lifecycle Manager erforderlich.
**Anmerkung**
Die Berechtigungen `ec2:DescribeAvailabilityZones`, `ec2:DescribeRegions`, `kms:ListAliases` und `kms:DescribeKey` sind nur für Konsolenbenutzer erforderlich. Wenn kein Konsolenzugriff erforderlich ist, können Sie die Berechtigungen entfernen.
Das ARN-Format der *AWSDataLifecycleManagerDefaultRole*Rolle unterscheidet sich je nachdem, ob sie mit der Konsole oder der erstellt wurde AWS CLI. Wenn die Rolle mit der Konsole erstellt wurde, lautet das ARN-Format `arn:aws:iam::account_id:role/service-role/AWSDataLifecycleManagerDefaultRole`. Wenn die Rolle mit dem erstellt wurde AWS CLI, ist das ARN-Format`arn:aws:iam::account_id:role/AWSDataLifecycleManagerDefaultRole`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "dlm:*",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": [
"arn:aws:iam::111122223333:role/AWSDataLifecycleManagerDefaultRole",
"arn:aws:iam::111122223333:role/AWSDataLifecycleManagerDefaultRoleForAMIManagement",
"arn:aws:iam::111122223333:role/service-role/AWSDataLifecycleManagerDefaultRole",
"arn:aws:iam::111122223333:role/service-role/AWSDataLifecycleManagerDefaultRoleForAMIManagement"
]
},
{
"Effect": "Allow",
"Action": "iam:ListRoles",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:DescribeAvailabilityZones",
"ec2:DescribeRegions",
"kms:ListAliases",
"kms:DescribeKey"
],
"Resource": "*"
}
]
}
```
------
**Berechtigungen für die Verschlüsselung**
Berücksichtigen Sie Folgendes, wenn Sie mit Amazon Data Lifecycle Manager und verschlüsselten Ressourcen arbeiten.
+ Wenn das Quell-Volume verschlüsselt ist, stellen Sie sicher, dass die Standardrollen (**AWSDataLifecycleManagerDefaultRole**und **AWSDataLifecycleManagerDefaultRoleForAMIManagement**) von Amazon Data Lifecycle Manager berechtigt sind, die KMS-Schlüssel zu verwenden, die zur Verschlüsselung des Volumes verwendet werden.
+ Wenn Sie **regionsübergreifendes Kopieren** für unverschlüsselte oder durch unverschlüsselte Snapshots AMIs gesicherte Snapshots aktivieren und sich dafür entscheiden, die Verschlüsselung in der Zielregion zu aktivieren, stellen Sie sicher, dass die Standardrollen berechtigt sind, den KMS-Schlüssel zu verwenden, der für die Verschlüsselung in der Zielregion erforderlich ist.
+ Wenn Sie **regionsübergreifendes Kopieren** für verschlüsselte oder durch verschlüsselte Snapshots AMIs gesicherte Snapshots aktivieren, stellen Sie sicher, dass die Standardrollen berechtigt sind, sowohl den Quell- als auch den Ziel-KMS-Schlüssel zu verwenden.
+ Wenn Sie die Snapshot-Archivierung für verschlüsselte Snapshots aktivieren, stellen Sie sicher, dass die Amazon Data Lifecycle Manager Manager-Standardrolle () berechtigt **AWSDataLifecycleManagerDefaultRole**ist, den KMS-Schlüssel zu verwenden, der zur Verschlüsselung des Snapshots verwendet wird.
Weitere Informationen finden Sie unter [Benutzern in anderen Konten die Verwendung eines KMS-Schlüssels erlauben](https://docs.aws.amazon.com//kms/latest/developerguide/key-policy-modifying-external-accounts.html) im *AWS Key Management Service -Entwicklerhandbuch*.
Weitere Informationen finden Sie unter [Ändern von Berechtigungen für einen Benutzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html) im *IAM-Benutzerhandbuch*.
# AWS verwaltete Richtlinien für Amazon Data Lifecycle Manager
Eine AWS verwaltete Richtlinie ist eine eigenständige Richtlinie, die von erstellt und verwaltet AWS wird. AWS Verwaltete Richtlinien dienen dazu, Berechtigungen für viele gängige Anwendungsfälle bereitzustellen. AWS Mit verwalteten Richtlinien können Sie Benutzern, Gruppen und Rollen die entsprechenden Berechtigungen effizienter zuweisen, als wenn Sie die Richtlinien selbst schreiben müssten.
Sie können die in AWS verwalteten Richtlinien definierten Berechtigungen jedoch nicht ändern. AWS aktualisiert gelegentlich die in einer AWS verwalteten Richtlinie definierten Berechtigungen. Diese Aktualisierung wirkt sich auf alle Prinzipal-Entitäten (Benutzer, Gruppen und Rollen) aus, an die die Richtlinie angefügt ist.
Amazon Data Lifecycle Manager bietet AWS verwaltete Richtlinien für allgemeine Anwendungsfälle. Diese Richtlinien erleichtern die Definition der geeigneten Berechtigungen und die Steuerung des Zugriffs auf Ihre Ressourcen. Die von Amazon Data Lifecycle Manager bereitgestellten AWS verwalteten Richtlinien sind so konzipiert, dass sie Rollen zugeordnet werden können, die Sie an Amazon Data Lifecycle Manager übergeben.
**Topics**
+ [AWSDataLifecycleManagerServiceRole](#AWSDataLifecycleManagerServiceRole)
+ [AWSDataLifecycleManagerServiceRoleForAMIManagement](#AWSDataLifecycleManagerServiceRoleForAMIManagement)
+ [AWSDataLifecycleManagerSSMFullZugriff](#AWSDataLifecycleManagerSSMFullAccess)
+ [AWS verwaltete Richtlinienaktualisierungen](#policy-update)
## AWSDataLifecycleManagerServiceRole
Die **AWSDataLifecycleManagerServiceRole**Richtlinie gewährt Amazon Data Lifecycle Manager die entsprechenden Berechtigungen zur Erstellung und Verwaltung von Amazon EBS-Snapshot-Richtlinien und Richtlinien für kontoübergreifendes Kopieren von Ereignissen.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:CreateSnapshot",
"ec2:CreateSnapshots",
"ec2:DeleteSnapshot",
"ec2:DescribeInstances",
"ec2:DescribeVolumes",
"ec2:DescribeSnapshots",
"ec2:EnableFastSnapshotRestores",
"ec2:DescribeFastSnapshotRestores",
"ec2:DisableFastSnapshotRestores",
"ec2:CopySnapshot",
"ec2:ModifySnapshotAttribute",
"ec2:DescribeSnapshotAttribute",
"ec2:ModifySnapshotTier",
"ec2:DescribeSnapshotTierStatus",
"ec2:DescribeAvailabilityZones"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": "arn:aws:ec2:*::snapshot/*"
},
{
"Effect": "Allow",
"Action": [
"events:PutRule",
"events:DeleteRule",
"events:DescribeRule",
"events:EnableRule",
"events:DisableRule",
"events:ListTargetsByRule",
"events:PutTargets",
"events:RemoveTargets"
],
"Resource": "arn:aws:events:*:*:rule/AwsDataLifecycleRule.managed-cwe.*"
}
]
}
```
------
## AWSDataLifecycleManagerServiceRoleForAMIManagement
Die **AWSDataLifecycleManagerServiceRoleForAMIManagement**Richtlinie gewährt Amazon Data Lifecycle Manager die entsprechenden Berechtigungen zur Erstellung und Verwaltung von Amazon EBS-backed AMI AMI-Richtlinien.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:CreateTags",
"Resource": [
"arn:aws:ec2:*::snapshot/*",
"arn:aws:ec2:*::image/*"
]
},
{
"Effect": "Allow",
"Action": [
"ec2:DescribeImages",
"ec2:DescribeInstances",
"ec2:DescribeImageAttribute",
"ec2:DescribeVolumes",
"ec2:DescribeSnapshots"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "ec2:DeleteSnapshot",
"Resource": "arn:aws:ec2:*::snapshot/*"
},
{
"Effect": "Allow",
"Action": [
"ec2:ResetImageAttribute",
"ec2:DeregisterImage",
"ec2:CreateImage",
"ec2:CopyImage",
"ec2:ModifyImageAttribute"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:EnableImageDeprecation",
"ec2:DisableImageDeprecation"
],
"Resource": "arn:aws:ec2:*::image/*"
}
]
}
```
------
## AWSDataLifecycleManagerSSMFullZugriff
Berechtigt Amazon Data Lifecycle Manager dazu, die Systems-Manager-Aktionen auszuführen, die für die Ausführung von Vor- und Nach-Skripten auf allen Amazon-EC2-Instances erforderlich sind.
**Wichtig**
Die Richtlinie verwendet den Bedingungsschlüssel `aws:ResourceTag`, um den Zugriff auf bestimmte SSM-Dokumente einzuschränken, wenn Vor- und Nach-Skripte verwendet werden. Damit Amazon Data Lifecycle Manager auf die SSM-Dokumente zugreifen kann, müssen Sie sicherstellen, dass Ihre SSM-Dokumente das Tag `DLMScriptsAccess:true` enthalten.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowSSMReadOnlyAccess",
"Effect": "Allow",
"Action": [
"ssm:GetCommandInvocation",
"ssm:ListCommands",
"ssm:DescribeInstanceInformation"
],
"Resource": "*"
},
{
"Sid": "AllowTaggedSSMDocumentsOnly",
"Effect": "Allow",
"Action": [
"ssm:SendCommand",
"ssm:DescribeDocument",
"ssm:GetDocument"
],
"Resource": [
"arn:aws:ssm:*:*:document/*"
],
"Condition": {
"StringEquals": {
"aws:ResourceTag/DLMScriptsAccess": "true"
}
}
},
{
"Sid": "AllowSpecificAWSOwnedSSMDocuments",
"Effect": "Allow",
"Action": [
"ssm:SendCommand",
"ssm:DescribeDocument",
"ssm:GetDocument"
],
"Resource": [
"arn:aws:ssm:*:*:document/AWSEC2-CreateVssSnapshot",
"arn:aws:ssm:*:*:document/AWSSystemsManagerSAP-CreateDLMSnapshotForSAPHANA"
]
},
{
"Sid": "AllowAllEC2Instances",
"Effect": "Allow",
"Action": [
"ssm:SendCommand"
],
"Resource": [
"arn:aws:ec2:*:*:instance/*"
]
}
]
}
```
------
## AWS verwaltete Richtlinienaktualisierungen
AWS Dienste verwalten und aktualisieren AWS verwaltete Richtlinien. Sie können die Berechtigungen in AWS verwalteten Richtlinien nicht ändern. Dienste fügen einer AWS verwalteten Richtlinie gelegentlich zusätzliche Berechtigungen hinzu, um neue Funktionen zu unterstützen. Diese Art von Update betrifft alle Identitäten (Benutzer, Gruppen und Rollen), an welche die Richtlinie angehängt ist. Es ist sehr wahrscheinlich, dass Dienste eine AWS verwaltete Richtlinie aktualisieren, wenn eine neue Funktion eingeführt wird oder wenn neue Operationen verfügbar werden. Dienste entfernen keine Berechtigungen aus einer AWS verwalteten Richtlinie, sodass durch Richtlinienaktualisierungen Ihre bestehenden Berechtigungen nicht beeinträchtigt werden.
Die folgende Tabelle enthält Einzelheiten zu den Aktualisierungen der AWS verwalteten Richtlinien für Amazon Data Lifecycle Manager, seit dieser Service begonnen hat, diese Änderungen zu verfolgen. Um automatische Warnungen über Änderungen an dieser Seite erhalten, abonnieren Sie den RSS-Feed auf [Dokumentenverlauf für das Amazon EBS-Benutzerhandbuch](doc-history.md).
| Änderungen | Beschreibung | Date |
| --- | --- | --- |
| AWSDataLifecycleManagerServiceRole— Die Richtlinienberechtigungen wurden aktualisiert. | Amazon Data Lifecycle Manager hat die ec2:DescribeAvailabilityZones Aktion hinzugefügt, um Snapshot-Richtlinien die Erlaubnis zu erteilen, Informationen über Local Zones abzurufen. | 16. Dezember 2024 |
| AWSDataLifecycleManagerSSMFullZugriff — Die Richtlinienberechtigungen wurden aktualisiert. | Die Richtlinie wurde aktualisiert, um anwendungskonsistente Snapshots für SAP HANA unter Verwendung des SSM-Dokuments AWSSystemsManagerSAP-CreateDLMSnapshotForSAPHANA zu unterstützen. | 17. November 2023 |
| AWSDataLifecycleManagerSSMFullZugriff — Eine neue AWS verwaltete Richtlinie wurde hinzugefügt. | Amazon Data Lifecycle Manager hat die AWSData LifecycleManager SSMFull Access AWS Managed Policy hinzugefügt. | 7. November 2023 |
| AWSDataLifecycleManagerServiceRole— Es wurden Berechtigungen zur Unterstützung der Snapshot-Archivierung hinzugefügt. | In Amazon Data Lifecycle Manager wurden die Aktionen ec2:ModifySnapshotTier und ec2:DescribeSnapshotTierStatus der Berechtigung zum Erteilen von Snapshot-Richtlinien hinzugefügt, um Snapshots zu archivieren und den Archivierungsstatus für Snapshots zu überprüfen. | 30. September 2022 |
| AWSDataLifecycleManagerServiceRoleForAMIManagement— Berechtigungen zur Unterstützung veralteter AMIs wurden hinzugefügt. | Amazon Data Lifecycle Manager hat die ec2:EnableImageDeprecation- und ec2:DisableImageDeprecation-Aktionen hinzugefügt, um EBS-unterstützte AMI-Richtlinien die Berechtigung zum Aktivieren und Deaktivieren der AMI-Veraltung zu erteilen. | 23. August 2021 |
| Amazon Data Lifecycle Manager hat mit der Verfolgung von Änderungen begonnen | Amazon Data Lifecycle Manager hat damit begonnen, Änderungen an seinen AWS verwalteten Richtlinien nachzuverfolgen. | 23. August 2021 |
# IAM-Servicerollen für Amazon Data Lifecycle Manager
Eine AWS Identity and Access Management (IAM-) Rolle ähnelt einem Benutzer insofern, als es sich um eine AWS Identität mit Berechtigungsrichtlinien handelt, die festlegen, was die Identität tun kann und was nicht. AWS Eine Rolle ist jedoch nicht einer einzigen Person zugeordnet, sondern kann von allen Personen angenommen werden, die diese Rolle benötigen. Eine Servicerolle ist eine Rolle, die ein AWS Dienst übernimmt, um Aktionen in Ihrem Namen auszuführen. Als Service, der für Sie Backup-Operationen durchführt, erfordert der Amazon Data Lifecycle Manager die Übergabe einer Rolle, die es annehmen soll, wenn es für Sie Rechtslinien-Geschäfte durchführt. Weitere Informationen zu IAM-Rollen finden Sie unter [IAM-Rollen](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) im *IAM-Benutzerhandbuch*.
Die Rolle, die Sie an Amazon Data Lifecycle Manager übergeben, muss über eine IAM-Richtlinie mit den Berechtigungen verfügen, die es Amazon Data Lifecycle Manager ermöglichen, Aktionen im Zusammenhang mit Richtlinienoperationen durchzuführen, wie z. B. das Erstellen von Snapshots und das Kopieren von Snapshots und AMIs das Löschen von Snapshots sowie AMIs das Abmelden. AMIs Für jeden der Amazon Data Lifecycle Manager-Richtlinientypen sind unterschiedliche Berechtigungen erforderlich. Die Rolle muss außerdem Amazon Data Lifecycle Manager als vertrauenswürdige Entität aufgelistet haben. Dadurch kann Amazon Data Lifecycle Manager die Rolle übernehmen.
**Topics**
+ [Standard-Servicerollen für Amazon Data Lifecycle Manager](#default-service-roles)
+ [Benutzerdefinierte Service-Rollen für Amazon Data Lifecycle Manager](#custom-role)
## Standard-Servicerollen für Amazon Data Lifecycle Manager
Amazon Data Lifecycle Manager verwendet die folgenden Standard-Service-Rollen:
+ **AWSDataLifecycleManagerDefaultRole**— Standardrolle für die Verwaltung von Snapshots. Es vertraut nur dem `dlm.amazonaws.com`-Dienst, um die Rolle zu übernehmen, und Amazon Data Lifecycle Manager kann die Aktionen ausführen, die für Snapshot- und kontoübergreifende Snapshot-Kopierrichtlinien in Ihrem Namen erforderlich sind. Diese Rolle verwendet die ` AWSDataLifecycleManagerServiceRole` AWS verwaltete Richtlinie.
**Anmerkung**
Das ARN-Format der Rolle unterscheidet sich je nachdem, ob sie mit der Konsole oder der AWS CLI erstellt wurde. Wenn die Rolle mit der Konsole erstellt wurde, lautet das ARN-Format `arn:aws:iam::account_id:role/service-role/AWSDataLifecycleManagerDefaultRole`. Wenn die Rolle mit dem erstellt wurde AWS CLI, ist das ARN-Format`arn:aws:iam::account_id:role/AWSDataLifecycleManagerDefaultRole`.
+ **AWSDataLifecycleManagerDefaultRoleForAMIManagement**— Standardrolle für die Verwaltung AMIs. Es vertraut nur dem `dlm.amazonaws.com`-Dienst, um die Rolle zu übernehmen, und Amazon Data Lifecycle Manager ermöglicht es Ihnen, die Aktionen auszuführen, die von EBS-unterstützten AMI-Richtlinien in Ihrem Namen erforderlich sind. Diese Rolle verwendet die `AWSDataLifecycleManagerServiceRoleForAMIManagement` AWS verwaltete Richtlinie.
Wenn Sie die Amazon Data Lifecycle Manager-Konsole verwenden, erstellt Amazon Data Lifecycle Manager die **AWSDataLifecycleManagerDefaultRole**Servicerolle automatisch, wenn Sie zum ersten Mal eine Snapshot- oder kontoübergreifende Snapshot-Kopierrichtlinie erstellen, und erstellt die **AWSDataLifecycleManagerDefaultRoleForAMIManagement**Servicerolle automatisch, wenn Sie zum ersten Mal eine EBS-gestützte AMI-Richtlinie erstellen.
Wenn Sie die Konsole nicht verwenden, können Sie die Servicerollen mithilfe des Befehls manuell erstellen. [create-default-role](https://docs.aws.amazon.com/cli/latest/reference/dlm/create-default-role.html) Geben Sie für `--resource-type` `snapshot` an AWSDataLifecycleManagerDefaultRole, ob Sie erstellen oder erstellen `image` möchten AWSData LifecycleManagerDefaultRoleForAMIManagement.
```
$ aws dlm create-default-role --resource-type snapshot|image
```
Wenn Sie diese standardmäßigen Servicerollen löschen und sie dann erneut erstellen müssen, können Sie dasselbe Verfahren anwenden, um die sie in Ihrem Konto neu anzulegen.
## Benutzerdefinierte Service-Rollen für Amazon Data Lifecycle Manager
Alternativ zur Verwendung der Standarddienstrollen können Sie benutzerdefinierte IAM-Rollen mit den erforderlichen Berechtigungen erstellen und sie dann beim Erstellen einer Lebenszyklus-Richtlinie auswählen.
**Erstellen einer benutzerdefinierten IAM-Rolle**
1. Erstellen Sie Rollen mit den folgenden Berechtigungen.
+ Notwendige Berechtigungen zum Verwalten von Snapshot-Lebenszyklusrichtlinien
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:CreateSnapshot",
"ec2:CreateSnapshots",
"ec2:DeleteSnapshot",
"ec2:DescribeInstances",
"ec2:DescribeVolumes",
"ec2:DescribeSnapshots",
"ec2:EnableFastSnapshotRestores",
"ec2:DescribeFastSnapshotRestores",
"ec2:DisableFastSnapshotRestores",
"ec2:CopySnapshot",
"ec2:ModifySnapshotAttribute",
"ec2:DescribeSnapshotAttribute",
"ec2:ModifySnapshotTier",
"ec2:DescribeSnapshotTierStatus",
"ec2:DescribeAvailabilityZones"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": "arn:aws:ec2:*::snapshot/*"
},
{
"Effect": "Allow",
"Action": [
"events:PutRule",
"events:DeleteRule",
"events:DescribeRule",
"events:EnableRule",
"events:DisableRule",
"events:ListTargetsByRule",
"events:PutTargets",
"events:RemoveTargets"
],
"Resource": "arn:aws:events:*:*:rule/AwsDataLifecycleRule.managed-cwe.*"
},
{
"Effect": "Allow",
"Action": [
"ssm:GetCommandInvocation",
"ssm:ListCommands",
"ssm:DescribeInstanceInformation"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ssm:SendCommand",
"ssm:DescribeDocument",
"ssm:GetDocument"
],
"Resource": [
"arn:aws:ssm:*:*:document/*"
],
"Condition": {
"StringEquals": {
"aws:ResourceTag/DLMScriptsAccess": "true"
}
}
},
{
"Effect": "Allow",
"Action": [
"ssm:SendCommand",
"ssm:DescribeDocument",
"ssm:GetDocument"
],
"Resource": [
"arn:aws:ssm:*::document/*"
]
},
{
"Effect": "Allow",
"Action": [
"ssm:SendCommand"
],
"Resource": [
"arn:aws:ec2:*:*:instance/*"
],
"Condition": {
"StringNotLike": {
"aws:ResourceTag/DLMScriptsAccess": "false"
}
}
}
]
}
```
------
+ Notwendige Berechtigungen zum Verwalten von AMI-Lebenszyklusrichtlinien
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:CreateTags",
"Resource": [
"arn:aws:ec2:*::snapshot/*",
"arn:aws:ec2:*::image/*"
]
},
{
"Effect": "Allow",
"Action": [
"ec2:DescribeImages",
"ec2:DescribeInstances",
"ec2:DescribeImageAttribute",
"ec2:DescribeVolumes",
"ec2:DescribeSnapshots"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "ec2:DeleteSnapshot",
"Resource": "arn:aws:ec2:*::snapshot/*"
},
{
"Effect": "Allow",
"Action": [
"ec2:ResetImageAttribute",
"ec2:DeregisterImage",
"ec2:CreateImage",
"ec2:CopyImage",
"ec2:ModifyImageAttribute"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:EnableImageDeprecation",
"ec2:DisableImageDeprecation"
],
"Resource": "arn:aws:ec2:*::image/*"
}
]
}
```
------
Weitere Informationen finden Sie unter [Erstellen einer Rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html) im *IAM-Benutzerhandbuch*.
1. Fügen Sie eine Vertrauensstellung für die Rollen hinzu.
1. Wählen Sie in der IAM-Konsole **Roles (Rollen)** aus.
1. Wählen Sie die erstellte Rolle aus und wählen Sie **Trust relationships (Vertrauensstellungen)**.
1. Wählen Sie **Edit Trust Relationship (Vertrauensstellung bearbeiten)**, fügen Sie die folgende Richtlinie hinzu und wählen Sie **Update Trust Policy (Vertrauensstellung aktualisieren)**.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {
"Service": "dlm.amazonaws.com"
},
"Action": "sts:AssumeRole"
}]
}
```
------
Wir empfehlen Ihnen, die `aws:SourceAccount`- und `aws:SourceArn`-Bedingungsschlüssel zu verwenden, um sich vor dem [Problem des verwirrten Stellvertreters](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html) zu schützen. Beispielsweise können Sie der vorherigen Vertrauensrichtlinie den folgenden Bedingungsblock hinzufügen. Das `aws:SourceAccount` ist der Besitzer der Lebenszyklusrichtlinie und das `aws:SourceArn` ist der ARN der Lebenszyklusrichtlinie. Wenn Sie die Lebenszyklusrichtlinie IF nicht kennen, können Sie diesen Teil des ARN durch einen Platzhalter (`*`) ersetzen und dann die Vertrauensrichtlinie aktualisieren, nachdem Sie die Lebenszyklusrichtlinie erstellt haben.
```
"Condition": {
"StringEquals": {
"aws:SourceAccount": "account_id"
},
"ArnLike": {
"aws:SourceArn": "arn:partition:dlm:region:account_id:policy/policy_id"
}
}
```
# Überwachen Sie die Amazon Data Lifecycle Manager Manager-Richtlinien
Sie können die folgenden Funktionen verwenden, um den Lebenszyklus Ihrer Snapshots zu überwachen und AMIs.
**Topics**
+ [Konsole und AWS CLI](#monitor-console-cli)
+ [AWS CloudTrail](#monitor-lifecycle-cloudtrail)
+ [Überwachen Sie die Data Lifecycle Manager-Richtlinien mit EventBridge](monitor-cloudwatch-events.md)
+ [Überwachen Sie die Data Lifecycle Manager-Richtlinien mit CloudWatch](monitor-dlm-cw-metrics.md)
## Konsole und AWS CLI
Sie können Ihre Lebenszyklus-Richtlinien mit der Amazon-EC2-Konsole oder der AWS CLI anzeigen. Jeder von einer Richtlinie erstellte Snapshot und AMI verfügt über einen Zeitstempel und richtlinienbezogene Tags (Markierungen). Sie können Snapshots filtern und AMIs anhand dieser Tags überprüfen, ob Ihre Backups wie gewünscht erstellt werden.
## AWS CloudTrail
Mit können Sie Benutzeraktivitäten und API-Nutzung nachverfolgen AWS CloudTrail, um die Einhaltung interner Richtlinien und regulatorischer Standards nachzuweisen. Weitere Informationen finden Sie im [AWS CloudTrail -Benutzerhandbuch](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/).
# Überwachen Sie die Data Lifecycle Manager-Richtlinien mit EventBridge
Amazon EBS und Amazon Data Lifecycle Manager geben Ereignisse im Hinblick auf Aktionen von Lebenszyklus-Richtlinien aus. Sie können Amazon CloudWatch Events verwenden AWS Lambda , um Ereignisbenachrichtigungen programmgesteuert zu verarbeiten. Ereignisse werden auf bestmögliche Weise ausgegeben. Weitere Informationen finden Sie im [ EventBridge Amazon-Benutzerhandbuch](https://docs.aws.amazon.com/eventbridge/latest/userguide/).
Die folgenden Ereignisse sind verfügbar:
**Anmerkung**
Es werden keine Ereignisse für Aktionen der AMI-Lebenszyklusrichtlinie ausgegeben.
+ `createSnapshot` – Ein Amazon-EBS-Ereignis, das ausgegeben wird, wenn eine `CreateSnapshot`-Aktion erfolgreich ist oder fehlschlägt. Weitere Informationen finden Sie unter [EventBridge Amazon-Veranstaltungen für Amazon EBS](ebs-cloud-watch-events.md).
+ `DLM Policy State Change` – Ein Amazon Data Lifecycle Manager-Ereignis, das ausgegeben wird, wenn eine Lebenszyklus-Richtlinie einen Fehlerstatus annimmt. Das Ereignis enthält eine Beschreibung der Fehlerursache.
Das folgende Beispiel zeigt ein Ereignis, bei dem die von der IAM-Rolle gewährten Berechtigungen nicht ausreichen.
```
{
"version": "0",
"id": "01234567-0123-0123-0123-0123456789ab",
"detail-type": "DLM Policy State Change",
source": "aws.dlm",
"account": "123456789012",
"time": "2018-05-25T13:12:22Z",
"region": "us-east-1",
"resources": [
"arn:aws:dlm:us-east-1:123456789012:policy/policy-0123456789abcdef"
],
"detail": {
"state": "ERROR",
"cause": "Role provided does not have sufficient permissions",
"policy_id": "arn:aws:dlm:us-east-1:123456789012:policy/policy-0123456789abcdef"
}
}
```
Das folgende Beispiel zeigt ein Ereignis, das ausgegeben wird, wenn ein Limit überschritten wird.
```
{
"version": "0",
"id": "01234567-0123-0123-0123-0123456789ab",
"detail-type": "DLM Policy State Change",
"source": "aws.dlm",
"account": "123456789012",
"time": "2018-05-25T13:12:22Z",
"region": "us-east-1",
"resources": [
"arn:aws:dlm:us-east-1:123456789012:policy/policy-0123456789abcdef"
],
"detail":{
"state": "ERROR",
"cause": "Maximum allowed active snapshot limit exceeded",
"policy_id": "arn:aws:dlm:us-east-1:123456789012:policy/policy-0123456789abcdef"
}
}
```
+ `DLM Pre Post Script Notification` – Ein Ereignis, das ausgegeben wird, wenn ein Vor- oder Nach-Skript initiiert wird, erfolgreich ist oder fehlschlägt.
Beispielsweise wird folgendes Ereignis ausgegeben, wenn ein VSS-Backup erfolgreich durchgeführt wird.
```
{
"version": "0",
"id": "12345678-1234-1234-1234-123456789012",
"detail-type": "DLM Pre Post Script Notification",
"source": "aws.dlm",
"account": "123456789012",
"time": "2023-10-27T22:04:52Z",
"region": "us-east-1",
"resources": ["arn:aws:dlm:us-east-1:123456789012:policy/policy-01234567890abcdef"],
"detail": {
"script_stage": "",
"result": "success",
"cause": "",
"policy_id": "arn:aws:dlm:us-east-1:123456789012:policy/policy-01234567890abcdef",
"execution_handler": "AWS_VSS_BACKUP",
"source": "arn:aws:ec2:us-east-1:123456789012:instance/i-01234567890abcdef",
"resource_type": "EBS_SNAPSHOT",
"resources": [{
"status": "pending",
"resource_id": "arn:aws:ec2:us-east-1::snapshot/snap-01234567890abcdef",
"source": "arn:aws:ec2:us-east-1:123456789012:volume/vol-01234567890abcdef"
}],
"request_id": "a1b2c3d4-a1b2-a1b2-a1b2-a1b2c3d4e5f6",
"start_time": "2023-10-27T22:03:29.370Z",
"end_time": "2023-10-27T22:04:51.370Z",
"timeout_time": ""
}
}
```
# Überwachen Sie die Data Lifecycle Manager-Richtlinien mit CloudWatch
Sie können Ihre Amazon Data Lifecycle Manager-Lebenszyklusrichtlinien mithilfe von CloudWatch Amazon Data Lifecycle Manager überwachen. Dabei werden Rohdaten gesammelt und zu lesbaren Metriken verarbeitet, die nahezu in Echtzeit verfügbar sind. Sie können diese Metriken verwenden, um genau zu sehen, wie viele Amazon EBS-Snapshots und AMIs EBS-gestützte Amazon EBS-Snapshots im Laufe der Zeit durch Ihre Richtlinien erstellt, gelöscht und kopiert wurden. Sie können auch Alarme einrichten, die auf bestimmte Grenzwerte achten und Benachrichtigungen senden oder Aktivitäten auslösen, wenn diese Grenzwerte erreicht werden.
Die Metriken werden über einen Zeitraum von 15 Monaten aufbewahrt, sodass Sie auf historische Informationen zugreifen und ein besseres Verständnis darüber erhalten, wie Ihre Lebenszyklus-Richtlinien über einen längeren Zeitraum funktionieren.
Weitere Informationen zu Amazon CloudWatch finden Sie im [ CloudWatch Amazon-Benutzerhandbuch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/).
**Topics**
+ [Unterstützte Metriken](#metrics)
+ [Metriken für Ihre Richtlinien anzeigen CloudWatch](#view-metrics)
+ [Metriken grafisch darstellen](#graph-metrics)
+ [Erstellen Sie einen CloudWatch Alarm für eine Richtlinie](#create-alarm)
+ [Beispielanwendungsfälle](#use-cases)
+ [Verwalten von Richtlinien, die fehlerhafte Aktionen melden](#manage)
## Unterstützte Metriken
Die folgenden Amazon Data Lifecycle Manager Manager-Metriken sind im `AWS/EBS` Namespace enthalten. Die Metriken unterscheiden sich je nach Richtlinientyp.
Alle Metriken können auf der `DLMPolicyId`-Dimension gemessen werden. Die nützlichsten Statistiken sind `sum` und `average`, und die Maßeinheit ist `count`.
Wählen Sie eine Registerkarte, um die von diesem Richtlinientyp unterstützten Metriken anzuzeigen.
------
#### [ EBS snapshot policies ]
| Metrik | Description |
| --- | --- |
| `ResourcesTargeted` | Die Anzahl der Ressourcen, die von den Tags bestimmt werden, die in einer Snapshot- oder EBS-unterstützten AMI-Richtlinie angegeben sind. |
| `SnapshotsCreateStarted` | Die Anzahl der Snapshot-Aktionen, die von einer Snapshot-Richtlinie initiiert wurden. Jede Aktion wird nur einmal aufgezeichnet, auch wenn mehrere nachfolgende Wiederholungen vorliegen. Wenn eine Snapshot-Erstellung fehlschlägt, sendet Amazon Data Lifecycle Manager eine `SnapshotsCreateFailed`-Metrik. |
| `SnapshotsCreateCompleted` | Die Anzahl der Snapshots, die von einer Snapshot-Richtlinie erstellt wurden. Dies schließt erfolgreiche Wiederholungen innerhalb von 60 Minuten nach der geplanten Zeit ein. |
| `SnapshotsCreateFailed` | Die Anzahl der Snapshots, die von einer Snapshot-Richtlinie nicht erstellt werden konnten. Dies schließt erfolglose Wiederholungen innerhalb von 60 Minuten nach der geplanten Zeit ein. |
| `SnapshotsSharedCompleted` | Die Anzahl der Snapshots, die von einer Snapshot-Richtlinie für Konten freigegeben werden. |
| `SnapshotsDeleteCompleted` | Die Anzahl der Snapshots, die von einer Snapshot- oder EBS-gestützten AMI-Richtlinie gelöscht wurden. Diese Metrik gilt nur für Snapshots, die von der Richtlinie erstellt wurden. Sie gilt nicht für regionsübergreifende Snapshot-Kopien, die von der Richtlinie erstellt wurden. Diese Metrik umfasst Snapshots, die gelöscht werden, wenn die Registrierung einer EBS-gestützten AMI-Richtlinie aufgehoben wird. AMIs |
| `SnapshotsDeleteFailed` | Die Anzahl der Snapshots, die nicht durch eine Snapshot- oder EBS-unterstützte AMI-Richtlinie gelöscht werden konnten. Diese Metrik gilt nur für Snapshots, die von der Richtlinie erstellt wurden. Sie gilt nicht für regionsübergreifende Snapshot-Kopien, die von der Richtlinie erstellt wurden. Diese Metrik umfasst Snapshots, die gelöscht werden, wenn die Registrierung einer EBS-gestützten AMI-Richtlinie aufgehoben wird. AMIs |
| `SnapshotsCopiedRegionStarted` | Die Anzahl der regionsübergreifenden Snapshot-Kopieraktionen, die von einer Snapshot-Richtlinie gestartet wurden. |
| `SnapshotsCopiedRegionCompleted` | Die Anzahl der regionsübergreifenden Snapshot-Kopien, die von einer Snapshot-Richtlinie erstellt. Dies schließt erfolgreiche Wiederholungen innerhalb von 24 Stunden nach der geplanten Zeit ein. |
| `SnapshotsCopiedRegionFailed` | Die Anzahl der regionsübergreifenden Snapshot-Kopien, die von einer Snapshot-Richtlinie nicht erstellt werden konnten. Dies schließt erfolglose Wiederholungen innerhalb von 24 Stunden nach der geplanten Zeit ein. |
| `SnapshotsCopiedRegionDeleteCompleted` | Die Anzahl der regionsübergreifenden Snapshot-Kopien, die gemäß der Aufbewahrungsregel durch eine Snapshot-Richtlinie gelöscht wurden. |
| `SnapshotsCopiedRegionDeleteFailed` | Die Anzahl der regionsübergreifenden Snapshot-Kopien, die gemäß der Aufbewahrungsregel durch eine Snapshot-Richtlinie nicht gelöscht werden konnten. |
| `snapshotsArchiveDeletionFailed` | Die Anzahl der archivierten Snapshots, die von einer Snapshot Richtlinie aus der Archivstufe nicht gelöscht werden konnten. |
| `snapshotsArchiveScheduled` | Die Anzahl der Snapshots, die von einer Snapshot Richtlinie für die Archivierung vorgesehen waren. |
| `snapshotsArchiveCompleted` | Die Anzahl der Snapshots, die von einer Snapshot Richtlinie erfolgreich archiviert wurden. |
| `snapshotsArchiveFailed` | Die Anzahl der Snapshots, die von einer Snapshot-Richtlinie nicht archiviert werden konnten. |
| `snapshotsArchiveDeletionCompleted` | Die Anzahl der archivierten Snapshots, die von einer Snapshot Richtlinie aus der Archivstufe erfolgreich gelöscht werden konnten. |
| `PreScriptStarted` | Die Anzahl der Instances, für die ein Vor-Skript erfolgreich initiiert wurde. Wenn Skriptwiederholungen aktiviert sind, kann diese Metrik pro Richtlinienausführung mehrmals ausgegeben werden. |
| `PreScriptCompleted` | Die Anzahl der Instances, für die ein Vor-Skript erfolgreich abgeschlossen wurde. Die Metrik wird auch dann ausgegeben, wenn das Vor-Skript außerhalb des angegebenen Timeout-Zeitraums abgeschlossen wird. Wenn Skriptwiederholungen aktiviert sind, kann diese Metrik pro Richtlinienausführung mehrmals ausgegeben werden. |
| `PreScriptFailed` | Die Anzahl der Instances, für die ein Vor-Skript nicht erfolgreich abgeschlossen wurde. Die Metrik wird auch dann ausgegeben, wenn das Vor-Skript außerhalb des angegebenen Timeout-Zeitraums abgeschlossen wird. Wenn Skriptwiederholungen aktiviert sind, kann diese Metrik pro Richtlinienausführung mehrmals ausgegeben werden. |
| `PostScriptStarted` | Die Anzahl der Instances, für die ein Nach-Skript erfolgreich initiiert wurde. Wenn Skriptwiederholungen aktiviert sind, kann diese Metrik pro Richtlinienausführung mehrmals ausgegeben werden. |
| PostScriptCompleted | Die Anzahl der Instances, für die ein Nach-Skript erfolgreich abgeschlossen wurde. Die Metrik wird auch dann ausgegeben, wenn das Nach-Skript außerhalb des angegebenen Timeout-Zeitraums abgeschlossen wird. Wenn Skriptwiederholungen aktiviert sind, kann diese Metrik pro Richtlinienausführung mehrmals ausgegeben werden. |
| PostScriptFailed | Die Anzahl der Instances, für die ein Nach-Skript nicht erfolgreich abgeschlossen wurde. Die Metrik wird auch dann ausgegeben, wenn das Nach-Skript außerhalb des angegebenen Timeout-Zeitraums abgeschlossen wird. Wenn Skriptwiederholungen aktiviert sind, kann diese Metrik pro Richtlinienausführung mehrmals ausgegeben werden. |
| `VSSBackupStarted` | Die Anzahl der Instances, für die ein VSS-Backup erfolgreich initiiert wurde. Wenn Skriptwiederholungen aktiviert sind, kann diese Metrik pro Richtlinienausführung mehrmals ausgegeben werden. |
| `VSSBackupCompleted` | Die Anzahl der Instances, für die ein VSS-Backup erfolgreich abgeschlossen wurde. Die Metrik wird auch dann ausgegeben, wenn das VSS-Backup außerhalb des Timeout-Zeitraums abgeschlossen wird. Wenn Skriptwiederholungen aktiviert sind, kann diese Metrik pro Richtlinienausführung mehrmals ausgegeben werden. |
| `VSSBackupFailed` | Die Anzahl der Instances, für die ein VSS-Backup nicht erfolgreich abgeschlossen wurde. Die Metrik wird auch dann ausgegeben, wenn das VSS-Backup außerhalb des Timeout-Zeitraums abgeschlossen wird. Wenn Skriptwiederholungen aktiviert sind, kann diese Metrik pro Richtlinienausführung mehrmals ausgegeben werden. |
------
#### [ EBS-backed AMI policies ]
Die folgenden Metriken können mit EBS-unterstützten AMI-Richtlinien verwendet werden:
| Metrik | Description |
| --- | --- |
| `ResourcesTargeted` | Die Anzahl der Ressourcen, die von den Tags bestimmt werden, die in einer Snapshot- oder EBS-unterstützten AMI-Richtlinie angegeben sind. |
| `SnapshotsDeleteCompleted` | Die Anzahl der Snapshots, die von einer Snapshot- oder EBS-gestützten AMI-Richtlinie gelöscht wurden. Diese Metrik gilt nur für Snapshots, die von der Richtlinie erstellt wurden. Sie gilt nicht für regionsübergreifende Snapshot-Kopien, die von der Richtlinie erstellt wurden. Diese Metrik umfasst Snapshots, die gelöscht werden, wenn die Registrierung einer EBS-gestützten AMI-Richtlinie aufgehoben wird. AMIs |
| `SnapshotsDeleteFailed` | Die Anzahl der Snapshots, die nicht durch eine Snapshot- oder EBS-unterstützte AMI-Richtlinie gelöscht werden konnten. Diese Metrik gilt nur für Snapshots, die von der Richtlinie erstellt wurden. Sie gilt nicht für regionsübergreifende Snapshot-Kopien, die von der Richtlinie erstellt wurden. Diese Metrik umfasst Snapshots, die gelöscht werden, wenn die Registrierung einer EBS-gestützten AMI-Richtlinie aufgehoben wird. AMIs |
| `SnapshotsCopiedRegionDeleteCompleted` | Die Anzahl der regionsübergreifenden Snapshot-Kopien, die gemäß der Aufbewahrungsregel durch eine Snapshot-Richtlinie gelöscht wurden. |
| `SnapshotsCopiedRegionDeleteFailed` | Die Anzahl der regionsübergreifenden Snapshot-Kopien, die gemäß der Aufbewahrungsregel durch eine Snapshot-Richtlinie nicht gelöscht werden konnten. |
| `ImagesCreateStarted` | Die Anzahl der **CreateImage**Aktionen, die durch eine EBS-gestützte AMI-Richtlinie eingeleitet wurden. |
| `ImagesCreateCompleted` | Die Anzahl der, die durch eine EBS-gestützte AMI-Richtlinie AMIs erstellt wurden. |
| `ImagesCreateFailed` | AMIs Diese Zahl konnte durch eine EBS-gestützte AMI-Richtlinie nicht ermittelt werden. |
| `ImagesDeregisterCompleted` | Die Anzahl der Personen, die durch eine EBS-gestützte AMI-Richtlinie AMIs abgemeldet wurden. |
| `ImagesDeregisterFailed` | AMIs Diese Zahl konnte durch eine EBS-gestützte AMI-Richtlinie nicht abgemeldet werden. |
| `ImagesCopiedRegionStarted` | Die Anzahl der regionsübergreifenden Kopieraktionen, die von einer EBS-unterstützten AMI-Richtlinie initiiert wurden. |
| `ImagesCopiedRegionCompleted` | Die Anzahl der regionsübergreifenden AMI-Kopien, die von einer EBS-unterstützten AMI-Richtlinie erstellt wurden. |
| `ImagesCopiedRegionFailed` | Die Anzahl der regionsübergreifenden AMI-Kopien, die nicht durch eine EBS-unterstützte AMI-Richtlinie erstellt werden konnten. |
| `ImagesCopiedRegionDeregisterCompleted` | Die Anzahl der regionsübergreifenden AMI-Kopien, die gemäß der Aufbewahrungsregel durch eine EBS-unterstützte AMI-Richtlinie abgemeldet wurden. |
| `ImagesCopiedRegionDeregisteredFailed` | Die Anzahl der regionsübergreifenden AMI-Kopien, die gemäß der Aufbewahrungsregel durch eine EBS-unterstützte AMI-Richtlinie nicht abgemeldet werden konnten. |
| `EnableImageDeprecationCompleted` | Die Anzahl AMIs davon wurde durch eine EBS-gestützte AMI-Richtlinie als veraltet markiert. |
| `EnableImageDeprecationFailed` | AMIs Diese Zahl konnte durch eine EBS-gestützte AMI-Richtlinie nicht als veraltet markiert werden. |
| `EnableCopiedImageDeprecationCompleted` | Die Anzahl der regionsübergreifenden AMI-Kopien, die durch eine EBS-unterstützte AMI-Richtlinie für die Verwarnung markiert wurden. |
| `EnableCopiedImageDeprecationFailed` | Die Anzahl der regionsübergreifenden AMI-Kopien, die durch eine EBS-unterstützte AMI-Richtlinie nicht für die Verwarnung markiert werden konnten. |
------
#### [ Cross-account copy event policies ]
Die folgenden Metriken können mit kontoübergreifenden Kopierereignissen verwendet werden:
| Metrik | Description |
| --- | --- |
| `SnapshotsCopiedAccountStarted` | Die Anzahl der kontoübergreifende Snapshot-Kopieraktionen, die von einer Richtlinie für kontoübergreifende Kopierereignisse. |
| `SnapshotsCopiedAccountCompleted` | Die Anzahl der Snapshots, die von einer Richtlinie für kontoübergreifende Kopierereignisse kopiert werden. Dies schließt erfolgreiche Wiederholungen innerhalb von 24 Stunden nach der geplanten Zeit ein. |
| `SnapshotsCopiedAccountFailed` | Die Anzahl der Snapshots, die von einer Richtlinie für kontoübergreifende Kopierereignisse nicht von einem anderen Konto kopiert werden konnten. Dies schließt erfolglose Wiederholungen innerhalb von 24 Stunden nach der geplanten Zeit ein. |
| `SnapshotsCopiedAccountDeleteCompleted` | Die Anzahl der regionsübergreifenden Snapshot-Kopien, die gemäß der Aufbewahrungsregel durch eine kontoübergreifende Kopierereignisrichtlinie gelöscht wurden. |
| `SnapshotsCopiedAccountDeleteFailed` | Die Anzahl der regionsübergreifenden Snapshot-Kopien, die gemäß der Aufbewahrungsregel durch eine kontoübergreifende Kopierereignisrichtlinie nicht gelöscht werden konnten. |
------
## Metriken für Ihre Richtlinien anzeigen CloudWatch
Sie können die Befehlszeilentools AWS-Managementkonsole oder die Befehlszeilentools verwenden, um die Metriken aufzulisten, die Amazon Data Lifecycle Manager an Amazon sendet CloudWatch.
------
#### [ Amazon EC2 console ]
**Zeigen Sie Metriken mithilfe der Amazon EC2-Konsole wie folgt an:**
1. Öffnen Sie die Amazon-EC2-Konsole unter [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. Wählen Sie im Navigationsbereich **Lifecycle Manager** aus.
1. Wählen Sie eine Richtlinie im Raster aus, und wählen Sie dann die Registerkarte **Überwachung**.
------
#### [ CloudWatch console ]
**So zeigen Sie Metriken mit der CloudWatch Amazon-Konsole an**
1. Öffnen Sie die CloudWatch Konsole unter [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Wählen Sie im Navigationsbereich **Metriken** aus.
1. Wählen Sie das **EBS**-Namespace und dann **Data Lifecycle Manager-Metriken** aus.
------
#### [ AWS CLI ]
**So listen Sie alle verfügbaren Metriken für Amazon Data Lifecycle Manager auf**
Verwenden Sie den [list-metrics](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/list-metrics.html)-Befehl:
```
$ C:\> aws cloudwatch list-metrics \
--namespace AWS/EBS
```
**So listen Sie alle Metriken für eine bestimmte Richtlinie auf**
Verwenden Sie den Befehl [list-metrics](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/list-metrics.html) und geben Sie die `DLMPolicyId`-Dimension an.
```
$ C:\> aws cloudwatch list-metrics \
--namespace AWS/EBS \
--dimensions Name=DLMPolicyId,Value=policy-abcdef01234567890
```
**So listen Sie eine einzelne Metrik für alle Richtlinien auf**
Verwenden Sie den Befehl [list-metrics](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/list-metrics.html) und geben Sie die `--metric-name`-Option an.
```
$ C:\> aws cloudwatch list-metrics \
--namespace AWS/EBS \
--metric-name SnapshotsCreateCompleted
```
------
## Diagrammen von Metriken für Ihre Richtlinien
Nachdem Sie die Richtlinie erstellt haben, können Sie die Amazon EC2-Konsole öffnen und auf der Registerkarte **Monitoring (Überwachung)** die Überwachungsdiagramme für die Richtlinie anzeigen. Jedes Diagramm basiert auf einer der verfügbaren Amazon EC2-Metriken.
Folgende Diagramm-Metriken sind verfügbar:
+ Zielgerichtete Ressourcen (basierend auf `ResourcesTargeted`)
+ Snapshot-Erstellung gestartet (basierend auf `SnapshotsCreateStarted`)
+ Snapshot-Erstellung abgeschlossen (basierend auf `SnapshotsCreateCompleted`)
+ Snapshot-Erstellung fehlgeschlagen (basierend auf `SnapshotsCreateFailed`)
+ Snapshot-Freigabe abgeschlossen (basierend auf `SnapshotsSharedCompleted`)
+ Snapshot-Löschen abgeschlossen (basierend auf `SnapshotsDeleteCompleted`)
+ Snapshot-Löschen fehlgeschlagen (basierend auf `SnapshotsDeleteFailed`)
+ Snapshot regionenübergreifende Kopie wurde gestartet (basierend auf `SnapshotsCopiedRegionStarted`)
+ Erstellen eines Snapshots regionenübergreifenden Kopie (basierend auf `SnapshotsCopiedRegionCompleted`)
+ Fehler bei regionenübergreifender Kopie des Snapshots (basierend auf `SnapshotsCopiedRegionFailed`)
+ Snapshot regionsübergreifendes Kopieren wurde abgeschlossen (basierend auf `SnapshotsCopiedRegionDeleteCompleted`)
+ Fehler beim Löschen regionsübergreifender Snapshot-Kopieren (basierend auf `SnapshotsCopiedRegionDeleteFailed`)
+ Kontoübergreifende Snapshot-Kopie gestartet (basierend auf `SnapshotsCopiedAccountStarted`)
+ Kontoübergreifende Kopie des Snapshots abgeschlossen (basierend auf `SnapshotsCopiedAccountCompleted`)
+ Kontoübergreifende Snapshot-Kopie fehlgeschlagen (basierend auf `SnapshotsCopiedAccountFailed`)
+ Kontoübergreifende Snapshot-Löschung abgeschlossen (basierend auf `SnapshotsCopiedAccountDeleteCompleted`)
+ Kontoübergreifende Snapshot-Kopieren fehlgeschlagen (basierend auf `SnapshotsCopiedAccountDeleteFailed`)
+ AMI-Erstellung gestartet (basierend auf `ImagesCreateStarted`)
+ AMI-Erstellung abgeschlossen (basierend auf `ImagesCreateCompleted`)
+ AMI-Erstellung fehlgeschlagen (basierend auf `ImagesCreateFailed`)
+ AMI-Abmeldung abgeschlossen (basierend auf `ImagesDeregisterCompleted`)
+ AMI-Abmeldung fehlgeschlagen (basierend auf `ImagesDeregisterFailed`)
+ Erstellen einer AMI regionenübergreifenden Kopie (basierend auf `ImagesCopiedRegionStarted`)
+ AMI regionenübergreifende Kopie abgeschlossen (basierend auf `ImagesCopiedRegionCompleted`)
+ Fehler bei AMI regionenübergreifenden Kopieren (basierend auf `ImagesCopiedRegionFailed`)
+ AMI regionsübergreifende Kopie Abmeldung abgeschlossen (basierend auf `ImagesCopiedRegionDeregisterCompleted`)
+ AMI regionsübergreifende Kopie Abmeldung fehlgeschlagen (basierend auf `ImagesCopiedRegionDeregisteredFailed`)
+ AMI Veraltungs-Aktivierung abgeschlossen (basierend auf `EnableImageDeprecationCompleted`)
+ AMI Veraltungs-Aktivierung fehlgeschlagen (basierend auf `EnableImageDeprecationFailed`)
+ AMI regionsübergreifende Kopie Veraltungs-Aktivierung abgeschlossen (basierend auf `EnableCopiedImageDeprecationCompleted`)
+ AMI regionsübergreifende Kopie Veraltungs-Aktivierung fehlgeschlagen (basierend auf `EnableCopiedImageDeprecationFailed`)
## Erstellen Sie einen CloudWatch Alarm für eine Richtlinie
Sie können einen CloudWatch Alarm erstellen, der die CloudWatch Kennzahlen für Ihre Richtlinien überwacht. CloudWatch sendet Ihnen automatisch eine Benachrichtigung, wenn die Metrik einen von Ihnen angegebenen Schwellenwert erreicht. Sie können mit der CloudWatch Konsole einen CloudWatch Alarm erstellen.
Weitere Informationen zum Erstellen von Alarmen mithilfe der CloudWatch Konsole finden Sie im folgenden Thema im * CloudWatch Amazon-Benutzerhandbuch*.
+ [Erstellen Sie einen CloudWatch Alarm auf der Grundlage eines statischen Schwellenwerts](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html)
+ [Erstellen Sie einen CloudWatch Alarm, der auf der Erkennung von Anomalien basiert](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Anomaly_Detection_Alarm.html)
## Beispielanwendungsfälle
Im Folgenden finden Sie Beispiele für Anwendungsfälle:
**Topics**
+ [Beispiel 1: Metrik ResourcesTargeted](#case1)
+ [Beispiel 2: SnapshotDeleteFailed metrisch](#case2)
+ [Beispiel 3: SnapshotsCopiedRegionFailed metrisch](#case3)
### Beispiel 1: Metrik ResourcesTargeted
Sie können die `ResourcesTargeted`-Metrik nutzen, um die Gesamtzahl der Ressourcen zu überwachen, die von einer bestimmten Richtlinie bei jeder Ausführung ausgerichtet sind. Auf diese Weise können Sie einen Alarm auslösen, wenn die Anzahl der Zielressourcen unter oder über einem erwarteten Schwellenwert liegt.
Wenn Sie beispielsweise erwarten, dass Ihre tägliche Richtlinie Backups von nicht mehr als `50`-Volumes können Sie einen Alarm erstellen, der eine E-Mail-Benachrichtigung sendet, wenn die `sum` für `ResourcesTargeted` größer als `50` über einen `1`-Stunden-Zeitraum ist. Auf diese Weise können Sie sicherstellen, dass keine Snapshots aus Datenträgern, die falsch markiert wurden, unerwartet erstellt wurden.
Sie können den folgenden Befehl verwenden, um diesen Alarm zu erstellen:
```
$ C:\> aws cloudwatch put-metric-alarm \
--alarm-name resource-targeted-monitor \
--alarm-description "Alarm when policy targets more than 50 resources" \
--metric-name ResourcesTargeted \
--namespace AWS/EBS \
--statistic Sum \
--period 3600 \
--threshold 50 \
--comparison-operator GreaterThanThreshold \
--dimensions "Name=DLMPolicyId,Value=policy_id" \
--evaluation-periods 1 \
--alarm-actions sns_topic_arn
```
### Beispiel 2: SnapshotDeleteFailed metrisch
Sie können die `SnapshotDeleteFailed`-Metrik nutzen, um auf Fehler beim Löschen von Snapshots gemäß der Snapshot-Aufbewahrungsregel der Richtlinie zu überwachen.
Wenn Sie beispielsweise eine Richtlinie erstellt haben, die Snapshots automatisch alle zwölf Stunden löschen soll, können Sie einen Alarm erstellen, der Ihr Engineering-Team benachrichtigt, wenn `sum` von `SnapshotDeletionFailed` größer als `0` über einen `1`-Stunden-Zeitraum ist. Dies könnte dabei helfen, unsachgemäße Snapshot-Aufbewahrung zu untersuchen und sicherzustellen, dass Ihre Speicherkosten nicht durch unnötige Snapshots erhöht werden.
Sie können den folgenden Befehl verwenden, um diesen Alarm zu erstellen:
```
$ C:\> aws cloudwatch put-metric-alarm \
--alarm-name snapshot-deletion-failed-monitor \
--alarm-description "Alarm when snapshot deletions fail" \
--metric-name SnapshotsDeleteFailed \
--namespace AWS/EBS \
--statistic Sum \
--period 3600 \
--threshold 0 \
--comparison-operator GreaterThanThreshold \
--dimensions "Name=DLMPolicyId,Value=policy_id" \
--evaluation-periods 1 \
--alarm-actions sns_topic_arn
```
### Beispiel 3: SnapshotsCopiedRegionFailed metrisch
Verwenden der `SnapshotsCopiedRegionFailed`-Metrik, um zu ermitteln, wann Ihre Richtlinien Snapshots nicht in andere Regionen kopieren können.
Wenn Ihre Richtlinie beispielsweise Snapshots täglich über Regionen hinweg kopiert, können Sie einen Alarm erstellen, der eine SMS an Ihr Engineering-Team sendet, wenn `sum` von `SnapshotCrossRegionCopyFailed` größer als `0` über einen `1`-Stunden-Zeitraum ist. Dies kann hilfreich sein, um zu überprüfen, ob nachfolgende Snapshots in der Herkunft von der Richtlinie erfolgreich kopiert wurden.
Sie können den folgenden Befehl verwenden, um diesen Alarm zu erstellen:
```
$ C:\> aws cloudwatch put-metric-alarm \
--alarm-name snapshot-copy-region-failed-monitor \
--alarm-description "Alarm when snapshot copy fails" \
--metric-name SnapshotsCopiedRegionFailed \
--namespace AWS/EBS \
--statistic Sum \
--period 3600 \
--threshold 0 \
--comparison-operator GreaterThanThreshold \
--dimensions "Name=DLMPolicyId,Value=policy_id" \
--evaluation-periods 1 \
--alarm-actions sns_topic_arn
```
## Verwalten von Richtlinien, die fehlerhafte Aktionen melden
Weitere Informationen darüber, was zu tun ist, wenn eine Ihrer Richtlinien einen unerwarteten Wert ungleich Null für eine Metrik für fehlgeschlagene Aktionen meldet, finden Sie im Artikel [Was sollte ich tun, wenn Amazon Data Lifecycle Manager fehlgeschlagene Aktionen in CloudWatch Metriken meldet](https://repost.aws/knowledge-center/cloudwatch-metrics-dlm)?
# Service-Endpunkte für Amazon Data Lifecycle Manager
Ein *Endpunkt* ist eine URL, die als Einstiegspunkt für einen AWS Webservice dient. Amazon Data Lifecycle Manager unterstützt die folgenden Endpunkttypen:
+ IPv4 Endpunkte
+ Dual-Stack-Endpunkte, die sowohl als auch unterstützen IPv4 IPv6
+ FIPS-Endpunkte
Wenn Sie eine Anfrage stellen, können Sie den Endpunkt und die Region angeben, die verwendet werden sollen. Wenn Sie keinen Endpunkt angeben, wird der IPv4 Endpunkt standardmäßig verwendet. Um einen anderen Endpunkttyp zu verwenden, müssen Sie ihn in Ihrer Anforderung angeben. Beispiele für diese Vorgehensweise finden Sie unter [Angeben von Endpunkten](#dlm-endpoint-examples).
Informationen zum Amazon Data Lifecycle Manager finden Sie unter [Amazon Data Lifecycle Manager Manager-Endpoints](https://docs.aws.amazon.com/general/latest/gr/dlm.html) in der *Allgemeine Amazon Web Services-Referenz*.
**Topics**
+ [IPv4 Endpunkte](#dlm-ipv4)
+ [Dual-Stack IPv4 - (und IPv6) Endpunkte](#dlm-ipv6)
+ [FIPS-Endpunkte](#dlm-fips)
+ [Angeben von Endpunkten](#dlm-endpoint-examples)
## IPv4 Endpunkte
IPv4 Endpunkte unterstützen nur IPv4 Datenverkehr. IPv4 Endpunkte sind für alle Regionen verfügbar.
Sie müssen die Region als Teil des Endpunktnamens angeben. Die Endpunktnamen verwenden die folgende Benennungskonvention:
+ dlm. *region*.amazonaws.com
Der IPv4 Endpunkt für die Region USA Ost (Nord-Virginia) lautet beispielsweise. `dlm.us-east-1.amazonaws.com`
## Dual-Stack IPv4 - (und IPv6) Endpunkte
Dual-Stack-Endpunkte unterstützen sowohl den als auch den Datenverkehr. IPv4 IPv6 Dual-StackEndpunkte sind für alle Regionen verfügbar.
Zur Verwendung IPv6 müssen Sie einen Dual-Stack-Endpunkt verwenden. Wenn Sie eine Anfrage an einen Dual-Stack-Endpunkt stellen, wird die Endpunkt-URL je nach dem von Ihrem Netzwerk und Client verwendeten Protokoll in eine IPv6 oder eine IPv4 Adresse aufgelöst.
Sie müssen die Region als Teil des Endpunktnamens angeben. Dual-Stack-Endpunktnamen verwenden die folgende Namenskonvention:
+ `dlm.region.api.aws`
Der Dual-Stack-Endpunkt für die Region USA Ost (Nord-Virginia) lautet `dlm.us-east-1.api.aws` beispielsweise.
## FIPS-Endpunkte
Amazon Data Lifecycle Manager bietet FIPS-validierte Dual-Stack IPv4 - (und IPv6) Endpunkte für die folgenden Regionen:
+ `us-east-1` – USA Ost (Nord-Virginia)
+ `us-east-2` – USA Ost (Ohio)
+ `us-west-1` – USA West (Nordkalifornien)
+ `us-west-2` – USA West (Oregon)
+ `ca-central-1` – Kanada (Zentral)
+ `ca-west-1`— Kanada West (Calgary)
FIPS-Dual-Stack-Endpunkte verwenden die folgende Namenskonvention:. `dlm-fips.region.api.aws` Der FIPS-Dual-Stack-Endpunkt für die Region USA Ost (Nord-Virginia) lautet beispielsweise. `dlm-fips.us-east-1.api.aws`
## Angeben von Endpunkten
Die folgenden Beispiele zeigen, wie Sie mithilfe von AWS CLI einen Endpunkt für die `US East (N. Virginia)`-Region angeben.
+ **Dual-Stack**
```
aws dlm create-default-role \
--resource-type snapshot \
--endpoint-url https://dlm.us-east-2.api.aws
```
+ **IPv4**
```
aws dlm create-default-role \
--resource-type snapshot \
--endpoint-url https://dlm.us-east-2.amazonaws.com
```
# Erstellen Sie eine private Verbindung zwischen einer VPC und Amazon EBS
Sie können eine private Verbindung zwischen Ihrer VPC und Amazon EBS herstellen, indem Sie einen *VPC-Schnittstellen-Endpunkt* erstellen, der von betrieben wird. [AWS PrivateLink](https://aws.amazon.com/privatelink/) Sie können auf Amazon EBS zugreifen, als wäre es in Ihrer VPC, ohne ein Internet-Gateway, ein NAT-Gerät, eine VPN-Verbindung oder AWS Direct Connect eine Verbindung zu verwenden. Instances in Ihrer VPC benötigen keine öffentlichen IP-Adressen, um mit Amazon EBS zu kommunizieren.
Wir erstellen eine Endpunkt-Netzwerkschnittstelle in jedem Subnetz, das Sie für den Schnittstellen-Endpunkt aktivieren.
*Weitere Informationen finden Sie AWS PrivateLink im Leitfaden unter [Zugriff AWS-Services durch](https://docs.aws.amazon.com/vpc/latest/privatelink/privatelink-access-aws-services.html).AWS PrivateLink *
**Anmerkung**
Amazon Data Lifecycle Manager unterstützt IPv4 VPC-Schnittstellen-Endpunkte für alle kommerziellen und regionalen sowie IPv6 Schnittstellen-VPC-Endpunkte nur für kommerzielle AWS GovCloud (US) Regionen.
## Überlegungen zu Amazon EBS-VPC-Endpunkten
*Bevor Sie einen VPC-Schnittstellen-Endpunkt für Amazon EBS einrichten, lesen Sie die [Überlegungen](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#considerations-interface-endpoints) im AWS PrivateLink Handbuch.*
Standardmäßig ist der vollständige Zugriff auf Amazon EBS über den Endpunkt zulässig. Sie können den Zugriff auf den Schnittstellenendpunkt mithilfe von VPC-Endpunktrichtlinien steuern. Sie können Ihrem VPC-Endpunkt eine Endpunktrichtlinie hinzufügen, die den Zugriff auf Amazon EBS steuert. Die Richtlinie gibt die folgenden Informationen an:
+ Der **Principal**, der Aktionen ausführen kann.
+ Die **Aktionen**, die ausgeführt werden können.
+ Die **Ressourcen**, auf denen Aktionen ausgeführt werden können.
Weitere Informationen finden Sie unter [Steuerung des Zugriffs auf Services mit VPC-Endpunkten](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html) im *Amazon VPC Benutzerhandbuch*.
Im Folgenden finden Sie ein Beispiel für eine Endpunktrichtlinie für Amazon EBS. Wenn diese Richtlinie an einen Endpunkt angehängt ist, gewährt sie allen Benutzern die Erlaubnis, zusammenfassende Informationen zu den Amazon Data Lifecycle Manager Manager-Richtlinien abzurufen.
```
{
"Statement": [{
"Action": "dlm:GetLifecyclePolicies",
"Effect": "Allow",
"Principal": "*",
"Resource": "*"
}]
}
```
## Erstellen Sie einen VPC-Schnittstellen-Endpunkt für Amazon EBS
Sie können einen VPC-Endpunkt für Amazon EBS entweder mit der Amazon VPC-Konsole oder mit () erstellen. AWS Command Line Interface AWS CLI Weitere Informationen finden Sie unter [Erstellen eines VPC-Endpunkts](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint-aws) im *AWS PrivateLink -Leitfaden*.
Erstellen Sie einen VPC-Endpunkt für Amazon EBS mit dem folgenden Servicenamen:
+ `com.amazonaws.region.dlm`
Wenn Sie privates DNS für den Endpunkt aktivieren, können Sie API-Anfragen an Amazon EBS stellen, indem Sie dessen Standard-DNS-Namen für die Region verwenden, `dlm.us-east-1.amazonaws.com` zum Beispiel.
# Probleme mit Amazon Data Lifecycle Manager beheben
Die folgende Dokumentation kann zum Beheben möglicher Probleme nützlich sein.
**Topics**
+ [Fehler: `Role with name already exists`](#dlm-role-arn-issue)
## Fehler: `Role with name already exists`
**Description**
Sie erhalten den Fehler `Role with name AWSDataLifecycleManagerDefaultRole already exists` oder `Role with name AWSDataLifecycleManagerDefaultRoleForAMIManagement already exists`, wenn Sie versuchen, eine Richtlinie unter Verwendung der Konsole zu erstellen.
**Ursache**
Das ARN-Format der Standardrolle unterscheidet sich je nachdem, ob sie mit der Konsole oder der AWS CLI erstellt wurde. Obwohl sie unterschiedlich ARNs sind, verwenden die Rollen denselben Rollennamen, was zu einem Rollenbenennungskonflikt zwischen der Konsole und der führt AWS CLI.
**Lösung**
Führen Sie folgende Schritte aus, um dieses Problem zu lösen:
1. (*Nur für Snapshot-Richtlinien, die für Vor- und Nachskripte aktiviert* sind) Hängen Sie die AWS verwaltete **AWSDataLifecycleManagerSSMFullAccess-Richtlinie** manuell an die **AWSDataLifecycleManagerDefaultRole**IAM-Rolle an. Weitere Informationen finden Sie unter [Hinzufügen von IAM-Identitätsberechtigungen](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html#add-policies-console).
1. Wählen Sie bei der Erstellung Ihrer Amazon Data Lifecycle Manager Manager-Richtlinie für die **IAM-Rolle** die Option **Andere Rolle auswählen** aus und wählen Sie dann entweder **AWSDataLifecycleManagerDefaultRole**(für eine Snapshot-Richtlinie) oder **AWSDataLifecycleManagerDefaultRoleForAMIManagement**(für eine AMI-Richtlinie) aus.
1. Fahren Sie mit der Erstellung der Richtlinie wie gewohnt fort.