1. 课程导入与学习地图

在AWS上,很多团队第一次遇到VPC Endpoint,往往是因为一个很具体的问题:位于私有子网中的EC2实例需要访问S3读取模型文件,但子网没有NAT网关,安全合规也不允许流量走公网。此时最直接的解法不是加NAT,而是使用VPC Endpoint,让实例通过AWS私有网络直接到达S3。这个场景背后,就是本课程要解决的核心问题:如何让VPC内的资源在不经过互联网的前提下,安全、可控、可观测地访问AWS服务或自建服务。

VPC Endpoint并不是单一产品,而是一组接入机制的统称。它主要分为两类:Gateway Endpoint和Interface Endpoint(底层由AWS PrivateLink提供)。Gateway Endpoint只支持S3和DynamoDB,实现方式是在路由表中添加一条指向该Endpoint的前缀列表路由,不产生按小时计费;Interface Endpoint则通过在子网中创建弹性网络接口(ENI)和私有IP,把服务以“本地网络接口”的形式暴露给VPC,支持绝大多数AWS服务以及通过PrivateLink发布的第三方或自建服务,但会产生按小时和按流量计费。理解这两类Endpoint的差异,是后续所有配置、排障和成本判断的基础。

核心价值可以概括为三点:私网可达——流量不经过Internet Gateway或NAT;访问可控——通过Endpoint Policy、安全组和路由精确限定谁能访问什么;架构简化——减少对NAT网关、公网IP和复杂对等连接的依赖。

本课程的学习目标不是记住控制台按钮位置,而是建立一条完整的判断链:面对一个“VPC内资源要访问某个服务”的需求,能够判断该用Gateway还是Interface Endpoint,如何规划子网、安全组、路由和DNS,如何验证连通性,以及当访问失败时如何定位问题。课程结束时,你应该能够独立完成一次从需求分析到验证通过的Endpoint接入,并能解释每一步为什么这样做。

整体知识框架分为四个层次。第一层是概念与选型:理解Gateway Endpoint、Interface Endpoint、PrivateLink、Endpoint Service、Endpoint Policy等术语之间的关系,掌握选型判断依据。第二层是网络与DNS:理解Endpoint如何影响路由、安全组、私有DNS和解析行为,尤其是Interface Endpoint的DNS名称如何把服务域名解析到私有IP。第三层是实战配置:以S3 Gateway Endpoint和某AWS服务Interface Endpoint为例,完成创建、策略绑定、路由确认和客户端验证。第四层是排障与优化:覆盖常见失败模式,如路由缺失、安全组未放行、DNS未启用、策略拒绝、跨可用区流量等,并给出排查顺序和成本优化思路。

VPC Endpoint 私网服务接入 · 学习地图 从需求判断到验证排障的四层知识结构 第一层 概念与选型 Gateway Endpoint(S3 / DynamoDB,路由表前缀列表,无小时费) Interface Endpoint(ENI + 私有IP,PrivateLink,按小时与流量计费) Endpoint Policy / Endpoint Service / 私有DNS 基本概念 第二层 网络与DNS 路由表:前缀列表 → Endpoint;子网关联决定可用区覆盖 安全组:Interface Endpoint 的 ENI 入站规则决定谁可访问 私有DNS:服务域名解析到私有IP,客户端无需改代码 第三层 实战配置 S3 Gateway Endpoint:创建 → 关联路由表 → 策略 → 验证 Interface Endpoint:选服务 → 选子网与安全组 → 启用私有DNS 客户端验证:aws s3 ls / curl / nslookup 观察解析与连通性 第四层 排障与优化 失败模式:路由缺失 / 安全组拒绝 / DNS未启用 / 策略拒绝 排查顺序:解析 → 路由 → 安全组 → 策略 → 服务端 成本优化:按可用区规划 ENI,避免跨AZ流量与冗余Endpoint 一次私网访问的路径 私有子网 EC2 / Lambda DNS 解析到私有IP 路由 / 安全组放行 Endpoint / PrivateLink AWS服务 / 自建服务 全程不经过 Internet / NAT

实战环境准备方面,建议使用一个独立的测试VPC,避免影响现有业务。最小可用环境包括:一个VPC(例如10.0.0.0/16),两个私有子网分别位于不同可用区(如10.0.1.0/24和10.0.2.0/24),一台位于私有子网的EC2实例(Amazon Linux 2023,t3.micro即可),以及一个用于测试的S3桶。如果计划测试Interface Endpoint,还需要准备一个目标服务,例如SSM、ECR或SQS。IAM权限方面,至少需要ec2:CreateVpcEndpoint、ec2:ModifyVpcEndpoint、ec2:DescribeVpcEndpoints、s3:ListBucket等权限。工具上,EC2实例中预装AWS CLI v2,便于用命令行验证;本地或跳板机具备SSH访问能力。

为了让你对“一次完整接入”有直观预期,下面给出一个后续会反复使用的验证命令示例。假设已经为S3创建了Gateway Endpoint并关联了私有子网的路由表,在EC2实例中执行:

# 确认S3域名解析结果(Gateway Endpoint不改变DNS,仍为公网域名)
nslookup my-test-bucket.s3.cn-north-1.amazonaws.com.cn

# 确认路由表中存在前缀列表路由
aws ec2 describe-route-tables \
  --filters "Name=route.pl-63a5450a,Values=*" \
  --query "RouteTables[].Routes[?DestinationPrefixListId!=null]"

# 实际访问S3,观察是否成功且不经过NAT
aws s3 ls s3://my-test-bucket/ --region cn-north-1

判断接入是否成功的依据不是“命令没报错”,而是三个可观察事实:第一,目标服务的域名解析结果符合预期(Gateway Endpoint仍解析为公网域名但路由走私有;Interface Endpoint应解析为子网内的私有IP);第二,路由表或安全组中存在对应的放行条目;第三,从私有子网发起的请求能够返回预期数据,且VPC流日志中不出现经NAT网关的流量。如果这三点中任何一点不成立,就需要进入第四层的排障路径。

学习本课程时,建议每完成一个配置动作,就立即用一条命令或一次控制台查询验证当前状态,而不是等全部配完再统一测试。Endpoint接入的问题往往出在“以为配了但实际没生效”的环节,例如路由表关联了错误的子网、安全组只放行了出站、私有DNS未勾选等。逐步验证能显著降低排障成本。