多账户环境下AWS Route53公托管区的用户域名配置难题

一、精细化权限控制的跨账户DNS管理（推荐方案） #

保留全球网络账户的site.com根托管区，通过IAM权限策略实现生产账户对特定顶级子域名的可控管理：

• 给生产账户的专用IAM角色授予仅针对生产相关顶级子域名的DNS记录操作权限，比如限定只能修改app.site.com.、api.site.com.等记录集（注意域名末尾的点是Route53的规范格式）
• 在全球账户的Route53托管区资源策略中，添加权限规则（简化示例）：

  {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Principal": {
          "AWS": "arn:aws:iam::生产账户ID:role/生产DNS管理角色"
        },
        "Action": "route53:ChangeResourceRecordSets",
        "Resource": "arn:aws:route53:::hostedzone/根托管区ID",
        "Condition": {
          "StringEquals": {
            "route53:RecordNames": ["app.site.com.", "api.site.com."],
            "route53:RecordTypes": ["A", "AAAA", "CNAME", "Alias"]
          }
        }
      }
    ]
  }
  

• 生产团队可通过AssumeRole操作，在自己的账户中执行根托管区的生产域名记录维护，既满足app.site.com的需求，又确保根托管区的其他记录（如dev.site.com的NS委托）仍由全球网络团队管控，权限边界清晰。

二、调整域名职责划分（备选方案） #

如果坚持生产记录不存于非生产账户，可调整架构为：

• 全球网络账户仅负责site.com根域名的注册、全局NS服务器配置，以及dev.site.com的NS委托记录
• 将app.site.com等生产顶级子域名的托管区直接创建在生产账户，然后在全球账户的根托管区中为这些子域名添加NS记录，委托生产账户托管
• 这种方式下，生产账户完全自主管理面向用户的域名，全球账户仅做根级委托，避免生产记录跨账户存放，但需要额外维护多个顶级子域名的NS委托。

三、对原方案的分析 #

• 原方案1的顾虑可通过权限精细化控制解决：生产记录虽存于全球账户托管区，但只有生产团队能操作，所有权和维护权仍归属生产侧，符合职责分离原则，并非“不合理”
• 原方案2的风险确实存在：开发环境依赖生产账户的DNS配置，会增加生产故障的影响范围，且打破环境隔离的最佳实践，不推荐采用

内容的提问来源于stack exchange，提问作者colioli