为 Azure Database for PostgreSQL flexible server 创建 Private Endpoint
在产品环境中，PSQL Server 和应用通常处于不同的网络环境中，甚至位于不同的 Subscription。Azure Database for PostgreSQL Flexible Server 常见的两种接入方式是 VNet Integration 和 Public Access + Private Endpoint。如果希望最小化网络打通范围，并降低安全与合规边界扩散的风险，通常更适合使用 Private Endpoint。
比较 🔗
VNet Integration：将 PostgreSQL Flexible Server 部署到委派子网中，再通过 VNet Peering 让应用网络与数据库网络互通。它本质上是把两个网络打通。这样虽然结构直接，但也可能带来额外的安全和合规工作。例如应用所在网络是 PCI 网络时，网络互通后，数据库所在网络通常也需要进入同等安全边界评估范围。
Public Access + Private Endpoint：数据库保留公共入口能力（但可完全关闭），但客户端优先通过 Private Endpoint 从自己的 VNet 私网访问。相比之下，Private Endpoint 更适合只想把“某一个具体 PaaS 实例”私网暴露给消费方，而不希望扩大网络信任边界的场景。Private Link 连接的是某个资源实例，而不是整个服务或整个 VNet，因此更容易控制访问范围，也更有利于隔离和审计。
可以简单理解为：
| 方案 | 网络模型 | 安全边界 | 适用场景 |
|---|---|---|---|
VNet Integration + Peering | VNet 级别互通 | 边界更大，联通后要一起评估 | 同一信任域内，长期稳定互通 |
Public Access + Private Endpoint | 资源实例级别私网接入 | 边界更小，更利于隔离 | 跨团队、跨 Subscription、合规要求较严 |
微软强调 Private Endpoint 的几个优势，本质上可以概括为：
- 只把特定的 PostgreSQL 实例私网暴露给客户端，而不是打通整张网络。
- 可以从本地网络、VPN、ExpressRoute 或已对等互联的网络私下访问，不需要走公网。
- 有助于降低数据泄露风险，因为访问范围限定在具体资源实例上。
- 支持跨 Region 私网访问，客户端和服务端不必位于同一区域。
使用 Private Endpoint 的步骤 🔗
假设数据库和应用在不同的Subscription，且数据库在 A Subscription，应用在 B Subscription。要让应用通过 Private Endpoint 访问数据库，需要完成以下步骤：
- 在 A Subscription 中创建 Azure Database for PostgreSQL flexible server 时，启用
Public Access。 - 在 B Subscription 中按需创建
PrivateDnsZone，并通过VirtualNetworkLink将 Private DNS Zone 与应用的 VNet 关联。 - 在 B Subscription 中的客户端网络所在的 VNet 中创建
Private Endpoint，将其关联到目标子网和 PSQL Server；private_link_service_connections可以使用自动批准或手动批准模式。 - 在 B Subscription 中的客户端网络所在的 VNet 中创建
PrivateDnsZoneGroup，将PrivateDnsZone与Private Endpoint关联起来。
需要注意的是：
- Private Endpoint 的 DNS 解析通常依赖于 Private DNS Zone，因此需要在客户端网络中配置 Private DNS Zone，并将其与客户端 VNet 关联。这样，客户端才能将数据库域名解析到 Private Endpoint 的私有 IP 地址。
- 对于同一种 Private DNS Zone（比如
privatelink.postgres.database.azure.com），一个 VNet 通常只关联一个实例。因此，如果客户端网络需要访问多个 Azure Database for PostgreSQL flexible server，通常会复用同一个 Private DNS Zone，并在该 Zone 中为不同数据库维护各自的 DNS 记录。需要注意的是，如果依赖PrivateDnsZoneGroup的自动关联和 Azure 的自动记录管理机制，最好额外验证这些记录不会被覆盖或删除；在更复杂的场景下，也可以采用集中 DNS 管理或手动校验记录的方式。 - 虽然在 Azure Portal 中可以从数据库页面发起 Private Endpoint 的创建流程，但 Private Endpoint 本身是创建在客户端 VNet 中的资源，因此通常应由客户端网络所在 Subscription 的管理员来创建。如果当前 Identity 只能管理本 Subscription 内的资源，无法同时完成两侧操作，那么更合适的做法是先在客户端侧创建
Manual Private Link Connection，再由数据库所在 Subscription 的管理员审批该连接请求。