SAP BTP Destinations and Cloud Connector for Azure

Q: Do I need SAP Cloud Connector to call Azure OpenAI from BTP?

No. Azure OpenAI is a public endpoint; a plain Internet-proxy-type destination works, as shown in our [OpenAI integration guide](/tutorials/sap-btp-azure-openai-integration/). The connector matters for private backends; SAP Private Link service is the alternative for supported PaaS services in Cloud Foundry/Kyma runtimes.

Why a Destination Needs a Private Path at All

Every BTP application that calls a backend you host in Azure hits the same question: how does a request leave the managed BTP network and reach a machine with no public face? The answer is one of two mechanisms, and picking wrong costs days of firewall tickets. In our Azure OpenAI integration tutorial destinations point at public endpoints, which is fine for SaaS APIs. The moment your backend is an S/4HANA system, a PO gateway, or anything bound to an Azure Private Endpoint, the destination must route through SAP’s private-connectivity stack. This guide is that prerequisite, promoted to a page of its own: installing and sizing SAP Cloud Connector on Azure VMs, registering it to a subaccount, wiring HTTP and RFC destinations at private endpoints, the three truststores, and triage for the 401/503/ping failures we actually hit.

Cloud Connector or SAP Private Link Service: Choosing the Path

SAP Cloud Connector is a reverse-invoke proxy you install inside your own network. Microsoft’s SAP architecture guidance puts the mechanism plainly: the connector “requires outbound internet access to establish a TLS-encrypted HTTPS tunnel with SAP BTP”, acts “as a reverse invoke proxy between the private IP range in your virtual network and SAP BTP applications”, and therefore “you don’t need open firewall ports or other access for inbound connections”. That asymmetry — connector dials out, BTP never dials in — is why it survives strict Azure firewalls.

The newer alternative, SAP Private Link service, gives private connectivity between BTP services and services in your IaaS account, with traffic staying on the hyperscaler backbone; those destinations use proxy type PrivateLink. The official documentation currently scopes supported runtimes to Cloud Foundry and Kyma, so the tunnel remains the documented route for everything else, including the Connectivity service itself. As of 2026-11 the SAP docs do not list Azure OpenAI among services reachable that way — treat anything beyond the documented runtimes and service list as unverified.

Both coexist: landing-zone designs we review (see our SAP landing zone guide) run the connector in a perimeter subnet while private-link instances handle selected PaaS backends.

Install and Size the Cloud Connector VM

The official prerequisites are the sizing baseline, and they are surprisingly small:

Resource	Minimum	Recommended
CPU	Dual core 2 GHz (x86-64, aarch64, or ppc64le)	Multi core 3 GHz
Memory (RAM)	4 GB	16 GB
Free disk	2 GB	20 GB

SAP does not name specific Azure VM SKUs for the connector — that mapping is not documented as of 2026-11. In practice a Standard_D2ds_v5 clears the minimum comfortably; take the SKU from your landing zone’s approved list rather than inventing an exception.

The Java dependency is where teams trip: “A full JDK must be installed. Lightweight JRE installations are not sufficient.” SAP JVM 64-bit is the recommended runtime, and the documented matrix ties each JDK to connector versions: SAP JVM 8 or Oracle JDK 8 require 2.7.2+; SapMachine 11 (end of maintenance) works 2.14.0–2.18.2; SapMachine 17 works 2.15.0–2.19.x; SapMachine 21 needs 2.17.0+; SapMachine 25 needs 2.19.0+. Download the archive and SAP JVM from tools.hana.ondemand.com; heed the documented caution against Apache Portable Runtime (APR) — avoiding it is cheaper than hand-adapting server.xml.

Beyond the install, logs, audit files, and configuration growth need headroom — hence the 20 GB recommended floor. For high availability, SAP supports a master and shadow connector sharing configuration natively — two VMs, no load balancer or clustering software (HA configuration). After install the admin UI is https://<vm>:8443 with the literal first sign-in Administrator / manage (case sensitive) — change it immediately. The UI ships with a self-signed certificate, which matters for anyone scripting against the API.

