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