我们有一个aws s3存储桶，用于托管我们的动态图像，这些图像将由Web和移动应用程序通过https提取，并具有不同的大小（网址/宽度x高度/图像名称），即http://test.s3.com/200x300/image.png）。
为此，我们做了两件事：
1-实时调整大小：我的s3存储桶中有一个重定向规则，用于将404错误请求不存在的图像大小重定向到调用Lambda函数的API网关。 lambda函数获取原始图像并调整其大小，然后将其放置在与请求的大小匹配的存储桶中的文件夹中。
我们遵循了本文中的步骤： https://aws.amazon.com/blogs/compute/resize-images-on-the-fly-with-amazon-s3-aws-lambda-and-amazon-api-gateway/
2- HTTPS：我使用SSL证书创建了一个Cloudfront发行版，其起源是s3静态网站终结点
问题：使用cloudfront https域从s3请求图像总是会导致404错误，即使该特定图像大小已经存在，我的重定向规则也会重新定义API网关。
我尝试调试此问题没有运气。我检查了这些请求，从我看来，事情应该可以正常进行。
对于如何更好地调试此问题（以及在此处需要提供哪种日志）的提示，我将不胜感激。
谢谢
Sary
答案 0 :(得分：1)
此解决方案依靠S3为丢失的对象生成HTTP重定向，将浏览器重定向到API网关以调整对象的大小...并将其保存在原始URL。
问题有两个：
Cache-Control标头，并且Cache-Control时，CloudFront的默认行为是在内部缓存名为Default TTL的计时器的值的响应，该计时器的默认值设置为86400秒（24小时）。 / li>
这引起的问题是，即使现在存在该对象，CloudFront也会记住原始的重定向并将浏览器一次又一次地发送给它。
为“对象缓存”选择Customize而非Use Origin Cache Headers，然后将Default TTL设置为0（全部在CloudFront缓存行为设置中）将解决此问题，因为它没有配置CloudFront缓存原点不包含任何相关Cache-Control标头的响应。
有关更多背景信息：
What is Cloudfront Minimum TTL for?解释了最小/默认/最大TTL计时器以及它们的应用方式/时间。
Setting "Object Caching" on CloudFront解释了这些选项的令人困惑的UI标签，这很可能是在配置所有三个计时器之前的一个保留时间。