最具性价比的 AWS 服务器折腾姿势

到底要选哪个呢

如果我只是需要一个最基础、最简单、最便宜的服务器，用来稳定地跑一些非常轻的服务，我应该找哪家云服务提供商？

在之前，我首先想到的肯定不会是三大提供商（AWS、Azure、GCP），倒不是担心被反薅上千刀，只是大厂的主要客户从来都不是个人开发者，所以哪怕是入门级别的机器都要动辄好几刀，再加上存储、流量费用，一个月少说都得十几刀，怕是有点太看得起我跑的服务了。

更糟糕的是，由于 IPv4 地址越来越稀缺，AWS¹、Azure²、GCP³ 已经无一例外开始对 IPv4 地址收费，价格都是 3.6$ 每月，对个人开发者来说基本上是劝退了。

所以，真的没有办法能满足一个可怜、弱小又无助的开发者了吗？

是时候转向 ARM 了

随着 ARM 架构处理器在服务器市场的兴起，三大提供商也纷纷上线了 ARM 架构的机型。早在 2018 年，AWS 就率先推出了由自研的 Graviton 处理器驱动的 A1 实例⁴，2022 年又推出了由 Graviton2 处理器驱动的 M6g 实例⁵，并在当年底隆重推出了我们今天的主角——T4g 实例⁶，这也是第一款入门级的 ARM 实例。

与我们熟悉的 T3 实例类似，T4g 也提供了多种入门级的规格可供选择。以新加坡区域为例（如无特指，后文中的价格均为新加坡区域价格），其中价格最低的 t4g.nano 仅需 0.0053$ 每小时（3.87$ 每月），再加上最小可选 8GB EBS（0.77$ 每月），每月计算和存储成本为 4.64$。

如果叠加 EC2 Instance Savings Plans，在预留 3 年且预付全部费用的情况下，计算成本甚至会降到 1.46$ 每月，加上存储成本共计 2.23$ 每月，整体成本下降了一半还要多。

既然计算和存储资源的问题已经解决，那么剩下的就是 IPv4 地址的成本了。

我选择 IPv6

从三大提供商完全一致的 IPv4 定价来看，这种已然“耗尽”的资源确实没有什么降价空间，既然如此，能不能干脆不用 IPv4 了呢？

2022 年中，AWS 推出纯 IPv6 子网和 EC2 实例⁷，这意味着你终于可以拥有一台只有 IPv6 地址，没有 IPv4 公网地址（私有 IPv4 地址还是得有的）的云服务器了，同时也可以让 3.6$ 每月的费用滚蛋了。

万事俱备，启动吧，我的服务！

是谁在阻止我使用 IPv6

众所周知，IETF 从 1990 年就开始规划下一代协议，IPv4 地址在 2008 年就已经到了分配末期，中办国办在 2017 年印发《推进互联网协议第六版（IPv6）规模部署行动计划》，从国家层面推动 IPv6 发展，美国更是拥有全世界数量最多的 IPv6 前缀⁸。

但是三十几年后的今天，当你试图用一台纯 IPv6 服务器克隆 GitHub 上的一个仓库，想部署点什么东西的时候，你会发现：GitHub 的主域名没有 AAAA 记录。没错，全世界最大的同性交友网站不支持 IPv6，可想而知其他中小型网站的支持程度如何。

事实上，由于 IPv6 与 IPv4 完全不兼容，所以势必存在由 IPv4 向 IPv6 演进的过渡期，这一时期的互联网会从 IPv4 单栈网络逐渐转变为 IPv4/IPv6 双栈网络。由于种种原因，这一过渡期已经持续了二三十年，并且可以预见还会持续很长时间，这也意味着，在这一时期内完全摆脱 IPv4 既不现实也没有意义，网站们自然也就没有足够的动力进行网络改造，所以仍有不少我们耳熟能详的网站依旧只支持 IPv4 访问。

但是 IPv4 确实太贵了，有没有办法救一下呢？

如何拯救我的纯 IPv6 服务器

解决方法显而易见，必然要通过一台 IPv4/IPv6 双栈设备进行中转，才能连接两个互不兼容的网络。AWS 推荐的方案是：DNS64 + NAT64⁹。

