Technical Articles
SAP Private linky swear with Azure – running Cloud Connector and SAP Private Link side-by-side
|
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 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 Invoke Proxy (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 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)
🤑110.09€ |
Customer’s Azure Subscription:
Customer’s BTP Subscription:
🤑69.46€ |
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 Gowri 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
Martin
Hi Martin,
Thanks for a great blog. Utilizing private link is a good option for lots of customers who run their SAP workloads on hyperscalers. I am particularly interested in the third option BTP->Private Link->SAP Cloud Connector->??? which offers lots of flexibility, especially for customers that are using SCC already. Do you have any update on the availability of this option? Any documentation on how to set it up? Thanks.
Rivers
Hi Rivers,
such Roadmap questions need to be directed at SAP. I collaborate with SAP engineering from the Microsoft side but SAP owns the service.
Gowri any comment from your side?
KR
Martin
Hi Rivers,
This scenario is included in our list of supported scenarios. However, we currently do not have a fixed timeline for its implementation. We will be able to provide you with more details regarding the progress of this scenario in Q4.
Thank you, Gowrisankar
What an amazing post Martin. PLS connectivity via Cloud connector with makes perfect sense when BTP has to be connected to Onprem
Cloud connector only setup makes sense when we have traffic inbound /outbound via internet.
Only PLS setup, its too cumbersome from an organisational perspective and also has outbound traffic limitations.
Do you agree with that?
Thank you,
Saurabh
Hi Saurabh Kumbhare,
don't fully understand your question. The SAP Private Link is usually applied to Cloud-2-Cloud scenarios even though you could technically resolve through routing tables, NVAs etc. to onprem. The Cloud Connector might play a role in Cloud-2-Cloud integrations for the purpose of the SAP specific audit log for instance.
Does that help?
KR
Martin
Hi Martin, this is a great blog and video. We are wondering if the the approuter in this scenario open to DDOS attacks? How is it secured?
Thank you,
Katie
Hi Katie,
any BTP service endpoint "lives" on the Internet and is prone to a DDOS attack. SAP is in charge protecting you and performing disaster recovery where needed. See this thread for more details.
You have that challenge for all services, not just the approuter. The Security part you control, is enforced through the OAuth2 flow described by SAP here using XSUAA. However, your service could still be busy/down for a while rejecting the calls if the URL gets out no matter the routing service.
You may consider fronting your BTP services with a web application firewall from Azure Front Door for instance to counter. You would then configure the approuter to accept incoming calls only from that domain.
Something like this in xs-app.json file.
But even with this the approuter is still publicly resolvable and could be targeted. Have look here to dig deeper in CF routing options.
Would be worth posting a followup question here to hear more from the CF community folks. Let me know how that goes.
KR
Martin
Extremely interesting post. One thing I have to mention. To my mind the price comparison is a bit too simplified here.
Generally I would say you need 3 machines for Cloud Connector. One for dev/test and two for production. One can argue about more or less machines.
But - and there is a catch - you can connect nearly arbitrary numbers of subaccounts to a cloud connector. And you will likely need many, if you follow Microsoft´s recommendation or SAP´s account model 5. And you have the ressource ACL topic that you need to solve.
If you have multiple stages and several applications I think you can easily end up with 30 and more subaccounts as a medium sized org. In that case the pendulum easly in favor of SCC.
But really great article series. I also still miss the reverse private link connection to SCC and HANA cloud. These are so obvious use-case and even in 2023 SAP has not implemented them. Product management at SAP is ...
Thanks for sharing that comment Sebastian Wolters. Regarding your comment on the component re-use and pendulum for Cloud Connector I would add that customers often have a hub-spoke topology with a routing device in the hub. From there you would have the same scaling argument that you used in favor of the SCC for the SAP Private Link.
Either way wanted to kick off such conversations and spark weighing of options with the post, such as you did 🙂 thanks again.
KR
Martin
Thanks for bringing up the discussion.The point I tried to make is not the central hub or a missing reuse there. Of course you can setup a central load balancer or application gateway that all subaccounts can connect to. But my argument here is if I follow the recommended subaccount models I would need a SAP private link instance in every subaccount. Even if all of them connect to the same hub ressource. If you have 10 applications with 3 stages you would theoretically end up with 30 subaccounts. Even if you would seperate more on spaces, as far as I know Cloud Foundry private link instances do not support instance sharing. But that is not info I checked myself.
So you would possibly pay 30*51,10€ = 1533€ plus bandwith per month. The SAP bandwith price is hefty. 1€ per GB or 10GB (the calculator is unclear by measuring GB but in blocks of 10). This is at least 10(!) times of what Microsoft charges SAP (Azure Private Link is at 0.09€ per 10GB) or what you as an Azure cloud engineer are used to. If I choose the Cloud Connector my data ingress is free. Neither SAP charges me nor does Microsoft.
To my mind this can really add up. One extreme scenario would certainly be SAP Integration Suite with the SFTP adapter that reads multiple large files several times per day and moves them to Azure blob storage via private link (Not to mention the dependence on a public app router that also needs to be able to handle the load). Or the other way around: Read a lot of data from Azure Storage or a SAP backend and transmit it to a b2b customer.
So my personal recommendation (everyone is free to do what he or she wants) right now is to use private link very consciously and only when necessary. For example if you really need the 99.9% SLA and your Cloud Connector installation cannot provide that. Likely due to your SAP Basis availability. Otherwise even a single VM with premium SSDs can provide you with that SLA. Or you really have these low latency demands. The scaling is not so relevant to my mind due to the bandwith fees. If you want to move TBs per month that´s way too costly.
Hi Sebastian,
The SAP Private Link service allows instance sharing, which is documented on our troubleshooting page. We have different angles to consider here:
Azure Private Link Service (generic LB scenario for VMs and others):
Hyperscaler Native Services:
For Cloud Connector, it involves ingress flow. If the traffic is going cross availability zones, it is still being charged (0.010€ per GB) by Microsoft. More information can be found regarding this can be found here: https://azure.microsoft.com/en-us/pricing/details/bandwidth/
SAP BTP bandwidth pricing is documented in the discovery center. Currently, BTP CF (Cloud Foundry) is not charged for bandwidth. However, once we have a solution, internet egress traffic will be more expensive than privatelink.
More details can be found here: https://discovery-center.cloud.sap/serviceCatalog/bandwidth?service_plan=bandwidth®ion=all&commercialModel=cloud&tab=service_plan
Thanks, Gowrisankar
Martin Pankraz :
Just want to know if my current workload is running in a Kubernetes Cluster (EKS) and if I am currently using a Connectivity Proxy for Kubernetes to connect to My On Premise S4 running in Azure (Private Cloud) via Cloud Connector then in this case how private service will helpful for me?
Hi Ujala Kumar Panda,
the mix of things described in that one sentence is a little hard to disect. I believe you mean AKS (not EKS?). I describe the Azure Kubernetes Service options for SAP Private Link for Azure here. In general you cannot mix hyperscaler and BTP Private Link. Both parties need to be on the same. On-Premises is often not a good scenario for the SAP Private Link. Stick with the Cloud Connector in such cases to avoid the complexity of ExpressRoutes, Firewalls etc. connecting from your hyperscaler environment where you terminate your SAP Private Link.
KR
Martin