与CloudFront结合使用时，AWS S3标准不频繁访问与减少冗余存储类别？

Question

我正在使用CloudFront缓存和分发当前存储在标准存储类S3中的所有缩略图。 由于CloudFront仅缓存原始数据并且每24小时访问它们，因此使用比标准更便宜的存储类是有意义的：标准不常访问（IA）或减少冗余（RR）。 但我不确定哪一种更合适且更具成本效益。

Standard-IA拥有最便宜的存储空间（比标准类便宜58％，比RR便宜47％），但比标准和RR要贵60％。 但是，在计算成本时，存储在Standard-IA类中的128kb以下的所有文件都会舍入到128kb，这适用于我的大多数缩略图。

同时，RR级的存储仅比标准级便宜20％，但其请求成本比标准IA低60％。

我不确定哪一个在实践中最具成本效益，并且会感谢任何有经验的人都能提供一些反馈。

Answer 1

你的问题的前提是有问题的。 在选择S3存储类时，CloudFront 可能会将对象缓存一段时间的事实实际上没什么关系。

REDUCED_REDUNDANCY有时候更便宜REDUCED_REDUNDANCY 因为S3将您的数据存储在较少的物理设备上 ，在某种程度上降低了可靠性以换取较低的价格......并且在发生故障时，对象在统计上更有可能被S3丢失。 如果S3因冗余减少而丢失对象，CloudFront将在某个时刻开始返回错误。

选择此存储类的决定性因素是对象是否易于替换。

减少冗余存储（RRS）是一种Amazon S3存储选项，通过以比Amazon S3标准存储更低的冗余级别存储非关键，可重现的数据，使客户能够降低成本。 它提供了一种经济高效的高可用性解决方案，用于分发或共享在其他地方持久存储的内容，或用于存储缩略图，转码媒体或其他易于复制的处理数据。

https://aws.amazon.com/s3/reduced-redundancy/

由于不同原因， STANDARD_IA （不频繁访问）成本较低：存储节省被检索费用抵消。 如果每月下载一次以上的对象，则合并费用将超过STANDARD的费用。 它适用于不经常访问的对象。 由于CloudFront具有多个边缘位置，每个边缘位置都有自己独立的缓存，²对象是否“当前存储在”CloudFront中不是一个简单的是/否答案的问题。 通过指定大型Cache-Control: max-age值也无法“游戏系统”。 CloudFront对其缓存存储不收取任何费用，因此只有在指定的到期时间之前才能从缓存中清除对象是明智的。 实际上，轶事观察证实了文档的内容，即由于相对缺乏“流行度”，对象有时会从CloudFront中清除。

选择此存储类的决定性因素是增加的数据传输（检索）费用是否足够低，以证明它们抵消的存储费用节省是合理的。 除非预期每月下载的对象少于一次或两次，否则此存储类不会节省成本。

标准/不经常访问应该保留给你真正不常需要的东西，比如tarball和数据库转储以及在第一次访问后不太可能被审查的图像，例如（借用我的世界的一个例子）证明 - 购买/收据由客户扫描并提交以获得折扣索赔。 退税一旦获得批准，我们就不太可能再次查看该收据，但我们确实需要将其存档。 您好，Standard_IA。 （请注意，S3在文件存储30天后，使用存储桶上的生命周期策略）自动执行此操作。

标准 - IA非常适合长期文件存储，来自同步和共享的旧数据，备份数据和灾难恢复文件。

https://aws.amazon.com/s3/faqs/#sia

附注：一种节省一些存储成本的替代机制是在存储之前gzip -9内容，并设置Content-Encoding: gzip 。 我已经使用S3多年来一直这样做了，我还在等待我的第一张支持票来报告无法处理它的浏览器。 即使是据称已被压缩的内容（例如.xlsx电子表格）也会缩小一点，而您挤出的每个字节意味着存储和下载带宽费用会略微降低。

从根本上说，如果您的内容可以轻松更换，例如您仍然拥有原始内容的已调整大小的图片......或者可以从源数据轻松重新运行的报告......或其他地方备份的内容（AWS基本上始终是我的首选云端服务，但我的S3资产备份存储在另一个云提供商的存储服务中，例如）...然后减少冗余是一个不错的选择。

---

REDUCED_REDUNDANCY有时 在 2016年底仅在某些地区 更便宜 。在此之前，它的价格低于STANDARD ，但由于11月宣布的S3价格下降导致价格具有竞争力的奇怪世界奇怪的怪癖， 2016 ，在一些AWS地区， STANDARD存储类是现在略小于昂贵REDUCED_REDUNDANCY （“RRS”）。 例如，在us-east-1中，标准从0.03美元/ GB降低到0.023美元/ GB，但RRS保持在0.024美元/ GB ...... 没有明显的理由在该地区使用RRS。 定价页面的结构给人的印象是，RRS可能不再被AWS视为当前的产品。 实际上，它比STANDARD_IA和GLACIER都要陈旧。 它不太可能完全被弃用或消除，但如果它不再是其主要产品之一，它们可能不会倾向于将其成本降低到与其他存储类别对齐的程度。

² “CloudFront有多个边缘位置，每个都有自己独立的缓存”仍然是技术上真实的陈述，但CloudFront悄然开始推出，然后在2016年底宣布了一些重大的架构变化，引入了区域边缘缓存 。 从某种意义上说，现在，全球边缘缓存是独立的“不太真实”。 它们仍然是，但它没有什么区别，因为CloudFront现在是一个双层网络，全局（外层）边缘节点有时从区域（内层）边缘节点获取内容，而不是直接从原点获取内容服务器。 这应该会增加对象被认为是“在”缓存中的可能性的影响，因为外层中的缓存未命中可能会被内层转换为命中，这也被报告具有更多可用缓存存储空间比部分或全部外层。 从外部观察中尚不清楚这对S3起源的命中率有多大影响，因为文件表明区域边缘不用于S3（仅限定制起源），但似乎不太清楚，这普遍适用特别是随着Lambda @ Edge的推出。 这可能很重要，但在撰写本文时，我认为它不会对我对此处提出的问题的答案产生任何实质性影响。

Answer 2

由于CloudFront仅缓存原始文件并且每24小时访问它们

如果需要，您实际上可以使CloudFront缓存更长时间。 您只需要在设置Cache Control标头的对象中添加元数据，并根据S3文档指定最长100年的年龄。 您只需设置一个以秒为单位的max-age ，所以如果您真的希望将对象缓存100年：

Cache-Control: max-age=3153600000

至于你关于SIA与RR的主要问题，你几乎可以找到两者之间的所有差异。 这只是计算使用一个与另一个的成本的问题。 您只需要运行一些计算并查看成本估算。 如果您在128K下有100个缩略图，那么SIA将向您收取100 * 128K字节的费用，而RR只会向您收取这100个缩略图总大小的费用。 同样，如果您在CloudFront中设置了相当高的缓存超时，那么您每天只能看到来自S3的10次提取，因此SIA会向您收取每天10 * 128K字节的检索费，而RR只会向您收取大小的费用这10个缩略图中。

根据缩略图的大小和数量以及您预期的流量使用一些实数，应该很容易得出成本估算值。

仅供参考，您可能还想看看其中一些幻灯片和/或这些视频 。 这些都来自亚马逊的re：Invent会议，这些链接应该在这些会议上为您提供特定于S3的演示。