Dezember 2020
Autor:in des Beitrags
Matthias
Architect Cloud
Veröffentlicht am
02.12.2020 von Matthias
Jetzt Blogbeitrag teilen
Xing LinkedIn Facebook Twitter
AWS Backup Notifications

Einfach und schnell mit der PowerShell AWS CLI

Es gibt Leute, die die AWS CLI lieben, doch viele können mit der Konsole nichts anfangen. Die meisten AWS Einstellungen lassen sich auch schließlich leicht durch das GUI konfigurieren, warum sich also mit der CLI auseinandersetzen?

Nun gibt es aber manche Konfigurationen, die sich nur mit der CLI erledigen lassen. So zum Beispiel die Backup Notifications für einen Backup Vault.

In einem Backup Vault (Tresor) werden alle abgeschlossenen Backups gespeichert.

In diesem Blog zeige ich, wie man mit einem simplen PowerShell Script ganz einfach diese Notifications für einen Backup Vault einrichten kann.

Zusätzlich legen wir mit dem Script aber auch noch ein eigenes Simple Notification Service (SNS) Topic mit einer Subscription an, so dass wir diese nicht im GUI konfigurieren, sondern alles in einem Zug erstellen können.

Das Topic benötigen wir, da wir sonst nicht die benötigten Berechtigungen haben, um Benachrichtigungen zu empfangen. Außerdem werden die Ereignisse, bei denen Benachrichtigungen verschickt werden, im SNS Topic definiert.

Für unser Beispiel verwenden wir den standardmäßig vorhanden Default Backup Vault. Wenn man dennoch einen neuen Vault benutzen will, erkläre ich weiter unten wie das geht.

AWS CLI einrichten

Zuallererst müssen wir jedoch unsere PowerShell/CMD für AWS vorbereiten.

Im Grunde ist es ganz einfach. Alles, was wir brauchen, ist:

– den eigenen Access Key
– den dazugehörigen Secret Key
– die .MSI von AWS

Wie man an den Access und Secret Key kommt, wird in der AWS Dokumentation erklärt.

Sobald die .MSI installiert wurde, müsst ihr in eurer PowerShell oder CMD eure AWS Verbindungsdaten mit dem Kommando aws configure hinterlegen.

Wählt für euren region name die Region, in der sich eure AWS Umgebung befindet.

Als output format geben wir JSON an.

— aws configure —

Und schon ist es uns möglich, alles, was wir in der AWS GUI können, auch in unserer AWS CLI aka PowerShell zu erledigen… und sogar mehr!

PowerShell mit AWS Commands

Damit wir das Script nicht jedes Mal umschreiben müssen, erstellen wir uns Variablen, die wir zu Beginn definieren und jederzeit schnell und einfach wieder ändern können – auch sehr hilfreich, wenn wir das Script erweitern sollten.

Dazu erstellen wir uns für das Script ein neues File in einem Programm unserer Wahl (Visual Studio Code, Notepad++, etc.) oder wahlweise direkt in der Powershell und fangen mit vier Variablen an:

# PARAMETER

$SNSTopicName = “BESTTOPIC”

$BackupVaultName = “Default”

$ProtocolType = “email”

$ProtocolNotification = “bestemailadress@example.de”

Für den BackupVaultName tragen wir Default ein. Solltet ihr einen anderen Vault benutzen, oder einen neuen erstellen wollen, müsst ihr hier natürlich die Bezeichnung anpassen.

Ihr könnt bei der Variablen ProtocolType auch statt email ein anderes Protokoll angeben. Eine Liste dazu findet ihr hier.

Nur nicht vergessen, dass die ProtocolNotification dementsprechend geändert werden muss!

Optional: Neuen Backup Vault erstellen

Einen neuen Vault könnt ihr mit create-backup-vault anlegen. Dieser benötigt neben dem Namen auch keine weiteren Angaben.

Anschließend kommt unser erster richtiger AWS Befehl für das Script, den wir wieder hinter eine Variable schreiben.

# AWS TOPIC

