<!-- AI_TASK_START: AI标题翻译 -->
[解决方案] 使用 AWS IAM 条件键实现 Amazon Route 53 精细化访问（第一部分）
<!-- AI_TASK_END: AI标题翻译 -->
<!-- AI_TASK_START: AI竞争分析 -->
# 解决方案分析
## 解决方案概述
该解决方案旨在解决在多团队共享 **Amazon Route 53** 托管区（Hosted Zone）时，如何实现对 DNS 记录进行**精细化访问控制**的挑战。在多账户或多团队协作的环境中，通常会存在多个团队共享同一个公共或私有托管区的场景，例如共享子网环境或沙箱环境。此时，必须确保每个团队只能管理其授权范围内的 DNS 记录，以防止对关键服务记录的误操作或越权修改。
该方案的核心技术原理是利用 **AWS Identity and Access Management (IAM)** 的高级功能，特别是 **IAM 条件密钥 (condition keys)** 和 **AWS principal tags**（附加到 IAM 用户或角色上的标签）。通过创建一个集中的 IAM 策略，该策略利用 `route53:ChangeResourceRecordSetsNormalizedRecordNames` 条件密钥，将用户尝试修改的 DNS 记录名称与附加在该用户身上的标签值（通过 `${aws:PrincipalTag/{custom-attribute}}` 变量获取）进行动态比较。这种方法无需为每个用户或每条记录创建独立的策略，而是通过管理用户标签来实现权限的动态授予或拒绝，从而以一种可扩展且易于管理的方式贯彻**最小权限原则**。
## 实施步骤
1. **创建 Principal 标签**
- 为需要授权的 IAM 用户添加一个自定义标签。例如，创建一个标签，其密钥为 `dnsrecords`，值为该用户被授权管理的 DNS 后缀，如 `svc1.example.com`。
- 此步骤将权限元数据直接附加到身份主体上，使策略能够动态引用。
2. **创建权限策略**
- 创建一个客户管理的 IAM 策略。该策略允许 `route5-3:ChangeResourceRecordSets` 操作，但附加一个 `Condition` 块。
- 在 `Condition` 块中，使用 `ForAllValues:StringLike` 或其他条件运算符（如 `StringEquals`）将 `route53:ChangeResourceRecordSetsNormalizedRecordNames` 条件密钥与 `*.${aws:PrincipalTag/dnsrecords}` 变量进行匹配。这表示只有当用户尝试修改的 DNS 记录名称与用户 `dnsrecords` 标签值所定义的模式匹配时，操作才被允许。
3. **附加权限策略**
- 将上一步创建的 IAM 策略附加到目标 IAM 用户或其所属的用户组。一旦附加，该策略立即生效，开始根据用户的标签来约束其 DNS 修改权限。
4. **验证 DNS 更新权限**
- 使用被授权的 IAM 用户身份登录，尝试创建或修改符合其标签值模式的 DNS 记录（例如 `dev.svc1.example.com`），操作应成功。
- 再次尝试创建或修改不符合模式的 DNS 记录（例如 `dev.svc2.example.com`），操作应因权限不足而被拒绝，从而验证精细化访问控制已生效。
## 方案客户价值
- **可扩展的访问管理**：无需为每个用户或权限组合维护大量独立的 IAM 策略。管理员只需通过修改用户标签即可调整权限，极大地简化了在大型组织中对 DNS 权限的管理。
- **强化安全与合规**：严格遵循**最小权限原则**，确保用户只能访问和修改其业务所需的特定 DNS 记录。这降低了因人为失误或恶意行为导致关键 DNS 记录被篡改的风险。
- **提升运维效率**：将权限管理的关注点从复杂的 JSON 策略文档转移到简单的键值对标签上，降低了管理门槛，使 DNS 权限的分配和回收更加敏捷和直观。
## 涉及的相关产品
- **Amazon Route 53**: AWS 提供的可扩展、高可用的域名系统（DNS）服务，方案中的权限控制目标。
- **AWS Identity and Access Management (IAM)**: AWS 的核心安全服务，用于管理用户身份和对 AWS 资源的访问权限，提供策略、条件密钥和标签等关键功能。
- **AWS Command Line Interface (AWS CLI)**: 用于通过命令行与 AWS 服务交互的工具，可用于自动化标签和策略的创建与附加。
## 技术评估
该解决方案在技术上具有显著优势，但也存在一些应用上的考量。
- **优势**
- **高度灵活性**：通过组合使用不同的条件运算符（`StringEquals`, `StringNotEquals`, `StringLike`, `StringNotLike`），可以实现多样化的授权逻辑，如精确允许/拒绝单个记录，或允许/拒绝整个子域的记录。
- **动态授权**：权限与身份（Principal Tag）绑定，而非写死在策略中。当用户职责变更时，只需更新标签即可，策略本身保持不变。
- **原生集成**：完全利用 AWS IAM 和 Route 53 的原生功能，无需引入第三方工具或复杂的自定义逻辑，稳定性和安全性有保障。
- **局限与考量**
- **标签值限制**：单个标签的值无法包含逗号等分隔符来表示多个独立的 DNS 记录。如果一个用户需要管理多个不相关的记录或域后缀，则需要为其附加多个不同的标签，并相应地调整 IAM 策略，这可能增加管理的复杂性。
- **适用场景**：此方案最适用于多团队**共享托管区**的场景。对于每个团队拥有独立托管区的环境，AWS 推荐使用 **Route 53 Profiles** 进行集中化的 DNS 配置管理，这可能是更佳实践。
- **扩展控制维度**：除了记录名称，还可以结合其他 Route 53 条件密钥，如 `route53:ChangeResourceRecordSetsActions`（限制操作为 `CREATE`, `DELETE` 或 `UPDATE`）和 `route53:ChangeResourceRecordSetsRecordTypes`（限制记录类型如 `A`, `CNAME`），以实现更深层次的控制。
<!-- AI_TASK_END: AI竞争分析 -->
<!-- AI_TASK_START: AI全文翻译 -->
# 使用 AWS IAM 条件键实现 Amazon Route 53 的精细化访问 (第一部分)
**原始链接:** [https://aws.amazon.com/blogs/networking-and-content-delivery/implementing-fine-grained-amazon-route-53-access-using-aws-iam-condition-keys-part-1/](https://aws.amazon.com/blogs/networking-and-content-delivery/implementing-fine-grained-amazon-route-53-access-using-aws-iam-condition-keys-part-1/)
**发布时间:** 2025-08-25
**厂商:** AWS
**类型:** BLOG
---
用户通常采用多账户策略 (multi-account strategies) 来支持多个团队部署工作负载 (workloads)。本文面向需要通过共享的 [Amazon Route 53 私有托管区 (private hosted zone)](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-private.html) 或 [公有托管区 (public hosted zones)](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/AboutHZWorkingWith.html) 来管理跨团队 DNS 权限 (DNS permissions) 的亚马逊云科技 (Amazon Web Services) (AWS) 管理员和网络工程师。在某些情况下，多个团队可能共享同一个托管区，此时有必要通过访问控制来允许或拒绝更新共享托管区内的一个或多个 DNS 记录。一个例子是，多个团队在只有一个共享托管区的 [共享子网 (shared subnet)](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-sharing.html) 中运作，每个团队被授权管理共享托管区内特定的 DNS 后缀 (DNS suffix)。另一个例子是，在一个供用户实验的沙盒 (sandbox) 共享托管区中，用户被禁止管理沙盒共享托管区内某些共享服务的 DNS 记录。
本文将讨论一种可扩展的解决方案，该方案利用 [AWS Identity and Access Management (IAM)](https://aws.amazon.com/iam/) 的 [条件键 (condition keys)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) 和 [AWS 主体标签 (AWS principal tags)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principaltag) ，对 Route 53 的私有或公有托管区实现精细化访问 (fine-grained access)，从而授予在共享托管区中更新部分 DNS 记录的条件访问权限。本文将通过一个示例，指导您如何在同一个 [AWS 账户 (AWS account)](https://docs.aws.amazon.com/accounts/latest/reference/accounts-welcome.html) 内为 [IAM 用户 (IAM users)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) 授予精细化访问权限。
## 解决方案概述
我们假设您已熟悉使用 [Route 53 托管区](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-working-with.html) 进行 DNS 管理、使用 [IAM 策略和权限 (IAM policy and permissions)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) 进行访问管理，以及通过 [IAM 用户标签 (tags for IAM users)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags_users.html) 创建键值对作为自定义属性。该解决方案利用 [IAM 条件元素 (IAM condition element)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) 以及 [Route 53 的 IAM 操作、资源和条件键](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonroute53.html) 来实现对 Route 53 托管区的精细化访问。IAM 策略中的 `condition` 是一个可选元素，用于指定策略授予或拒绝权限的具体条件。该解决方案通过允许您基于用户属性创建精细化权限，并遵循最小权限原则 (least-privilege principles) 来缩减权限范围，从而简化了访问管理。
下图展示了 Route 53 精细化访问的架构。图中左侧的 IAM 用户被分配了一个自定义标签键 “` *dnsrecords*`”，其值是他们被允许更新的 DNS 记录。当用户尝试修改右侧 Route 53 托管区中的 DNS 记录时，中间的 IAM 策略会评估 [route53:ChangeResourceRecordSets](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonroute53.html#amazonroute53-actions-as-permissions) 操作，并使用条件键 [route53:ChangeResourceRecordSetsNormalizedRecordNames](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonroute53.html#amazonroute53-policy-keys) 将待更新的 DNS 记录名称与用户标签值进行比较，以授予访问权限。
图 1: 使用 IAM 条件键实现 Route 53 精细化访问
以下四个权限策略展示了如何使用四种条件运算符 (condition operators) 来授予 DNS 记录的权限。Route 53 条件键 `route53:ChangeResourceRecordSetsNormalizedRecordNames` 通过匹配 `${aws:PrincipalTag/{custom-attribute}}` 键，来控制 `route53:ChangeResourceRecordSets` 操作请求中的 DNS 记录名称，从而授予管理特定 DNS 记录的权限。`${aws:PrincipalTag/{custom-attribute}}` 条件键指定了附加到 IAM 用户上的标签值。
### 使用 StringEquals 允许访问特定 DNS 记录
当您希望授予管理特定 DNS 记录名称的权限时，请使用 `ForAllValues:StringEquals` 运算符。当您希望限制用户仅能管理一个精确定义的记录，而不允许访问共享托管区中的其他记录时，这种方法非常理想。以下权限策略允许更新一条 DNS 记录，请将 `*{custom-attribute}*` 和 `*{**Route53HostedZoneID}*` 分别替换为您的自定义标签属性和托管区 ID。
```json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "route53:ChangeResourceRecordSets",
"Resource": "arn:aws:route53:::hostedzone/{Route53HostedZoneID}",
"Condition": {
"ForAllValues:StringEquals": {
"route53:ChangeResourceRecordSetsNormalizedRecordNames": [
"${aws:PrincipalTag/{custom-attribute}}"
]
}
}
}
]
}
```
该策略与值为 “`svc1.example.com`” 的主体标签相结合，意味着用户只能管理 DNS 记录 “`svc1.example.com`”。该用户将被拒绝管理其他记录的权限，例如：
- 创建新记录 “`api.svc1.example.com`”
- 更新现有记录 “`marketing.example.com`”
- 删除现有记录 “`svc2.example.com`”
### 使用 StringNotEquals 拒绝访问特定 DNS 记录
当您希望拒绝管理特定 DNS 记录的权限时，请使用 `ForAllValues:StringNotEquals` 运算符。当您希望保护某个特定的 DNS 记录，同时允许用户在共享托管区中创建任何其他 DNS 记录时，这种方法非常理想。以下权限策略拒绝更新一条 DNS 记录，请将 `*{custom-attribute}*` 和 `*{**Route53HostedZoneID}*` 分别替换为您的自定义标签属性和托管区 ID。
```json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "route53:ChangeResourceRecordSets",
"Resource": "arn:aws:route53:::hostedzone/{Route53HostedZoneID}",
"Condition": {
"ForAllValues:StringNotEquals": {
"route53:ChangeResourceRecordSetsNormalizedRecordNames": [
"${aws:PrincipalTag/{custom-attribute}}"
]
}
}
}
]
}
```
该策略与值为 “`svc1.example.com`” 的主体标签相结合，意味着用户将被拒绝管理 DNS 记录 “`svc1.example.com`” 的权限。该用户将被允许更新其他 DNS 记录，例如：
- 创建新记录 “`api.svc1.example.com`”
- 更新现有记录 “`marketing.example.com`”
- 删除现有记录 “`svc2.example.com`”
### 使用 StringLike 允许访问以特定模式结尾的 DNS 记录
在自定义属性前使用带通配符 (wildcard) “`*`” 和句点 “`.`” 的 `ForAllValues:StringLike` 运算符，可以授予管理特定域后缀 (domain suffix) 中 DNS 记录的权限。当您希望限制用户仅能管理某个域后缀，而不允许访问共享托管区中的其他记录时，这种方法非常理想。以下权限策略允许您更新某个域后缀中的 DNS 记录，请将 `*{custom-attribute}*` 和 `*{**Route53HostedZoneID}*` 分别替换为您的自定义标签属性和托管区 ID。
```json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "route53:ChangeResourceRecordSets",
"Resource": "arn:aws:route53:::hostedzone/{Route53HostedZoneID}",
"Condition": {
"ForAllValues:StringLike": {
"route53:ChangeResourceRecordSetsNormalizedRecordNames": [
"*.${aws:PrincipalTag/{custom-attribute}}"
]
}
}
}
]
}
```
该策略与值为 “`svc1.example.com`” 的主体标签相结合，意味着用户将能够管理 “`.svc1.example.com`” 后缀下的任何 DNS 记录，例如：
- 创建新记录 “`api.svc1.example.com`”
- 更新现有记录 “`dev.svc1.example.com`”
- 删除现有记录 “`prod.svc1.example.com`”
然而，该用户将被拒绝管理其他记录的权限，例如：
- 创建新记录 “`svc1.example.com`”
- 更新现有记录 “`marketing.example.com`”
- 删除现有记录 “`api.svc2.example.com`”
### 使用 StringNotLike 拒绝访问以特定模式结尾的 DNS 记录
在自定义属性前使用带通配符 “`*`” 和句点 “`.`” 的 `ForAllValues:StringNotLike` 运算符，可以拒绝更新特定域后缀中的 DNS 记录。当您希望在共享环境中保护特定的 DNS 后缀，同时允许用户在共享托管区中创建任何其他 DNS 记录时，这种方法非常理想。以下权限策略拒绝更新以特定模式结尾的 DNS 记录，请将 `*{custom-attribute}*` 和 `*{**Route53HostedZoneID}*` 分别替换为您的自定义标签属性和托管区 ID。
```json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "route53:ChangeResourceRecordSets",
"Resource": "arn:aws:route53:::hostedzone/{Route53HostedZoneID}",
"Condition": {
"ForAllValues:StringNotLike": {
"route53:ChangeResourceRecordSetsNormalizedRecordNames": [
"*.${aws:PrincipalTag/{custom-attribute}}"
]
}
}
}
]
}
```
该策略与值为 “`svc1.example.com`” 的主体标签相结合，意味着用户将被拒绝管理 “`.svc1.example.com`” 后缀下的 DNS 记录，例如：
- 创建新记录 “`api.svc1.example.com`”
- 更新现有记录 “`dev.svc1.example.com`”
- 删除现有记录 “`prod.svc1.example.com`”
然而，该用户将被授予管理其他记录的权限，例如：
- 创建新记录 “`svc1.example.com`”
- 更新现有记录 “`marketing.example.com`”
- 删除现有记录 “`api.svc2.example.com`”
## 解决方案实施
您将创建一个解决方案，允许用户仅管理与其分配的标签值相匹配的 DNS 记录。通过以下步骤，您可以配置 IAM 用户标签和策略，从而实现对 Route 53 托管区的精细化访问控制。完成后，用户将只能管理与其自定义标签值相匹配的 DNS 记录。
本示例使用 “`dnsrecords`” 自定义属性中的值，通过在同一账户中使用一个权限策略，来授予在共享托管区 “`example.com`” 中更新以 “`.svc1.example.com`” 域后缀结尾的 DNS 记录的条件访问权限。
### 先决条件
在继续之前，您需要具备以下条件：
- 用于域 “`example.com`” 的托管区
- 与托管区位于同一 AWS 账户中的 IAM 用户
- 使用具有更新 IAM 用户和权限的凭证登录到托管区所在的 AWS 账户
### 步骤 1: 创建主体标签
请参考 [标记 IAM 用户](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags_users.html) 中的步骤，在 [AWS 管理控制台 (AWS Management Console)](https://aws.amazon.com/console/) 中为 IAM 用户创建属性/标签 “`dnsrecords`”，并将其值设为 “`svc1.example.com`”。
您可以使用以下 [AWS 命令行界面 (AWS Command Line Interface) (AWS CLI)](https://aws.amazon.com/cli/) 命令来创建键为 “`dnsrecord`”、值为 “`svc1.example.com`” 的标签，请将 `<USER_NAME>` 替换为您的 IAM 用户名：
```bash
aws iam tag-user --user-name <USER_NAME> --tags '{"Key": "dnsrecord", "Value": "svc1.example.com"}'
```
### 步骤 2: 创建权限策略
请参考用户指南 [使用客户管理的策略定义自定义 IAM 权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) 中的步骤，在控制台中使用以下 JSON 策略文件创建用于 DNS 记录精细化访问的 IAM 权限策略。在 `${aws:PrincipalTag/dnsrecords}` 前面有一个通配符 “`*`” 和一个句点 “`.`”，以启用字符串匹配。值 `*Z1R8UBAEXAMPLE*` 是私有托管区的 ID，您必须将其替换为您的托管区 ID。
```json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "route53:ChangeResourceRecordSets",
"Resource": "arn:aws:route53:::hostedzone/Z1R8UBAEXAMPLE",
"Condition": {
"ForAllValues:StringLike": {
"route53:ChangeResourceRecordSetsNormalizedRecordNames": [
"*.${aws:PrincipalTag/dnsrecords}"
]
}
}
}
]
}
```
您可以使用以下 CLI 命令来创建权限策略，请将 `<POLICY_NAME>` 替换为策略名称，并将 `<DOCUMENT_FILE>` 替换为上述 JSON 策略文档的位置：
```bash
aws iam create-policy –policy-name <POLICY_NAME> --policy-document <DOCUMENT_FILE>
```
### 步骤 3: 将权限策略附加到 IAM 用户或组
将步骤 2 中创建的权限策略附加到步骤 1 中带有自定义标签的 IAM 用户，或该用户所在的组，以启用对该用户的精细化托管区访问控制。请参考用户指南 [更改 IAM 用户的权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html) 中的步骤在控制台中将权限附加到用户，或参考用户指南 [将策略附加到 IAM 用户组](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups_manage_attach-policy.html) 中的步骤将权限附加到组。
您可以使用以下 CLI 命令将权限策略附加到 IAM 用户，请将 `<POLICY_ARN>` 替换为步骤 2 中创建的策略的 ARN，并将 `<USER_NAME>` 替换为步骤 1 中创建的 IAM 用户：
```bash
aws iam attach-user-policy --policy-arn <POLICY_ARN> --user-name <USER_NAME>
```
您可以使用以下 CLI 命令将权限策略附加到 IAM 组，请将 `<POLICY_ARN>` 替换为步骤 2 中创建的策略的 ARN，并将 `<GROUP_NAME>` 替换为包含步骤 1 中创建的 IAM 用户的组：
```bash
aws iam attach-user-policy --policy-arn <POLICY_ARN> --group-name <GROUP_NAME>
```
### 步骤 4: 验证 DNS 更新权限
现在，该 IAM 用户有权在共享托管区 “`example.com`” 中管理 “`.svc1.example.com`” 域后缀下的 DNS 记录。您可以按照开发者指南 [使用 Route 53 控制台编辑 DNS 记录](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-editing.html) 中的步骤或使用开发者指南中的 [change-resource-record-sets CLI](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/route-53_example_route-53_ChangeResourceRecordSets_section.html) 命令来验证权限是否按预期工作。
例如，使用以下 CLI 命令和 JSON 配置文件创建 DNS 记录 “`dev.svc1.example.com`” 将会成功。
```bash
aws route53 change-resource-record-sets --hosted-zone-id Z1R8UBAEXAMPLE --change-batch file://svc1-create.json
```
```json
{
"Comment": "configuration to create dev.svc1.example.com record",
"Changes": [
{
"Action": "CREATE",
"ResourceRecordSet": {
"Name": "dev.svc1.example.com",
"Type": "A",
"TTL": 300,
"ResourceRecords": [
{
"Value": "10.1.1.1"
}
]
}
}
]
}
```
使用以下 CLI 命令和 JSON 配置文件创建 DNS 记录 “`dev.svc2.example.com`” 将会失败。
```bash
aws route53 change-resource-record-sets --hosted-zone-id Z1R8UBAEXAMPLE --change-batch file://svc2-create.json
```
```json
{
"Comment": "configuration to create dev.svc2.example.com record",
"Changes": [
{
"Action": "CREATE",
"ResourceRecordSet": {
"Name": "dev.svc2.example.com",
"Type": "A",
"TTL": 300,
"ResourceRecords": [
{
"Value": "10.1.1.1"
}
]
}
}
]
}
```
## 注意事项
尽管 `route53:ChangeResourceRecordSetsNormalizedRecordNames` 条件是一个多值键 (multi-valued key)，可以使用逗号 “`,`” 分隔多个值进行匹配，但标签值本身不能包含逗号来分隔多个值。因此，一个自定义属性 (custom attributes) 只能包含一个 DNS 记录值来与权限策略配合使用。如果需要对多个 DNS 记录值进行访问控制，则必须使用多个自定义属性来配合相应的权限策略。
Route 53 提供了更多 [IAM 策略条件](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/specifying-conditions-route53.html) ，可用于对 DNS 记录进行更精细的访问控制。`route53:ChangeResourceRecordSetsActions` 条件键可以将操作限制为 `CREATE`、`UPDATE` 和 `DELETE`。`route53:ChangeResourceRecordSetsRecordTypes` 条件键可以限制对 DNS 记录类型的操作。
在管理 IAM 访问权限时，请考虑用户、组和策略的 [IAM 配额和字符限制](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html) 。
如果您的权限未按预期工作，[排查 IAM 策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_policies.html) 文档中包含了针对常见问题的实用指南。
对于不使用共享托管区，而是每个团队为自己的服务管理私有托管区的环境，推荐的最佳实践是使用 [Route 53 Profiles](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/profiles.html) 来集中管理 [Amazon Virtual Private Clouds (Amazon VPCs)](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) 和账户的 DNS 配置。文章 [使用 Amazon Route 53 Profiles 构建可扩展的多账户 AWS 环境](https://aws.amazon.com/blogs/networking-and-content-delivery/using-amazon-route-53-profiles-for-scalable-multi-account-aws-environments/) 对该架构进行了回顾。
## 结论
在本文中，我们回顾了一种可扩展的解决方案，即使用 AWS IAM 条件键和 AWS 主体标签，对共享的 Amazon Route 53 托管区进行精细化访问控制，以便多个团队能够管理共享托管区中的部分 DNS 记录。回顾内容包括一个在同一账户内实现托管区条件访问的示例。在接下来的两篇文章中，我们将回顾如何使用 IAM 条件键和 AWS 主体标签实现跨账户 (cross-account) 和联合用户 (federated user) 的精细化访问。
## 关于作者
### Daniel Yu
Daniel Yu 是一名高级技术客户经理 (Senior Technical Account Manager)，他与企业级支持 (Enterprise Support) 用户合作，帮助他们优化云转型计划。凭借在网络和安全基础设施方面的专业知识，他专注于为 AWS 架构设计和卓越运营提供战略指导。
<!-- AI_TASK_END: AI全文翻译 -->