DNS64：DNS64 是指一种专门的 DNS 服务器，在其处理某个域名的 AAAA 记录查询时，如果该域名仅有 A 记录，那么 DNS64 会使用该 A 记录生成出来一项 AAAA 记录。
NAT64：NAT64 是一种可以让 IPv6 主机与 IPv4 服务器通信的机制。IPv6客户端将希望与之通信的 IPv4 地址嵌入在 IPv6 网段的主机部分，构成一个嵌入 IPv4 的 IPv6 地址，并将数据包发往生成的地址。NAT64 网关则创建 IPv6 与 IPv4 地址间的 NAT 映射，使得它们可以彼此通信。

简言之，如果你的服务器试图访问 GitHub 官网，会先向 DNS64 服务器请求 github.com 的 AAAA 记录，此时 DNS64 服务器发现 github.com 只存在 A 记录，指向 20.205.243.166，那么它就会返回一个 AAAA 记录，指向 64:ff9b::14cd:f3a6。其中 64:ff9b::/96 是 IETF 通过 RFC 6052 保留的 NAT64 前缀¹⁰，末尾两段是 IPv4 地址的十六进制转写。

之后，你的服务器就会尝试访问 64:ff9b::14cd:f3a6，而 NAT64 网关会将数据包转发到 20.205.243.166，这样你的纯 IPv6 服务器就可以访问 IPv4 服务啦。

而在 AWS 中，你可以直接在子网设置中启用 DNS 64，然后在子网路由表中添加一条路由，允许 VPC 将以 64:ff9b::/96 为前缀的 IPv6 数据包转发到 NAT 网关，完全无须对服务器进行任何配置变更，简单高效。

但是，任何事物都不是完美的。这个方案存在一个显而易见的问题：它只适合使用 DNS 查找远程主机地址的场景，无法参与客户端直接使用 IPv4 地址的场景，即你可以通过它来访问 github.com，但是不能直接访问 20.205.243.166。

同时，虽然 AWS 免费提供 DNS64 服务，但是 NAT 网关可是实打实收费的，价格 0.059$ 每小时（43.13$ 每月），这意味着如果你没有十几台以上的服务器共同使用这个 NAT 网关的话，还不如直接给服务器上一个 IPv4 地址。

所以对个人开发者来说，更好的途径其实是随便找一台具有 IPv4 地址的服务器，然后在它与纯 IPv6 服务器之间建立隧道，因为就算服务器翻车了也不会直接影响你的服务，而且隧道部署起来十分简单，时间成本很低。部署过程在另一篇文章中会提到，本文暂且不谈；或者还可以使用公共 NAT64 服务——没错，虽然这听起来过于慈善了，但是真的有这样的服务。

无论如何，我们姑且找到了拯救纯 IPv6 服务器的方法，终于可以访问 GitHub 啦！那么接下来，要如何访问你的服务呢？

将免费进行到底

要从互联网访问你的服务，方法有很多，CDN 大概是其中最方便实惠的一种，配置简单，还有许多免费 CDN 可供选择。我们的老朋友 Cloudflare 就提供免费的 CDN 服务，而且配置极其简单，但是它要求你将域名完全托管到 Cloudflare，并不是一个完全普适的方法。那么，还有其他免费的方案可供选择吗？

这个时候就得继续回到 AWS 啦，因为 AWS 是三大提供商里唯一一个提供免费 CDN 套餐的，并且从 2021 年底开始，其 CDN 服务 CloudFront 每月最多可免费传输 1 TB 的数据（之前为 50 GB）¹¹。但是众所周又知，CloudFront 直到今天也不支持 IPv6 源服务器，尽管其自身是支持通过 IPv6 访问的。

但是没有关系，因为就在 2024 年底，CloudFront 推出了 VPC 源功能¹²，这意味着只要你的 EC2 实例拥有私有 IPv4 地址，就可以当作源服务器，这恰好与纯 IPv6 服务器的情况相同。具体来说，CloudFront 会在你的 EC2 实例所在的子网中添加一个网络接口，这样 CloudFront 就可以直接与子网中的实例通信了。