This is a great article Ben, thanks for putting it all in one place, with great pictures too.
One thing to note for large customers that want to use private networking everywhere, the name for the Synapse Studio Portal private endpoint is just "web.azuresynapse.net", instead of the instance name like the other resources. For folks with integrated DNS across Azure, this means that registering this in a spoke landing zone for the first Synapse workload would in effect mean that the second Synapse workload that wanted private endpoints for the studio would be unable to register that DNS name twice (since it isn't unique).
Two options for that, the first being just use the public endpoint for the Synapse Studio. This is probably the easiest and best way, with very low risk.
- it's control plane access,
- requires Azure RBAC, Azure AD MFA or conditional access, etc.
- threat model is very similar to the Azure Portal itself
The other option might be to have a private endpoint hub for the Synapse Studio created centrally in the hub network, and allow any Synapse based workload to use that instead. Would need a bit more planning, firewall rule consideration, etc.
Awesome article Ben.