事情就是这样。现在我有一个电子商务网站，人们可以在其中为他们的产品发送大量图片。所有图像都存储在 Amazon 的 S3 中。当我们需要缩略图或其他东西时，我会检查 S3 是否有可用的。如果没有，我处理一个并将其发送到 S3 并在浏览器上显示。每个不同大小的缩略图都存储在 S3 中，并且在每次请求时检查缩略图的可用性是一种消耗金钱。恐怕一旦网站开始受到更多关注（如果它得到...），我会付出很多。
考虑替代方案时，我正在考虑仅将原始图像保留在 S3 中，并在每次请求时动态处理图像。我想这样我会通过 CPU 使用率，但我还没有做任何基准来看看我能走多远。问题是我不会花钱提出请求并在 S3 上存储更多图像，而且我可以将所有内容缓存在用户的浏览器上。我知道这样做并不安全，所以这就是我在这里提出这个问题的原因。
你怎么看？你觉得我怎么能解决这个问题？
我会在上传时调整大小并将所有版本存储在 S3 中。
例如，如果您有一个更大的图像（1200x1200 ~200kb）并创建 3 个调整大小的版本（300x300、120x120 和 60x60），您只需添加大约 16% 或 32kb（对于我的测试图像，YMMV）。假设您需要存储一百万张图像；大约多出 30 GB，或每月额外增加 4.5 美元。据报道，Flickr 拥有 20 亿张图片（在 2007 年），每月额外增加约 9000 美元，如果你有那么大，也不算太糟糕。
另一个主要优势是您将能够使用亚马逊的 CloudFront。
如果您要从 S3 代理到您的客户端（听起来就像您正在做的那样），请考虑两个优化：
“图像包”将减少 PUT/GET/DELETE 操作的数量，这些操作在 S3 中不是免费的。如果您有 4 个图像尺寸，您将减少 4 个。
缓存将进一步减少 S3 流量，因为我认为工作流程通常是查看缩略图 -> 单击它以获得更大的图像。
最重要的是，您可以实现一个“热图像”缓存，该缓存会主动推送到您的 Web 节点，以便在您使用集群时对其进行预缓存。
另外，我不推荐使用 Slicehost<->S3。过境费用会杀了你。你真的应该使用 EC2 来节省大量带宽（钱！！）。
如果您不是代理，而是将图像的 S3 URL 交给您的客户端，那么您肯定需要预处理所有图像。然后您不必检查它们，只需将 URL 传递给您的客户端。
每次重新处理图像都是昂贵的。您会发现，如果您可以假设所有图像都已调整大小，那么您的 Web 节点上的工作量就会减少，并且一切都会加快。尤其如此，因为您没有触发多个 S3 请求。
保留以下内容的本地缓存：
然后在这两种情况下，您都有本地参考。如果图像不在本地缓存中，您可以检查本地缓存以查看它是否在 S3 中。为您最受欢迎的项目节省 S3 流量，并在检查 S3 以查找不在本地缓存中的项目时节省延迟。