SAP Secure Login Service for SAP GUI enables secure authentication and single sign-on (SSO) for SAP GUI using SAP BTP, leveraging its built-in platform capabilities for high availability
In most cases, this is sufficient, as the service is only used during the user’s initial login. Once authenticated, an X.509 certificate provides SSO for the rest of the session.
However, some organizations require higher resilience and opt for a multi-region failover setup. In this blog, I’ll walk through how to implement this using SAP Secure Login Service, SAP BTP Custom Domain Service, and AWS Route 53.
Architecture
Prerequisites
SAP BTP
Two subaccounts in different regions (e.g. US10, US21, EU10 etc). For this blog i have used US10 and EU10.
SLS subscribed in both subaccounts
Custom Domain Service entitlement assigned and activated in both subaccounts
AWS
Route 53 hosted zone for your domain
Identity
IAS tenants configured with SLS
Certificates
TLS certificate for sls.yourdomain.com (from a public CA)
Step 1: Configure Custom Domain Service — US10 (Primary)
In the US10 subaccount, open Custom Domain Manager and complete the following:
Reserve domain: yourdomain.com
Create custom domain: sls.yourdomain.com
Create a SaaS route: map sls.yourdomain.com to the SLS subscription
Perform TLS configurations
Create a Server Identity and generate a CSR (Certificate Signing Request)
Obtain a TLS certificate from a public CA using the CSR and Upload the full certificate chain and activate it
Activate it
Note the CNAME target shown under “DNS CNAME Recommendation” — you will need this exact value for Route 53
About the CNAME target The CNAME target provided by Custom Domain Manager is SAP’s ingress hostname for SaaS routes in the US10 region. Use exactly what Custom Domain Manager shows. Do not substitute or guess any hostname.
Step 2: Configure Custom Domain Service — EU10 (Secondary)
Repeat exactly the same steps in the EU10 subaccount. Use the same custom domain: sls.yourdomain.com.
Note the CNAME target for EU10 as well.
Why the same hostname in both subaccounts? Each subaccount independently maps sls.yourdomain.com to its local SLS SaaS instance. This is fully supported by Custom Domain Service. Both instances respond to the same hostname, which is what makes Route 53 failover work transparently. Route 53 resolves sls.yourdomain.com to the CNAME target of whichever region is active — and that region’s SLS instance is already configured to serve requests for that hostname.
Step 3: Configure IAS Redirect URI
In your IAS tenants, add the following as an allowed redirect URI for the SLS application:
Keep all existing redirect URIs — just add this one. Because both SLS instances share the same hostname, this single redirect URI covers both regions regardless of which instance handles the authentication request.
Each SLS instance uses a separate IAS tenant, add this redirect URI in both tenants ( US10 and EU10)
Step 4: Configure Route 53 Failover Routing
Health Checks
Create two Route 53 health checks — one per SLS instance — targeting each SLS instance hostname directly:
Health Check 1 (Primary — US10):
Protocol: HTTPS
Endpoint: <your-us10-sls-hostname> (the actual SLS instance hostname in US10, e.g. yourinstance.us10.sls.cloud.sap)
Path: /health
Port: 443
Purpose: Monitors US10 SLS instance directly
Health Check 2 (Secondary — EU10):
Protocol: HTTPS
Endpoint: <your-eu10-sls-hostname> (the actual SLS instance hostname in EU10, e.g. yourinstance.eu10.sls.cloud.sap)
Path: /health
Port: 443
Purpose: Monitors EU10 SLS instance directly
(like primary US10 setup)
Why target the SLS instance hostname directly? The health checks must target each SLS instance hostname directly — not sls.yourdomain.com. At any point in time, sls.yourdomain.com only resolves to the currently active region. A health check on sls.yourdomain.com would only monitor whichever instance Route 53 is currently routing to, and would never detect that the primary is down (because Route 53 would have already switched). By monitoring each SLS instance hostname independently, Route 53 can detect failures in either region at any time.
CNAME records for failover
Primary Record
Name: sls.yourdomain.com
Type: CNAME
Value: api.cf.us10.hana.ondemand.com
Routing policy: Failover — PRIMARY
Health check: Yes (associate Health Check 1 — US10)
Secondary Record
Similarly for Secondary
TTL recommendation Could set TTL to 60 seconds. A lower TTL means faster DNS propagation during failover events.
Step 5: Configure SAP Secure Login Client
Configure SAP Secure Login Client (SLC) with the SLS URL pointing to your custom domain:
Because the URL always points to sls.yourdomain.com, no SLC reconfiguration is needed when a failover occurs. Route 53 changes the DNS resolution transparently.
Failover Behavior
Scenario
Result
Primary healthy
Traffic → US10 SLS SaaS instance
Primary fails health check
Route 53 switches DNS to EU10 CNAME target
Primary recovers
Route 53 switches traffic back to US10
Failover Timing
Health check detection: ~30–90 seconds
DNS TTL propagation: ~60 seconds
Total worst-case failover time: approximately 2 minutes
Important Considerations
Failover Is NOT Session-Aware Active login flows that are in progress during a failover event may fail. Users may need to retry authentication. Design user communications accordingly and set expectations with support teams.
SLS Instances Are Independent Both SLS instances must be kept in sync manually. This includes IAS configuration, authentication policies, certificate trust configuration, and version levels. Drift between instances can cause inconsistent behavior depending on which region is active.
Certificate Strategy You can use the same TLS certificate (same Subject Alternative Name) across both regions for simplicity, since both Custom Domain Manager instances are serving the same hostname. Alternatively, use separate certificates per region for better security isolation. Either approach is valid.
Health Checks on Both Records It is recommended to add health checks on both primary and secondary records. Without a health check on the secondary, Route 53 may route traffic to a failed secondary during a primary failover, resulting in an outage even though the primary was available.
Testing
1. DNS Verification
nslookup sls.yourdomain.com
Confirm it resolves to the US10 CNAME target under normal conditions.
2. End-to-End Login
Open SAP GUI Secure Login Client and authenticate end-to-end. Confirm the full OIDC flow completes, including the redirect back to sls.yourdomain.com/login/callback.
3. Failover Simulation
Disable the primary health check in Route 53. Wait approximately 2 minutes, then run:
nslookup sls.yourdomain.com
Confirm it now resolves to the EU10 CNAME target.
4. Secondary Authentication
Verify that authentication still works end-to-end when Route 53 is routing to the EU10 instance.
5. Failback
Re-enable the primary health check. After the TTL expires, confirm DNS resolves back to the US10 CNAME target and authentication continues to work.
SAP Backend user mapping
There aretwo options to ensure that the SNC mapping remains intact:
Use parameters of the SAP Cryptographic Library tostrip the region names from the certificate subjectbefore the mapping takes place. That way, certificates from different regions will match the same SNC name. See note 2338952for details.
Change the SAP Secure Login Service configuration touse a customer-managed certificate authority. This gives you the option to customize the subject name of the certificate so that it does not include the BTP region.
Conclusion
By combining SAP BTP Custom Domain Service and AWS Route 53 failover routing, you eliminate the single point of failure in SAP GUI authentication. The key enabler is the shared custom domain: both SLS SaaS instances respond to sls.yourdomain.com, making the OIDC redirect_uri consistent across regions regardless of which instance is currently active.
Route 53 health checks detect failures automatically and update DNS within approximately two minutes. End users and SAP Secure Login Client configurations require no changes when a failover or failback occurs.
Final Takeaway This setup provides:
High availability for SAP GUI authentication via a managed SaaS architecture
Transparent DNS-level failover with no client reconfiguration
A consistent OIDC redirect URI across both regions
IntroductionInspired by the initial blog by our Product team membershttps://community.sap.com/t5/technology-blog-posts-by-sap/high-availability-setup-for-sap-secure-login-service-with-microsoft-azure/ba-p/14140475SAP Secure Login Service for SAP GUI enables secure authentication and single sign-on (SSO) for SAP GUI using SAP BTP, leveraging its built-in platform capabilities for high availability In most cases, this is sufficient, as the service is only used during the user’s initial login. Once authenticated, an X.509 certificate provides SSO for the rest of the session.However, some organizations require higher resilience and opt for a multi-region failover setup. In this blog, I’ll walk through how to implement this using SAP Secure Login Service, SAP BTP Custom Domain Service, and AWS Route 53.Architecture PrerequisitesSAP BTPTwo subaccounts in different regions (e.g. US10, US21, EU10 etc). For this blog i have used US10 and EU10.SLS subscribed in both subaccountsCustom Domain Service entitlement assigned and activated in both subaccountsAWSRoute 53 hosted zone for your domainIdentityIAS tenants configured with SLSCertificatesTLS certificate for sls.yourdomain.com (from a public CA)Step 1: Configure Custom Domain Service — US10 (Primary)In the US10 subaccount, open Custom Domain Manager and complete the following:Reserve domain: yourdomain.comCreate custom domain: sls.yourdomain.com Create a SaaS route: map sls.yourdomain.com to the SLS subscription Perform TLS configurationsCreate a Server Identity and generate a CSR (Certificate Signing Request)Obtain a TLS certificate from a public CA using the CSR and Upload the full certificate chain and activate itActivate itNote the CNAME target shown under “DNS CNAME Recommendation” — you will need this exact value for Route 53About the CNAME targetThe CNAME target provided by Custom Domain Manager is SAP’s ingress hostname for SaaS routes in the US10 region. Use exactly what Custom Domain Manager shows. Do not substitute or guess any hostname.Step 2: Configure Custom Domain Service — EU10 (Secondary)Repeat exactly the same steps in the EU10 subaccount. Use the same custom domain: sls.yourdomain.com.Note the CNAME target for EU10 as well.Why the same hostname in both subaccounts?Each subaccount independently maps sls.yourdomain.com to its local SLS SaaS instance. This is fully supported by Custom Domain Service. Both instances respond to the same hostname, which is what makes Route 53 failover work transparently. Route 53 resolves sls.yourdomain.com to the CNAME target of whichever region is active — and that region’s SLS instance is already configured to serve requests for that hostname.Step 3: Configure IAS Redirect URIIn your IAS tenants, add the following as an allowed redirect URI for the SLS application:https://sls.yourdomain.com/login/callback Keep all existing redirect URIs — just add this one. Because both SLS instances share the same hostname, this single redirect URI covers both regions regardless of which instance handles the authentication request. Each SLS instance uses a separate IAS tenant, add this redirect URI in both tenants ( US10 and EU10)Step 4: Configure Route 53 Failover RoutingHealth ChecksCreate two Route 53 health checks — one per SLS instance — targeting each SLS instance hostname directly:Health Check 1 (Primary — US10):Protocol: HTTPSEndpoint: <your-us10-sls-hostname> (the actual SLS instance hostname in US10, e.g. yourinstance.us10.sls.cloud.sap)Path: /healthPort: 443Purpose: Monitors US10 SLS instance directlyHealth Check 2 (Secondary — EU10):Protocol: HTTPSEndpoint: <your-eu10-sls-hostname> (the actual SLS instance hostname in EU10, e.g. yourinstance.eu10.sls.cloud.sap)Path: /healthPort: 443Purpose: Monitors EU10 SLS instance directly(like primary US10 setup)Why target the SLS instance hostname directly?The health checks must target each SLS instance hostname directly — not sls.yourdomain.com. At any point in time, sls.yourdomain.com only resolves to the currently active region. A health check on sls.yourdomain.com would only monitor whichever instance Route 53 is currently routing to, and would never detect that the primary is down (because Route 53 would have already switched). By monitoring each SLS instance hostname independently, Route 53 can detect failures in either region at any time.CNAME records for failoverPrimary RecordName: sls.yourdomain.comType: CNAMEValue: api.cf.us10.hana.ondemand.comRouting policy: Failover — PRIMARYHealth check: Yes (associate Health Check 1 — US10) Secondary RecordSimilarly for Secondary TTL recommendationCould set TTL to 60 seconds. A lower TTL means faster DNS propagation during failover events.Step 5: Configure SAP Secure Login ClientConfigure SAP Secure Login Client (SLC) with the SLS URL pointing to your custom domain:https://sls.yourdomain.com/slc/v1/login Distribute this configuration via:GPO (Group Policy Object)IntuneSCCMBecause the URL always points to sls.yourdomain.com, no SLC reconfiguration is needed when a failover occurs. Route 53 changes the DNS resolution transparently.Failover BehaviorScenarioResultPrimary healthyTraffic → US10 SLS SaaS instancePrimary fails health checkRoute 53 switches DNS to EU10 CNAME targetPrimary recoversRoute 53 switches traffic back to US10Failover TimingHealth check detection: ~30–90 secondsDNS TTL propagation: ~60 secondsTotal worst-case failover time: approximately 2 minutes Important ConsiderationsFailover Is NOT Session-AwareActive login flows that are in progress during a failover event may fail. Users may need to retry authentication. Design user communications accordingly and set expectations with support teams.SLS Instances Are IndependentBoth SLS instances must be kept in sync manually. This includes IAS configuration, authentication policies, certificate trust configuration, and version levels. Drift between instances can cause inconsistent behavior depending on which region is active.Certificate StrategyYou can use the same TLS certificate (same Subject Alternative Name) across both regions for simplicity, since both Custom Domain Manager instances are serving the same hostname. Alternatively, use separate certificates per region for better security isolation. Either approach is valid.Health Checks on Both RecordsIt is recommended to add health checks on both primary and secondary records. Without a health check on the secondary, Route 53 may route traffic to a failed secondary during a primary failover, resulting in an outage even though the primary was available.Testing1. DNS Verificationnslookup sls.yourdomain.comConfirm it resolves to the US10 CNAME target under normal conditions.2. End-to-End LoginOpen SAP GUI Secure Login Client and authenticate end-to-end. Confirm the full OIDC flow completes, including the redirect back to sls.yourdomain.com/login/callback.3. Failover SimulationDisable the primary health check in Route 53. Wait approximately 2 minutes, then run:nslookup sls.yourdomain.comConfirm it now resolves to the EU10 CNAME target.4. Secondary AuthenticationVerify that authentication still works end-to-end when Route 53 is routing to the EU10 instance.5. FailbackRe-enable the primary health check. After the TTL expires, confirm DNS resolves back to the US10 CNAME target and authentication continues to work.SAP Backend user mappingThere are two options to ensure that the SNC mapping remains intact:Use parameters of the SAP Cryptographic Library to strip the region names from the certificate subject before the mapping takes place. That way, certificates from different regions will match the same SNC name. See note 2338952 for details.Change the SAP Secure Login Service configuration to use a customer-managed certificate authority. This gives you the option to customize the subject name of the certificate so that it does not include the BTP region.ConclusionBy combining SAP BTP Custom Domain Service and AWS Route 53 failover routing, you eliminate the single point of failure in SAP GUI authentication. The key enabler is the shared custom domain: both SLS SaaS instances respond to sls.yourdomain.com, making the OIDC redirect_uri consistent across regions regardless of which instance is currently active.Route 53 health checks detect failures automatically and update DNS within approximately two minutes. End users and SAP Secure Login Client configurations require no changes when a failover or failback occurs.Final TakeawayThis setup provides:High availability for SAP GUI authentication via a managed SaaS architectureTransparent DNS-level failover with no client reconfigurationA consistent OIDC redirect URI across both regions @Christian_Cohrs1 Read More Technology Blog Posts by SAP articles
