折腾AWS PrivateLink时，我发现最麻烦的往往不是安装，而是配置。假设你有一个运行在 AWS 上的应用，需要访问另一个 VPC 里的数据库，或者调用一个第三方 SaaS 的 API。最直接的方式可能是通过公网 IP 访问，但公网意味着暴露、延迟不可控、以及潜在的安全风险。AWS PrivateLink 就是为了解决这个场景而生的——它让你在 VPC 内部通过私有 IP 直连目标服务，整个路径不经过公网，就像在同一个局域网里通信一样。
PrivateLink 是什么？一句话说清楚
我的处理经验
AWS PrivateLink 是一项网络服务，它允许你安全地访问 AWS 服务、其他 AWS 账号中的资源，或者第三方 SaaS 服务，而无需使用公共互联网、无需配置 NAT 网关、无需为每个 VPC 建立 VPN 或 Peering 连接。它的核心是 VPC Endpoint（终端节点）和 Endpoint Service（终端节点服务）。
- VPC Endpoint：从你的 VPC 内部发起的一个“电话”，这个点就像一根专线插到目标服务上。
- Endpoint Service：由服务提供方（比如 AWS 自身或一个第三方应用）创建的“听筒”，允许消费者通过 PrivateLink 接入。
当你在 VPC 中创建一个接口型 Endpoint（Interface Endpoint）时，AWS 会在你的 VPC 子网里放置一个弹性网络接口（ENI），它拥有一个私有 IP。所有发往该 Endpoint 的流量都会自动通过 AWS 内部网络路由到目标服务，整个过程对外部网络完全不可见。
AWS PrivateLink：为什么要用 PrivateLink？三个典型场景
场景一：跨 VPC 访问内部服务，避免 VPC Peering 泛滥
如果你有几十个 VPC，每个 VPC 都有自己的业务模块，传统做法是用 VPC Peering 把每对需要的 VPC 连起来。但对数增长会导致网络拓扑变成一团乱麻，而且 Peering 是易失联的——你无法让多个 VPC 共享一个“中心”服务。PrivateLink 采用星型模型：服务提供方发布一个 Endpoint Service，所有消费者只需在自己的 VPC 里创建 Endpoint 指向这个服务，就可以访问它，无需在 VPC 间建立任何对等连接。
场景二：使用 AWS 托管服务时不经过公网
默认情况下，很多 AWS 服务（如 S3、DynamoDB、CloudWatch）的 API 调用会经过公网。虽然数据在传输层加密，但路径上仍可能被截获或受到延迟波动。PrivateLink 让你在 VPC 内通过私有 IP 调用这些服务（例如 S3 Gateway Endpoint 或 Interface Endpoint），所有流量留在 AWS 骨干网中，既安全又稳定。
场景三：访问第三方 SaaS 服务时不暴露公网 IP
很多 SaaS 厂商（如 Datadog、Snowflake、Confluent）都在 AWS Marketplace 上提供 PrivateLink 接入。你只需要在自己的 VPC 里创建 Endpoint，SaaS 厂商就会把它的服务“拉”到你的 VPC 内部。你的应用可以用私有 IP 直接访问，既避免了出口带宽成本，又无需在安全组中放行白名单 IP。
延伸阅读：此处可内链到“AWS PrivateLink配置案例”相关文章。
PrivateLink 与 VPN、Direct Connect、VPC Peering 的区别
验证与回滚
很多初学者容易混淆这几个概念，我们用表格理清它们的分工：
- VPN（虚拟专用网络）：通过公网加密隧道连接两个网络，适用于混合云场景（本地数据中心到 AWS）。但延时受公网影响，且需要维护 VPN 网关。
- Direct Connect（专线）：物理专线，延迟低且不经过公网，但成本高、部署周期长。适合大规模企业级连接。
- VPC Peering（对等连接）：在两个 VPC 间建立一对一的私有路由，但无法传递到第三个 VPC，且无法实现服务发布/订阅模式。
- PrivateLink：按需的私有连接，消费者和服务提供者解耦，支持跨账号、跨区域（需要配合 Transit Gateway 等），且没有网络爆炸半径问题。
你可以这样记忆：VPN 是“拉网线到你家”，Direct Connect 是“铺一条水泥路”，VPC Peering 是“两栋楼之间搭桥”，而 PrivateLink 是“每栋楼装一部直通电话，不用管中间的通路”。
PrivateLink 的架构设计：服务提供者与消费者
服务提供者（Service Provider）
通常是拥有 NLB（网络负载均衡器）或 AWS PrivateLink 支持的服务（如 SaaS 供应商）。你需要在服务所在 VPC 中创建一个 Endpoints Service，并关联到 NLB。NLB 后面可以是 EC2 实例、Lambda 函数或其他计算资源。创建时，你可以配置以下关键参数：
- Acceptance Required：是否要求消费者创建 Endpoint 时需手动审批。如果启用，每次连接请求都需要你手动确认。
- Allowed Principals：允许哪些 AWS 账号（或 IAM 角色）创建连接。可以按账号白名单控制。
- Availability Zones：服务在哪些可用区可用。通常建议至少两个区以保证高可用。
服务消费者（Service Consumer）
你在自己 VPC 中创建 VPC Endpoint，选择接口类型（Interface Endpoint），然后输入服务提供者提供的 Service Name（格式如 com.amazonaws.vpce.us-east-1.vpce-svc-xxxxxxxx）。创建后，AWS 会在你指定的子网中放置 ENI，并分配私有 IP。此后，你可以在 VPC 内的任何资源上用这个私有 IP 或 AWS Private DNS 名称访问服务提供者。
注意：如果你需要跨区域访问，可以结合 AWS Transit Gateway 或 VPC Peering 先将网络打通，再通过 PrivateLink 访问服务。但跨区域场景下延迟会增大，建议服务部署在同一区域。
精细化访问控制：不只靠安全组
PrivateLink 的“私有”并不等于“自动安全”。你仍然需要从多个层次控制谁能访问、怎样访问。以下是四个关键控制点：
1. 安全组（Security Group）与网络 ACL
VPC Endpoint 是附着在 ENI 上的，因此你可以为这个 ENI 绑定安全组。通常做法是：只允许特定 VPC CIDR 或特定子网的流量访问 Endpoint。但更推荐的做法是：
– 在服务提供者的 NLB 后面挂入目标组时，为目标实例配置安全组，只允许来自 VPC Endpoint 的私有 IP 范围（或子网范围）的流量。
– 消费者端的安全组也明确放行到 Endpoint 私有 IP 的 443 端口。
2. IAM 策略控制谁可以创建/使用 Endpoint
可以创建一个 IAM 策略，限制某个用户或角色只能创建指向特定 Service Name 的 VPC Endpoint。例如：
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:CreateVpcEndpoint",
"Resource": "*",
"Condition": {
"StringEquals": {
"ec2:VpcEndpointServiceName": "com.amazonaws.vpce.us-east-1.vpce-svc-xxxxxxx"
}
}
}
]
}
3. 服务提供者的 Allowed Principals
在 Endpoint Service 中，你可以通过 Allowed Principals 设置只允许特定 AWS 账号或 IAM Role 发起连接。即使消费者 VPC 在另一个账号下，只要它的 IAM 角色不在白名单里，连接请求就被拒绝。这是跨账号访问的核心控制手段。
4. 启用私有 DNS（Private DNS Name）
默认情况下，创建 Interface Endpoint 时，AWS 会为它生成一个私有托管区域（Private Hosted Zone），自动将服务的公有 DNS 名称解析到 Endpoint 的私有 IP。这样，你在 VPC 内使用原来的服务域名（例如 database.amazonaws.com）就能直接走私有连接，而不需要修改代码。但要注意：如果你需要精细化控制哪些子网能使用私有 DNS 解析，可以手动配置 Route 53 解析规则。
补充参考：此处可内链到“AWS PrivateLink故障排查实例”。
关联教程：此处可内链到“AWS PrivateLink部署与验证”内容。
想继续深入：此处可内链到“AWS PrivateLink优化清单”文章。
常见踩坑与最佳实践
验证与回滚
- 不要忘记 NAT 网关：创建 Interface Endpoint 后，如果你的子网没有路由到 NAT 网关，且 Endpoint 所在的子网没有连接到服务提供者所在的 VPC，可能会产生非对称路由。建议将 Endpoint 放在与目标子网相同的可用区，并确保路由表正确。
- 跨区域数据流量计费：虽然 PrivateLink 不出公网，但跨可用区或跨区域的数据传输仍然按 AWS 内部定价收费。对于高频调用，建议将服务提供者与消费者部署在同一可用区以减少成本。
- 测试连通性：创建完成后，用
telnet或nc测试 Endpoint 的私有 IP 和端口是否可达。如果安全组设置正确但还是不通，检查 NLB 的健康检查配置是否允许来自 Endpoint 子网的流量。 - 监控与审计：开启 VPC Flow Logs 跟踪连接到 Endpoint 的流量来源和目的地。配合 AWS CloudTrail 记录 Endpoint 创建/删除事件。
进阶阅读：此处可内链到“AWS PrivateLink性能优化”指南。
AWS PrivateLink：总结：PrivateLink 带给小白的核心价值
配置前的检查
当你不需要复杂的网络拓扑、不希望数据出现在公网、同时又想保持按需连接时，PrivateLink 是最优雅的方案。它把网络连接抽象为“服务”，你可以像调用函数一样，只需知道服务名称就能安全地访问。对于刚接触 AWS 的开发者，理解 PrivateLink 能让你的架构图从复杂的网状线变成干净的星型结构。下次需要连接 VPC 之间或连接第三方服务时，先想想能不能用 PrivateLink，它会帮你省去很多烦恼。把这些步骤跑通后，AWS PrivateLink基本就能稳定落地。
延伸阅读