Load Balancer General Guidelines
TinyURL = Dsd5yQ Content Owner = Eric Seager Expiry date =EXP_NONE
Purpose
Outbound HTTPS Communication over the Internet
Inbound HTTPS Communication with Load Balancers
Overview
Inbound Internal Load Balancers
Inbound External Load Balancers
Client Certificate Authentication
Purpose
This wiki provides high level guidelines for TSMs and DCEMs while supporting customer Load balancer requests. Refer to Network Customer Service
Requests List and Support for the various Load balancer requests supported across different Network teams. Please see SAP Note [Link]
/notes/3345151/E for more details.
Outbound HTTPS Communication over the Internet
SAP Enterprise Cloud Services (SAP ECS) customers are given a proxy server to connect HTTP/HTTPS destinations over the Internet. The proxy server
is intended for managed SAP Systems within the SAP Enterprise Cloud Services environment. All HTTP/HTTPS communication will go through the proxy
server. To configure connectivity to use the proxy server in the SAP Enterprise Cloud Services (SAP ECS) environment, use the host “proxy” and the proxy
service or port “3128”. This includes, but not limited to, SAP S/4HANA and the SAP Cloud Connector.
Copyright © 2015-2018, SAP SE Page 1 of 5 Internal - Unless expressly defined otherwise in page content
The proxy server in the SAP Enterprise Cloud Services environment is a dedicated proxy server and is specific to the customer environment (not shared).
The proxy server also consists of an allowed list which controls the allowed outbound communication. By default, SAP delivers the proxy server with an
allow list comprising of [Link]. If the customer wants additional entries within the proxy server, there is a service request option to add additional
domains. For example, if a customer needs to connect to “[Link]” for a web service over the Internet, the customer will open up
a service request requesting “[Link]” to be added to the allow list for the proxy server. This will allow the customer to connect to [Link]
regardless of the number of prefixes in the fully qualified domain name.
The proxy server permits HTTP and HTTPS (HTTP with SSL/TLS) communication. SAP Enterprise Cloud Services (SAP ECS) requires that customers
use HTTPS only.
Copyright © 2015-2018, SAP SE Page 2 of 5 Internal - Unless expressly defined otherwise in page content
Inbound HTTPS Communication with Load Balancers
Overview
Rise/PCE and STE customers are provided a block of load balancers for their SAP Enterprise Cloud Services (SAP ECS) environment for inbound HTTPS
(HTTP with SSL/TLS) communication. Inbound Load Balancers are used for business users on the customer corporate network as well as business users
over the Internet. Load Balancers are used for security purposes so firewall only configuration is not used. This section will go over the usage,
requirements and roles and responsibilities of SAP Enterprise Cloud Services (SAP ECS) and the customer with regards to load balancer usage. Inbound
connectivity of protocols other than HTTPS see "Non-HTTP/HTTPS External Connectivity" section of this document.
Customers with SAP Enterprise Cloud Services (SAP ECS) systems can only have ports open to end users greater than 1023 and cannot have their
systems, such as Web Dispatchers and/or S/4HANA have the standard ports 80 and 443 for HTTP/HTTPS configured on the SAP ECS systems. The
reason for this is that all ports under 1024 require at the operating system level the process using the port to be run as the root user. SAP Enterprise Cloud
Services views this as a security concern. To provide customers with a solution where ports under 1024 are available (i.e. 80 and 443), SAP Enterprise
Cloud Services provides load balancers to customers. All load balancers are configured for port 443 (SSL/TLS). Port 80 (HTTP non-ssl) can be requested
to be implemented but only as a redirect to port 443.
Load Balancers are setup with a 1:1 relationship meaning that 1 load balancer per 1 system/port. For example, if a customer has a Web Dispatcher with 2
different backend systems on two different ports and a load balancer is required to access both systems, there will be a load balancer for each port.
SAP Customers for SAP Enterprise Cloud Services have 4 location types where to have their SAP Enterprise Cloud Services (SAP ECS) environment:
SAP Datacenters – private cloud infrastructure hosted by SAP
Microsoft Azure – private cloud infrastructure hosted by Microsoft
Copyright © 2015-2018, SAP SE Page 3 of 5 Internal - Unless expressly defined otherwise in page content
Amazon Web Services (AWS) – private cloud infrastructure hosted by Amazon
Google Cloud Platform (GCP) – private cloud infrastructure hosted by Google
Inbound Internal Load Balancers
Internal Inbound Load Balancers are Load Balancers which are only visible to the customer’s network and can only be accessed through the connection
from the customer network. These load balancers are not Internet-facing. SAP Enterprise Cloud Services has two internal load balancer types which
customers need to be aware of. These types are dependent on the SAP Enterprise Cloud Services location type for which the customer’s environment is
housed on:
SSL/TLS decrypt/re-encrypt – These internal load balancers will act as a reverse proxy (or URL re-write). SSL/TLS certificate for this load
balancer type are required
Passthrough – SSL/TLS may be required depending on the location type. This load balancer type does not decrypt/re-encrypt but relies on the
backend system/next hop to do the decrypt/re-encrypt. The backend system must have a SSL/TLS SAN where the load balancer URL is included.
For example, a Load Balancer ([Link]) going to a Web Dispatcher ([Link]). The Web
Dispatcher will have both [Link] and [Link] in the Subject Alternative Name in the SSL
/TLS certificate if not using a wildcard (*.[Link])
Location Type Load Balancer Type SSL/TLS Certificate required for the Internal Load Balancer FQDN required in SSL/TLS Certificate on next hop
Load Balancer? (backend system)
SAP Datacenter SSL/TLS decrypt/re- Yes No
encrypt
Microsoft Azure Passthrough No Yes
Amazon Web SSL/TLS decrypt/re- Yes No
Services encrypt
Google Cloud Passthrough Yes Yes
Platform
SAP Enterprise Cloud Services recommends that customers request an internal inbound load balancer for their Quality and Production S/4HANA
environments with Web Dispatchers at a very minimum. Production environments consist of active-active Web Dispatchers and an inbound internal load
balancer will use both for the customer’s end users. The Quality internal inbound internal load balancer is to allow the customer to test the load balancer’s
behavior with the Quality S/4HANA environment.
Customers can open service requests for load balancer implementation for their SAP Enterprise Cloud Services (SAP ECS) systems. Load Balancers are
not setup during the initial build due to requirements that a customer may have. Customers should gather the following requirements before opening a
service request:
Fully Qualified Domain Name (FQDN) – this will be the URL used by the end users. This URL should end in the domain used by the SAP
Enterprise Cloud Services (SAP ECS) systems. Example: [Link]
Backend system or next hop – this is typically a Web Dispatcher or Web Dispatchers (2-production only)
Backend system or next hop port – this is typically a Web Dispatcher or Web Dispatchers (2-production only) and the default port for Web
Dispatchers for HTTPS (HTTP with SSL/TLS) is 44380.
Is there a disaster recovery site? – only select yes if the load balancer is for production and disaster recovery is a part of the environment
Necessary SSL/TLS certificate/private key – most load balancers will require an SSL certificate (Exception is Azure Internal Load Balancers).
If you use ALB(Application Load Balancer) on AWS to configure internal LB, then we have two possible options for certificate management for
frontend (Listeners).
1. Obtaining server certificate from AWS Certificate Manager (ACM)
2. Obtained from an external provider and importing to ACM or IAM
Please be aware that the server certificate from ACM can not be used by other applications(Web Dispatchers or ABAP/JAVA systems).
Only when you make sure you(customer) are the owner for the domain, then you can use ACM for Internal inbound LB or external inbound LB, as
you need to validate using Email or DNS.
Inbound External Load Balancers
All Inbound External Load Balancers are setup with SSL/TLS decrypt/re-encrypt as well as a Web Application Firewall. Customers who require users to
access SAP Enterprise Cloud Services (SAP ECS) systems over the Internet should request an inbound external load balancer.
Customers have two options for the load balancer URL:
SAP-owned domain. This format is <customer info>.<CID>.[Link]. The customer will decide on what they would like for <customer
info>. The <CID> is the customer ID. The SSL/TLS certificate as well as the registration in the public DNS is handled by SAP ECS so it is
reachable from the Internet.
Copyright © 2015-2018, SAP SE Page 4 of 5 Internal - Unless expressly defined otherwise in page content
Customer owned domain. The customer provides us what domain they want to use. SAP ECS will provide the customer the location of the load
balancer, which the customer will need to enter in their public DNS (customer will be responsible for DNS entry for Internet access). Also, SAP
ECS will send the customer a certificate request (CSR) for their Certificate Authority (CA) to sign if a signed SSL/TLS private key is not provided.
Enterprise Cloud Services (SAP ECS) Datacenters – SAP will provide an IP address for the customer to create an A-record in their
public DNS
Both internal LB for on-prem access and external LB for internet access uses the Application Load Balancer. In both cases (Internal LB
or Internet LB), AWS provides the FDQN from AWS domain but not IP addresses. So the AWS recommends customers to create a
CNAME record in their internet facing DNS servers to resolve and route queries to AWS load balancers. A-record creation is not
recommended because,
1. ALB are deployed at least in two availability zones for high availability which means two or more private IPs are reserved
minimum and DNS based load balancing is implemented between them by AWS.
2. According to AWS, Load balancer IP addresses are not static. It will change during the maintenance or restart of load balancers.
3. When the traffic higher or lower, AWS triggers auto scaleup or down for load balancers instances. This will add or remove
additional IP addresses dynamically
SAP Enterprise Cloud Services recommends that customers request an external inbound load balancer for their Quality and Production S/4HANA
environments with Web Dispatchers at a very minimum. The Quality inbound external load balancer is to allow the customer to test the load balancer’s
behavior with the Quality S/4HANA environment.
Customers can open service requests for load balancer implementation for their SAP Enterprise Cloud Services (SAP ECS) systems. Load Balancers are
not setup during the initial build due to requirements that a customer may have. Customers should gather the following requirements before opening a
service request:
Fully Qualified Domain Name (FQDN) – this will be the URL used by the end users
Backend system or next hop – this is typically a Web Dispatcher or Web Dispatchers (2-production only)
Backend system or next hop port – this is typically a Web Dispatcher or Web Dispatchers (2-production only) and the default port for Web
Dispatchers for HTTPS (HTTP with SSL/TLS) is 44380.
Is there a disaster recovery site? – only select yes if the load balancer is for production and disaster recovery is a part of the environment
Necessary SSL/TLS certificate/private key –Customers can choose for the Load Balancer implementers to create a certificate request, or the
customer can provide an existing private key. This is not necessary if requesting the [Link] SAP-owned domain
Client Certificate Authentication
Client Certificate Authentication is when an end user passes a certificate in the HTTP request to be used to authenticate the user on the backend system.
This is a Single-Sign-On (SSO) which some customers may use for their end users. In SAP Enterprise Cloud Services, there are limitations on usage of
client certificate authentication depending on location type:
Location Type Client Certificate Authentication Available for Internal Client Certificate Authentication Available for External
Inbound Load Balancer Inbound Load Balancer
SAP Datacenter Yes Yes
Microsoft Azure Yes No
Amazon Web Conditional* See: [Link] No
Services
Google Cloud Yes No
Platform
If the customer is in a location where client certificate authentication is required but not available, the customer will require the Advanced Load Balancer.
The limitation does NOT include Single-Sign-On (SSO) for SAML. This is for client certificate authentication only.
Copyright © 2015-2018, SAP SE Page 5 of 5 Internal - Unless expressly defined otherwise in page content
