我们在 amazon S3 上托管视频并使用 cloudfront 来传送视频。以下是上个月的数据：
从云端到最终用户的总流量为 4.2 TB。其中 4 TB 在欧洲，其余主要在美国。
这花费了我们 512 美元。一切正如预期。
此外，从 S3 到边缘位置的传输成本约为 1 TB。= 成本 115 美元
这是转移给最终用户的成本的 22.4%，占综合成本的 18%。我想知道，这正常吗？我觉得有点多。
我们在 S3 中存储了 280 GB 的视频，分布在大约 20000 个视频上。我们的大部分流量来自新鲜视频。当月排名前 100 的视频占总流量的约 80%。
我只是觉得边缘位置可能下载了太多不必要的视频，而且点击量很少。然后这些视频被删除，之后又被请求，我们又将视频下载到边缘服务器。
- 这个比例正常吗？或者至少与其他人的经历有些接近吗？
- 我可以以某种方式告诉 cloudfront 在开始缓存文件之前设置一个阈值或其他内容吗？例如：在您看到您所在位置附近一天内有 x 次下载之前，不要缓存此文件。
- 如果上述方法不可行，还有其他方法可以实现同样的效果吗？不要通过 cloudfront 提供访问频率较低的文件，直接转到 S3。我觉得这可能是一个问题，因为我无论如何都会使用 cloudfront 的流式传输功能。
我没有更改 TTL，因此我假设它是标准的 24 小时。如果我增加它，这无论如何都不会改变任何东西，因为如果文件没有改变，cloudfront 将不会再次下载该文件（他们不会）。
问题是文件超出缓存。
答案1
我会直接从 S3 提供不太受欢迎的视频。YouTube 不会在其 CDN 上提供视频，除非某个视频的观看次数达到 300 次。我会跟踪最后 x 次视频观看的时间，并将列表存储在 Redis 之类的东西中，如果倒数第 x 次观看是在某个时间范围内，则才从 CloudFront 提供视频。