我们有一个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 似乎是最干净的选项，但不会快速或轻易实现。所以我们正在寻找替代方案。
我们还应该考虑其他选择吗？