Cloud Connector Fundamentals: Purpose and Architecture
Understand why Cloud Connector exists, how it establishes secure connectivity between BTP and on-premise systems, and the core components involved in the tunnel architecture.
Explanation
Cloud Connector is a Java-based agent installed inside a customer's own network (on-premise or in a private data center) that acts as a reverse-invoke proxy for SAP BTP. Its core business purpose is to let cloud applications running in BTP subaccounts (Cloud Foundry, Kyma, or Integration Suite) call on-premise systems such as S/4HANA, ECC, or other backend HTTP/RFC-based systems without the customer having to open inbound firewall ports from the internet into their landscape. The fundamental design problem Cloud Connector solves is directionality. Classic reverse proxy or DMZ setups require inbound rules that expose internal systems to the internet, which security teams resist. Cloud Connector flips this: it initiates an outbound HTTPS connection from inside the customer network to SAP BTP's connectivity service. Once this tunnel is established and authenticated, BTP can send requests back through that same tunnel to reach internal systems, but no unsolicited inbound connection from the internet is required. This is why security teams find it more acceptable than traditional reverse proxies. Architecturally, Cloud Connector runs as a standalone Java process (deployable on Linux or Windows) with its own administration UI (typically on a locally bound HTTPS port). It is paired to exactly one BTP subaccount at a time in versions before multi-subaccount support was introduced; more recent versions support connecting a single Cloud Connector instance to multiple subaccounts, though many productive landscapes still use one Cloud Connector per subaccount or per landscape tier (dev/test/prod) for isolation and blast-radius control. The pairing process uses the BTP subaccount's Cloud Connector administrator/subaccount credentials or certificate-based authentication (depending on setup) to register the local Cloud Connector instance against the target subaccount's Connectivity configuration. Once paired, the connector maintains a persistent, encrypted tunnel (TLS) to SAP's connectivity proxy infrastructure. Requests originating from BTP applications that use the 'Connectivity' destination type with proxy type 'OnPremise' get routed by the platform through this tunnel to the Cloud Connector, which then forwards the request to the actual internal system based on configured mappings. Key components inside Cloud Connector configuration include: Subaccount pairing (the trust relationship to BTP), Cloud To On-Premise mappings (also called Access Control, defining which internal hosts/ports/paths are exposed and under what virtual host name), and System Mapping details for protocol type (HTTP, HTTPS, RFC, LDAP, TCP). Cloud Connector does not simply forward raw traffic blindly; it enforces an explicit allow-list model. Only virtual-to-internal system mappings that an administrator has explicitly configured are reachable from BTP; everything else is blocked by default. This principle of least exposure is central to why enterprises trust Cloud Connector for regulated environments. It is important to distinguish Cloud Connector from other BTP connectivity mechanisms: the Connectivity service itself is the platform-side component that BTP applications use (via destinations with proxy type OnPremise) to route calls; Cloud Connector is the on-premise counterpart. They work together but are configured in different places—the Connectivity service and destination configuration live in BTP cockpit, while Cloud Connector's mapping and access control live in its own administration console running on-premise. For S/4HANA private cloud or on-premise ECC landscapes, Cloud Connector is typically the only supported path for BTP-to-backend calls when the backend cannot be exposed on the public internet. In S/4HANA public cloud (multi-tenant SaaS), the backend is already internet-reachable through its own API endpoints, communication arrangements, and communication scenarios, so Cloud Connector is generally not used at all—connectivity there relies on OAuth/communication arrangements rather than on-premise tunneling. This distinction matters heavily when scoping integration projects: assuming Cloud Connector is always needed for 'SAP-to-BTP' integration is a common misconception that this lesson deliberately corrects. High availability is another architectural consideration: production landscapes typically run Cloud Connector in a master/shadow configuration, where a shadow instance stands by and can take over if the master becomes unavailable, since a single Cloud Connector instance is a single point of failure for on-premise reachability from BTP.
Real project scenario
A retail company migrating side-by-side extensions to BTP Cloud Foundry needed their new Node.js approval-workflow app to call an on-premise S/4HANA private cloud system's OData services for purchase order data. The security team refused to open any inbound port on the S/4HANA network segment. The integration architect proposed Cloud Connector: install it in the customer's DMZ-adjacent internal segment, pair it to the BTP subaccount, and expose only the specific OData service path needed via an access control entry. This satisfied both the security team (no inbound exposure, explicit allow-list) and the application team (transparent HTTPS destination lookup from the app using the Connectivity service).
Common mistakes
• Assuming Cloud Connector is required for all SAP BTP to SAP system integration, including S/4HANA public cloud, which is usually reachable directly via its own APIs. • Treating Cloud Connector as a generic reverse proxy that forwards all traffic, rather than understanding its strict allow-list (access control) model. • Installing only a single Cloud Connector instance in production with no shadow/backup, creating an unplanned single point of failure. • Confusing the BTP-side Connectivity service/destination configuration with the on-premise Cloud Connector administration console, leading to misconfigured troubleshooting efforts in the wrong place. • Not documenting which subaccount a given Cloud Connector instance is paired to, causing confusion in multi-landscape (dev/test/prod) environments.
Best practices
• Use one Cloud Connector deployment per landscape tier (dev, test, prod) to isolate blast radius and avoid accidental cross-environment access. • Configure master/shadow high-availability pairs for production Cloud Connector installations. • Apply the principle of least privilege: only map the specific hosts, ports, and URL paths actually required by BTP applications. • Maintain clear documentation of subaccount-to-Cloud-Connector pairing, especially in landscapes with multiple subaccounts. • Periodically review access control entries to remove mappings no longer used by any active integration.
Interview angle
Interviewers often ask why Cloud Connector uses outbound-only connections and how that differs from a traditional reverse proxy or VPN. Be ready to explain the reverse-invoke tunnel concept, the allow-list access control model, and clearly state when Cloud Connector is NOT needed (e.g., S/4HANA public cloud, systems already internet-reachable via approved APIs). Also expect questions distinguishing the platform-side Connectivity service from the on-premise Cloud Connector agent.