使用AWS Route53内部区域与通配符证书实现跨VPC内部SSL路由是否可行？

你的这个方案整体是可行且合理的，完全能通过AWS的服务实现VPC内部及跨VPC的安全SSL通信，我结合实际使用经验给你拆解每个步骤的合理性，再补充一些容易踩坑的细节：

一、Route53内部私有区域的合理性 #

• 你创建的site.internal私有区域完全适配内部服务路由需求：这类区域的DNS记录仅对关联的VPC生效，不会暴露到公网，完美隔离内部域名和公网域名体系。
• 要实现跨VPC解析，记得在私有区域的「关联VPC」设置里，把需要访问该域名的其他VPC添加进去——这是跨VPC解析的前提，不然其他VPC的实例根本找不到这个域名的记录。

二、CNAME指向ALB的正确性 #

• 把api.site.internal（或者直接配置*.site.internal的CNAME）指向内部ALB是标准操作，只要你的ALB设置为内部类型，流量就会完全在VPC内部流转，不会走公网出口，符合内部通信的安全要求。
• 注意：如果ALB是公网类型，虽然也能解析，但流量会绕公网一圈，既不安全也不高效，所以一定要选内部ALB。

三、通配符证书的关键注意事项（核心坑点） #

这部分是你方案里最需要注意的地方，直接关系到SSL通信是否能正常工作：

• 不能用ACM的公证书：因为site.internal是私有域名，ACM公证书的验证流程（DNS/HTTP验证）需要公网可访问，而私有域名在公网查不到，所以肯定验证失败。
• 正确的证书获取方式：你需要用**AWS Certificate Manager私有证书颁发机构（ACM PCA）**来生成*.site.internal的通配符证书，或者自己搭建私有CA。ACM PCA的优势是可以和Route53私有区域自动集成，域名验证一键完成，不用手动操作。
• 证书信任问题：跨VPC的实例默认不会信任ACM PCA或私有CA颁发的证书，所以你必须把CA的根证书导入到这些实例的信任存储中：
  • Linux系统：把根证书放到/etc/pki/ca-trust/source/anchors/目录，然后执行update-ca-trust命令更新信任列表。
  • Windows系统：通过「证书管理器」把根证书导入到「受信任的根证书颁发机构」存储中。
    只有这样，curl、浏览器或者其他客户端工具才不会报“SSL证书不受信任”的错误。

四、跨VPC通信的额外前提 #

• 确保VPC之间已经通过VPC对等连接、中转网关或者Transit Gateway打通了网络，否则即使DNS解析正常，流量也无法到达目标ALB——这是很多人容易忽略的点。
• 配置ALB的安全组，只允许来自关联VPC内部的IP段访问，进一步缩小攻击面，提升内部服务的安全性。

测试建议 #

1. 先在同一VPC内的实例执行curl -v https://api.site.internal，确认DNS解析正常、证书验证通过、能正常返回服务响应。
2. 再到跨VPC的实例重复测试，验证跨VPC的解析和通信是否正常。

内容的提问来源于stack exchange，提问作者donkeyx