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