In this blog article, we present a way to conveniently start and stop SAP systems in different AWS accounts via email. But why all this? In general, not all SAP systems need to run continuously 24/7 - especially test, development or QA systems. As a rule of thumb, if a system runs less than 67 hours a week, it is cheaper to run it on demand than to make a three-year reservation in advance.
There are several ways to start and stop SAP systems automatically. The most common is probably a simple scheduler. This means, for example, that the systems are started every morning at 8 a.m. and shut down every evening at 6 p.m., from Monday to Friday. This results in 50 hours of running time per week, which is less than the 67 hours of the break-even point:
However, these systems are not usually in operation for the full 10 hours every day, which opens up further potential savings if the systems are started and stopped on-demand. A convenient and simple solution is needed for this. No SAP user wants to log into the AWS console to both start the EC2 instances and the SAP and HANA services, especially not for distributed systems with multiple EC2 instances per SAP SID. In addition to established solutions such as Slack or Teams integration, where the systems can be controlled using a chatbot, there are also companies that use neither Slack nor Teams.
But what probably every company uses is email. So I came up with this solution, where the SAP user just needs to send an email with the subject "Start S4H" to a special email address provided by AWS like "account1@sap-start-stop.awsapps.com" to start their SAP system with the SID "S4H". The system is stopped again with the subject "Stop S4H". Various accounts can be addressed before the @ sign of the e-mail address.
The system then uses SNS to send an email confirming receipt and the start of the automation. Once the system has been successfully started, another email is sent to the SAP user.
Architecture overview
There is a shared service account that provides the AWS WorkMail email address. A free test domain is used, which is perfectly adequate for these purposes. Using SES rules, the emails are sent to the appropriate S3 buckets of the connected AWS accounts. If there is only one account where the SAP systems are located, everything can be run in one account.
There is an S3 bucket in each target account where the email from SES is made available. The S3 bucket has a bucket policy that allows SES to store the emails as a file from the shared service account.
Each S3 bucket has a trigger that is activated for new files with the prefix "incoming-email/". This triggers the Lambda function, which first checks whether the sender of the email is on the Allow list. This ensures that unauthorised persons who are able to find the email address cannot also start and stop the SAP systems. The Lambda function then searches the subject for the words 'Start' or 'Stop' and the corresponding SID.
It then starts or stops the SAP system with the specified SID. This controls the EC2 instances and the corresponding SAP and HANA services. At the heart of this automation is my customised version which, unlike the original, sends more detailed SNS notifications to provide precise information about which system has been started or stopped for which SID or in which account. This makes it easier to keep track of a large number of SAP systems and AWS accounts.
To make deploying the solution easier, I have created a CloudFormation template. You can find the template here: GitHub
.
Three steps to deploy
Step 1
Set up the Shared Service Account. Here, you need to create an AWS WorkMail domain and SES forwarding rules so that AWS can receive emails and forward them to specific S3 buckets across accounts. Since CloudFormation doesn't support this, it has to be done by hand. But it's quick and simple, and there's a guide on GitHub to walk you through it.
Step 2
Deploy in Target Accounts that run the SAP systems. This is where you create the S3 bucket and set the right bucket policy so the Shared Service Account can send emails to this bucket. Then you set up a Lambda function to check the sender against an allowed list and scan the email subject for "Start" or "Stop" and the right SID. There's also the SSM Automation for managing EC2 instances and SAP and HANA processes, and an SNS Topic to let you know when commands are processed and completed. All of this is packaged in a CloudFormation template on GitHub, offering a quick setup for each Target Account. Repeat this step for every Target Account if you have more than one.
Step 3
Tag the EC2 instances. This helps SSM Automation find the right instances for each SAP SID. Use the following tags:
ssmsap:enabled = TRUE (or FALSE to disable)
ssmsap:role = HANA, APP, SCS, or combinations like APP,SCS for instances with both roles.
ssmsap:sid = The SID for the Netweaver system on APP and SCS instances.
ssmsap:hanatenant = The Netweaver system SID on HANA instances (even if the DB tenant name doesn't match the SID).Remember, tag keys are exact, and values should be uppercase.
You can now send an email with the subject, for example, "Start S4H," to your AWS WorkMail domain. You will receive a confirmation email followed by a notification once the system has started.
Congratulations, you have successfully initiated an SAP system on AWS using an email!
Additional subscribers can now be added to the SNS Topic "SSMSAPStartStopNotifications". All subscribers will receive email notifications for every start and stop event. To expand the Allowed Domain List—which means adding more email addresses authorized to use this automation—simply update the CloudFormation stack.
AWS services and costs for the Solution
The following AWS services are used for this solution and the associated costs are shown:
As can be seen, even with intensive use of SAP start/stop automation via email, monthly AWS costs would only be in the cent range. The reason for this is the use of serverless services, which enable very cost-efficient scaling.
From my perspective, there are simply no alternatives that match the effectiveness of the chosen AWS services for this solution.
AWS WorkMail with its free test domain, allows me to receive emails in my AWS account at no cost and to process them subsequently.
Simple Email Service (SES) provides a convenient and swift method to route incoming emails from WorkMail to their respective S3 buckets.
Simple Storage Service (S3) is the most cost-effective storage option for this use case and integrates seamlessly with SES and Lambda services.
Lambda offers the easiest and most cost-efficient approach to execute my logic for verifying senders, parsing email subjects, and initiating SSM Automation tasks.
AWS Systems Manager (SSM) Automation enables me to coordinate and execute the complex startup and shutdown processes of an SAP system effortlessly.
SNS Topic is by far the simplest way to notify my users about the initiation and completion of the automation process.
Start and stop advantages via mail
The implementation of this solution for starting and stopping SAP systems via email is extremely simple and can be set up in just a few minutes. Another decisive advantage over alternative solutions such as integration in Teams or Slack is that no additional cooperation with a Teams or Slack administrator is required. By eliminating this dependency, the solution can be used autonomously and without additional organizational hurdles, making it ideal for companies that want a quick and easy way to start and stop their SAP systems.
In my experience, a time-controlled emergency stop has proven to be useful, for example by automatically shutting down the SAP systems at 8 p.m. every day shut down automatically if someone starts the system by e-mail but forgets to shut it down again.
To accomplish this, you will need to create an AWS Systems Manager (SSM) Maintenance Window. The stop time can be defined using a cron expression.
When setting up the task, choose "Register Automation task." From there, select the SSM Automation titled "ssmsapstartstop" that was created with CloudFormation.
For targets, opt for "Task target not required." In the input parameters, specify the appropriate operation—either Stop or Start—and the SID. This step of registering the task must be completed for each SID that you want to include in the emergency stop process.
Things to consider
The automatic start/stop function only supports SAP S/4HANA systems. In general, it is possible to start or stop other systems with this solution, but the SSM Automation document and the Lambda function would have to be adapted.
AWS WorkMail is only available in the regions "N. Virginia", "Oregon" and "Ireland". Therefore, the shared service account must be set up in one of these regions. The target accounts and their SAP systems can be located in any region.
We look forward to a personal exchange on this topic. Follow our author Patrick Zink on LinkedIn and feel free to write to him on the topic.