Hi @filipniziol ,

Have you encountered any situation where you had two workspaces with Private Link configured and were able to invoke an API call from one workspace with Private Link to the other workspace, also with Private Link enabled?

All our production workspaces are deployed with Private Link.  Production workspaces are deployed in Northern Europe.  We are able to access a REST endpoint hosted on any production workspace from a workspace deployed in south east asia. 

Therefore, in the cross-region scenario, cross-workspace access is not an issue.  Which leads me to conclude that VNET peering is necessary only when cross accessing workspaces deployed in the same region.

If yes, this could indicate a misconfiguration, where both Private Link and public access are enabled simultaneously on the workspace. This setup would allow API calls via the public endpoint, bypassing the restrictions intended by Private Link.

We've implemented the scenario in the red box below and it seems like it's working well.  This means that classic compute in the data plane can interact with notebooks/jobs/etc, in the control plane.  At this point, we're fine with workspaces accessed through the public IP - my objective was to eliminate public IPs between control and data planes.  

What is odd is why cross workspace access poses no problem when bridging regions but throws an error when we try to invoke a call on a host which is in the same region of the calling workspace (as mentioned above).

Regards,

James