让我先简单介绍一下我正在考虑迁移到S3 + Cloudfront的系统架构。
我们在树中有许多实体订单。树的叶子有许多资源（具体的jpg图像），通常在20-5000的数量级，平均为~200。每个资源都有一个唯一的URL，通过我们今天的colo设置提供。
我可以将所有这些资源转移到S3，在此基础上设置Cloudfront并完成。如果只是我没有保护资源。
大多数实体都是公共的（即约99％），其余的以多种方式（登录，IP，时间等）保护。一旦实体受到保护，所有资源也必须受到保护，并且只能在执行有效授权后才能访问。
我可以通过创建两个S3存储桶来解决这个问题 - 一个是私有，一个是公共存储。对于私人内容，我会在用户获得授权后生成签名的Cloudfront URL。但是，实体的状态可能会随意地从公共状态变为私有状态，反之亦然。系统管理员可能会在实体树的任何级别更改实体，从而导致整个树中的级联更改。一个变化可能导致~20k实体的变化，乘以200个资源，这将影响400万个资源。
我可以在后台监控状态更改中运行服务，但这很麻烦，更改400万个S3项目的ACL需要相当长的时间，而当发生这种情况时，我们要么会有未受保护的私有内容，要么我们必须为其生成签名网址的公开内容。
另一种可能性是默认情况下将所有资源设为私有。在对实体发出的每个请求中，我们将生成一个自定义策略，为该特定用户授予对实体中包含的所有资源的访问权限（通过在自定义策略中使用通配符URL）。这需要为每个实体创建一个策略 - 这不会是一个问题。但是，这意味着我们的用户无法再缓存任何内容，因为每个新会话的URL都会更改。虽然私有内容不是问题，但是对于99％的公共实体而言，我们会放弃所有缓存。
另一种选择是将所有内容保密，并将上述方法用于私人实体。对于公共实体，我们可以为每个公共实体生成一个所有用户都可以共享的自定义策略。如果我们将生命周期设置为6小时并确保在5小时后生成新策略，则将确保用户的策略生命周期至少为一小时。这样做的好处是可以实现长达6小时的缓存，同时允许私有内容在状态更改后最多可以公开6个小时。这是可以接受的，但我不确定它是否值得（尝试计算当前请求的缓存/命中率）。显然，我们可以调整5/6小时的边界以启用更长/更短的缓存，但代价是更长/更短的私有实体曝光。
是否有人部署了类似的解决方案？我忽视的任何AWS功能都可能有用吗？一般的评论吗？
答案 0 :(得分：17)
根据受欢迎的要求，我自己回答了这个问题。
在收集相关指标并进行一些计算之后，我们最终得出的结论是，我们可以忍受更少的缓存，并被CloudFront更快的对象服务速度所抵消。我的博客详细介绍了实际的实施：How to Set Up and Serve Private Content Using S3 and Amazon CloudFront
答案 1 :(得分：0)
同一个存储桶中的资产可以有不同的隐私政策。 因此，您可以在同一个存储桶中拥有公共和私有资产。
在上传时，只需设置隐私设置。
然后只需在URL上签名即可访问私有资产。