Understanding Private Link Service vs Private Endpoint

Key Distinction

• Private Endpoint: Allows resources within your VNet to connect outbound to Azure services
• Private Link Service: Allows external services to connect inbound to resources in your VNet

The Challenge with VNet-Injected MySQL Flexible Server

When MySQL Flexible Server is VNet-injected:

• It exists entirely within your private VNet address space
• Traditional private endpoints are not supported (as your engineering team noted)
• External services like Snowflake OpenFlow cannot directly reach it

How Private Link Service Solves This

Architecture Flow

Snowflake OpenFlow → Private Endpoint (Snowflake's VNet) → Private Link Service (Your VNet) → MySQL Flexible Server

Step-by-Step Process

1. Private Link Service Creation

• You create a Private Link Service in your VNet
• This service acts as a secure “front door” to your MySQL server
• It gets a unique service identifier (alias)

1. Load Balancer Integration

• Private Link Service requires a Standard Load Balancer
• Load balancer backend pool contains your MySQL Flexible Server
• Traffic routing is handled transparently

1. Connection Establishment

• Snowflake creates a Private Endpoint in their VNet
• This Private Endpoint connects to your Private Link Service
• Connection request appears in your Azure portal for approval

1. Traffic Flow

• OpenFlow sends requests to their Private Endpoint
• Traffic routes through the Private Link connection to your Private Link Service
• Your Load Balancer forwards traffic to MySQL Flexible Server
• Responses follow the reverse path

Traffic Direction Analysis

Inbound Connection Requirement

YES, the inbound connection shown in your diagram is necessary because:

• OpenFlow Architecture: Snowflake OpenFlow runs in Snowflake’s infrastructure and must connect TO your database
• CDC Requirements: Change Data Capture requires persistent connections from OpenFlow to monitor MySQL binlogs
• Connection Initiation: The connection is always initiated from Snowflake’s side, making it inherently inbound to your infrastructure

Traffic Flow Breakdown

Security Benefits

Network Isolation

• No public IP addresses required on MySQL
• Traffic never traverses the public internet
• Connection uses Azure’s backbone network

Access Control

• You control which services can connect via Private Link Service
• Connection requests require your explicit approval
• NSG rules can further restrict traffic

Monitoring

• All connections are logged and auditable
• Private Link Service provides connection metrics
• Standard Azure monitoring applies

Implementation Requirements

Prerequisites

• Standard Load Balancer (required for Private Link Service)
• MySQL Flexible Server in VNet-injected mode
• Appropriate NSG rules
• Resource permissions for Private Link Service creation

Configuration Steps

1. Create Standard Load Balancer with MySQL in backend pool
2. Create Private Link Service linked to the Load Balancer
3. Configure NSG rules to allow traffic from Private Link Service subnet
4. Share Private Link Service alias with Snowflake team
5. Approve connection request when it appears
6. Configure OpenFlow connector with connection details

Why This Approach Works

The Private Link Service architecture elegantly solves the fundamental challenge:

• Your Constraint: VNet-injected MySQL cannot have traditional private endpoints
• Snowflake’s Need: OpenFlow requires inbound connectivity for CDC
• The Solution: Private Link Service provides secure inbound connectivity without compromising your network isolation

This is Microsoft and Snowflake’s recommended pattern for exactly this scenario, allowing enterprise-grade security while enabling real-time data integration.