AWS Route 53 是 AWS 的 DNS 服务用于域名注册、DNS 解析、流量路由和健康检查。网站部署在 EC2、S3、CloudFront、ALB 或 API Gateway 后需要通过 DNS 把域名指向对应资源。Route 53 的作用不是运行网站而是决定用户输入域名后请求应该被引导到哪里。AWS 官方文档也将 Route 53 定义为高可用、可扩展的 DNS Web 服务并支持域名注册、DNS 路由和资源健康检查。AWS Route 53 是什么Route 53 负责域名解析和流量路由用户访问 example.com 时浏览器需要先查询这个域名对应的目标地址。Route 53 负责返回 DNS 结果例如 EC2 公网 IP、CloudFront 分发域名、ALB 域名或 S3 静态网站端点。在 AWS 架构中Route 53 通常位于最外层。EC2 负责运行应用S3 负责保存文件CloudFront 负责 CDN 分发ALB 负责流量转发Route 53 负责把域名请求指向正确入口。服务器开通、系统镜像、安全组和公网访问规则应在解析前完成。Hosted Zone 是 DNS 记录的容器Hosted Zone 可以理解为某个域名在 Route 53 中的 DNS 管理区。创建 example.com 的 Public Hosted Zone 后可以在里面添加 www.example.com、api.example.com、cdn.example.com 等记录。Public Hosted Zone 用于公网域名解析Private Hosted Zone 用于 VPC 内部域名解析。内部系统、数据库服务、微服务地址和私有 API 更适合使用 Private Hosted Zone并与 VPC 网络规划一起设计。Route 53 常见 DNS 记录怎么选A 记录和 CNAME 记录A 记录用于把域名解析到 IPv4 地址适合指向固定公网 IP。EC2 如果使用 Elastic IP可以用 A 记录指向该 IP。普通公网 IP 会随实例停止和启动变化不适合作为长期解析目标。CNAME 记录用于把一个域名解析到另一个域名例如把 www.example.com 指向某个服务商提供的域名。CNAME 不能用于根域名 example.com这是传统 DNS 规则的限制。Alias 记录适合 AWS 资源Route 53 的 Alias 记录是 AWS 扩展能力可把域名指向 CloudFront、S3 bucket、Elastic Load Balancer 等 AWS 资源。Alias 记录既可用于根域名也可用于子域名因此在 AWS 环境中比普通 CNAME 更适合绑定 CloudFront、ALB 和 S3。常见选择如下目标资源推荐记录EC2 Elastic IPA 记录CloudFrontAlias 记录ALBAlias 记录S3 静态网站Alias 记录第三方服务域名CNAME 记录邮箱验证MX / TXT 记录SSL 验证CNAME / TXT 记录DNS 记录选择错误会导致域名无法访问、根域名无法绑定、CloudFront 证书验证失败或解析结果不稳定。不同 AWS 场景下怎么配置解析域名解析到 EC2EC2 直接作为网站源站时应使用 Elastic IP 作为稳定公网入口再用 A 记录指向该 IP。安全组应开放 80 和 443SSH 只允许固定来源访问。域名解析成功后还要检查 Web 服务、HTTPS 证书、Nginx 或 Apache 配置。直接解析到 EC2 适合小型网站、测试服务和简单应用。正式业务更适合在 EC2 前面增加 ALB 或 CloudFront减少源站直接暴露。域名解析到 ALB生产业务通常使用 Application Load Balancer 作为入口再把流量转发到多台 EC2。Route 53 应使用 Alias 记录指向 ALB。这样可以避免域名直接绑定单台服务器也方便后续扩容、健康检查和多可用区部署。ALB 适合后台系统、API 服务、企业应用和多实例架构。它解决的是应用入口和流量分发问题不替代 DNS也不替代 CloudFront。域名解析到 CloudFrontCloudFront 绑定自定义域名时需要先在 CloudFront 添加 Alternate Domain Name再配置覆盖该域名的 SSL/TLS 证书。AWS 文档说明使用 Route 53 域名配合 CloudFront distribution 时应创建指向 CloudFront distribution 的 Alias 记录Alias 记录可用于根域名和子域名。CloudFront 使用 ACM 证书时证书必须在 US East (N. Virginia) us-east-1 区域申请或导入。域名解析到 S3 静态网站S3 静态网站可以通过 Route 53 解析到 S3 website endpoint但正式项目更建议使用 CloudFront 作为访问入口由 CloudFront 连接 S3 源站。这样可以统一 HTTPS、缓存、访问控制和全球分发。S3 bucket 不应为了访问静态文件而整体公开。Route 53 健康检查和故障切换Health Check 用于判断资源状态Route 53 Health Check 可以自动向 Web 服务器等资源发起请求判断资源是否可访问、可用和功能正常。资源不可用时可以触发通知也可以让 Route 53 把流量转向其他健康资源。Health Check 适合检测网站入口、API 地址、主备节点和外部服务状态。它不能替代应用监控也不能判断所有业务逻辑是否正常。正式业务仍需结合 CloudWatch、日志和应用层监控。Failover Routing 适合主备架构Failover Routing 可以在主资源健康时返回主资源在主资源不健康时返回备用资源。AWS 文档说明Failover routing 可把流量路由到健康资源或在主资源不健康时切换到另一个资源。主备架构常见于企业官网、下载站、金融后台、API 服务和跨区域灾备。Route 53 负责 DNS 层切换真正的业务恢复还取决于数据库复制、文件同步、应用部署和切换演练。Weighted 和 Latency Routing 适合流量调度Weighted Routing 可以按指定比例把流量分配到多个资源适合灰度发布、AB 测试和多集群过渡。Latency Routing 适合多区域部署根据用户到 AWS 区域的延迟选择较合适的资源。AWS 文档列出的路由策略包括 latency、weighted、failover、geolocation、IP-based 和 multivalue answer 等。这些策略不能解决架构本身的问题。数据库未同步、源站未部署、证书未配置、缓存未规划时DNS 策略无法保证业务可用。Route 53 费用怎么看Route 53 费用主要来自 Hosted Zone、DNS 查询量、Health Check、域名注册和部分高级路由功能。AWS 官方说明Route 53 没有长期合约或最低承诺费用主要基于配置的 hosted zones 和 Route 53 回答的 DNS 查询数量。DNS 本身通常不是云账单的大头但 Health Check、多个 Hosted Zone、全球流量、CloudFront、ALB、WAF 和日志会一起形成长期成本。网站真实成本不能只看 EC2 实例DNS、CDN、负载均衡、流量和安全服务都应纳入预算。长期项目如果需要账号开通、域名解析、CloudFront、ALB、账单核对和基础技术支持可以通过AWS代理商协助处理。具体服务范围、充值赠金和适用产品应按账号类型、充值金额和实际规则确认。Route 53 常见配置错误注册商 NS 未切换域名如果在外部注册商购买创建 Route 53 Hosted Zone 后还需要把注册商处的 NS 服务器改成 Route 53 提供的 NS 记录。否则 Route 53 里的解析记录不会生效。CloudFront 域名和证书不匹配CloudFront 绑定自定义域名时证书必须覆盖该域名Alternate Domain Name 也必须添加到 distribution。只在 Route 53 里添加解析记录不能完成 CloudFront 域名绑定。TTL 设置过长TTL 控制 DNS 结果缓存时间。上线前或迁移期间TTL 不宜过长否则修改记录后需要等待更长时间才会在用户侧生效。稳定运行后可以根据业务情况设置更长 TTL减少解析查询和波动。A、CNAME、Alias 混用错误根域名不能使用普通 CNAME。CloudFront、ALB、S3 这类 AWS 资源应优先使用 Alias 记录。EC2 如果没有 Elastic IP不应直接把动态公网 IP 作为长期解析目标。Route 53 配置顺序正式配置 Route 53 时应先确认域名注册位置再创建 Hosted Zone随后切换 NS 服务器。源站为 EC2 时先配置 Elastic IP、安全组和 Web 服务源站为 CloudFront 时先配置证书和 Alternate Domain Name源站为 S3 时先确认 bucket 权限和访问方式源站为 ALB 时先确认监听器、目标组和健康检查。Route 53 的核心不是添加一条 DNS 记录而是把域名、源站、证书、缓存、安全和故障切换放在同一套上线流程里管理。域名解析配置正确用户才能稳定访问 AWS 上的应用源站、安全和证书没有配置完整即使 DNS 生效网站仍然可能无法正常访问。