AWS 将开始对 IPv4 使用收费，但关键服务不支持 IPv6

原文 ↗ Hacker News 讨论 ↗

Amazon Web Services 计划开始对公共 IPv4 地址收费，这引发了人们对其定价以及关键服务对 IPv6 支持不完整的审视。评论者指出，虽然其他云提供商早已对 IPv4 计费，而且地址空间确实具有真实的市场价值，但 AWS 的举动会迫使许多用户重新考虑架构、跳板机、NAT 和私有端点——往往只是把一类成本换成另一类成本。讨论的大部分焦点在于，尽管硬件和操作系统早已长期支持 IPv6，为什么它的采用仍然如此缓慢，反复出现的担忧包括迁移复杂性、隐私问题以及双栈运行开销。

AWS 的 IPv4 收费与云定价背景

  • 许多人认为新的 IPv4 “保留费”就是一次直接涨价，而且时机正好卡在 IPv4 地址已经有转售价值的时候。
  • 有些人认为，按每个 IP 收费相对于市场租赁价格和 AWS 的利用率约束并不离谱；也有人认为，鉴于 IP 的来源本是公共资源，这种做法属于寻租。
  • 几位评论者指出，大多数主流云厂商本来就对 IPv4 收费；一些较小的供应商仍将其免费打包或以更低价格提供，这使 AWS 看起来更贵。

AWS 及其他云的 IPv6 支持缺口

  • 评论者强调，AWS 的一些关键服务仍然缺少完整的 IPv6 或仅 IPv6 支持（例如 ALB、许多公共端点）。
  • 在 Azure 和 GCP 的托管服务与网络中也有类似缺口（托管数据库、GKE、对等互联、Cloud NAT）。
  • 这削弱了 AWS 所谓让客户“加速 IPv6 采用”的说法，因为在实践中你往往没法真正只用 IPv6。

迁移复杂性：IPv6 vs IPv4 与“v4.1”设想

  • 关于 IPv6 的设计（ND、SLAAC、RA、ULA、链路本地、默认不使用 NAT）是否因为这些机制而不必要地增加了采用难度，还是说这只是扩大地址空间所不可避免的代价，存在激烈争论。
  • 有人认为 IPv6 本可以只是“带更大地址的 IPv4”，或者一种保留现有 v4 地址的 IPv4.1，从而降低部署难度。也有人反驳说，任何首部和结构上的变化都会带来同样的双栈、转换和隧道复杂性。
  • 讨论还把它与 Python 2→3 作比较：迁移过程漫长，需要兼容层，但并没有简单替代方案。

NAT、安全与隐私争论

  • 一方认为 NAT 实际上是一种事实上的、易于使用的默认拒绝安全层，并把 IPv6 的端到端模型视为隐私与安全上的倒退。
  • 另一方强调 NAT 不是安全机制，仍然需要合适的防火墙，而具备默认拒绝防火墙的 IPv6 可以提供同等或更好的安全性，同时避免 NAT 对 P2P 和协议的破坏。
  • “IPv6 是隐私噩梦”的说法也受到质疑；另一些人则认为 IPv6 可能比 IPv4 更难被扫描。

减少公共 IPv4 使用的变通方案

  • 建议的缓解措施包括：SSH 跳板机、SSM/Session Manager、EC2 Instance Connect、NAT 网关/实例、PrivateLink/VPC endpoints、NAT64 网关，以及将流量卸载到 CloudFront 或其他服务商。
  • 有些人表示已经成功移除了大多数公共 IPv4；另一些人指出，端点定价和架构锁定会抵消 IPv4 节省下来的成本。

市场动态、惯性与心理因素

  • 一些评论者认为，制度惯性、缺乏明确商业收益、IPv4 所有权的既有格局，以及用户预期，是 IPv6 推广的主要障碍。
  • 对于 IPv4 是否会真正被关闭，意见不一；有些人预测最终会出现仅 IPv6 网络，另一些人则认为大量持有 IPv4 的机构和工业系统会让这一进程无限期拖延。