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