本地用户访问Azure数据湖与PowerBI的连接路径及VPN隧道扩展性咨询

Great question — let’s break this down clearly, starting with exactly how the connection flows for your local users, then tackling the VPN scalability challenge.

Your initial understanding is mostly correct, but let’s add granular details specific to your architecture:

• Step 1: User initiates the request
  When a local user opens a PowerBI report (via browser or desktop app) or accesses ADLS directly (e.g., through Azure Storage Explorer), their device first resolves the target resource’s address. If you’ve configured private endpoints for ADLS (a security and performance best practice), your local DNS will resolve ADLS to its private IP within your Azure VNet. For PowerBI, the request first goes to the PowerBI service; if the report uses ADLS as a data source (especially with DirectQuery or VNet-integrated access), the service will route the data request through your Azure VNet.

• Step 2: Traffic routes to the local VPN gateway
  Your local network’s routers/firewall use preconfigured route rules to send any traffic targeting Azure VNet subnets to your on-premises VPN gateway.

• Step 3: Encrypted transit via Site-to-Site VPN tunnel
  The traffic is encrypted and sent over the secure Site-to-Site VPN tunnel to your Azure Virtual Network Gateway.

• Step 4: Azure routes traffic to target resources

  • For ADLS requests: The Azure gateway forwards the traffic directly to ADLS (if using private endpoints, this stays within the Azure VNet with no public internet hop).
  • For PowerBI reports: The PowerBI service retrieves data from ADLS via the VNet connection, generates the rendered report, and sends the response back through the same tunnel.

• Step 5: Response travels back to the user
  The response follows the reverse path: Azure gateway → encrypted VPN tunnel → local VPN gateway → user’s device.

As your user base or data volume grows, Site-to-Site VPN can hit bottlenecks around bandwidth, throughput, or concurrent connections. Here are the most effective fixes:

• Upgrade your Azure VPN Gateway SKU
  Azure offers VPN Gateway SKUs ranging from VpnGw1 (100Mbps throughput) up to UltraPerformance (20Gbps). Higher-tier SKUs support more concurrent tunnels and larger traffic volumes. If you’re on a lower SKU, upgrading is the fastest way to boost capacity.

• Switch to active-active VPN gateway mode
  By default, VPN gateways run in active-passive mode (one instance handles traffic, the other is standby). Active-active mode enables both gateway instances to process traffic simultaneously, effectively doubling your throughput and adding redundancy. You can also set up multiple Site-to-Site tunnels (one per local gateway) to split traffic across connections.

• Add ExpressRoute as a dedicated connection
  For high-volume, low-latency needs, ExpressRoute is a better long-term solution than VPN. It provides private, dedicated connections between your on-premises network and Azure, with bandwidth options from 50Mbps to 100Gbps. You can keep VPN as a fallback for redundancy, while using ExpressRoute for most traffic.

• Optimize traffic with private endpoints and routing

  • Deploy private endpoints for ADLS and enable PowerBI’s VNet integration: This keeps all data traffic within private networks, eliminating public internet hops and reducing VPN tunnel load.
  • Configure precise route tables in both your local network and Azure VNet: Ensure only necessary traffic (e.g., ADLS, PowerBI data requests) travels through the VPN, avoiding unnecessary bandwidth usage.

• Reduce repeat traffic with caching and data modeling

  • For PowerBI, use import mode instead of DirectQuery where possible: This imports data into PowerBI datasets on a schedule, reducing real-time ADLS access and VPN traffic.
  • Set up local caching servers for frequently accessed ADLS data: This cuts down on repeated requests to Azure, lightening the VPN’s load.

内容的提问来源于stack exchange，提问作者Sudipto Goswami