Route 53 Files 是一项新服务，可将 AWS 计算资源与 Route 53 数据库无缝连接，使托管区像文件系统一样可访问。用户通过标准 UNIX 软件编辑 DNS 记录后，更改会自动同步至 Route 53，反之亦然，支持多计算资源共享访问，无需额外步骤。

我兴奋地宣布推出 Route 53 Files，这是一个全新的文件系统，能将任何 AWS 计算资源与亚马逊最高可用性数据库无缝连接。四十年前，伯克利互联网域名服务器（BIND）启动时，DNS 记录存储在“区域文件”中。你可以用 vi 编辑这些文件，但修改生效前必须通知 BIND 重新加载。后来，其他 DNS 服务器如 Daniel Bernstein 的 tinydns 出现，它直接从磁盘上的数据库提供记录——但即便如此，编辑人类可读的 DNS 记录后，仍需重新编译数据库文件。

有了 Route 53 Files，你可以使用标准 UNIX 软件编辑 DNS，无需额外步骤。它将托管区域作为文件系统访问；这意味着你在文件系统中对记录的修改会自动反映到 Route 53，而通过其他渠道（如 AWS 管理控制台、Route 53 API、AWS CLI）在 Route 53 中进行的更改也会自动出现在文件系统中。一个 Route 53 Files 文件系统可以挂载到多个计算资源上，实现团队间共享访问区域，无需重复操作。

过去，你必须在 Route 53 控制台、API 及其构建的工具之间做出选择。Route 53 Files 消除了这种权衡。你的托管区域成为组织所有 DNS 记录的中心枢纽，可直接从任何 AWS 计算实例、容器或函数访问，无论你是在运行生产应用、响应事件，还是构建智能 AI 系统。

你可以将任何已注册的公共或私有托管区域作为原生文件系统，挂载到 Amazon EC2 实例、Amazon ECS 或 Amazon EKS 上的容器，或 AWS Lambda 函数上。该文件系统将每个资源记录集呈现为文件，每个记录名称呈现为目录，支持标准的 NFS v4.1+ 操作，如创建、读取、更新和删除 DNS 记录。别名记录显示为指向目标的符号链接，因此 ls -l 会按预期渲染，readlink 也能正常工作。跨区域别名则显示为悬空符号链接——因为其目标不在同一文件系统中。

在底层，Route 53 Files 使用 S3 Files，文件保存到实时 DNS 的延迟约为 90 秒，而 Route 53 中其他更改出现在挂载点中的延迟最多为 6 分钟。（注意：更改到达实时 DNS 并不保证立即全球可见；全球可见性取决于记录 TTL 和缓存行为。）该文件系统支持多个计算资源并发访问，采用最后写入者胜出的冲突解决机制，非常适合共享工作负载，例如通过文件工具协作的 AI 代理或使用 sed 相互撤销更改的值班工程师。

让我展示如何开始使用。创建第一个 Route 53 Files 文件系统、挂载它并从 EC2 实例编辑 DNS 非常简单。在此示例中，我已有一个 Route 53 托管区域和一个 EC2 实例。首先，我导航到 Route 53 Files 控制台并创建 IAM 角色。这些角色允许 Route 53 Files 在我的 AWS 账户中创建资源，并读写现有托管区域。我填写 12 位 AWS 账户 ID 和计划使用的托管区域 ID；如果需要，可以指定多个区域或使用“*”允许所有区域注册。点击“创建包”后，浏览器内会生成一个包含精确权限的 IAM 角色策略的 tarball；如果你对安全性敏感，可以审计角色生成代码，确认它未授予不必要的权限。下载包后，解压并运行包含的脚本以创建角色。tarball 内还有 README.txt 文件，包含说明，包括如何调整以允许日后注册更多区域。

