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

Question

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

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

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

我们已尝试“未成功”使用以S3来源为后盾的Cloudfront。要将SPA与Cloudfront和HTML5（基于非哈希）的路径路由一起使用，必须指定CustomErrorResponses为http状态代码404和403提供index.html文件。尽管这可以正确地为index.html文件提供服务，但响应始终以x-cache: Error from cloudfront标头结尾。这意味着在将index.html作为默认错误文档提供服务之前，cloudfront花了一些时间在S3源中查找HTML5路径。结合使用Cloudfront使用源响应Lambda @ Edge函数添加自定义http标头这一事实，可以为这些非缓存的响应增加延迟。]

[在美国某些地区，我们看到此文件的请求需要500-1000毫秒。例如，在弗吉尼亚州托管了一个云分布，并在美国中部设有一个查看器，请求似乎从查看器路由到最近的边缘位置（有时更向西），然后往返于弗吉尼亚州（托管S3来源） ，最后从边缘位置返回到查看器。

我们还尝试使用Lambda @ Edge未能成功地将错误响应正文和标头一起缓存。

我们还没有尝试过的是：

1. Application Load Balancer指向lambda函数（带有或不带有API网关）
2. Application Load Balancer直接指向EC2实例。

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

[试图找到为AWS中的单页应用程序提供index.html文件的最高效方法。主要要求是：AWS服务必须能够从通配符域提供文件...

Answer 1

此解决方案是针对Cloudfront发行版定义DefaultCacheBehavior（*）之外的其他缓存行为。