In diesem Blogartikel stellen wir eine Möglichkeit vor, wie SAP-Systeme in unterschiedlichen AWS-Accounts bequem mithilfe einer E-Mail gestartet und gestoppt werden können.

Aber warum das Ganze? In der Regel müssen nicht alle SAP-Systeme durchgehend 24/7 laufen – insbesondere Test-, Dev- oder QA-Systeme. Als Faustregel gilt: Wenn ein System weniger als 67 Stunden die Woche läuft, ist es günstiger, dieses System On-Demand betreiben zu lassen, anstatt eine All-Upfront-Reservierung für drei Jahre zu tätigen.

Es gibt verschiedene Möglichkeiten, SAP-Systeme automatisiert zu starten und zu stoppen. Die wohl bekannteste ist ein simpler Scheduler. Das bedeutet, dass die Systeme beispielsweise jeden Morgen um 8 Uhr gestartet und jeden Abend um 18 Uhr wieder heruntergefahren werden, und das von Montag bis Freitag. Daraus ergeben sich 50 Stunden Laufzeit pro Woche, die somit unter den 67 Stunden des Break-Even-Points liegen.

In der Regel sind diese Systeme jedoch nicht jeden Tag die vollen 10 Stunden in Betrieb, wodurch sich weitere Einsparungsmöglichkeiten ergeben, wenn das Starten und Stoppen der Systeme on-demand erfolgt. Hierfür wird eine komfortable und einfache Lösung benötigt. Kein SAP-Anwender möchte sich in der AWS-Konsole anmelden, um die EC2-Instanzen zu starten und daraufhin die SAP- und HANA-Dienste zu aktivieren, vor allem nicht bei verteilten Systemen mit mehreren EC2-Instanzen pro SAP-SID. Neben etablierten Lösungen wie einer Slack- oder Teams-Integration, bei der mithilfe eines Chatbots die Systeme gesteuert werden können, gibt es auch Unternehmen, die weder Slack noch Teams nutzen.

Doch was wahrscheinlich jedes Unternehmen nutzt, ist E-Mail. Daher habe ich mir diese Lösung überlegt, mit der der SAP-Anwender lediglich eine E-Mail mit dem Betreff „Start S4H“ an eine spezielle, von AWS bereitgestellte E-Mail-Adresse wie „account1@sap-start-stop.awsapps.com“ senden muss, um sein SAP-System mit der SID „S4H“ zu starten. Mit dem Betreff „Stop S4H“ wird das System wieder gestoppt. Vor dem @-Zeichen der E-Mail-Adresse können verschiedene Accounts angesprochen werden.

Anschließend verschickt das System mithilfe von SNS eine E-Mail, die den Empfang und den Beginn der Automatisierung bestätigt. Sobald das System erfolgreich gestartet wurde, wird eine weitere E-Mail an den SAP-Anwender verschickt.

Architektur Übersicht

Es gibt einen Shared-Service-Account, welcher die AWS-WorkMail-E-Mail-Adresse bereitstellt. Hierzu wird eine kostenfreie Testdomain genutzt, die für diese Zwecke vollkommen ausreichend ist. Mithilfe von SES-Rules werden die E-Mails an die jeweiligen S3-Buckets der angebundenen AWS-Accounts gesendet. Falls nur ein Account vorhanden ist, in dem sich die SAP-Systeme befinden, kann auch alles in einem Account betrieben werden.

In den jeweiligen Ziel-Accounts befindet sich ein S3-Bucket, in welchem die E-Mail von SES bereitgestellt wird. Der S3-Bucket besitzt eine Bucket-Policy, die SES vom Shared-Service-Account erlaubt, die E-Mails als Datei zu sichern.

Jeder S3-Bucket ist mit einem Trigger ausgestattet, der bei neuen Dateien unter dem Präfix „incoming-email/“ ausgelöst wird. Dieser startet die Lambda-Funktion, welche zunächst prüft, ob der Absender der E-Mail auf der Allow-Liste steht. Dadurch wird sichergestellt, dass Unbefugte, die die E-Mail-Adresse ausfindig machen konnten, nicht ebenfalls die SAP-Systeme starten und stoppen können. Die Lambda-Funktion durchsucht dann den Betreff nach den Wörtern 'Start' oder 'Stop' und der jeweiligen SID.

