caching - Cloudfront私有(private)内容+签名url架构

Question

首先让我快速介绍一下我正在考虑迁移到 S3+Cloudfront 的系统的架构。

我们在树中排列了许多实体。树的叶子拥有一定数量的资源(具体为jpg图片)，通常在20-5000个左右，平均~200个。每个资源都有一个唯一的 URL，该 URL 通过我们今天的托管设置提供服务。

我可以将所有这些资源转移到 S3，在其上设置 Cloudfront 并完成。要是我不用保护资源就好了。

大多数实体都是公开的(即~99%)，其余实体通过多种方式之一(登录、IP、时间等)受到保护。一旦实体受到保护，所有资源也必须受到保护，并且只有在执行有效授权后才能访问。

我可以通过创建两个 S3 存储桶来解决这个问题 - 一个是私有(private)的，一个是公共(public)的。对于私有(private)内容，我会在用户获得授权后生成签名的 Cloudfront URL。然而，一个实体的状态可能会任意地从公共(public)状态变为私有(private)状态，反之亦然。系统管理员可能会更改实体树任何级别的实体，从而导致整个树发生级联更改。一项更改可能会导致约 2 万个实体发生更改，乘以 200 个资源，这将影响 400 万个资源。

我可以在后台运行一项服务来监视状态更改，但这会很麻烦，并且更改 400 万个 S3 项目的 ACL 将需要相当长的时间，而在这种情况发生时，我们要么拥有不 protected 私有(private)内容，要么我们必须为其生成签名 URL 的公共(public)内容。

另一种可能性是默认将所有资源设为私有(private)。对于向实体发出的每个请求，我们将生成一个自定义策略，为该特定用户授予对该实体中包含的所有资源的访问权限(通过在自定义策略中使用通配符 url)。这需要为每个访问者、每个实体创建一个策略——但这不是问题。但是，这意味着我们的用户无法再缓存任何内容，因为每个新 session 的 URL 都会发生变化。虽然对于私有(private)内容来说这不是问题，但如果我们放弃对 99% 的公共(public)实体的所有缓存，那就太糟糕了。

另一种选择是将所有内容保密并对私有(private)实体使用上述方法。对于公共(public)实体，我们可以为每个公共(public)实体生成一个所有用户都可以共享的自定义策略。如果我们将生命周期设置为 6 小时并确保在 5 小时后生成新策略，则将确保用户的策略生命周期至少为一小时。这样做的优点是可以缓存长达 6 小时，同时允许私有(private)内容在状态更改后可能公开长达 6 小时。这是可以接受的，但我不确定它是否值得(尝试计算当前请求的缓存/命中率)。显然，我们可以调整 5/6 小时边界以启用更长/更短的缓存，但代价是更长/更短地暴露于私有(private)实体。

有人部署过类似的解决方案吗？我忽略了哪些可能有用的 AWS 功能？有什么总体意见吗？

Answer 1

根据大众的要求，我自己回答这个问题。

收集相关指标并进行一些计算后，我们最终得出结论，我们可以减少缓存，但 CloudFront 更快的对象服务速度可以抵消这一影响。实际实现详见我的博客:How to Set Up and Serve Private Content Using S3 and Amazon CloudFront