Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
Showing results for 
Search instead for 
Did you mean: 
Active Contributor
This post is part 8 of a series sharing service implementation experience and possible applications of SAP Private Link Service on Azure.

Find the table of contents and my curated news regarding series updates here.

Looking for part 9?

Find the associated GitHub repos here.

Dear community,

Continuing with the implementation journey of SAP Private Link Service (PLS) for Azure we will have a closer look at the “ins and outs” of running both SAP Business Technology Platform (BTP) connectivity options that SAP offers.

This post builds upon part 1 of the series in terms of comparing SAP Cloud Connector (SCC) with the new SAP Private Link for Azure.

Fig. 1 Combining PLS and SAP Cloud Connector gets you the best of both worlds

Looking under the hood

The SAP Cloud Connector was purpose-built for SAP BTP integration with traditional data centre or on-premises based workloads with emphasis on creating a private tunnel from within the customer’s network. That way opening problematic inbound channels on the customer firewall could be avoided. Till today it is a common pattern to connect to BTP also from cloud based Hyperscaler environments.

Since then, the SCC has evolved on the application layer with SAP specific connectivity features.

 SAP Cloud Connector (SCC)SAP Private Link (PLS)
Workload typeSAP owned Java software running on a Virtual Machine or Container, requiring OS and JVM patching and upgradesBuilt upon Microsoft’s managed PaaS Azure Private Link 👍
Integration ConceptReverse Invoke Proxy (outbound Internet connection required)Traffic travels privately via Microsoft backbone (no Internet connectivity required) 👍
Service availabilityIndependent, can be installed anywhere including on-premises, a Raspberry PI, or any hyperscaler 👍Requires BTP and target workload to be run on Azure by design
Location on the OSI modelSoftware-based connectivity with Layer 7 features 👍Layer 4 device as interconnected with Azure Standard Load balancer
High Availability / Disaster RecoveryVM redundancy with master-shadow concept / Azure Backup and DRBuilt-in, because PaaS. See SLA for details 👍
Scalability / SizingLimited by JVM, SAP T-Shirt sizes recommended (VM resize requires restart)Practically unlimited because PaaS utilizing Microsoft backbone 👍
MonitoringOS level commands for hardware metrics, or Admin UI and SCC APIs. VM monitoring on AzureBuilt-in with Azure and Azure Monitor, because PaaS. 👍
BandwidthLimited by host running SCC and network path to BTPPractically unlimited because utilizes Microsoft backbone 👍
Transport Layer Security (SSL/TLS)SSL/TLS termination built-in, virtual + physical hostname mapping. Only virtual hostnames are used in BTP masking true names if desired with added benefit of somwhat simpler TLS setup.👍SAP-generated hostnames for PLS require a dedicated trust setup with BTP Trust Store and SAP Personal Security Environment (PSE) including Server Name Indication (SNI). See this dedicated post for more details.
Device SecurityApply SAP’s guidelines for a secure setup. Consider configuring Azure AD as Identity Provider for SCC Admin Cockpit and add your own trusted domain and cert for the SCC URL.Built-in, managed PaaS by Microsoft 👍
SAP RFC supportnative👍Only WebSocket RFC so far. Read more on that here.
SAP Principal Propagationnativesupported, potential flow simplification addressed with SAP.
SAP app specific Audit LoggingBuilt-in, solves the task for all connected BTP scenarios in one place 👍
Requires workaround with involved components:

Either SAP WebDispatcher and Azure immutable storage for example, or

BTP app integration with BTP Audit Logging Service before reaching through the tunnel.
SAP Endpoint specific access controlBuilt-in support for RFC and OData path allow listing as well as restrictions for LDAP and TCP. Restrictions can be applied to pre-registered target systems too. 👍Requires configuration in multiple components on the integration path: SAP Web Dispatcher Access Control List (ACL), http path allow list, SAP UCON for RFC on the ERP (downside all-or-nothing approach, compared to SCC fine-grained options). See more details here. Last resort is the Azure Network Security Group to block complete port ranges for RFC for instance.

Message Round Trip Time1 (RTT)

