Securing Your SAP Workloads on AWS: Best Practices for Managing Web Traffic

At Lynxmind we combine the best practices from both worlds SAP + AWS to design and deploy highly available SAP systems, in a safe and cost-optimized way.

This article provides insights into the architecture of the SAP Web Dispatcher on AWS, showing common patterns and common practices to handle internal requests coming from the corporate network, and external requests coming from the public internet. Additionally, check out how to use a Web Application Firewall to strengthen your security posture when handling external (public) requests.

What is SAP Web Dispatcher and its use?

Note: The focus of this article is to discuss different architectures to deploy the SAP Web Dispatcher using AWS as an example. It is not the intention to point out all the capabilities and detailed configurations of this tool. For more information, check SAP’s documentation .

The SAP Web Dispatcher is located between the Web client (browser) and your SAP system that is running the Web application.

It is the entry point for HTTP(s) requests into your system, which consists of one or more SAP NetWeaver application servers. As a “software web switch”, SAP Web Dispatcher can reject or accept connections.

When it accepts a connection, it balances the load to ensure an even distribution across the servers. SAP Web Dispatcher, therefore, contributes to security and also balances the load in your SAP system. You can use SAP Web Dispatcher in both ABAP and Java systems.

Below are some of the tasks performed by an SAP Web Dispatcher:

• Selection of appropriate application server - Persistence with stateful applications, load balancing, ABAP or Java server.
• Configuration for multiple systems - You can place an SAP Web Dispatcher in front of multiple SAP systems, and configure which requests go to which system, or perform load balancing across system boundaries.
• URL filtering - You can define URLs that you want to be rejected, and by doing so restrict access to your system.
• Web caching - You can use the SAP Web Dispatcher as a Web Cache to improve the response times and to conserver the application server cache.
• URL rewriting, manipulation of HTTP header fields - The Web Dispatcher can manipulate inbound HTTP requests in general on the basis of defined rules.
• Depending on the SSL configuration you can forward, terminate, and (re)encrypt requests.

With this quick recap, let’s talk about our first architectural pattern…

Pattern 1 - SAP Web Dispatcher Architecture for Internal (Corporate Network) Requests

The following diagram illustrates the architecture of a customer network connected to an AWS VPC through AWS Direct Connect.

Note: This is a high-level example to make our case, however, for larger AWS multi-account implementations this would not be the network architecture as you would use separate accounts for egress and ingress traffic for scaling, having a Transit Gateway to manage all connections. Check this AWS blog for more details.

Pattern 1 - Internal Requests

Request Flow:

1. An end-user sends an HTTP(s) request from the internal corporate network, which is connected to the AWS VPC via AWS Direct Connect.
2. The internal Application Load Balancer (ALB) receives the request and sends it to the respective Target Group.
3. The Target Group distributes the load among all SAP Web Dispatchers available (02 servers in this example).
4. The SAP Web Dispatcher which received the request forwards it to the SAP backend system by using Logon Groups for load balancing purposes in the SAP application layer.

This high-level design represents internal connections coming from the corporate network. However, many customers have the requirement to receive external requests from the public internet as well, and this is what we are going to see in the next pattern…

Read the full article on our website. ??

https://www.lynxmind.com/blog/sap-on-aws