$SNSTopicARN = aws sns create-topic –name $SNSTopicName | ConvertFrom-Json

$SNSTopicARN = $SNSTopicARN.TopicArn

Ein simpler Befehl, der ein neues SNS Topic auf eurem AWS Account anlegt.

Damit wir in der Variablen nur noch den Amazon-Ressourcennamen (ARN) des neu erstellten Topics haben, konvertieren wir die Ausgabe zuerst von JSON in ein PowerShell Objekt und wählen danach nur die TopicArn aus.

Ein neu erstelltes SNS Topic beinhaltet jedoch noch nicht unsere gewünschte Zugriffsrichtlinie, ohne die wir keine Benachrichtigungen erhalten würden.

aws sns set-topic-attributes –topic-arn $SNSTopicARN –attribute-name Policy –attribute-value „{\`“Version\`“:\`“2008-10-17\`“,\`“Id\`“:\`“__default_policy_ID\`“,\`“Statement\`“:[{\`“Sid\`“:\`“__default_statement_ID\`“,\`“Effect\`“:\`“Allow\`“,\`“Principal\`“:{\`“Service\`“:\`“backup.amazonaws.com\`“},\`“Action\`“:\`“SNS:Publish\`“,\`“Resource\`“:\`“$($SNSTopicARN)\`“}]}“

Hier wird angegeben, dass der Service Principal von backup.amazonaws.com Zugriffsrechte auf das SNS Topic erhält.

Denjenigen, die sich jetzt vielleicht wundern, warum wir das nicht einfach alles im AWS GUI gemacht haben, sei gesagt: Der nächste Schritt lässt sich nur in der CLI erledigen.

Im GUI lassen sich die Zugriffsrichtlinie sowie die Abonnements vom SNS Topic leicht verwalten und editieren. Jedoch lassen sich die Ereignisse, bei denen eine Benachrichtigung verschickt wird, nicht einstellen.

aws backup put-backup-vault-notifications —backup-vault-name $BackupVaultName –sns-topic-arn $SNSTopicARN —backup-vault-events `

BACKUP_JOB_STARTED `

BACKUP_JOB_COMPLETED `

BACKUP_JOB_SUCCESSFUL `

BACKUP_JOB_FAILED `

BACKUP_JOB_EXPIRED `

RESTORE_JOB_STARTED `

RESTORE_JOB_COMPLETED `

RESTORE_JOB_SUCCESSFUL `

RESTORE_JOB_FAILED `

COPY_JOB_STARTED `

COPY_JOB_SUCCESSFUL `

COPY_JOB_FAILED `

RECOVERY_POINT_MODIFIED `

BACKUP_PLAN_CREATED `

BACKUP_PLAN_MODIFIED

In unserem Beispiel geben wir alle möglichen Ereignisse an. Diese können nach Belieben entfernt oder hinzugefügt werden.

Jetzt haben wir einen neuen SNS Topic, der mit unserem Backup Vault verbunden ist und unsere Ereignisse beinhaltet.

Alles, was wir noch machen müssen, ist, dem Topic unsere Protokoll-Adresse mitzuteilen, auf der wir die Benachrichtigungen erhalten wollen.

Dazu abonnieren wir unser zuvor erstelltes Topic mit dem sns subscribe Befehl:

aws sns subscribe –topic-arn $SNSTopicARN –protocol $ProtocolType –notification-endpoint $ProtocolNotification

Wenn wir jetzt unser Script ausführen, bekommen wir eine Subscription-Benachrichtigung (je nach angegebenen ProtocolType z.B. per Email), die wir bestätigen müssen, um anschließend die gewünschten Mitteilungen, bei eintretenden Backup-Events, zu erhalten.

Und schon sind wir fertig!

Fazit

Vieles lässt sich über das GUI erledigen, doch für manche Konfigurationen ist die AWS CLI unabdingbar und auch viel cooler 😉

Warum also nicht gleich alles in einem?

Mit einem PowerShell Script lässt sich der Prozess deutlich vereinfachen und übersichtlicher gestalten – und es ist auch wieder verwendbar!

 

Im nächsten Teil erweitern wir unser Script und fügen einen Backup Plan hinzu, wodurch wir den gesamten Erstellungsprozess mit allen Komponenten, die für ein Backup benötigt werden, auf einmal aufbauen.

Das könnte dich auch interessieren

Webinar

Von der Cloud-Idee zum konkreten Azure-Projekt: Mit Microsoft Funding schneller in die Umsetzung

Wie wird aus der Entscheidung für Azure ein konkretes Projekt? In unserem Webinar erfahren Sie, wie Sie Migration und Modernisierung strukturiert planen, Workloads priorisieren und Microsoft Funding gezielt einbinden.
Weiterlesen
Blogbeitrag

Microsoft setzt auf Passkeys: Warum Unternehmen jetzt ihre MFA-Prozesse neu denken sollten 

Microsoft setzt zunehmend auf Passkeys und phishing-resistente Authentifizierung. Wir zeigen, was das für Onboarding und MFA-Recovery bedeutet und wie der Temporary Access Pass dabei unterstützt.
Weiterlesen
Blogbeitrag

mbuf Jahreskongress 2026

Das Event des Microsoft Business User Forums – Austausch, Wissen und Vernetzung im Microsoft-Umfeld. Seien Sie dabei!
Weiterlesen
Webinar

Datenklassifizierung: Was NIS2, Copilot und KI von Ihren Daten einfordern und wie Sie jetzt das Fundament legen, das wirklich hält

Viele Unternehmen haben Sensitivity Labels – und trotzdem bleiben große Teile ihrer Daten unklassifiziert. Im Webinar zeigen wir, wie Microsoft Purview und Informationscluster die Basis für Copilot, KI und Compliance schaffen.
Weiterlesen
M365 Summit

M365 Summit – Bereit für die Zukunft mit Microsoft 365?

Treffen Sie uns beim M365 Summit 2026 in Mainz und erleben Sie unsere Session mit MLP rund um Power Platform und KI-Transformation.
Weiterlesen
Blogbeitrag

Warum Exit-Readiness zu einer belastbaren Cloud-Strategie gehört 

DORA, NIS2, DSGVO & Co. erhöhen die Anforderungen an den Umgang mit Cloud-Abhängigkeiten. Wir zeigen, warum Exit-Readiness zunehmend zur Compliance-Pflicht wird und welche Nachweise Auditoren konkret erwarten.
Weiterlesen
Blogbeitrag

Typische KI-Workflows im Unternehmen: Welche Aufgaben in Chat, Agenten und Zielsysteme gehören

Gute KI-Workflows entstehen durch klare Arbeitsteilung: Wir zeigen, welches Werkzeug sich für welchen Arbeitsschritt eignet – und wie KI dadurch effizienter und wirtschaftlicher wird.
Weiterlesen
Blogbeitrag

Warum Cloud Exit kein Widerspruch zur Cloud-Strategie ist

Was bedeutet Cloud Exit wirklich? Erfahren Sie, warum Unternehmen trotz Microsoft Cloud auf Exit-Readiness setzen sollten und welche Rolle DORA, NIS2 und DSGVO spielen.
Weiterlesen
Webinar

12.500 € verbrannt und niemand merkt’s: So verhindern Managed Services Kostenfallen und Risiken

In diesem kostenlosen Webinar erfahren Sie, wie Azure-Kostenfallen entstehen, wie Fehlkonfigurationen frühzeitig erkannt werden und welche Betriebsstandards Managed Services dafür einsetzen.
Weiterlesen
Blogbeitrag

KI wirtschaftlich einsetzen: Warum nicht jede Aufgabe einen KI-Agenten braucht

Nicht jede Aufgabe braucht einen KI-Agenten – und nicht jede Automatisierung überhaupt KI. Erfahren Sie, wie Sie für jede Anforderung die passende Lösung wählen und KI wirtschaftlich, effizient und mit der richtigen Komplexität einsetzen.
Weiterlesen
Jetzt Blogbeitrag teilen
Xing LinkedIn Facebook Twitter