AWS Client VPN 还是 EC2 上的 VPN：一份运维手册

两种方案都能给团队一个远程接入 VPN，因此真正的问题不是哪一个存在，而是哪一个你能运维。区别在于凌晨 3 点谁拥有这个端点，以及出故障时你能触达哪些控制手段。请按顺序走完下面五步，因为每一步都可能提前结束比较。跳过清点这一步，正是团队最终迁移两次的原因。

第 1 步：先写需求，再谈账单

你需要在一页纸上写清五个事实：谁用什么方式认证、哪些客户端平台必须可用、哪些私有目标要能到达、你承诺了什么可用性，以及流量实际长什么样。没有这些，后面每次比较都会变成功能清单之争。

目标要写具体。「能访问 VPC」通常意味着三件不同的事：VPC 的 CIDR、一个对等网络，以及 Transit Gateway 后面的本地网段。托管端点能到达这三者，但每一个都需要一条路由和一条授权规则，每一个都是需求里单独的一行。

第 2 步：盘点已经在跑的东西

动手设计之前，先列出既有端点，以及在 EC2 上托管的任何服务器及其安全组。这些调用都是只读的，用具备 describe 权限的账号执行是安全的。

aws ec2 describe-client-vpn-endpoints
aws ec2 describe-client-vpn-authorization-rules --client-vpn-endpoint-id cvpn-endpoint-xxxx
aws ec2 describe-client-vpn-routes --client-vpn-endpoint-id cvpn-endpoint-xxxx
aws ec2 describe-client-vpn-connections --client-vpn-endpoint-id cvpn-endpoint-xxxx
aws ec2 describe-instances --filters Name=tag:role,Values=vpn

把输出当作一张「客户端已经能到哪里」的地图来读。缺少一条授权规则，能解释一个看起来像路由问题的故障；端点只关联了一个子网，能解释为什么一次可用区故障拖垮了整个服务。

还要记录挂到任何自建实例上的安全组。这些规则属于访问模型的一部分，而它们正是有人照模板重建实例时最先悄悄出问题的地方。

第 3 步：划清责任

托管服务拥有端点集群、它的补丁以及它在区域内的可用性。你拥有身份注册、授权规则、端点背后的网络路径、日志配置，以及关联多少个子网的决策。

自建则把这一切反过来。你拥有来宾操作系统、VPN 守护进程及其配置、证书与密钥、备份、监控与恢复。EC2 的安全模型把来宾和应用的安全交给客户，而 VPN 服务器也只是来宾。

把责任划分写成一张表，右栏填名字。如果在证书续期旁边没有出现任何人的名字，那就是本次的发现，它比每小时差价更重要。

第 4 步：跟你描述得清的工作负载做比较

成本跟着形态走，不跟规模走。托管方案要统计端点关联小时、客户端连接小时、流量，以及你启用的身份与日志服务。自建方案要统计算力、存储、网络、许可，以及让服务器保持已打补丁的工程时间。把两组数字放进同一张表，用同一个时间跨度。忽略补丁工时的三年比较，永远会偏向你已经拥有的那台服务器。

性能比较需要同样的纪律。一个交互式桌面会话、一次大流量传输和五十个并发小请求，压的是路径上不同的环节：加密用的 CPU、实例的网络能力、客户端自身的协议栈，以及目标端。请用有代表性的客户端、在同一任务下对比两种设计。

更大的实例并不证明传输会更快，一次成功的会话也不是容量规划。把继承来的关于实例系列的传说当成待验证的假设，而不是采购规则。

第 5 步：用演练过的回滚来切换

在既定周期内并行运行两个端点，先把新的客户端配置分发给一个小范围，并保持旧端点的授权规则不动，直到这个小组在真实工作中用过新配置。回滚是切换配置，不是重建，所以现在就决定旧配置放在哪里。

按这个顺序验证：认证成功、客户端拿到预期路由、被授权的目标有应答、未被授权的目标失败，并且日志里两个事件都有记录。任何一步失败，就停下来修这一步，而不是转向下一个客户端分组。把每次检查的结果写下来，因为只被记成「能用了」的切换，一个月后无法排查。

切换之后，把那些枯燥的检查排进日程：证书到期、关联数量、已经不再匹配任何分组的授权规则，以及连接数与你的预期之间的差距。Client VPN 管理指南是这些你配置过的端点、认证与路由部分的参考。