AWS个人账号 亚马逊EC2内网DNS自定义
为什么需要自定义DNS？
各位运维老铁们，是不是每次给EC2实例写文档的时候，都要先抄一遍IP地址？重启实例后，IP一变，文档就得重写，简直比女朋友突然变心还让人心累！更别提当实例多了以后，10.0.1.10、10.0.1.11...这些数字串比圆周率还难记。这时候，自定义DNS就成救命稻草了——让服务器们都有个好听的名字，再也不用靠数字密码认人了。
AWS内网DNS默认情况
AWS默认为每个EC2实例分配了一个内网DNS名称，格式类似ip-10-0-1-10.ec2.internal。这名字确实有点"官方"，但用起来还是挺方便的。不过问题来了，当你的架构复杂起来，比如有多个服务实例，或者需要给某个服务起个有意义的名字时，这种默认的命名方式就显得不够灵活了。比如，你想给数据库实例叫db-prod，而不是ip-10-0-2-50.ec2.internal，这时候就得自己动手了。
自定义DNS的正确姿势——Route 53私有托管区域
别慌，AWS早就想到了这一点，提供了Route 53私有托管区域这个神器。简单来说，它就像是你自己的私人通讯录，只允许你的VPC内的机器查询，别人连看都看不到。下面，咱们一步步来操作。
创建私有托管区域
第一步，打开Route 53控制台，点击"创建托管区域"。这时候，系统会问你："要创建公共还是私有区域？"选"私有"。接着输入你的域名，比如mycompany.local。注意，千万别用.com、.net这些公共后缀，否则AWS会说"你这是想干嘛？"直接拒绝。用.local或者.internal这种私有后缀，安全又不冲突。
关联VPC并添加记录
创建完成后，需要将它关联到你的VPC。在托管区域的详情页，找到"关联VPC"按钮，选择你要关联的VPC。接着，就可以添加记录了。比如，添加一个A记录，主机名填web，记录值填你的EC2实例私有IP。这样，其他实例就可以通过web.mycompany.local来访问这个实例了。
验证解析是否生效
测试的时候，别急着用ping，先用nslookup试试。比如在终端输入：nslookup web.mycompany.local。如果返回正确的IP，说明搞定。如果返回"服务器未知"，别慌，先检查VPC的DNS设置——在VPC控制台，找到你的VPC，看看"DNS解析"和"DNS主机名"是不是都亮着绿灯。如果没开，赶紧打开，否则DNS查询根本过不去。
实战案例：给你的应用起个响亮的名字
假设你有个Web应用，部署在三个EC2实例上，负载均衡器用的是ALB。这时候，你希望用app.yourcompany.local来访问，这样运维和开发团队都方便。具体操作：
- 在Route 53创建私有托管区域app.yourcompany.local
- 将VPC关联到该区域
- 添加CNAME记录，将app.yourcompany.local指向ALB的DNS名称
这样，无论ALB的IP如何变化，只需要维护一个CNAME记录，所有实例都能通过app.yourcompany.local访问，再也不用担心IP变动带来的麻烦。
避坑指南：常见问题与解决办法
AWS个人账号 解析失败？先检查这些
解析失败？别急，先检查以下几点：
- 私有托管区域是否已关联VPC
- VPC的DNS解析和DNS主机名是否启用
- 记录是否正确，比如A记录的IP是否正确
- DNS缓存问题，可以用dig +trace命令查看解析路径
名称冲突怎么办？
比如你用了example.com作为私有区域，但可能和公网上存在的域名冲突。这时候，建议用私有域名，比如内部专用后缀，比如.company或者.internal，这样避免冲突。另外，AWS官方建议使用非公共的域名后缀，比如example.internal，这样更安全。
性能问题？
Route 53私有托管区域的性能非常稳定，通常不需要担心。但如果实例数量特别多，建议检查DNS查询的响应时间，确保没有瓶颈。不过一般来说，Route 53的响应速度都是毫秒级的，比自己搭DNS服务器靠谱多了。
总结
自定义内网DNS看似复杂，其实只要用好Route 53私有托管区域，几步就能搞定。它不仅解决了IP变动带来的麻烦，还让整个架构更加清晰易管理。下次再有人问你"那个服务的IP是多少"，你可以优雅地回复："用app.yourcompany.local访问就行啦！"
