Dear community,

Continuing with the implementation journey of BTP 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 type	SAP owned Java software running on a Virtual Machine or Container, requiring OS and JVM patching and upgrades	Built upon Microsoft’s managed PaaS Azure Private Link
Integration Concept	Reverse Connect (outbound Internet connection required)	Traffic travels privately via Microsoft backbone (no Internet connectivity required)
Service availability	Independent, 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 model	Software-based connectivity with Layer 7 features	Layer 4 device as interconnected with Azure Standard Load balancer
High Availability / Disaster Recovery	VM redundancy with master-shadow concept / Azure Backup and DR	Built-in, because PaaS. See SLA for details
Scalability / Sizing	Limited by JVM, SAP T-Shirt sizes recommended (VM resize requires restart)	Practically unlimited because PaaS utilizing Microsoft backbone
Monitoring	OS level commands for hardware metrics, or Admin UI and SCC APIs. VM monitoring on Azure	Built-in with Azure and Azure Monitor, because PaaS.
Bandwidth	Limited by host running SCC and network path to BTP	Practically 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 Security	Apply 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 support	native	Only WebSocket RFC so far. Read more on that here.
SAP Principal Propagation	native	supported, potential flow simplification addressed with SAP.
SAP app specific Audit Logging	Built-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 control	Built-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 Time* (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.
Pricing** 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 machines*** for HA: 100.46€ 110.09€	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 69.46€

* Sequence 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

** 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.

*** 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

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 M 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 Azure storage PaaS solutions 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

Martin