Register the Connector: Principals, Roles, and Location IDs

Registration lives in the BTP cockpit under Connectivity → Cloud Connectors. Create a role collection with the documented defaults — Subaccount Administrator, Cloud Connector Administrator, Connectivity and Destination Administrator — assign your principal, then Download Authentication Data for the verification code. The code is valid only a few minutes, so have the connector UI open. With one connector per subaccount the location ID can stay empty; with several connectors each carries a unique location ID per subaccount and every destination must repeat it to route. SAP recommends against mixing production and non-production subaccounts on one connector, and the registration user is only needed for initial setup — revoke it afterwards.

The connector authenticates to BTP with an auto-generated X.509 certificate that renews automatically; renewal thresholds scale with validity (1-day certificates renew 12 hours before expiry; 155–365 days renew 30 days before). You can also harden the admin UI with client-certificate logon: pick the user-mapping OID, put the issuer’s root certificate in the Authentication Allowlist, and decide whether User/Password Fallback stays checked for mixed mode. Two documented gotchas: the feature is unavailable on SAP-operated connectors, and in HA setups you must set a distinct HA port or the shadow fails verbatim: “There is no trust with Cloud Connector on https://:. Reset shadow configuration and try to connect shadow again.”

Azure Networking the Connector Needs

What leaves the VM is one thing: outbound TLS on port 443 to the Connectivity service hosts of your subaccount’s region. The prerequisites network section gives the patterns — cf.<region>.hana.ondemand.com for Cloud Foundry (e.g. cf.eu10.hana.ondemand.com), *.abap.<region>.hana.ondemand.com for ABAP environments, hosts like ae1.hana.ondemand.com for trial. On the Azure side:

NSG outbound. NSGs are stateful and defaults allow all outbound (AllowInternetOutBound/AllowAllOutBound, priority 65001). An untouched connector subnet needs nothing; once a hub firewall or custom rules intervene, allow 443 to those FQDNs — default rules cannot be removed, only overridden by higher-priority custom rules.
Outbound IP stability. Microsoft’s SAP internet inbound/outbound guidance places the connector in the SAP perimeter/DMZ spoke, typically with a NAT gateway giving the subnet static public IPs for SNAT — handy when allowlists need fixed source addresses, and it dodges the port-exhaustion ceiling of firewall-attached IPs.
IPv6. SAP is rolling out dual-stack ingress (planned ≥February 2026 AWS, ≥April 2026 GCP); if your egress path or JVM prefers IPv6, allowlist v6 too — connector 2.18.1 shows the stack status on its About page.
No inbound. Worth repeating: the tunnel opens no inbound ports.

HTTP and RFC Destinations Through Azure Private Endpoints

An HTTP destination reaches a private backend when ProxyType is OnPremise (default Internet) and a connected connector serves the subaccount. The destination URL must be the virtual host:port exposed in the connector’s system mapping (Configure Access Control) — nothing behind the tunnel is otherwise routable from BTP. The docs note the on-premise use cases “are also applicable to virtual private cloud (VPC) environments”, which is exactly the Azure-VNet case. Each mapping pairs a virtual host/port with an internal host/port plus permitted URLs; HostInHeader picks INTERNAL or VIRTUAL for the Host header — choose VIRTUAL when the backend vhost or certificate expects the virtual name.

Azure’s private endpoint overview shapes the rest: the endpoint is a NIC with a private IP from your subnet that stays fixed for the endpoint’s lifecycle; the endpoint must be in the same region as the VNet; traffic flows only when the connection is Approved; NSGs, UDRs, and ASGs apply, though the portal hides effective routes and rules on the endpoint NIC and flow logs don’t cover inbound endpoint traffic. Crucially, a private endpoint does not itself restrict public access — disable publicNetworkAccess separately, and know that a source-port condition targeting an endpoint is interpreted as *.

