Wann beschäftigt man sich mit neuen Diensten? In Unternehmen passiert das in der Regel immer dann, wenn bestimmte Einschränkungen umgangen oder Hürden überwunden werden müssen. Ein Beispiel ist der Einsatz von Cloudwatch. Das ist die von AWS bereitgestellte Monitoring-Lösung zur Überwachung der Infrastruktur in der Cloud. Will man beim Auftreten von Alarmen dafür individuelle Benachrichtigungen erstellen – zum Beispiel für den Helpdesk –, bietet der Alarm nur wenige Konfigurationsmöglichkeiten. Ein anderer Weg ist, die Nachrichten zunächst abzufangen, dann zu bearbeiten und abschließend weiterzusenden. Das klingt aufwendig, lässt sich aber mit bestimmten Diensten aus der Amazon-Cloud in kürzester Zeit mit einem serverlosen Ansatz lösen. Die Dienste des Vertrauens heißen SNS, Lambda und SES. Doch was verbirgt sich hinter diesen Akronymen?

SNS steht für Simple-Notification-Service und ist der von AWS verwaltete Dienst für Publish-/Subscribe-Benachrichtigungen zur Koordination der Zustellung von Nachrichten an abonnierende Endpunkte und Clients. Über dieses System lassen sich verschiedene Dienste durch sogenannte Themen verbinden. Diese werden wiederum von Konsumenten abonniert. Wird eine Nachricht an ein bestimmtes Thema gesendet, verteilt SNS diese an alle dazugehörigen Abonnenten.

AWS Lambda oder λ ist ein serverloser Datenverarbeitungsdienst, der den in der Funktion definierten Code beim Eintreffen bestimmter Ereignisse (zum Beispiel eine Nachricht in einem abonnierten SNS-Thema) ausführt. Man braucht sich nicht selbst um die Administration der Infrastruktur zu kümmern, da diese von AWS verwaltet wird. Dafür kann man sich voll und ganz auf den Code konzentrieren. Zudem wird nur die Rechenleistung berechnet, die tatsächlich genutzt wird. Ansonsten fallen keine zusätzlichen Kosten an.

Der letzte im Bunde ist der AWS Simple Email Service – kurz SES. Wie der Name vermuten lässt, stellt SES einen cloud-basierten Dienst zum Senden von E-Mails dar. Vor dem Versand muss eine eigene E-Mail-Adresse verifiziert werden. Erst dann kann von diesem Absender eine Nachricht direkt über AWS verschickt werden. Doch wie genau lässt sich diese serverlose Nachrichtenverarbeitung umsetzen?

Die Basis bildet ein neues SNS-Thema, das die Cloudwatch-Alarme als Ziel wählen können. Wird ein Alarm ausgelöst, wird eine Nachricht an das Thema gesendet und alle Clients, die es abonniert haben, erhalten eine Meldung. Einer der sogenannten Konsumenten wird zum Kernstück in der Verarbeitungskette: die Lambda-Funktion.

Die Lambda-Funktion kann in verschiedenen Programmiersprachen entwickelt werden, zum Beispiel in Node.js oder Python. Bibliotheken, um mit der AWS-Umgebung zu kommunizieren, sind darin bereits enthalten. Mittels der AWS Identity-Access-Management-Rollen werden die Berechtigungen definiert. Es gibt verschiedene Möglichkeiten, um eine Funktion auszulösen. Zum Beispiel kann das SNS-Thema, das die Alarme aus Cloudwatch empfängt, als Auslöser dienen. Beim Auslösen durch das Auftreten einer neuen Nachricht innerhalb des abonnierten Themas wird der Funktion ein Event-Parameter im JSON-Format (JSON steht für Javascript Object Notation) übergeben. Daraus lässt sich eine SNS-Nachricht extrahieren, die alle wichtigen Informationen über den Auslöser und die Eigenschaften des Alarms enthält. Sobald die Instanz-ID ausgelesen wurde, kann man weitere Informationen beispielsweise über die EC2-Instanz (Elastic Compute Cloud) mittels Lambda direkt aus AWS abrufen. Voraussetzung dafür ist allerdings, dass alle Berechtigungen korrekt gesetzt wurden.

Wie lassen sich notwendige Informationen zur Schwere des Alarms oder der verantwortlichen Teams hinzufügen? Auch diese Details können aktuell noch nicht im Alarm konfiguriert werden. Ein Lösungsansatz wäre die Verwendung der Beschreibungsfelder der Alarme. Sobald weitere Wunschparameter im JSON-Format hinterlegt werden, können diese in der Lambda-Funktion komfortabel ausgelesen und für die E-Mail verwendet werden. Mit dieser Informationen lässt sich die gewünschte E-Mail für den Helpdesk konstruieren und anschließend über die bei SES registrierte E-Mail-Adresse versenden. Alternativ kann man ein weiteres SNS-Thema erstellen und als Ziel für die Nachrichten verwenden. Das können der Helpdesk oder andere Benutzer abonnieren.

Wer sich jetzt die Frage stellt, ob er diese Konfiguration in jedem AWS-Account neu vornehmen muss  – Was auch bedeuten würde: Jedes Mal, wenn sich etwas ändert, den Code überall anpassen zu müssen. Wobei es auch hier Automatisierungsmöglichkeiten von AWS gibt –, dem sei die Angst genommen: Es reicht, die Funktion einmal zu erstellen, zum Beispiel in einem Shared-Services-Account. Sie kann anschließend für alle anderen Accounts, sei es für verschiedene Umgebungen oder Projekte, genutzt werden.

Das AWS-Berechtigungskonzept ermöglicht die Autorisierung von Ressourcen oder Diensten über Accounts hinweg. Dazu muss nur die Berechtigungsrichtlinie des SNS-Themas so modifiziert werden, dass das Thema Sender – und in diesem Fall Alarme – aus dem anderen Account akzeptiert. Danach kann das Thema in anderen Accounts zusätzlich als Ziel konfiguriert werden. Dieser Vorgang muss manuell mit Hilfe des Amazon-Ressourcennamen (ARN) erfolgen. Alternativ kann die Lambda-Funktion das SNS-Thema aus dem entsprechenden Accounts abonnieren. In diesem Fall muss die Berechtigung des Themas in dem Account, der die Alarmnachrichten empfängt, angepasst werden. Und zwar so, dass Abonnenten aus den anderen Accounts, speziell dem Account mit der Lambda-Funktion, akzeptiert werden.

Dieser kurze Ausflug in die Welt des Serverless Computing zeigt, dass es sich lohnt, über den Tellerrand von reiner Infrastrukturbereitstellung in der Cloud zu blicken. Dadurch gelingt es, Aufgaben zu vereinfachen und zusätzlich Kosten zu sparen. Außerdem lässt sich festhalten, dass es nicht nur einen Weg gibt, um die Services zu nutzen, sondern dass sich diese sehr flexibel in bestehende Lösungen integrieren lassen.