创建必要的 IAM 角色后，我可以将托管区域注册到 Route 53 Files。输入 AWS 账户 ID、托管区域 ID、要创建文件系统的 AWS 区域（我选择 ca-central-1），外部 ID 从创建角色包时自动填充。如果稍后返回此页面，可以从角色包 tarball 中的 README.txt 获取外部 ID。（外部 ID 确保只有你能注册托管区域；它也用于停止使用 Route 53 Files。）注册后，我获得一个文件系统 ID（如 fs-0123456789abcdef0），然后可以创建挂载目标。Route 53 Files 与 S3 Files 兼容，因此我使用相同命令创建挂载目标。注意，由于 Route 53 Files 使用 NFS，你需要使用允许 TCP 2049 端口访问的安全组。挂载目标可用后，我可以在 EC2 实例上挂载它。我已确认安装了 amazon-efs-utils 3.0.0 或更高版本及 botocore，并且 EC2 实例附加了包含 AmazonS3FilesClientFullAccess 策略的 IAM 角色。

现在，我可以使用标准命令行工具编辑 DNS。在文件系统中，foo/TYPE 是名为“foo”的 TYPE 记录；遵循 DNS 传统，特殊名称“@”指代区域顶点。例如，echo 1.2.3.4 | sudo tee /mnt/r53fs/example.com/@/A 为区域顶点 example.com 创建值为 1.2.3.4 的 A 记录。如果要使用轮询 DNS，只需在同一记录集中创建第二条记录：echo 5.6.7.8 | sudo tee -a /mnt/r53fs/example.com/@/A，由于文件有两行，DNS 将返回两个 IP 地址。我希望 www 主机别名指向区域顶点，因此创建符号链接：sudo ln -s ../@/A /mnt/r53fs/example.com/www/A。如果要在迁移前减少记录 TTL，只需创建 .TTL 同级文件：echo 60 | sudo tee /mnt/r53fs/example.com/@/A.TTL，更改会立即反映到实时 DNS；没有 .TTL 文件时默认使用 300 秒。通配符记录（如 .example.com）按预期命名；但注意， 在大多数 shell 中会展开，因此从命令行运行时需要转义：sudo mkdir /mnt/r53fs/example.com/\*。当然，文件系统不仅限于命令行；例如，可以从 cron 作业更新 DNS：echo "*/5 * * * * root date > /mnt/r53fs/daemonology.net/vixie/TXT" | sudo tee -a /etc/crontab，然后通过 dig 查询验证。

一些重要技术细节：Route 53 Files 与 AWS IAM 集成进行访问控制。每个角色都由你创建，服务不持有角色创建权限；如果删除 IAM 角色，服务会立即静默停止工作。如果同一记录同时在文件系统和 Route 53 中更改，我们力求最后写入者胜出；但由于 Route 53 不暴露记录修改时间戳，有时会基于文件系统中的更改时间和 Route 53 中的更改窗口进行合理猜测。Route 53 拒绝的写入会记录在记录旁的 .error 文件中；这异步发生，在错误数据到达 Route 53 后才会出现。路由策略、DNSSEC 特定记录类型以及设置了 EvaluateTargetHealth 为 true 的别名目前不支持。任何 Route 53 中不受 Route 53 Files 支持的记录会报告在文件系统根目录的 .r53fs-unsupported 文件中。更改会在你停止编辑记录一段时间后出现在 Route 53 中；与 S3 Files 一致，如果保持文件打开并持续更改，更改不会传播到 Route 53。为支持移动或删除文件后写入新文件的文本编辑器，设有短暂保持期；运行 vi www/A 不应导致 NXDOMAIN 错误。

客户反馈：Corey Quinn 表示，“我多年来一直说 Route 53 是一个数据库。Colin 像冠军一样拥抱了这一哲学，这个疯狂的东西比实际的 Route 53 API 好得多，后者在数据库领域是个尴尬。没有更改时间戳，没有事件，ChangeBatch 模式读起来像 XML 在监狱里学会了 JSON。而 echo 和 tee 在 72 秒内让我的记录上线。谢谢，Colin！”

