在所有 aws 服务中，为单页应用程序提供 index.html 的最高效方法是什么？

Question

试图找到在 AWS 中为单页应用程序提供 index.html 文件的最高效方式。主要要求是：

1. AWS 服务必须能够从通配符域（例如*.domain.com.
2. SPA 宁愿不使用基于哈希的路由，这意味着它https://foo.domain.com/path/to/resource优于像https://foo.domain.com/#/path/to/resource.

直接从 lambda 支持的 API 网关提供文件似乎不可行，因为这种方法不满足自定义通配符域要求。

我们尝试“失败”以使用由 S3 源支持的 Cloudfront。要将 SPA 与 cloudfront 和 HTML5（非基于哈希）路径路由一起使用，您必须指定CustomErrorResponses为 http 状态代码404和403. 虽然这可以正确地为 index.html 文件提供服务，但响应总是以x-cache: Error from cloudfront标题结尾。这意味着在将 index.html 作为默认错误文档提供之前，cloudfront 需要时间在 S3 源中查找 HTML5 路径。将此与 Cloudfront 使用源响应 Lambda@Edge 函数添加自定义 http 标头这一事实相结合，会增加这些非缓存响应的延迟。

在美国的某些地区，我们看到对该文件的请求需要 500-1000 毫秒。例如，对于在弗吉尼亚州托管的云前分发和在美国中部的查看器，请求似乎从查看器路由到最近的边缘位置（有时更远的西部），然后往返于弗吉尼亚州（托管 S3 源的地方） ，然后最终从边缘位置返回到查看器。

我们还尝试使用 Lambda@Edge 缓存错误响应正文和标头，但未成功。

我们还没有尝试的是：

1. 应用程序负载均衡器指向一个 lambda 函数（有或没有 API 网关）
2. Application Load Balancer 直接指向一个 EC2 实例。

在我们决定尝试这些更昂贵的托管选项之前，请询问社区是否有办法根据我们的要求使 cloudfront 的性能更高。如果不是，我希望 EC2 有可能比 ALB/lambda 性能更高，因为 EC2 不应该遭受冷启动？这是一个准确的假设吗？