用 AD Connector 与 Route 53 Resolver 在多 VPC 之间共用一套 AWS Managed Microsoft AD
目录服务大概是最不适合「每个环境来一套」的基础设施。AWS Managed Microsoft AD 本身不便宜，多开几套之后，账号、密码策略、组织单元很快就会各自漂移，最后谁是权威数据源都说不清楚。
更现实的做法是：让域只在一个 VPC 里真正落地，其余 VPC 以代理的方式接进来。托管 AD 部署在 VPC A，VPC B 里放一个 AD Connector 指向它——AD Connector 不存储任何目录数据，只是把认证请求透明地转发回去，因此身份源始终只有一个。
不过这条路上有个容易被忽略的前提：网络通了，不代表域名解析得开。下面按顺序把四件事讲清楚。
整体思路
VPC A VPC B
┌────────────────────────┐ ┌────────────────────────┐
│ AWS Managed Microsoft │ │ AD Connector (Small) │
│ AD │◄─────────┤ proxy to DC1 / DC2 │
│ ├─ DC1 │ Peering │ │
│ └─ DC2 │ │ EC2 / WorkSpaces / ... │
│ │ │ │
│ R53 Outbound Endpoint │◄─────────┤ DNS query │
└────────────────────────┘ └────────────────────────┘
Route 53 Resolver Rule (Forward): associate VPC A + VPC B四个组件各司其职：VPC Peering 负责三层可达，Route 53 Resolver 负责让 VPC B 认识这个域名，AD Connector 负责代理认证，托管 AD 则是唯一的身份源。
下文的示例环境为：域名 corp.workspaces.local，NetBIOS 名称 CORP，两个域控地址 172.31.16.172 与 172.31.18.31。
第一步：把两个 VPC 连起来
在 VPC A 与 VPC B 之间建立 VPC Peering，然后两侧路由表都要加上对方的 CIDR——只加一边是最常见的翻车原因，表面上连接已经 Active，实际流量有去无回。
安全组同样要放行：托管 AD 的域控安全组需要接受来自 VPC B CIDR 的 LDAP、Kerberos、DNS 等端口流量。
第二步：在 VPC A 创建 AWS Managed Microsoft AD
在 VPC A 中创建托管 AD，创建完成后记下三样东西，后面每一步都要用：
- 域名（本文为
corp.workspaces.local） - NetBIOS 名称（本文为
CORP） - 两个域控的私有 IPv4 地址（本文为
172.31.16.172、172.31.18.31）
第三步：让 VPC B 能解析这个域
这一步是整套方案的关键。VPC B 的 Route 53 Resolver 并不知道 corp.workspaces.local 该问谁，即使网络已经通了，AD Connector 依然会创建失败。解决办法是建一个出站端点，再用一条转发规则把该域的查询指向托管 AD 的域控。
创建 Route 53 Outbound Endpoint
-
输入端点名称。
-
VPC 选择 VPC A——注意是托管 AD 所在的 VPC，不是发起查询的 VPC B。
-
安全组选择托管 AD 的主域控安全组，名称形如
d-9067abcd12_controllers。托管 AD 会创建两个域控安全组，规则较多的那个是主安全组，另一个只是转发主安全组的规则。这里要选规则较多的主安全组。
-
其余 General settings 保持默认。
-
IP addresses 的可用区必须与托管 AD 所在可用区一致，否则解析请求会跨 AZ 绕行甚至不通。两个 IP 建议分处不同可用区以保证冗余。
-
其余设置保持默认，点击创建。
创建 Route 53 Resolver Rule
- 输入规则名称。
- 规则类型选择 Forward。
- 域名填与托管 AD 完全一致的域名。
- VPC 同时关联 VPC A 和 VPC B——两个都要选，只关联 VPC B 会导致 VPC A 内部解析异常。
- 出站端点选择上一步创建的端点。
- Target IP 填入两个域控的私有 IPv4 地址，两个都填，单点会失去冗余。
- 确认创建。
第四步：在 VPC B 创建 AD Connector
规格选择 Small 即可——AD Connector 只做认证代理，不承载目录数据，Small 足以应对常规请求量。
网络位置选择 VPC B 及其两个子网。
接下来的表单里，每一项都必须与托管 AD 严格对应——这里填错的代价是直接创建失败，而报错信息通常只会告诉你「无法连接到目录」：
| 字段 | 填什么 |
|---|---|
| 目录 DNS 名称 | 与托管 AD 域名一致 |
| NetBIOS 名称 | 与托管 AD 一致 |
| DNS IP 地址 | 托管 AD 两个域控的私有 IPv4 地址 |
| 服务账户用户名 | Admin（托管 AD 的固定账户，不可变更） |
| 服务账户密码 | 创建托管 AD 时设置的管理员密码 |
几个容易踩的点
回头看，这套方案的失败几乎都集中在同样几处：路由表只加了单侧、出站端点建在了 VPC B、转发规则漏关联 VPC A、端点可用区与域控不一致。它们的共同特征是——网络看起来是通的，但解析链路是断的，而 AD Connector 只会笼统地报「连不上目录」。
排查时可以在 VPC B 的实例上直接验证：
# 域名能否解析到域控 IP
dig corp.workspaces.local
# 域控端口是否可达
nc -vz 172.31.16.172 389先确认解析、再确认端口，两步就能把问题定位在 Route 53 还是 Peering。
落地之后
跑通之后的收益很直接：身份源只有一份，账号策略、组织单元不会再各自演化；新的 VPC 想接入，重复第三、四步即可，不必再建一套域；而 AD Connector 只做代理、不落数据，也就没有额外的目录同步负担。
多 VPC 共用一套目录，难点从来不在 AD 本身，而在那条常被忽略的解析链路——把它接通，剩下的就都是标准动作了。