Mountain panorama in red-purple tones

Balance Your Sap Workloads Like Never Before

A series of five blogposts in which we outline how to set up enterprise-grade SAP systems on AWS Cloud. This is part 4 of the series.

October 14 2020Norbert Putz

Network Load Balancer Setup with Target Groups

This blog post series is based on a proof of concept to demonstrate how easy it is to connect SAP Application Servers to a Network Load Balancer, which also has a connection to an Auto Scaling group to use the elastic feature of the cloud. With the help of this architecture, it is possible to scale in and out based on scaling policies in multiple availability zones (AZ). In this part we will focus on the Network Load Balancer and connect it to the auto scaling group. 


Abbildung1, Screenshot SAP on AWS

Figure 1: Three types of load balancers 

What happened in part 3? We have set up the auto scaling group and we were able to scale out based on predefined metrics because of a planned stress event with stress-ng. Let’s see how we can combine the Network Load Balancer with the auto scaling group.

Load Balancers in General

In part 3 of this blog series, I announced that we will get back to the load balancing part of the auto scaling group. And here we go: Our journey starts again in the EC2 console. On the left-hand side in the navigation pane, we have selected Load Balancers and clicked on the blue button in the middle Create Load Balancer. At this stage, we can choose from three types of Load Balancers: Application Load Balancer, Network Load Balancer and Classic Load Balancer. The Application Load Balancer provides a flexible feature to balance your HTTP (TCP/port 80) and HTTPS (TCP/port 443) loads between instances in a target group. But, you might remember, in our scenario we are communicating on port 3200 with the SAP dispatcher. Wrong port – so we need another solution. We could use Classic Load Balancer but therefore we need an application running in the EC2 classic network – and AWS recommends not to use it because it is a bit outdated and best fits for previous generations for HTTPS, HTTP and TCP traffic. The best solution for our case is to set up a Network Load Balancer. As the short introduction on figure 1 shows: “It is capable of handling millions of requests per second securely while maintain ultra-low latencies”. This is what we need. 

Setup of a Network Load Balancer attached to an Auto Scaling Group


Figure 2: Load balancing setting in auto scaling group

As shown in figure 2, at first, we will edit the setting load balancing for the auto scaling groups:


Figure 3: Basic configuration 

It contains two options: Load balancer target groups and Classic Load Balancer. As we will use Network Load Balancer, we will only set the target group. 

We will create the Network Load Balancer, which includes a step to create the target group. In step 1, we define the name and the scheme, which can be internet-facing and internal. We will go for the internal one as all our instances are running within one VPC. Let’s define the listener to TCP on port 3200. This is the port for the SAP dispatcher but we can add more listeners (up to 50) for one load balancer. For more information about limitation, consult the AWS official documentation


Figure 4: Specifying target group

In the next section, we will enable all availability zones because we would like to reach a multi availability zone solution at the end. 


Figure 5: Enable cross-zone load balancing

In this section we define to which targets in which target group our load balancer will route the requests using TCP protocol and 3200 as port. In addition, we have the possibility to set health check settings. We will leave the health check settings as they are for now. 

Our aim is to balance the load between different availability zones. Therefore we have to enable the setting Cross-Zone Load Balancing as shown in figure 5. 



Figure 6: Set target group for our load balancer

Finally, we need to set the target group for our load balancer. It has been created in blog series part 3 (sap-test-tg), so we will just use that as shown in in figure 6.

First test without stress


Figure 7: Healthy targets

First let’s see, whether we can reach our instances in the auto scaling group. We will change the capacities back to the values we used in part 3 (desired: 2, minimum: 1, maximum: 5) to see, whether the load balancer uses the target group, which registers targets in the VPC. 


Figure 8: New system entry for Network Load Balancer

As figure 7 shows, we have two desired EC2 instances in healthy status. As next step, in SAP Logon (SAP frontend), we have created a new system entry and entered my Network Load Balancer’s DNS name. You can find it in the load balancer console (Description tab/DNS name)). 


Figure 9: SAP transaction OS01 comparison with EC2 console

Checking SAP transaction OS01, we will see that the Network Load Balancer routed the traffic on TCP/3200 to nlb-test-1 in availability zone us-east-1b as shown in figure 9. 


Figure 10:  Scale-in, the fastest way

Congratulations! Our Network Load Balancer works perfectly together with the auto scaling group thanks to the target group. Now let’s scale-in once again. As you already know the easiest way to scale-in is to change the desired, minimum, and maximum capacity to 0 as shown in figure 10.


Let’s see, what we have reached in this part. I think, this part was also an interesting one. We have created a target group based on an auto scaling group and assigned it to a Network Load Balancer. In SAP Logon, we have created a new system entry for the load balancer and got access to one of the SAP application servers. 

Cost Optimization – Best Practices

If you try out this proof of concept “live”, it is important that you take care of the costs. With SAP Cloud Appliance Library (CAL) you can suspend the landscape anytime, if you don’t need it at the moment. In the SAP CAL console, by clicking on Suspend, both instances will be stopped (not terminated). With this, it is possible to save money, if the trial is not in use. Costs don’t go to zero – as you can see in the cost example above also suspended instances will lead to costs. If the landscape is not used for days, it is worth to terminate it, so that even costs during suspend status are also eliminated. The SAP solution can be deployed again at any time. 

Appetizer for Part 5

„And next week you’ll see ...” – just like in TV series, this concluding section is about to provide a short introduction about what will happen in part 5. In our fifth part we will focus on the whole solution. We will stress the instances to scale-out and test our load balancer. We will get an impression how the scaling works and which instances will remain healthy.

Stay tuned, final part 5 will be published soon! Happy architecting!

About the author
Norbert Putz, Cloud Architect

Norbert Putz

Cloud Architect, T-Systems International GmbH

Show profile and articles
Do you visit t-systems.com outside of Germany? Visit the local website for more information and offers for your country.