DNS is the sharpest edge: the service FQDN must resolve to the endpoint’s private IP inside the VNet via a private DNS zone linked to that VNet; one private DNS zone should not be linked to endpoints of two different services because A-record cleanup conflicts. Resolution happens on the connector VM itself, so the zone link (or a Private Resolver, or hosts-file entry) must cover the connector’s subnet — and the backend certificate must match the name you connect to.

For ABAP backends, RFC destinations also use proxy type OnPremise (Internet RFC means WebSocket RFC, no connector needed). Authorization types decide the principal story: CONFIGURED_USER is the default and ships your entered credentials; PrincipalPropagation and TechnicalUserPropagation exist only on OnPremise — don’t set jco.client.user/password manually with them, and avoid RepositoryDefaultCredentials combined with principal propagation because metadata lookups run with those rights. Note the documented constraints: jco.client.user is ≤12 characters and case-insensitive, alias users ≤40 case-sensitive, and TLS client-certificate logon fields only surface when the proxy type allows them.

Certificates and Truststores: Three Places, Three Jobs

The connector touches TLS in three separate stores:

Connector JVM → BTP. If the JVM distrusts the Connectivity service certificate chain the tunnel fails; the documented fix is importing the certificate or its CA into the JVM truststore. A TLS-terminating proxy or firewall between VM and BTP is the usual reason a chain that looks fine from your laptop is not fine from the VM.
Connector → backends. Since 2.15.0 a configuration API covers this store (path moved to onPremises in 2.18.0+). The trap: if trustAllBackends is false and the trusted-systems list is empty, the connector processes no HTTP requests at all. Inspect it (truststore doc):
```
curl -i -k -u <user>:<password> -X GET https://<host>:<port>/api/v1/configuration/connector/onPremises/truststore
```
The response lists alias, subject DN, issuer, and expiry per entry — enough to catch a rotation before it silently stops everything.
Destination truststore for HTTPS Internet destinations. Public endpoints need the certificate registered under Trust Store → Manage Destination Certificates in the subaccount — unrelated to the JVM store.

And item zero: the admin UI’s self-signed certificate is why scripted checks on port 8443 need -k or an internal CA. We replaced ours week one.

Troubleshooting: 401, 503, and Failed Pings

First, know what a green light is worth: Check Connection counts any backend status below 500 as success — a 401 still pings “successful” while every runtime call breaks — and the targeted URL cannot be a private or loopback address. The availability-check page lists verbatim OnPremise failures: “Backend status could not be determined.” (connector older than 2.7.1, not connected, backend at ≥500, or misconfigured); “Backend is not available in the list of defined system mappings in Cloud Connector.”; “Resource is not accessible in Cloud Connector or backend is not reachable.”; “Backend is not reachable from Cloud Connector.” Map symptoms in this triage table:

Symptom	Likely cause	First check
Ping OK but app gets 401	Backend answered <500 so ping passes; auth wrong	Destination authentication; user logon properties
503 “no Cloud Connector for your subaccount”	Connector disconnected, location ID mismatch, or connector on a different subaccount than the token	Cockpit Cloud Connections: Connected Since, peer labels
405 on HTTP proxy port 20003	`https://` where `http://` was required	Fix the scheme
407	Missing `Proxy-Authorization: Bearer <token>`	Add token (troubleshooting doc)
Not in list of defined system mappings	Virtual host/port unmapped or path not permitted	Configure Access Control
“There is no trust with Cloud Connector on…”	HA port not set for client-certificate logon	Configuration → User Interface → Authentication
All OnPremise calls silently fail	`trustAllBackends=false` with empty truststore	Query the truststore API above
Tunnel never establishes	Outbound 443 blocked; JVM distrusts chain	NSG/firewall; JVM truststore import

When the table runs out, evidence is in <scc_dir>/log/: scc_core.trc for the main trace, tunnel_traffic_*.trc and snc_traffic_*.trc for what crossed the tunnel. The monitoring and troubleshooting guide exposes trace levels (CPIC 0–3, TLS/SSL) that cost restarts and performance and are meant for support sessions; try Guided Answers and the Support Log Assistant first.

