Azure App Service 与VM上IaaS SQL Server集成的端点选型咨询

针对 Azure App Service 访问 IaaS 虚拟机上自建 SQL Server 的网络打通需求，优先选择为SQL Server配置 Private Endpoint，Service Endpoint 在这个场景下根本不具备适配的技术能力，不推荐作为方案选项。

Service Endpoint 完全不适配该场景的原因 #

• Service Endpoint 从设计之初就是给 Azure 原生托管 PaaS 服务（比如Azure SQL Database、Blob Storage这类官方运维的服务）做路由优化的：它的作用是给从VNet发出的、访问这类PaaS服务的流量打私有路由标签，让流量不走公网而走Azure骨干网。它的管控对象永远是Azure官方的PaaS服务，没法作用于你自己跑在VM上的自建SQL Server。
• 很多人会把「App Service VNet Integration」和「Service Endpoint」搞混：就算你给App Service配了VNet Integration，打通到VM所在VNet的路由，这个通路的能力来自私有路由本身，和Service Endpoint没有关联，配Service Endpoint纯属于多做无用功。
• 就算靠VNet Integration硬打通网络，安全管控的代价也很高：你需要在VM的NSG规则上放通整个App Service集成子网的3343端口入站权限，地址范围大，后续维护的风险高。

Private Endpoint 适配该场景的实际收益 #

• 不需要暴露公网：Private Endpoint 可以直接绑定SQL Server所在VM的网卡，给VM分配一个它所在VNet子网的专属私有IP，所有访问SQL Server的流量都通过这个私有IP走Azure骨干网，全程不碰公网，你完全不需要给VM开对公网的3343端口，从根上把SQL Server的公网暴露面消掉。
• 安全规则更精准：你只需要针对对应的Private Link连接配置访问权限，不需要给大范围的子网段开数据库端口规则，配合私有DNS区域做解析，还能避免应用连接串误连到公网SQL Server的问题。
• 部署限制更少：Private Endpoint 不要求App Service和VM所在VNet在同一个区域，也不需要绕VNet网关转发，跨区域部署的App Service也能通过骨干网稳定访问，链路延迟比走VNet网关的方案更低。

常见认知误区纠正 #

不要觉得配了VNet Integration就等于用了Service Endpoint：如果你刚好在同一个区域，提前配好了VNet Integration，确实可以不依赖Private Endpoint连通到VM，但这种方案需要额外维护路由、子网规则，区域限制多，长期跑生产的话，Private Endpoint的配置更简单，安全能力也更强。

内容的提问来源于stack exchange，提问作者G.Prashanth