Anschließend wird das SAP-System mit der genannten SID gestartet oder gestoppt. Dabei werden die EC2-Instanzen sowie die jeweiligen SAP- und HANA-Dienste gesteuert. Kernstück dieser Automatisierung ist die von mir angepasste Version, die im Gegensatz zum Original detailliertere SNS-Benachrichtigungen versendet, um genaue Informationen darüber zu liefern, welches System für welche SID oder in welchem Account gestartet oder gestoppt wurde. Dadurch wird es erleichtert, bei einer Vielzahl von SAP-Systemen und AWS-Accounts den Überblick zu bewahren.

Deployment der Solution

Um das Deployment der Lösung zu erleichtern, habe ich eine CloudFormation-Vorlage erstellt. Sie finden die Vorlage hier: GitHub.

Es gibt drei Schritte für das Deployment:

Schritt 1

Einrichten des Shared Service Accounts. Hier müssen Sie eine AWS WorkMail-Domain und SES-Weiterleitungsregeln erstellen, damit AWS E-Mails empfangen und sie zu spezifischen S3-Buckets über Accounts hinweg weiterleiten kann. Da CloudFormation dies nicht unterstützt, muss es manuell eingerichtet werden. Aber es ist schnell und einfach und es gibt eine Anleitung auf GitHub, die Sie dabei durchführt.

Schritt 2

Deployment in den Ziel-Accounts, die die SAP-Systeme betreiben. Hier erstellen Sie den S3-Bucket und setzen die richtige Bucket-Policy, damit der Shared Service Account E-Mails an diesen Bucket senden kann. Dann richten Sie eine Lambda ein, um den Absender gegen eine erlaubte Domain-Liste zu prüfen und den E-Mail-Betreff nach "Start" oder "Stop" und der richtigen SID zu scannen. Es gibt auch die SSM-Automatisierung für die Verwaltung von EC2-Instanzen und SAP- und HANA-Prozessen, sowie ein SNS-Topic, um Sie zu informieren, wenn Befehle verarbeitet und abgeschlossen wurden. All dies ist in einer CloudFormation-Vorlage auf GitHub verpackt, die ein schnelles Setup für jeden Ziel-Account bietet. Wiederholen Sie diesen Schritt für jeden Ziel-Account, falls Sie mehr als einen haben.

Schritt 3

Taggen der EC2-Instanzen. Dies hilft der SSM-Automatisierung, die richtigen Instanzen für jede SAP-SID zu finden. Verwenden Sie die folgenden Tags:

ssmsap:enabled = TRUE (oder FALSE zum Deaktivieren)

ssmsap:role = HANA, APP, SCS oder Kombinationen wie APP,SCS für Instanzen mit beiden Rollen.

ssmsap:sid = Die SID für das Netweaver-System auf APP- und SCS-Instanzen.

ssmsap:hanatenant = Die Netweaver-System-SID auf HANA-Instanzen (auch wenn der DB Tenant-Name nicht mit der SID übereinstimmt).

Denken Sie daran, dass Tag-Value exakt ist und Werte in Großbuchstaben angegeben werden müssen.

Sie können nun eine E-Mail mit dem Betreff, zum Beispiel "Start S4H", an Ihre AWS WorkMail-Domain senden. Sie erhalten eine Bestätigungs-E-Mail, gefolgt von einer Benachrichtigung, sobald das System gestartet wurde.

Herzlichen Glückwunsch, Sie haben erfolgreich ein SAP-System auf AWS über eine E-Mail gestartet!

Jetzt können zusätzliche Abonnenten zum SNS-Topic "SSMSAPStartStopNotifications" hinzugefügt werden. Alle Abonnenten erhalten E-Mail-Benachrichtigungen für jedes Start- und Stoppereignis.

Um die erlaubte Domain-Liste zu erweitern – also mehr E-Mail-Adressen hinzuzufügen, die berechtigt sind, diese Automatisierung zu nutzen – aktualisieren Sie einfach den CloudFormation-Stack.

AWS Services und Kosten für die Automatisierung

Folgende AWS Services werden für diese Solution genutzt, und die dazugehörigen Kosten dargestellt:

