Synapse Workspace Has No Managed VNet: Why It Matters and How to Fix It

Azure Synapse Analytics is one of those services that quietly handles a lot of sensitive movement: pipelines pulling from storage accounts, Spark jobs crunching customer data, SQL pools serving up reports. By default, the network posture of a Synapse workspace is more open than most teams realize. The managed virtual network feature is the single most important toggle for tightening that posture, and it is one that catches people out because of when it has to be set.

This check looks for Synapse workspaces where managed VNet is disabled, and it matters more than it sounds.

---

What this check detects

The synapse_nomanagedvnet check inspects every Azure Synapse workspace in your subscription and flags any where the managed virtual network setting is not enabled. In the workspace properties, this surfaces as managedVirtualNetwork being absent or set to anything other than "default".

When managed VNet is off, the integration runtimes that power your Synapse pipelines and Spark pools run in a shared network environment alongside other Azure tenants. There is no dedicated isolation boundary around the compute that touches your data.

---

Why it matters

The risk here is not theoretical exposure to the public internet. It is about tenant isolation and the way data leaves your workspace.

No tenant isolation for compute

Without managed VNet, the compute resources running your pipelines are not isolated at the network layer from other Azure customers using the same shared infrastructure. For most workloads this is an acceptable risk, but for regulated data (PCI, HIPAA, financial records) it is often a compliance gap. Auditors increasingly ask for evidence that data-processing compute runs in a dedicated network boundary.

You lose Managed Private Endpoints

This is the practical sting. Managed Private Endpoints, which let your Synapse workspace connect to other Azure resources (storage accounts, Key Vault, SQL databases) over a private link instead of public endpoints, are only available when managed VNet is enabled. Turn it off, and every connection from your pipelines to your data stores has to traverse public Azure endpoints.

Data exfiltration controls disappear

Managed VNet workspaces support data exfiltration protection, which restricts outbound traffic from the workspace to an approved list of Azure AD tenants. Without managed VNet, a malicious or compromised pipeline could write data out to an external storage account in an attacker-controlled tenant with no network-level block in place. That is a real exfiltration path that data exfiltration protection is designed to close.

---

How to fix it

Here is the catch that trips everyone up: managed VNet cannot be enabled on an existing Synapse workspace. It is a create-time-only setting. To remediate, you have to create a new workspace with the feature enabled and migrate your artifacts across.

Step 1: Create a new workspace with managed VNet enabled

Using the Azure CLI:

az synapse workspace create \
  --name myworkspace-secure \
  --resource-group my-rg \
  --storage-account mystorageaccount \
  --file-system synapsefs \
  --sql-admin-login-user sqladminuser \
  --sql-admin-login-password "$SQL_ADMIN_PASSWORD" \
  --location eastus \
  --enable-managed-virtual-network true \
  --allowed-tenant-ids $(az account show --query tenantId -o tsv)

The --enable-managed-virtual-network true flag is the one that satisfies this check. The --allowed-tenant-ids flag activates data exfiltration protection, restricting outbound connections to the tenants you list.

Step 2: Recreate your Managed Private Endpoints

Once the managed VNet workspace exists, set up private connections to your data stores:

az synapse managed-private-endpoints create \
  --workspace-name myworkspace-secure \
  --pe-name mystorage-pe \
  --resource-id "/subscriptions/SUB_ID/resourceGroups/my-rg/providers/Microsoft.Storage/storageAccounts/mystorageaccount" \
  --group-Id blob

You will need to approve the corresponding private endpoint connection on the target resource. For a storage account:

az storage account private-endpoint-connection approve \
  --account-name mystorageaccount \
  --resource-group my-rg \
  --name "the-connection-name" \
  --description "Approved for Synapse managed VNet"

Step 3: Migrate workspace artifacts

Export and re-import your pipelines, linked services, datasets, and notebooks. If you connected your workspace to Git, this is straightforward: point the new workspace at the same repository and publish. If not, use the Synapse REST API or the az synapse commands to export each artifact type and recreate it in the new workspace.

Doing it in Terraform

For teams managing Synapse as code, set managed_virtual_network_enabled to true from the start:

resource "azurerm_synapse_workspace" "secure" {
  name                                 = "myworkspace-secure"
  resource_group_name                  = azurerm_resource_group.main.name
  location                             = azurerm_resource_group.main.location
  storage_data_lake_gen2_filesystem_id = azurerm_storage_data_lake_gen2_filesystem.main.id
  sql_administrator_login              = "sqladminuser"
  sql_administrator_login_password     = var.sql_admin_password

  managed_virtual_network_enabled      = true

  data_exfiltration_protection_enabled = true
  managed_resource_group_name          = "myworkspace-secure-managed-rg"

  identity {
    type = "SystemAssigned"
  }
}

Note that changing managed_virtual_network_enabled on an existing resource forces Terraform to destroy and recreate the workspace, which reinforces the point: get it right at creation.

---

How to prevent it from happening again

Because this setting is create-time only, prevention is far cheaper than remediation. Catch it before the workspace exists.

Enforce with Azure Policy

Use a custom Azure Policy with a deny effect that blocks any Synapse workspace created without managed VNet enabled:

{
  "policyRule": {
    "if": {
      "allOf": [
        {
          "field": "type",
          "equals": "Microsoft.Synapse/workspaces"
        },
        {
          "anyOf": [
            {
              "field": "Microsoft.Synapse/workspaces/managedVirtualNetwork",
              "exists": "false"
            },
            {
              "field": "Microsoft.Synapse/workspaces/managedVirtualNetwork",
              "notEquals": "default"
            }
          ]
        }
      ]
    },
    "then": {
      "effect": "deny"
    }
  }
}

Assign this at the management group or subscription scope so it covers every team. A deny policy stops a non-compliant workspace from ever being created, which is exactly what you want for a setting you cannot fix later.

Gate it in CI/CD

If your Synapse workspaces are deployed through pipelines, add a check in your IaC validation stage. For Terraform, a quick grep in a pre-apply step works as a backstop:

# Fail the pipeline if any synapse workspace lacks managed VNet
if grep -A20 'azurerm_synapse_workspace' *.tf | \
   grep -q 'managed_virtual_network_enabled\s*=\s*false'; then
  echo "ERROR: Synapse workspace defined without managed VNet"
  exit 1
fi

A more robust approach is a policy-as-code tool like Checkov or Conftest, which can evaluate Terraform plans against rules before anything reaches Azure.

---

Best practices

• Enable managed VNet on every new workspace by default. Make it the standard in your module or template so engineers never have to remember it. The performance and cost overhead is minimal for the isolation you gain.
• Pair managed VNet with data exfiltration protection. Set allowedTenantIds to your own tenant so pipelines cannot write data to external tenants. This is one of the strongest outbound controls Synapse offers.
• Use Managed Private Endpoints for all data stores. Once managed VNet is on, route every connection to storage, Key Vault, and databases over private endpoints and disable public network access on those resources.
• Connect workspaces to Git from day one. The biggest barrier to remediation is artifact migration. Git integration turns a painful rebuild into a publish.
• Provision Spark pools knowing the warm-up tradeoff. Managed VNet adds a short startup delay to Spark clusters because of network setup. Plan pool warm-up or keep a small pool ready if you have latency-sensitive interactive workloads.

The takeaway is simple: managed VNet is cheap to enable at creation and expensive to add later. Treat it as a non-negotiable default, enforce it with policy, and your Synapse workspaces start their life with the network isolation regulated data deserves.