AWS Route 53 Resolver 端点别再傻傻分不清：出站 vs 入站，一文让你秒懂！|MK博客

开场小故事

上周公司做混合云演练，我的同事小王接到任务：让 AWS 上的服务可以解析本地机房的 DNS 记录。他兴冲冲地打开控制台，结果在「Inbound endpoint」和「Outbound endpoint」之间卡了整整 20 分钟，最后建反了方向，导致全网解析失败，被老板请去喝了“乌龙茶”。
如果你也曾面对这两个按钮发呆，那么这篇文章就是为你准备的。

一、把概念揉碎：DNS 其实是一次“问路”

想象你要去一家没去过的新餐厅：

你自己去问路 → 你主动走到路口的交警岗亭（on-prem DNS）问路 → 出站（Outbound）
餐厅派人来告诉你 → 餐厅把路线贴到你家门口的告示栏（Route 53）→ 入站（Inbound）

回到技术里：

场景	谁提问	谁回答	端点类型
AWS 主机想解析 `corp.diningroom.com`，记录存于本地 DNS	AWS 主机	on-prem DNS	Outbound
本地 PC 想解析 `api.diningroom.com`，记录存于 Route 53	本地 PC	Route 53	Inbound

二、费曼式 4 步记忆法

选一个类比
邮局窗口：Outbound = 寄信窗口，Inbound = 收信窗口。
用 10 岁小孩能听懂的话讲
“把 DNS 请求当成一封信，谁寄信就走去哪个窗口。”
找漏洞，故意说反
如果我们把“寄信”任务交给“收信窗口”，邮局会直接退回：“对不起，这是收件口。”
同理，把 Outbound 任务建成 Inbound，DNS 查询永远到不了本地服务器。
压缩成口诀
AWS 去问别人 → Outbound
别人来问 AWS → Inbound

三、动手实战

场景设定

你在一家连锁咖啡公司做云端运维。
公司总部 DNS（192.168.50.10）维护着内部域名 coffee.internal，里面有 beans.coffee.internal、portal.coffee.internal 等记录。
AWS 侧有一个“新品研发 VPC”（10.50.0.0/16），里面的 EC2 需要解析这些内部域名，但解析请求绝不能走公网。
权限要求：只能在“新品研发 VPC”里创建资源，且必须复用已存在的安全组 sg-coffee-dns-proxy。

目标

让 10.50.0.0/16 内的所有 EC2 能够解析 *.coffee.internal，同时验证流程一次到位。

步骤清单（对照口诀：AWS 去问别人 → Outbound）

预备检查

# 登录任意一台 EC2（10.50.x.x）
dig beans.coffee.internal
# 期望结果：NXDOMAIN → 确认当前无法解析

创建 Outbound Resolver Endpoint
• 控制台：Route 53 → Resolver → Outbound endpoints → Create
• Endpoint name：coffee-outbound-resolver
• VPC：选择“新品研发 VPC”
• Subnet：挑两条私有子网（10.50.10.0/24、10.50.20.0/24）
• Security group：sg-coffee-dns-proxy（已放行 TCP/UDP 53）
• 等待状态变为 Operational
创建转发规则（Forwarding rule）
• Rule name：coffee-internal-forward
• Domain name：coffee.internal
• Target IP：192.168.50.10（总部 DNS）
• 出站端点：选择刚创建的 coffee-outbound-resolver
• 关联 VPC：勾选“新品研发 VPC”

验证

# 再等 1~2 分钟传播
dig beans.coffee.internal +short
# 期望得到 192.168.50.55 之类内网地址 → 成功

一句话总结一下

把“新品研发 VPC”里的 EC2 当成想点咖啡的客人，总部 DNS 就是咖啡师——客人想喝什么，必须派“跑腿小哥”（Outbound Resolver Endpoint）去问咖啡师拿菜单。方向对了，咖啡自然到手！

四、常见翻车现场与急救

翻车症状	可能原因	急救方案
`NXDOMAIN` 仍在	端点建错方向（Inbound）	删掉重建 Outbound
安全组验证失败	用了默认 SG	换成指定 SG
规则未生效	忘记关联 VPC	Rule → Associate VPC

五、一张图带走所有知识点

┌──────────────┐               ┌──────────────┐
│   on-prem    │◄──────────────┤  AWS VPC     │
│ DNS 172.16.2.12│  Outbound   │  Outbound EP │
└──────────────┘   (寄信)      └──────────────┘

┌──────────────┐               ┌──────────────┐
│  on-prem PC  │──────────────►│  AWS VPC     │
│              │   Inbound     │  Inbound EP  │
└──────────────┘   (收信)      └──────────────┘

结语

下次再看到 Route 53 Resolver Endpoint 的架构，先默念口诀：
“谁寄信？AWS → Outbound，别人 → Inbound”。
三秒钟选对方向，再也不怕喝乌龙茶！