Background

Building on a previous blog post where I explored what a possible Azure Synapse Analytics logical architecture might look like in terms of end-to-end data curation/enrichment, here: Thinking about an Azure Synapse Analytics Logical Architecture v1

Now, with the recently added Synapse 'Managed Virtual Network' I'm exploring the same architecture from a physical network connectivity perspective.

Given all the different service offerings rolled up and unified within the Synapse Analytics resource connectivity was also going to be a concern. That concern, it seems, as now neatly been addressed with another bit of Microsoft IaaS abstraction.

https://docs.microsoft.com/en-us/azure/synapse-analytics/security/synapse-workspace-managed-vnet

As a data platform person, not really that comfortable dealing with network stuff, having these easy click options to add to our Synapse workspace is great:

  • Managed VNet's
  • Managed Private Endpoints
  • Managed Firewall's

Why? Well, there is certainly a newfound appetite for having all PaaS resources protected behind that extra layer of security in the form of private connections. No longer are we happy to simply open an Azure SQLDB to all other Azure resources, affectively adding a huge set of Microsoft IP ranges to the resource firewall.

So, friends, what do you think to the below picture as a first version for a complete Synapse data platform, all operating using private network connections? Surrounded in purple, I've also added a few other typically used Azure resources to highlight some wider integrations that might exist, all optional.

Caveats

A couple of things to call out here:

  1. You can only enable the Managed VNet support for Synapse at the time the resource is first deployed. You can't have this capability added later to an existing Synapse instance.
  2. What I've drawn in the Synapse Managed Resource Group is total guess work! Although the Resource Group is visible in your Azure Subscription and you can even 'unhide' some of the SQL contents, shown below, nothing more is known about the internals here. So, as I say, total guess work.

Other Thoughts

If we don't want to use the Microsoft Managed VNet and have the feature disabled for Synapse. There isn't yet an option to bring our own VNet, or use another established VNet on the corporate network. Hence, I choose to extend the diagram above with some possible options for Express Route connections etc. This is still just 1 way traffic for data sources getting data into Synapse though. As you'll see, we still have to hit the Synapse Workspace and SQL Endpoints via a public connection and using the local resource firewall to limit traffic.

What would be nice is to have the option to peer the Synapse VNet with a VNet of our own, like what can be done with Azure Databricks… Crudely drawn in the below picture with a thick red line 🙂

When can we have this please Microsoft?

Many thanks for reading.

Comments very welcome.