AWS Cloud Operations Blog
Increase SAP workloads scalability and resiliency with AWS native Application Load Balancer
In the evolving landscape of SAP systems, the transition to web-based access via SAP FIORI has necessitated robust load balancing solutions. Traditionally, end-users accessed SAP systems using the SAP GUI installed on their PC/laptop. However, critical transactions are now increasingly processed through web browsers. For scenarios like SAP HR time entry, these transactions might also be managed using the SAP NetWeaver Portal. A crucial component in this architecture is the load balancer. AWS offers the Amazon Application Load Balancer (ALB), which can distribute incoming SAP application traffic across multiple targets (e.g., SAP Web Dispatchers or SAP Application Servers hosted on Amazon Elastic Compute Cloud (EC2)) in one or more Availability Zones (AZs). While SAP Web Dispatcher (WD) has been a common choice for a load balancer, many organizations are now opting for Amazon’s Application Load Balancer (ALB) due to its enhanced features, easier management and operability, optimized costs, and integration with the AWS ecosystem.
Amazon Application Load Balancer (ALB) Overview
An Application Load Balancer (ALB) operates at the request level (Layer 7) application layer, the seventh layer of the Open Systems Interconnect (OSI) model. It evaluates listener rules to determine which rule to apply and selects a target from the target group for the rule action. Listener rules can route requests to different target groups based on application traffic content. The default routing algorithm is round robin, but it can be configured to use the least outstanding requests algorithm.
SAP Web Dispatcher Overview
Per SAP’s documentation, the SAP Web Dispatcher is the entry point for HTTP(s) requests into an SAP system, operating as a “software web switch” or a reverse proxy. It balances the load across the servers, ensuring an even distribution and contributing to system security. The SAP Web Dispatcher typically sits between the Web client (browser), an additional load balancer (s), and the SAP system running the Web application.
Key Considerations for Choosing Between SAP Web Dispatcher and Amazon ALB
Customers and partners often question whether to use an SAP Web Dispatcher, Amazon ALB, or both, based on their specific SAP workload requirements. This blog will focus on the functionalities and features that are common to or exclusive between SAP Web Dispatcher and Amazon ALB, while third-party load balancers and self-managed solutions on AWS are beyond its scope.
Solution Overview
To derive to the recommended solution it is imperative for us to go through important set of functionalities and their descriptions for a load balancer, in this case an SAP Web Dispatcher, and an Amazon ALB. Table 1.1 refers to the “same functionality” between an SAP Web Dispatcher and an Amazon ALB:
Functionality | Description | Application Load Balancer | SAP Web Dispatcher |
---|---|---|---|
HTTPS Termination | Intercepts encrypted HTTPS traffic when a server receives data from a secure socket layer (SSL) connection in an SSL session. SSL termination or SSL offloading decrypts and verifies data on the load balancer instead of the application server. | Yes | Yes |
Session Persistence | Session stickiness, a.k.a., session persistence, is a process in which a load balancer creates an affinity between a client and a specific network server for the duration of a session (i.e., the time a specific IP spends on a website). | Yes | Yes |
Support for HTTP/2 | An HTTP/2 load balancer must be capable of understanding and effectively handling HTTP/2 traffic, which includes features like multiplexing multiple requests over a single connection, prioritization of requests, and header compression. | Yes | Yes |
Server Name Indication (SNI) | An SNI (Server Name Indication) load balancer inspects the hostname requested in the TLS handshake and intelligently routes HTTPS traffic to the appropriate backend server hosting that website or service, rather than relying only on IP addresses and ports. | Yes | Yes |
Multiple Systems Routing | Distributes incoming network traffic across multiple systems or servers based on certain routing criteria. This type of load balancer is commonly used in distributed systems or large-scale applications to achieve high availability, scalability, and reliability. | Yes | Yes |
HTTP Header-based Routing | HTTP Header-based Routing load balancing refers to a method of distributing incoming HTTP requests across multiple backend servers or systems based on information contained within the HTTP headers of the incoming requests. | Yes | Yes |
HTTP Method-based Routing | HTTP Method-based Routing load balancing is a method where incoming HTTP requests are distributed across multiple backend servers or systems based on the HTTP method (such as GET, POST, PUT, DELETE, etc.) used in the request. | Yes | Yes |
mTLS | An mTLS load balancer is capable of terminating and initiating mutual TLS connections, requiring cryptographic certificates to authenticate both clients and backend servers. By enforcing encryption and mutual authentication, mTLS load balancers provide end-to-end security for sensitive applications. | Yes | Yes |
Table 1.1: “Same functionality” between an SAP Web Dispatcher and ALB
Table 1.2 refers to the “exclusive functionality” between an SAP Web Dispatcher and ALB:
Functionality | Description | Application Load Balancer | SAP Web Dispatcher |
---|---|---|---|
Load Balancing Algorithm | A load balancing algorithm is a method or strategy used by load balancers to distribute incoming network traffic across multiple servers or resources in a balanced and efficient manner. Common algorithms include Round Robin, Least Connections, IP Hash, and Weighted Round Robin. | Round-robin, Least-outstanding-Request, Automatic target weights | Simple Round-robin, Weighted-round-robin, Adaptive |
Web Caching | Caching capabilities to optimize the delivery of web content, improve scalability, and enhance the performance of web applications. | Possible with Amazon CloudFront | Yes |
Custom HTTP Headers | The ability of the load balancer to add certain headers by default to all HTTP(S) requests and responses that it proxies between backends and clients. | Possible with Amazon CloudFront | Yes |
Request Manipulation | Modifies or manipulates incoming HTTP requests before forwarding them to backend servers, including altering headers, parameters, payloads, or destination URLs to meet specific requirements. | No | Yes |
URL Filtering | Involves defining rules or patterns to inspect the URLs of incoming requests and then making routing decisions based on those rules. This enables traffic direction to specific backend systems or services based on URL characteristics. | Possible with AWS Web Application Firewall (WAF) | Yes |
Support of Web Sockets for RFC | Allows calling remote-enabled function modules (RFMs) over HTTP/WebSocket without requiring VPN connections. WebSocket is upgraded HTTP, allowing the use of reverse proxies, routers, etc., instead of SAProuter. | Yes (ABAP-ABAP connections only, no multiplexing, potential performance penalty) | Yes |
High-Availability (in-built) | Ensures continuous operation and minimal downtime, even in the event of hardware failures, software glitches, or other disruptions, maintaining uninterrupted service availability. | Yes | No |
Scalability | Dynamically adjusts resources or capacity to handle increasing traffic levels and growing demands on the system, ensuring optimal performance and resource utilization at all times. | Adaptive (Non-configurable) | Configurable (proactive/reactive) |
Native Integration with AWS Services | Seamless integration with services like AWS CloudFront, AWS CloudWatch, Amazon Certificate Manager (ACM), and AWS Web Application Firewall (WAF). | Yes | No |
Maintenance and Operations | Maintenance and operations related to load balancers, such as regular updates and patching, to ensure continued availability, performance, and security of applications and services. | AWS Managed | Customer-managed |
Table 1.2: “Exclusive functionality” between an SAP Web Dispatcher and ALB
Based on Table 1.1 “same functionality”, and Table 1.2 “exclusive functionality”, Figure 1.1 shows the decision matrix which can help you decide on whether to choose an SAP WD or an Amazon ALB or both for your SAP workloads on AWS:
Note 1: In Figure 1.1, PAS refers to Primary Application Server and AAS refers to Additional Application Server.
Note 2: For a High Availability (HA) configuration, you can also implement embedded SAP WD within the SAP ASCS/ERS instance and front end with multiple ALBs. However, at any given point in time the WD service will be running in an active-passive mode so decision should be based on the fact that whether a single web dispatcher can handle the production workload. More information can be found in SAP Note: 3115889 (SAP login required).
Figure 1.1: Amazon ALB vs. SAP Web Dispatcher – Decision Tree
Decision Matrix
Based on the functionalities, the following decision matrix can help determine the best load balancing solution for your SAP workloads on AWS:
- For scenarios fully covered by the shared functionalities (as shown in Table 1.1), Amazon ALB is the preferred choice.
- For exclusive functionalities (as shown in Table 1.2) needed in specific cases, deploying ALB behind SAP Web Dispatchers can offer the best of both worlds.
- For non-critical workloads, the choice between ALB and Web Dispatcher depends on operational convenience and specific requirements.
Conclusion
The key differentiator of Amazon ALB is its cloud-native nature. It seamlessly integrates with AWS Web Application Firewall (WAF) to mitigate known vulnerabilities, Amazon CloudFront for content delivery acceleration, AWS Certificate Manager (ACM), and Identity Access and Management (IAM) certificate stores for TLS/SSL certificate management. By monitoring ALB with Amazon CloudWatch, you can proactively track specific exceptions, metric thresholds, and manage state changes with event-driven response mechanisms, enabling automated actions.
Another important aspect of any internet or internal facing application is its security. The need to patch, update, and maintain the Web Dispatcher, and its underlying host components by yourself presents a significant challenge in addressing vulnerabilities that emerge constantly. In contrast, Amazon ALB is a purpose-built appliance continuously overseen by a team of security experts, benefiting from AWS’s substantial security investments. Its design as a purpose-built hardware significantly reduces its attack surface and enhances its security, unlike the Web Dispatcher, which has a broader attack surface. For information about AWS security services and how AWS protects infrastructure, see AWS Cloud Security. To design your SAP on AWS environment using the best practices for infrastructure see Security Pillar of AWS Well‐Architected Framework for SAP.
Useful Resources: