我们每天执行 3 次重复的自动化任务，将大型数据库的完整备份从 EU S3 存储桶下载并还原到我们在美国的本地服务器。这是在数据库本身很小并且传输时间/成本最小的时候设置的。由于我们无法控制的因素，数据库现在是 70+ GB。每 3 天进行一次完整备份，每 8 小时进行一次差异备份。我们每天 3 次的自动化任务需要提取最新的完整和差异的 .bak 文件。在白天的下载速度约为 120 Mbps 时，从 S3 中提取它可能需要几个小时，并且以每年 365 天、每天 3 倍的速度从 S3 传输 0.09 美元/GB，仅传输成本是非琐碎的。
似乎有很多选择可以最大限度地降低成本和运行时间。
- 我们可以在本地缓存完整的 .bak 文件，并在从 EU S3 存储桶中提取该文件之前检查该文件是否已在本地存在。每 3 天只有 1 个完整的 .bak 文件，但有 9 次恢复，因此其中 9 次恢复中有 8 次可以使用缓存副本。
- 我们还可以更改我们的备份策略，以减少完全备份的频率，从而减少完整的 .baks 下载频率。
- 从 S3 到同一区域内的另一个 AWS 服务的传输成本是免费的，因此，如果我们能够将此数据库恢复到欧盟的 EC2 实例，那就太好了，但使用恢复的数据库的团队目前需要将它们托管在本地，所以这是一个长期的想法。
- 我们可以主动将此数据库从欧盟存储桶复制到美国存储桶，然后从那里下载，但这会使我们的存储成本翻倍，并且无论区域如何，从 S3 转移出的成本都是相同的。
- AWS 主干网比互联网快，S3 到 CloudFront 是免费的，所以理论上我们可以通过 CloudFront 私下访问这些文件，这将提供一个速度更快的边缘位置，而且 CloudFront 也比 S3 略便宜，为 0.085 美元/GB。不过，这似乎是为了节省少量成本而进行的大量工程工作。我们的代码库是 C#，我们目前正在使用适用于 S3 的 AWS 开发工具包获取文件——我还没有研究过这如何与 CloudFront 一起工作（我觉得我可能在这里遗漏了一些东西）。
我的计划是实现本地缓存（#1），这是我们这边基于代码的解决方案。不过，这似乎是一种常见的用例，我想知道我是否遗漏了一些明显的东西。