amazon-web-services - 如果找不到文件，请禁用 Cloudfront 缓存

Question

我在 S3 存储桶前面创建了一个 Cloudfront 发行版，它带有 RoutingRule 以在未找到请求的文件时重定向到 lambda 函数。我正在使用它来调整图像大小。

所需流量:

向 Cloudfront 请求文件

在 Cloudfront 检查 S3 中找不到文件

S3 中找不到文件重定向到 lambda 函数

Lambda 将找到原始文件，调整其大小并重定向回 Cloudfront url。

s3 网站上的重定向规则集:

<RoutingRules>
  <RoutingRule>
    <Condition>
      <KeyPrefixEquals/>
      <HttpErrorCodeReturnedEquals>404</HttpErrorCodeReturnedEquals>
    </Condition>
    <Redirect>
      <Protocol>https</Protocol>
      <HostName>mylambda.execute-api.us-east-1.amazonaws.com</HostName>
      <ReplaceKeyPrefixWith>/?key=</ReplaceKeyPrefixWith>
      <HttpRedirectCode>307</HttpRedirectCode>
    </Redirect>
  </RoutingRule>
</RoutingRules>

当 lambda 函数重定向回原始 url 时，我在第 4 步遇到问题
Cloudfront 缓存了 404？并且来自 S3 的路由规则再次重定向到导致循环的 lambda 函数。

我确认 lambda 函数生成了该文件。

如果我使 Cloudfront 上的文件无效，我会成功地看到它从 S3 提供)

我尝试将 0 TTL 添加到 404 错误页面，但没有帮助。



重定向规则返回 307 状态代码 [Temporary Redirect] .但我不知道如何在此设置 0 TTL。我在 Cloudfront 自定义错误响应页面上找不到该选项。



根据 this article . 307 被缓存。需要为它设定一个规则......某处。

这是 RoutingRules on AWS S3 Static website hosting 上的后续问题

我感谢您的帮助。

更新:
1. 删除了 S3 上的 RoutingRule
2. 为 Cloudfront 发行版(API 网关)添加了一个新来源



lambda 函数现在返回

    return {
        statusCode: "200",
        body: "image converted",
    };

检查 Cloudwatch 日志我没有看到 lambda 函数被调用，当我转到 https://myCloudfront.cloudfront.net/photos/resized/test.jpg 时

我只看到一个普通的 404



我还为 404 添加了一个带有 0 TTL 的自定义错误页面

好消息是，如果我去 api 网关传递 key=/photos/resized/test.jpg
然后去 https://my.cloudfront.net/photos/resized/test.jpg有用。它正确读取图像。

我认为问题在于未触发 api 网关调用的故障转移。

Answer 1

当然，您可以使用 Lambda@Edge Origin Response 触发器来修改响应并设置所需的 header 。从某种意义上说，这将是“最正确”，因此也是“最理想”的解决方案，但仅在理论上，因为它引入了不必要的成本和复杂性。

默认 TTL 是 CloudFront 在内部使用的值，如果没有 Cache-Control找到响应头...因此，您可以将其设置为 0 并包含正确的 Cache-Control创建 S3 对象时使用 header ，以便除了重定向之外不会使用默认 TTL。我不喜欢这个是没有标题坚持浏览器也不缓存重定向。

但是您实际上并不需要在此处将重定向返回到浏览器。您根本不需要重定向。

With CloudFront’s Origin Failover capability, you can setup two origins for your distributions - primary and secondary, such that your content is served from your secondary origin if CloudFront detects that your primary origin is unavailable.

https://aws.amazon.com/about-aws/whats-new/2018/11/amazon-cloudfront-announces-support-for-origin-failover/

在这里，“不可用”这个词不必要地含糊不清，因为此功能的作用不止于此，而且它会做您想做的事。要设置触发源“故障转移”的内容...

You can choose any combination of the following status codes: 500, 502, 503, 504, 404, or 403.

https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/high_availability_origin_failover.html#concept_origin_groups.creating

所以只需要正常的存储桶行为就足够了，不需要重定向规则。

请注意，使用此设置，最终响应是 CloudFront 唯一可以缓存的内容——无论该响应来自主要 (S3) 还是辅助(通过 API 网关的 Lambda)源——因此这消除了 transient 响应的问题被缓存。

另请注意，尽管使用了“故障转移”一词，但 CloudFront 并未维护源状态的概念模型，因此每个请求独立存在，即使在其他请求“失败”时也会转到主要源。