定价与可用性：Route 53 Files 现已在除中东（巴林）和中东（阿联酋）外的所有商业 AWS 区域可用。注意，由于 Route 53 控制平面完全在 us-east-1 区域运行，影响 us-east-1 的区域性中断会阻止 Route 53 Files 文件系统更新 DNS——尽管文件系统在其自身区域仍可访问。你需支付 AWS 账户内由 Route 53 Files 创建的基础设施费用，但 Route 53 Files 服务本身免费。欢迎在评论区分享你的使用反馈。

常见问题：这是官方 AWS 服务吗？当然不是；但如果他们疯狂到想维护，我很乐意提供。为什么不在 4 月 1 日发布？因为 S3 Files 在 4 月初发布，我不想等到 2027 年 4 月。为什么通过 NFS 而非 FUSE 文件系统暴露 DNS 区域？因为更有趣，也因为 S3 Files 就是这样做的。如果运行 rm -rf * 会怎样？Route 53 Files 会尝试删除所有 DNS 记录；当然，Route 53 不允许删除托管区域的 SOA 或顶点 NS 记录，因此这些记录会静默重新出现在文件系统中。有 SLA 吗？是的，我保证在可用性低于 110% 的月份全额退款。这符合 HIPAA 吗？请不要将患者信息存储在 DNS 中。亚马逊有人知道你在做这个吗？绝对没有。如果他们知道，就必须试图阻止我。亚马逊人不仅是我的同事，还是我的朋友，我不想让任何人因我不可救药的怪异而惹上麻烦。

根据评论内容，总结如下：

主要观点与论据：

1. 创意与幽默性受赞赏（评论1、3、6、7）

   • 评论1：引用“请勿在DNS中存储患者信息”的问答，认为有趣。
   • 评论3：称其为“华丽而糟糕的主意”，表达欣赏。
   • 评论6：形容其模式“像在监狱里学了XML的JSON”，幽默评价。
   • 评论7：表示“笑得差点从椅子上摔下来”，高度认可。

2. 实用性存疑（评论2、5）

   • 评论2：质疑“有多少人手动管理DNS需要这个”，认为多数域名通过自动化管理。
   • 评论5：认为基于块的read()/write() API对管理键值DNS记录体验不佳。

3. 与现有工具对比（评论7、8、10）

   • 评论7：推荐DNSControl作为Route53 API的严肃替代方案，称其“像Terraform但不烂”。
   • 评论8：指出Route53本身可作为简单高可用键值存储，用于GitHub Actions等场景。
   • 评论10：提及该项目遵循Dyna53思路，认为Colin（作者）延续了Corey Quinn开创的流派。

4. 风格模仿精准（评论4）

   • 评论4：称赞作者“比大多数亚马逊人更内化AWS博客风格指南”，认为模仿到位。

平衡性总结： - 正面观点：多数评论认可其创意、幽默感和对AWS风格的精准模仿，部分认为有实用价值。 - 负面/质疑观点：少数评论质疑其实际需求（手动管理DNS的用户少）和API设计（块接口体验差）。 - 中立观点：部分评论将其与现有工具（DNSControl、Route53自身）对比，指出替代方案或已有类似功能。

关键引用（保留中英文）： - 评论3：“what a gorgeously terrible idea”（多么华丽而糟糕的主意） - 评论6：“a schema that reads like XML that learned JSON in prison”（像在监狱里学了XML的JSON的模式） - 评论7：“I laughed so hard I nearly fell out of my chair”（我笑得差点从椅子上摔下来） - 评论2：“Are there that many people managing their dns by hand that they need this?”（有多少人手动管理DNS需要这个？） - 评论8：“Route53 makes a great, simple, HA key-value store for some use cases”（Route53在某些场景下是很好的简单高可用键值存储）