High Availability and Load Balancing for Cloud Connector

Explanation

A single Cloud Connector instance is a single point of failure: if the host running it goes down, every cloud application relying on that connection to on-premise systems loses connectivity immediately, even if the backend systems themselves are healthy. For any production integration scenario - S/4HANA extension apps calling backend OData services, SAP Integration Suite flows reaching on-premise SOAP or RFC endpoints, or SuccessFactors extensions touching on-premise HR systems - this single point of failure is unacceptable, so Cloud Connector supports a master-shadow high availability model. In this model, one Cloud Connector instance is configured as the master and a second instance, installed on separate infrastructure (different host, ideally different availability zone or data center), is configured as the shadow. The shadow instance continuously replicates configuration from the master: subaccount mappings, access control lists, system mappings, and certificates. The shadow does not process traffic while the master is active; it stays in standby, periodically checking the master's health via a heartbeat mechanism. If the master becomes unreachable or fails a defined number of heartbeat checks, the shadow instance promotes itself to master and begins accepting the reverse-invoke connections from BTP. Setting this up requires: both instances installed with compatible versions, network connectivity between master and shadow for configuration replication (typically over HTTPS on the administration port), and both instances registered to the same subaccount(s) using the same authentication mechanism, though with separate connector instance names so BTP can distinguish them. During normal operation, BTP's connectivity service is aware of both connector instances registered to a subaccount and will route reverse-invoke tunnel setup requests according to the active/standby state reported by the connectors. Beyond basic failover, larger landscapes sometimes use multiple independent Cloud Connector pairs mapped to different subaccounts or different location IDs, allowing you to isolate traffic by business unit, environment (dev/test/prod), or backend landscape, and to scale connection capacity horizontally rather than vertically. The location ID is a critical concept here: when a subaccount has more than one Cloud Connector registered without HA pairing, each is distinguished by a unique location ID, and the calling application must specify which location ID to route through in its destination configuration. This is different from HA pairing, where master and shadow share the same location ID and are transparent to the destination configuration. Operationally, HA introduces new monitoring requirements: you must verify that shadow replication is current (a stale shadow that hasn't synced recent access control list changes will apply outdated rules on failover, potentially blocking newly permitted traffic or worse, allowing traffic that was supposed to be revoked), and you must periodically test failover in a controlled window rather than assuming it works, because untested failover mechanisms are a common source of extended outages when actually needed. Capacity planning also matters: the shadow instance's host should be sized identically to the master, since after failover it carries full production load, not a reduced fraction. A related but distinct consideration is load distribution: master-shadow HA is about failover, not load balancing, since only one instance is active at a time. If you need to scale throughput rather than just resilience, you typically deploy multiple independent Cloud Connector instances mapped to different location IDs and distribute destinations across them intentionally at the application/destination configuration level, rather than expecting automatic load spreading.

Code example

# Example: destination configuration referencing a specific location ID# (used when multiple non-HA Cloud Connector instances serve one subaccount) Name=erp_backend_via_locationAType=HTTPURL=https://myhost.on-premise.corp:8000ProxyType=OnPremiseCloudConnectorLocationId=LOC_AAuthentication=NoAuthentication # In an HA master-shadow pair, CloudConnectorLocationId is the SAME# for both master and shadow -- the destination does not change on failover;# BTP's connectivity service transparently routes to whichever instance# currently holds the 'master' (active) role. # Heartbeat check concept (conceptual, not an actual CLI command):# Shadow polls master's health endpoint every N seconds.# After M consecutive missed heartbeats, shadow promotes to master# and begins accepting reverse-invoke tunnel requests from BTP.

Real project scenario

A retail company ran a single Cloud Connector instance supporting an S/4HANA private cloud extension suite handling order management. During a routine OS patching window, the host was rebooted without anyone realizing extension apps depended on that connector, causing a 40-minute outage of order creation for store associates during business hours. Following the post-incident review, the integration team implemented a master-shadow HA pair across two separate virtual machines in different availability zones, added automated alerting on shadow replication lag, and scheduled a quarterly failover drill in a low-traffic maintenance window to validate that promotion actually worked end-to-end, including verifying that access control list changes made in the two weeks prior to the drill were correctly present on the shadow after promotion.

Common mistakes

• Assuming HA is automatic after installing a second Cloud Connector instance without explicitly configuring the master-shadow relationship • Sizing the shadow host smaller than the master, causing performance degradation after failover under full production load • Never testing failover, discovering during a real incident that the shadow's replicated configuration was stale or incomplete • Confusing location ID based multi-instance setups (used for scaling/isolation) with HA master-shadow pairs (used for failover), leading to incorrect destination configuration • Placing master and shadow in the same physical data center or availability zone, defeating the purpose of resilience against infrastructure-level failures • Not monitoring replication lag between master and shadow, so ACL or system mapping changes silently fail to propagate

Best practices

• Always deploy Cloud Connector in a master-shadow HA pair for production landscapes with genuine business criticality • Place master and shadow on physically or logically separate infrastructure, ideally different availability zones • Size the shadow host identically to the master since it must carry full load after promotion • Monitor replication lag and alert if the shadow falls behind on configuration sync • Schedule periodic controlled failover tests and document the results as part of operational readiness evidence • Use distinct location IDs only when you intend genuine traffic isolation or horizontal scaling, not as a substitute for HA • Document which subaccounts and destinations depend on which Cloud Connector pair to avoid untracked single points of failure

Interview angle

Interviewers assess whether you understand that master-shadow HA is failover-based (only one active instance) rather than active-active load balancing, and whether you can articulate the operational discipline required (replication monitoring, failover testing, host sizing) beyond just describing the initial setup. Be ready to explain location ID's role in both HA and non-HA multi-instance scenarios, since candidates commonly conflate the two.