Home > Docs > Features > VNet Data Gateway

🔒 VNet Data Gateway - Secure Connectivity from Your Virtual Network¶

Last Updated: 2026-04-21 | Version: 1.0.0

📑 Table of Contents¶

• 🎯 Overview
• 🏗️ Architecture
• ⚙️ Setup & Requirements
• 🔀 Gateway Comparison
• 🔌 Supported Data Sources
• 🔐 Security & Network Configuration
• 📊 Performance & Scaling
• 🎰 Casino Implementation
• 🏛️ Federal Agency Implementation
• ⚠️ Limitations
• 📚 References
• 🔗 Related Documents

🎯 Overview¶

The VNet Data Gateway is a Microsoft-managed gateway that runs inside a customer's Azure Virtual Network (VNet), enabling Fabric to securely connect to data sources that are not publicly accessible. Unlike the traditional on-premises data gateway — which requires installing and maintaining software on a dedicated VM — the VNet Data Gateway is a fully managed Azure resource that inherits the network security posture of your VNet.

This means data never leaves the customer's network boundary when transiting between private data sources and Fabric. The gateway containers are injected into a delegated subnet within the customer's VNet, giving them access to any resource reachable from that subnet — including on-premises networks connected via ExpressRoute or VPN, private endpoint-protected Azure services, and VNet-peered resources.

Key Capabilities¶

🏗️ Architecture¶

flowchart TB
    subgraph Fabric["☁️ Microsoft Fabric"]
        DS["Dataflow Gen2"]
        SM["Semantic Model"]
        LH["Lakehouse<br/>Shortcut"]
        PL["Pipeline<br/>Copy Activity"]
    end

    subgraph CustomerVNet["🔒 Customer Azure VNet (10.0.0.0/16)"]
        subgraph GWSub["Gateway Subnet (10.0.1.0/24)<br/>Delegated: Microsoft.PowerPlatform/vnetaccesslinks"]
            GW["VNet Data Gateway<br/>Managed Containers"]
        end

        subgraph DataSub["Data Subnet (10.0.2.0/24)"]
            SQL["Azure SQL MI<br/>Private Endpoint"]
            PG["PostgreSQL<br/>Private Endpoint"]
        end
    end

    subgraph OnPrem["🏢 On-Premises Data Center"]
        ORCL["Oracle Database"]
        SQLSRV["SQL Server 2019"]
        FILES["File Shares"]
    end

    Fabric -->|"Managed connection<br/>over Microsoft backbone"| GW
    GW -->|"Private link"| SQL
    GW -->|"Private link"| PG
    GW -->|"ExpressRoute / VPN"| ORCL
    GW -->|"ExpressRoute / VPN"| SQLSRV
    GW -->|"SMB over VPN"| FILES

    style Fabric fill:#2471A3,stroke:#1A5276,color:#fff
    style CustomerVNet fill:#1ABC9C,stroke:#16A085,color:#000
    style GWSub fill:#F39C12,stroke:#E67E22,color:#000
    style DataSub fill:#27AE60,stroke:#1E8449,color:#fff
    style OnPrem fill:#E74C3C,stroke:#C0392B,color:#fff

How It Works¶

1. Subnet Delegation: You delegate a subnet to Microsoft.PowerPlatform/vnetaccesslinks. This allows Microsoft to inject managed gateway containers.
2. Gateway Registration: In the Fabric portal (or via API), you create a VNet Data Gateway and associate it with the delegated subnet.
3. Connection Binding: Data connections in Fabric (Dataflows, Pipelines, Semantic Models) reference the VNet Gateway instead of an on-premises gateway.
4. Traffic Flow: When a query executes, Fabric routes the request through the Microsoft backbone to the gateway containers in your subnet. The containers connect to data sources using your VNet's routing and NSG rules.

⚙️ Setup & Requirements¶

Prerequisites¶

Step-by-Step Setup¶

1. Prepare the Subnet¶

// VNet with delegated subnet for VNet Data Gateway
resource vnet 'Microsoft.Network/virtualNetworks@2023-09-01' = {
  name: 'vnet-fabric-${environment}'
  location: location
  properties: {
    addressSpace: {
      addressPrefixes: ['10.0.0.0/16']
    }
    subnets: [
      {
        name: 'snet-vnet-gateway'
        properties: {
          addressPrefix: '10.0.1.0/26'
          delegations: [
            {
              name: 'delegation-powerplatform'
              properties: {
                serviceName: 'Microsoft.PowerPlatform/vnetaccesslinks'
              }
            }
          ]
          networkSecurityGroup: {
            id: nsgVnetGateway.id
          }
        }
      }
      {
        name: 'snet-data'
        properties: {
          addressPrefix: '10.0.2.0/24'
        }
      }
    ]
  }
}