What Tripped Us Up

Three things burned more hours than expected. One: a destination pinged green for weeks, then “failed” the day the app went live — the service FQDN had been resolving to its public IP all along; our private DNS zone was linked to the wrong VNet, and the ping couldn’t tell the difference. Two: after standing up the HA pair, half the traffic 503’d. The primary’s location ID was empty, the shadow’s was set — copy-paste asymmetry; destinations pinned to the empty default kept hitting one node. Location IDs are per-subaccount routing keys, not decoration. Three: a backend certificate rotation silently stopped all connector HTTP processing — trustAllBackends=false with an allowlist of the old cert, and nobody had read the “processes no HTTP requests” footnote until the outage review. We now script the truststore GET weekly and alert on expiry inside 30 days.

Azure-Side Connectivity Checklist

Outbound 443 allowed from the connector subnet to cf.<region>.hana.ondemand.com / *.abap.<region>.hana.ondemand.com (plus trial or custom-region hosts as applicable).
One outbound path decided: NAT gateway for static SNAT IPs, or firewall-routed egress — not both fighting over the same UDR.
Private DNS zone per service FQDN linked to the connector’s VNet; never one zone across two services.
Endpoint created in the same region as the VNet; connection Approved; publicNetworkAccess disabled unless intentionally open.
NSG and ASG review for the endpoint subnet: the portal does not display effective rules on endpoint NICs, so pull effective NSG data from the CLI/API instead.
If using SAP Private Link service instead: restrict requests to the SAP BTP subscription IDs in SAP Note 3811111 and approve only the endpoint named in the cf service output — within 24 hours or the request expires:
```
cf service privatelink-test
status:    create in progress
message:   Please approve the connection for Private Endpoint sap-privatelink-00000000-0000-0000-0000-000000000001 in your Azure portal
```
Connector VM: JDK matrix satisfied, default password changed, UI certificate replaced, master/shadow pair with distinct HA port, system mappings documented, registration role revoked.

What This Guide Does Not Cover

This is connectivity plumbing, not an integration walkthrough. We skip Application Router and IAS custom-IdP configuration, OAuth2 flows against Entra-protected APIs beyond naming the destination option, SAP-managed connectors (RISE/S/4HANA Private Cloud ships its own), end-to-end Private Link service provisioning (the developers.sap.com tutorial is the hands-on path), backend-side RFC trust setup, and destination migration between subaccounts. ExpressRoute and hub topology live in our landing zone tutorial.

FAQ

Do I need SAP Cloud Connector to call Azure OpenAI from BTP?

No. Azure OpenAI is a public endpoint; a plain Internet-proxy-type destination works, as shown in our OpenAI integration guide. The connector matters for private backends; SAP Private Link service is the alternative for supported PaaS services in Cloud Foundry/Kyma runtimes.

Can one Cloud Connector serve multiple subaccounts?

Yes. One connector can connect to several subaccounts. SAP recommends against mixing production and development/test subaccounts, and with more than one connector per subaccount each location ID routes destinations explicitly.

Why does destination “Check Connection” succeed but my app still gets 401?

Because the check defines success as the backend responding with status below 500. A 401 proves the network path works and the authentication configuration — destination auth type, principal propagation, or logon properties — does not.

How many VMs and how much disk does a production connector need?

Two VMs for the supported master/shadow HA pair, no load balancer required. Size each to the recommended column: multi-core 3 GHz, 16 GB RAM, at least 20 GB free disk, plus headroom for trace and audit growth.

References

Next Steps

With the tunnel live and destinations resolving into your private network, continue with the Azure OpenAI integration on SAP BTP, back up to the subaccount and Entra SSO setup if your principal story starts at identity, and see the SAP landing zone on Azure where the connector’s subnet lives. More in BTP category or all tutorials.