Wie zu sehen ist, würden selbst bei einer intensiven Nutzung der SAP-Start-/Stop-Automatik via Mail lediglich monatliche AWS-Kosten im Cent-Bereich anfallen. Der Grund dafür liegt in der Verwendung von Serverless-Services, die eine sehr kosteneffiziente Skalierung ermöglichen.

Aus meiner Sicht gibt es einfach keine Alternativen, die an die Wirksamkeit der ausgewählten AWS-Dienste für diese Lösung heranreichen.

AWS WorkMail erlaubt es mir mit seiner kostenlosen Testdomain, E-Mails in meinem AWS-Konto kostenfrei zu empfangen und anschließend zu verarbeiten.

Simple Email Service (SES) bietet eine bequeme und schnelle Methode, um eingehende E-Mails von WorkMail in die jeweiligen S3-Buckets weiterzuleiten.

Simple Storage Service (S3) ist die kostengünstigste Speicheroption für diesen Anwendungsfall und integriert sich nahtlos in die SES- und Lambda-Dienste.

Lambda bietet den einfachsten und kostengünstigsten Ansatz, um meine Logik zur Überprüfung der Absender, zum Durchsuchen der E-Mail-Betreffzeilen und zum Initiieren von der SSM-Automatisierung auszuführen.

AWS Systems Manager (SSM) Automation ermöglicht es mir, die komplexen Start- und Stop-Prozesse eines SAP-Systems zu koordinieren und auszuführen.

SNS Topic ist mit Abstand der einfachste Weg, um meine Nutzer über die Initiierung und Fertigstellung des Automatisierungsprozesses zu informieren.

Vorteile starten und stoppen via Mail

Die Implementierung dieser Lösung zum Starten und Stoppen von SAP-Systemen per E-Mail ist einfach und kann in nur wenigen Minuten eingerichtet werden. Ein weiterer entscheidender Vorteil gegenüber alternativen Lösungen wie Integration in Teams oder Slack ist, dass keine zusätzliche Zusammenarbeit mit einem Teams- oder Slack-Administrator erforderlich ist. Durch das Eliminieren dieser Abhängigkeit kann die Lösung autonom und ohne zusätzliche organisatorische Hürden genutzt werden, was sie ideal für Unternehmen macht, die eine schnelle und einfache Möglichkeit zum Starten und Stoppen ihrer SAP-Systeme möchten.

Aus meiner Erfahrung hat sich ein zeitgesteuertes Notausschalten als nützlich erwiesen, beispielsweise indem die SAP-Systeme jeden Tag automatisch um 20 Uhr abgeschaltet werden, falls jemand das System per E-Mail startet, aber vergisst, es wieder herunterzufahren.

Um dies zu erreichen, müssen Sie ein AWS Systems Manager (SSM) Maintenance Window erstellen. Die Stoppzeit kann mit einem Cron-Ausdruck definiert werden.

Beim Einrichten der Aufgabe wählen Sie "Register automation task". Von dort aus wählen Sie die SSM-Automatisierung mit dem Titel "ssmsapstartstop" aus, die mit CloudFormation erstellt wurde.

Für die Ziele wählen Sie "Task target not required". Geben Sie in den Eingabeparametern die entsprechende Operation an - entweder Stop oder Start - und die SID. Dieser Schritt der Registrierung der Aufgabe muss für jede SID durchgeführt werden, die Sie in den Notausschaltprozess einbeziehen möchten.

Things to consider

Die automatische Start-/Stop-Funktion unterstützt nur SAP S/4HANA-Systeme. Grundsätzlich ist es möglich, mit dieser Lösung auch andere Systeme zu starten oder zu stoppen, aber das SSM-Automatisierungsdokument und die Lambda-Funktion müssten angepasst werden.

AWS WorkMail ist nur in den Regionen "N. Virginia", "Oregon" und "Irland" verfügbar. Daher muss der Shared Service Account in einer dieser Regionen eingerichtet werden. Die Zielkonten und ihre SAP-Systeme können sich jedoch in jeder Region befinden.

Wir freuen uns auf einen persönlichen Austausch zu diesem Thema. Folgen Sie unserem Autor Patrick Zink auf LinkedIn und schreiben Sie ihm gerne zu diesem Thema.