让我先快速介绍一下我正在考虑迁移到 S3+Cloudfront 的系统架构。
我们在树中有许多实体顺序。树的叶子有很多资源（具体是jpg图片），一般在20-5000左右，平均200左右。每个资源都有一个唯一的 URL，通过我们今天的 colo 设置提供。
我可以将所有这些资源转移到 S3，在此基础上设置 Cloudfront 并完成。如果我不必保护资源就好了。
大多数实体是公开的（即~99%），其余实体以多种方式之一（登录名、IP、时间等）受到保护。一旦实体受到保护，所有资源也必须受到保护，并且只有在执行有效授权后才能访问。
我可以通过创建两个 S3 存储桶来解决这个问题——一个是私有的，一个是公共的。对于私有内容，我会在用户获得授权后生成签名的 Cloudfront URL。但是，实体的状态可能会任意从公共变为私有，反之亦然。系统管理员可能会在实体树的任何级别更改实体，从而导致整个树的级联更改。一项更改可能会导致约 20k 个实体发生更改，乘以 200 个资源，这将影响 400 万个资源。
我可以在后台运行一个服务来监控状态变化，但这会很麻烦，并且更改 400 万个 S3 项目的 ACL 需要相当长的时间，而在这种情况下，我们要么拥有不受保护的私人内容，要么拥有不受保护的公共内容我们必须为其生成签名的 URL。
另一种可能性是默认情况下将所有资源设为私有。在向实体发出的每个请求中，我们将生成一个自定义策略，为该特定用户授予对实体中包含的所有资源的访问权限（通过在自定义策略中使用通配符 url）。这将需要为每个访问者、每个实体创建一个策略——不过这不是问题。但是，这意味着我们的用户无法再缓存任何内容，因为每个新会话的 URL 都会更改。虽然对于私有内容来说不是问题，但对于我们来说，放弃对大约 99% 的公共实体的所有缓存会很糟糕。
另一种选择是保持所有内容的私密性并将上述方法用于私人实体。对于公共实体，我们可以为每个公共实体生成一个所有用户都将共享的自定义策略。如果我们将生命周期设置为 6 小时并确保在 5 小时后生成新策略，则用户将确保至少一小时的策略生命周期。这具有启用缓存长达 6 小时的优势，同时允许私有内容在状态更改后可能长达 6 小时公开。这是可以接受的，但我不确定它是否值得（尝试计算当前请求的缓存/命中率）。显然，我们可以调整 5/6 小时边界以启用更长/更短的缓存，但代价是更长/更短地暴露于私人实体。
有没有人部署过类似的解决方案？我忽略的任何可能有用的 AWS 功能？一般有什么意见吗？