CloudFront 源请求自定义 S3 逻辑源，是否仍在使用边缘位置缓存数据？

Question

我已经设置了一个 lambda@edge 函数，它动态决定使用哪个桶（来源）从（uri..）获取 s3 对象。

我想确保我正在做的事情不会首先破坏使用 CloudFront 的全部目的，这意味着，允许将原始内容（s3 存储桶）缓存在边缘，以便用户可以获得他们想要的东西从离他们最近的边缘位置快速请求。

我正在关注这个流程：

'use strict';

 const querystring = require('querystring');
 
 exports.handler = (event, context, callback) => {
     const request = event.Records[0].cf.request;
 
     /**
      * Reads query string to check if S3 origin should be used, and
      * if true, sets S3 origin properties.
      */
 
     const params = querystring.parse(request.querystring);
 
     if (params['useS3Origin']) {
         if (params['useS3Origin'] === 'true') {
             const s3DomainName = 'my-bucket.s3.amazonaws.com';
 
             /* Set S3 origin fields */
             request.origin = {
                 s3: {
                     domainName: s3DomainName,
                     region: '',
                     authMethod: 'none',
                     path: '',
                     customHeaders: {}
                 }
             };
             request.headers['host'] = [{ key: 'host', value: s3DomainName}];
         }
     }
     
    callback(null, request);
};

这只是我正在做的一个例子。（从 https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-examples.html#lambda-examples-content-based-S3-origin-request-trigger 中找到）我已经设置了一个 Origin-Request 触发器，它运行我的 lambda@adge 函数将决定使用哪个桶作为源。

当 lambda 函数在 Origin-Request 触发器中获得运行时设置存储桶 (s3DomainName)，只要该存储桶在 CloudFront 中设置为源之一已经，CloudFront 还能从缓存中提供文件吗？或者我是否像 cod 示例中那样通过设置原始存储桶来绕过使用 CloudFront 的整个过程？

Answer 1

I want to make sure that what I am doing does not defeat the whole purpose of using CloudFront

这并没有违背初衷。这按预期工作，并且响应仍将使用相同的规则进行缓存，如果此存储桶是静态配置的来源并且没有触发器就位。

只有在缓存未命中时才会触发源请求触发器——在检查缓存并且请求的资源不存在之后，CloudFront 得出需要将请求转发到源服务器的结论。 Origin Request 触发器会导致 CloudFront 暂时暂停其处理，同时您的触发器代码会评估并可能修改请求，然后再将控制权返回给 CloudFront。 Changing/setting 触发器中的源服务器修改了 CloudFront 随后将发送请求的目标，但它对是否缓存响应 can/will 或以其他方式更改 CloudFront 在响应从源服务器到达。而且，如果在新请求到达时缓存中已经有合适的响应可用，则触发器根本不会触发，因为它无事可做。

as long as that bucket is setup in CloudFront as one of the origin already

这实际上不是必需的。 具有 publicly-accessible 内容的任何 S3 存储桶都可以在源请求触发器中指定为源服务器，即使它不是分配上配置的源之一。

如果需要这样的触发器并且您的存储桶需要身份验证并且正在使用 KMS-based 对象加密，则还有其他规则和复杂性会起作用，但在那些情况下，仍然不会产生影响这种关于缓存的设计——只是一些来实际在 CloudFront 和存储桶之间进行身份验证，因为 Origin Access Identity（通常用于允许 CloudFront 向 S3 验证自身）不足以满足此用例。

它与 Origin Request 触发器和这个问题的要点没有直接关系，但值得注意，因为你正在使用 request.querystring：确保你理解 the concept of the cache key，这是请求属性的组合CloudFront 在确定是否可以使用给定的缓存对象来满足未来请求时将使用的。如果两个相似的请求导致不同的缓存键，那么 CloudFront 不会将它们视为相同的请求，并且一个请求的响应不能用作另一个的缓存响应，即使您的期望可能不是这样，因为这两个请求是对于同一个对象。 Origin Request 触发器无法更改请求的缓存键，无论是有意还是无意，因为它已经在触发器触发时由 CloudFront 计算。

meaning, allowing origins contents (s3 buckets) to be cached at edges so that users can get what they request fast from the closest edge location to them

啊。写完以上所有内容后，我现在突然想到，也许您的问题实际上可能源于我偶尔看到人们对 CloudFront 和 S3 如何交互的假设。这是一个可以理解的假设，但事实证明是不准确的。当存储桶配置为 CloudFront 源时，没有任何机制可以主动将存储桶的内容推送到 CloudFront 边缘。如果您认为这是在将存储桶配置为 CloudFront S3 来源时发生的事情，那么这个问题具有不同的意义，因为您实质上是在询问来自这些不同存储桶的内容是否仍会到达CloudFront 符合预期……但 CloudFront 就是我所说的“pull-through CDN”。只有当有人通过该边缘请求对象时，对象才会存储在给定边缘的缓存中——它们在作为初始请求的结果被获取时被缓存，而不是之前。因此，您的设置只是更改了 CloudFront 获取给定对象的位置。系统的其余部分与往常一样工作，CloudFront 按需提取和缓存内容。

CloudFront 源请求自定义 S3 逻辑源，是否仍在使用边缘位置缓存数据？

CloudFront origin request custom S3 logic origin, is it still using edge location cached data?

amazon-web-services

aws-lambda

amazon-cloudfront