(Not statistically significant! Only rough indicator)

Average RTT: 280ms

Max RTT: 902ms

Min RTT: 138ms


RTT seems to have a larger spread due to less predictable routing via public Internet. I assume the lower min outlier happened due to the SSL termination at SCC and final call via http instead of https.
Average RTT: 201ms

Max RTT: 315ms

Min RTT: 177ms




RTT more stable and 28% faster on average. 👍
Pricing2 per month (1 GiB data transfer)for free 🎁but secondary cost for maintenance (patching/upgrade)

    • Azure Backup (2VMs): 9.63€
    • Azure egress: free till > 5GiB
    • Azure ingress: free
    • 2 virtual machines3 for HA: 100.46€



Customer's Azure Subscription:

    • Azure Private Link Service: for free
    • Azure Standard Load Balancer: 17.36€

Customer's BTP Subscription:
    • SAP Private Link: 51.10€
    • Bandwidth: 1€ per GiB data processed

1Sequence of 10 requests from BTP CF Java app in West Europe (Amsterdam) to SAP Gateway in North Europe (Dublin). Measured via java.time.Instant class. Java Heap space 1GB, VM SKU B2ms: 2CPU/8GiB memory

2 Snapshot of pricing at time of writing the blog with no claim for correctness or completeness. Assumed smallest SKUs in West Europe wherever possible. Check Azure Price Calculator and SAP Estimator for reference and recent pricing info.

3 SCC T-Shirt-Size S: 2cores, 4GB memory, Azure VM SKU D2as with 3 year reserved instance


Fig.2 Moving from public outbound to fully private access


Note on the side

If you implement SCC and PLS side by side make sure to pay attention to the different access control capabilities and scopes. Let's say you put an OData path allow list for "/sap/opu/odata/" in the SCC but didn't make any adjustments on the SAP WebDispatcher path restrictions exposed via the PLS:

Congratulations🥳 you just created a likely undesired gap in your access control 😜

Which option should I pick?

As you can see both approaches have merit in their own regard.

sven.kohlhaas from SAP shared on the SAP on Azure YouTube channel during our joint webcast session more insights into the roadmap. We are working closely together to make sure to combine the best of both worlds and offer a “third configuration option” so to say:

Fig.3 Screenshot from roadmap shared by Sven

To mitigate the public outbound requirement (see fig.2) and profit from the SAP opinionated app layer features, it makes sense to offer the SCC functionality through the Private Link instead of via the public Internet. Compared to the existing scope of the PLS, that means the reverse integration direction is required (see fig.3 with emphasis on the initial communication flow).

Once that combined option becomes available you would be able to leverage it for scenarios like SAP Analytics Cloud using the SAC Agent, Data Warehouse Cloud (DWC) and Hana Cloud for example.

Comments from the “ground”

Customers I spoke with liked the isolation and SAP-only purpose of the Cloud Connector within their IT and networking landscape. SAP Basis and Azure IT or general IT are often strictly separate teams. Since SAP Private Link engages Azure Private Link and touches multiple components in its path, SAP Basis folks need to get in contact more with those other IT departments within the company. That often increases the governance and negotiation efforts.

Before that you could gotten away with two VM instance and a one-off conversation about your path out into the Internet. You could say the SAP Private Link for Azure brings together SAP Basis and general IT. That comes with a set of challenges for established organizational structures.

Thoughts on production readiness

SAP Private Link is generally available and therefor completely ready for prime time (quoting gowrisankar.m2 from the SAP engineering team 😊).

My blog series adds details to SAP’s standard docs to get you up and running smoother.

Final Words

Not too bad, huh? You saw today how SAP Cloud Connector and SAP Private Link differ in terms of scope, functionality, and service layer. Furthermore, you gained insights in the roadmap of the SAP PLS looking to combine both approaches to offer the best of both worlds.

The next part of the blog series will discuss connecting to Azure Kubernetes Service hosted apps via PLS.

Do you agree SAP @Developers and @Architects?

Find the related GitHub repos here.

Find your way back to the aggregator blog post here.

As always feel free to ask lots of follow-up questions.

Best Regards

Labels in this area