2. Configure NSG Rules¶

resource nsgVnetGateway 'Microsoft.Network/networkSecurityGroups@2023-09-01' = {
  name: 'nsg-vnet-gateway'
  location: location
  properties: {
    securityRules: [
      {
        name: 'AllowOutboundToDataSources'
        properties: {
          priority: 100
          direction: 'Outbound'
          access: 'Allow'
          protocol: 'Tcp'
          sourceAddressPrefix: '10.0.1.0/26'
          sourcePortRange: '*'
          destinationAddressPrefix: '10.0.2.0/24'
          destinationPortRanges: ['1433', '5432', '1521']
        }
      }
      {
        name: 'AllowOutboundHTTPS'
        properties: {
          priority: 110
          direction: 'Outbound'
          access: 'Allow'
          protocol: 'Tcp'
          sourceAddressPrefix: '10.0.1.0/26'
          sourcePortRange: '*'
          destinationAddressPrefix: 'AzureCloud'
          destinationPortRange: '443'
        }
      }
      {
        name: 'DenyAllOtherOutbound'
        properties: {
          priority: 4096
          direction: 'Outbound'
          access: 'Deny'
          protocol: '*'
          sourceAddressPrefix: '*'
          sourcePortRange: '*'
          destinationAddressPrefix: '*'
          destinationPortRange: '*'
        }
      }
    ]
  }
}

3. Register the Gateway in Fabric¶

Navigate to Settings > Manage connections and gateways > Virtual network data gateways > + New and select the subscription, VNet, and delegated subnet.

Alternatively via PowerShell:

# Register VNet Data Gateway
$params = @{
    Name              = "vnetgw-fabric-prod"
    SubscriptionId    = $subscriptionId
    ResourceGroupName = $rgName
    VNetName          = "vnet-fabric-prod"
    SubnetName        = "snet-vnet-gateway"
    Region            = "eastus2"
}
New-VirtualNetworkDataGateway @params

🔀 Gateway Comparison¶

flowchart LR
    subgraph Decision["🤔 Which Gateway?"]
        Q1{"Data source<br/>location?"}
        Q2{"Have Azure<br/>VNet?"}
        Q3{"Using ADF<br/>pipelines only?"}
    end

    Q1 -->|"On-premises only,<br/>no Azure VNet"| ONPREM["On-Premises<br/>Data Gateway"]
    Q1 -->|"Azure private<br/>or hybrid"| Q2
    Q2 -->|"Yes"| VNET["VNet Data<br/>Gateway ✅"]
    Q2 -->|"No"| ONPREM
    Q1 -->|"Azure + ADF<br/>pipelines"| Q3
    Q3 -->|"Yes"| SHIR["Self-Hosted<br/>Integration Runtime"]
    Q3 -->|"No"| VNET

    style VNET fill:#27AE60,stroke:#1E8449,color:#fff
    style ONPREM fill:#E67E22,stroke:#CA6F1E,color:#fff
    style SHIR fill:#3498DB,stroke:#2980B9,color:#fff

🔌 Supported Data Sources¶

🔐 Security & Network Configuration¶

Network Security Best Practices¶

flowchart TB
    subgraph Security["🛡️ Defense in Depth"]
        NSG["NSG Rules<br/>Allow only required ports"]
        UDR["Route Tables<br/>Force tunnel to firewall"]
        FW["Azure Firewall<br/>FQDN filtering"]
        PE["Private Endpoints<br/>No public exposure"]
        DIAG["NSG Flow Logs<br/>Traffic auditing"]
    end

    NSG --> UDR --> FW --> PE --> DIAG

    style Security fill:#E74C3C,stroke:#C0392B,color:#fff

Credential Management¶

All data source credentials are stored in Azure Key Vault or Fabric's managed credential store. Credentials never transit through the public internet.

# Connection using Fabric managed connection
connection_config = {
    "gateway_id": "vnetgw-fabric-prod",
    "datasource_type": "Sql",
    "server": "sql-casino-prod.database.windows.net",
    "database": "CasinoOps",
    "auth_type": "ServicePrincipal",
    "credential_reference": "kv-fabric/sp-sql-reader"
}

📊 Performance & Scaling¶

Scaling Behavior¶

The VNet Data Gateway automatically scales containers within the delegated subnet based on concurrent query load.

Subnet Sizing Guide¶

📝 Azure reserves 5 IPs per subnet. Subnet size directly limits max concurrent gateway containers.

🎰 Casino Implementation¶

Secure Access to On-Premises SQL Server¶

