如何从控制台估算 AWS Client VPN 账单

走一遍 AWS Client VPN 估算流程：数清关联数，从会话日志推算连接小时，再加上端点费用之外的开销。

上个月我在表格里做了一份 Client VPN 估算，发给客户后又改了两遍：一次是因为我把关联数乘上了子网数，一次是因为我用人数代替了会话数据。经得起复核的版本只依靠两个按小时计的计量项，以及一份很短的附加费用清单。你不用价格计算器，只凭控制台和一份日志导出就能把它重建出来。

两个计量项，端点上再没有别的

AWS 按关联小时和连接小时对 Client VPN 端点计费。关联小时对每个挂在端点上的目标网络持续计时，昼夜不停，无论有没有人连接。连接小时则按每个已连接的客户端计，直到该会话结束为止。

MeterWhat increments itWhat does not change it
Association-hoursEach associated subnet or Transit Gateway attachment, per hour, 24/7 while attachedNumber of users, traffic volume
Connection-hoursEach active client session, per hourHow many subnets that client can reach

那张表直接引出两个后果。端点上一个用户都没有，照样要花钱；一个人同时开着笔记本和手机，就会产生两条连接。

在控制台里数关联，而不是数 VPC 里的子网

打开 VPC，再打开 Client VPN endpoints，再打开你的端点，最后打开 Associations 标签页。那里的每一行都是一个子网关联，这个行数就是你的关联乘数。VPC 后面挂着多少应用子网，与它无关。

只要端点的路由和授权规则覆盖了目标，一条关联就足以抵达被授权的 VPC 网络。多出来的关联买到的是可用区故障下的韧性，而不是额外覆盖。因此双可用区设计会让关联小时翻倍，而一个八子网的应用 VPC 不会把任何东西乘八。

在那个页面上顺便看清关联类型。VPC 子网关联和直连 Transit Gateway 关联是两种不同的安排，账单行也不同，别把一个模型套进另一个的报价里。也不要靠拆东西来验证数量：移除最后一个目标网络会终止活动会话，并且在重新关联之前挡住新连接。

从会话数据推算连接小时

人数是错误的输入，而且两个方向都错。十个人各自挂着三台设备，就是三十条连接。一百个人每天各连二十分钟，离一百个并发会话差得远。

Client VPN 的连接日志会按客户端记录连接与断开事件，这正是你要的配对。导出一个有代表性的一周，把事件配对，再把时长加总：

connection-hours = sum of (disconnect_time - connect_time) per session
sessions         = one per client connection, not per person

然后修正两个习惯。午饭、夜间或笔记本休眠期间一直连着、从未拆掉隧道的会话照样计费，而且在人数统计里看不见。计量也按小时取整，所以二十分钟的会话要按整整一小时做预算，别假设按比例计费；如果账单更低，把它当成余量，而不是规划输入。

用你所在区域的费率来算

各区域的费率不同，所以去你部署所在区域的 AWS VPN 价格页取费率，作为输入贴进表格。仅作示例：取每小时 0.10 美元的关联费率和 0.05 美元的连接小时费率，再算一个 30 天的月份——两条关联整月保留，100 人在 20 个工作日里各连六小时：

association-hours = 2 * 24 * 30     = 1,440
association fee   = 1,440 * 0.10    = 144.00

connection-hours  = 100 * 6 * 20    = 12,000
connection fee    = 12,000 * 0.05   = 600.00

Client VPN subtotal                 = 744.00

现在一次只动一个输入，看哪一行在变。关联翻倍在这里多出 144 美元；平均会话时长翻倍多出 600 美元。这个比例通常替你结束设计争论：砍掉说不清的冗余，或者去抓空闲会话，看哪个数字更大。把区域和费率日期写在结果旁边，因为六周之后，没有这两项的报价无法复现。

补上小计漏掉的费用

端点费只买端点本身。之后流量碰到的每一样东西都有自己的计量，而这些行正是乐观的 VPN 估算垮掉的地方。

  • 从端点出去的流量所产生的互联网出网费，按 GB 计。
  • 公有 IPv4 地址，自带按小时计费，与 VPN 无关。
  • 你刚导出的连接日志在 CloudWatch Logs 里的摄取与存储。
  • 如果你跑 client-connect 处理器，还有 Lambda 调用。
  • 如果用户就是这样认证的，还有 Directory Service 或你的 SAML 身份提供商；如果在那里签发证书，还有 ACM Private CA 的费用。
  • 路径用到时的 NAT Gateway 小时费与数据处理费，以及 Transit Gateway 挂载小时费与数据处理费。

这些都不随关联数增长，所以一个只由端点费拼出来的每用户数字，在纸面上看着不错，等真实流量出现就会变大。即便只能估算，也把它们放在单独的行里，让读者看得出哪些部分是实测、哪些是猜的。

发出去之前检查表格

四项检查能抓住我确实犯过的错：关联数与 Associations 标签页完全一致；连接小时来自配对后的日志事件，而不是人数；区域和费率日期写下来了；每一项附加费用都有自己的行。四项里缺任何一项，你手里就只是一份排过版的猜测。

先把日志导出拿到手。那是你事后唯一无法凭记忆重建的输入，它也会告诉你，空闲会话的问题值不值得在第一张账单到来之前修掉。

相关文章