![使用 AWS Cloudfront 监听非 443 端口的域](https://linux22.com/image/788946/%E4%BD%BF%E7%94%A8%20AWS%20Cloudfront%20%E7%9B%91%E5%90%AC%E9%9D%9E%20443%20%E7%AB%AF%E5%8F%A3%E7%9A%84%E5%9F%9F.png)
我们有一个www.domain.com
可解析为由 AWS EC2 Nginx 实例支持的 AWS 负载均衡器。
www.domain.com:8888
代理到 AWS 后端 Web 应用程序。
www.domain.com:443
从 EC2 的磁盘提供静态 html,但以下情况除外:
/app/
代理在 EC2 上运行的动态后端应用程序的路径- 404 响应也代理到相同的动态后端 EC2 用于自定义错误页面。
目标:能够直接从域下的 S3 存储提供我们的静态 html www.domain.com
(我们目前将 S3 静态文件同步到 Nginx 服务器的磁盘)。
考虑的选项:
具有故障转移源组的 Cloudfront 将很好地处理端口 443 流量。但是如果我们
www.domain.com
与 cloudfront 关联,显然什么都不会监听www.domain.com:8888
。如果我们有一个提供侦听器的负载均衡器,
www.domain.com
我们可以处理端口 443 和 8888 上的动态流量。但如何将 S3 作为负载均衡器目标组并不明显。我相信使用 S3 的 VPC 端点可以实现这一点。但这能处理 404 故障转移吗?(参考:https://aws.amazon.com/blogs/networking-and-content-delivery/hosting-internal-https-static-websites-with-alb-s3-and-privatelink/ )我们着手一个项目来转移
www.domain.com:8888
流量到alt.domain.com:443
,然后使用选项 1。但是,只要我们想保留到 的链接,www.domain.com:8888
我认为我们就不能将 cloudfront 作为 的目的地www.domain.com
。有一个前端 Nginx 代理,它将 8888 个流量代理到负载均衡器,将 443 个流量代理到 cloudfront。这会抵消使用 Cloudfront 的许多优点,因为强制客户端流量通过代理到达那里。此外,我们需要通过 Amazon ACM 之外的 Lets Encrypt 处理 SSL 终止。
选项 3 似乎是最干净的选项,但不会快速或轻易实现。所以我们正在寻找替代方案。
我们还应该考虑其他选择吗?