Casino operators running SQL Server on-premises for their casino management system (CMS) can use the VNet Data Gateway to securely pull slot telemetry, player tracking, and compliance data into Fabric without exposing the CMS to the internet.

flowchart LR
    subgraph Casino["🏢 Casino Data Center"]
        CMS["Casino Management<br/>System (SQL Server)"]
        PTS["Player Tracking<br/>System (Oracle)"]
    end

    subgraph Azure["☁️ Azure"]
        ER["ExpressRoute<br/>Circuit"]
        GW["VNet Data Gateway<br/>snet-vnet-gateway"]
    end

    subgraph Fabric["🔷 Microsoft Fabric"]
        DF["Dataflow Gen2<br/>Incremental Refresh"]
        LH["Lakehouse<br/>lh_bronze"]
        PBI["Power BI<br/>Floor Dashboard"]
    end

    CMS -->|"TDS 1433"| ER
    PTS -->|"TNS 1521"| ER
    ER -->|"Private peering"| GW
    GW -->|"Managed connection"| DF
    DF --> LH --> PBI

    style Casino fill:#E74C3C,stroke:#C0392B,color:#fff
    style Azure fill:#F39C12,stroke:#E67E22,color:#000
    style Fabric fill:#2471A3,stroke:#1A5276,color:#fff

Casino Connection Configuration¶

# Dataflow Gen2 connection to on-premises CMS via VNet Gateway
casino_connection = {
    "gateway": "vnetgw-casino-prod",
    "source": {
        "type": "SqlServer",
        "server": "10.100.5.20",  # On-premises CMS SQL Server (private IP)
        "database": "CasinoMgmt",
        "auth": "Windows",
        "domain": "CASINO\\\\svc-fabric-reader"
    },
    "tables": [
        "dbo.SlotMachineEvents",
        "dbo.PlayerSessions",
        "dbo.ComplianceTransactions",
        "dbo.CageTransactions"
    ]
}

Compliance Data Access¶

For CTR and SAR reporting, the VNet gateway ensures that sensitive financial transaction data traverses only the private ExpressRoute circuit — never the public internet:

🏛️ Federal Agency Implementation¶

FedRAMP-Compliant Data Access¶

Federal agencies operating in Azure Government or Azure Commercial with FedRAMP requirements can use VNet Data Gateways to ensure all data access paths remain within controlled network boundaries.

flowchart TB
    subgraph FedNet["🏛️ Federal Network (FedRAMP Boundary)"]
        subgraph OnPrem["Agency Data Center"]
            DB1["HR Database<br/>SQL Server"]
            DB2["Financial System<br/>Oracle"]
        end

        subgraph AzGov["Azure Gov VNet"]
            ER2["ExpressRoute"]
            GW2["VNet Data Gateway"]
            PE2["Private Endpoints<br/>Storage, SQL"]
        end
    end

    subgraph FabricGov["🔷 Fabric (Gov Region)"]
        LH2["Lakehouse"]
        NB2["Notebooks"]
        PBI2["Power BI"]
    end

    DB1 --> ER2 --> GW2
    DB2 --> ER2
    GW2 --> PE2
    GW2 --> FabricGov

    style FedNet fill:#1A5276,stroke:#154360,color:#fff
    style AzGov fill:#1ABC9C,stroke:#16A085,color:#000
    style FabricGov fill:#2471A3,stroke:#1A5276,color:#fff

NIST 800-53 Alignment¶

EPA: Water Quality Sensor Data via Private Endpoints¶

# EPA Cosmos DB accessed via private endpoint through VNet Gateway
epa_connection = {
    "gateway": "vnetgw-epa-prod",
    "source": {
        "type": "CosmosDb",
        "endpoint": "https://cosmos-epa-sensors.documents.azure.us",  # Private endpoint resolved
        "database": "WaterQuality",
        "auth": "ManagedIdentity"
    },
    "containers": [
        "sensor-readings",
        "compliance-alerts",
        "station-metadata"
    ]
}

⚠️ Limitations¶

📚 References¶

🔗 Related Documents¶

• Network Security — Private endpoints and firewall configuration
• OneLake Security — Managed VNet and Workspace Identity
• Outbound Access Protection — Control outbound traffic from Fabric
• Mirroring — Mirroring may require VNet Gateway for private sources
• Identity & RBAC Patterns — Service principal auth for gateway connections
• Customer-Managed Keys — Encryption for data at rest
• Disaster Recovery & BCDR — Gateway HA and failover
• Architecture — System architecture overview

📝 Document Metadata - Author: Documentation Team - Reviewers: Network Engineering, Security, Platform Engineering, Compliance - Classification: Internal - Next Review: 2026-07-21