【问题标题】:AWS S3 batch operation - Got Dinged Pretty HardAWS S3 批处理操作 - 非常难受
【发布时间】:2019-05-15 23:40:16
【问题描述】:

我们使用新推出的 AWS S3 batch operation 将我们的 S3 存储桶(大约 15 TB 的数据)备份到 Glacier S3。在备份之前,我们估计了带宽和存储成本,并且还考虑了 Glacier 的强制性 90 天存储要求。

但是,与我们的估计成本相比,实际成本是巨大的。我们不知何故忽略了每 1000 个请求 0.05 美元的 UPLOAD 请求成本。我们有数百万个文件,每个文件上传都被视为一个请求,我们正在考虑花费数千美元:(

我想知道是否有任何方法可以避免这种情况?

【问题讨论】:

  • 当您说“备份我们的 S3 存储桶”时,您是将文件复制到 Glacier,还是只是将存储类更改为 Glacier?您的备份目标是避免意外删除,还是处理潜在的 S3 故障/文件丢失?
  • 您联系过 AWS Support 吗?他们可能愿意帮助解决诸如此类的一些账单冲击。既然您已经承担了费用,我认为 SO 用户无法真正提供帮助。
  • @JohnRotenstein 他们引入了一种自动批处理服务,可以查看您的存储桶库存并将其复制到另一个 S3 存储桶或降低成本的 S3 Glacier。我选择了后一个选项。目的是为了防止意外删除,因为我们只有 1 个副本。
  • @A.J.Parr 我已联系 AWS 支持并等待回复。我在这里向社区提出的问题是,是否有任何方法可以最大限度地降低成本。答案可能是否定的,但希望获得更有经验的用户的意见。

标签: amazon-web-services amazon-s3 amazon-glacier


【解决方案1】:

“备份”的概念很有意思。

传统上,如果数据存储在一个磁盘上,则必须进行备份,因为有一个单一故障点并不好。

然而,Amazon S3 将数据存储在跨多个可用区(实际上是多个数据中心)的多台设备上,这就是它们获得 99.999999999% 的持久性和 99.99% 的可用性的方式。 (请注意,持久性意味着保留数据的可能性,这与可用性并不完全相同,可用性意味着访问数据的能力。我想不同的是,在停电期间,数据可能无法访问,但它没有丢失。)

因此,在设备发生故障时进行备份的传统概念已经在 S3 中处理,所有这些都是标准成本。 (有一个较旧的 Reduced Redundancy 选项,它只复制到 2 个可用区而不是 3 个,但不再推荐。)

接下来是在意外删除对象时备份的概念。当一个对象在 S3 中被删除时,它是不可恢复的。但是,在存储桶上启用版本控制将保留多个版本,包括已删除的对象。这在需要保留对象以前的历史记录或可能需要撤消删除的情况下非常有用。缺点是存储成本包括保留的所有版本

S3 中还有新的对象锁定 功能,可以将对象锁定一段时间(例如 3 年)而不能删除它们。这对于必须将信息保留一段时间并避免意外删除的情况非常理想。 (还有一个相同的合法保留功能,但如果您有适当的权限,可以打开/关闭。)

最后,如果愤怒的员工决定报复你的公司没有备货他们最喜欢的咖啡口味,那么就有可能故意恶意删除。如果 AWS 用户拥有必要的权限,他们可以从 S3 中删除数据。为了防止这种情况,您应该限制谁拥有此类权限,并可能将其与版本控制结合起来(这样他们就可以删除对象的当前版本,但它实际上是由系统保留的)。

这也可以通过使用 Amazon S3 存储桶的跨区域复制来解决。一些组织使用此功能将数据复制到其他 AWS 账户拥有的存储桶,这样任何人都无法从两个账户中删除数据。这更接近真正备份的概念,因为副本与原始副本(按帐户)分开保存。与数据丢失的潜在成本相比,额外的存储成本是最小的。此外,如果您将副本存储桶配置为使用 Glacier Deep Archive 存储类,则成本会非常低。

您的复制到 Glacier 是另一种备份形式(从长远来看,它提供比 S3 更便宜的存储空间),但它需要定期更新才能成为连续备份(例如,通过使用了解 S3 和 Glacier 的备份软件)。 “每 1000 个请求 5c”的成本意味着它更适合用于存档(例如大型 zip 文件)而不是许多小文件。

底线:您对备份的需求可能就像打开版本控制并限制哪些用户可以从存储桶中完全删除对象(包括所有过去的版本)一样简单。或者,创建一个存储桶副本并将其存储在 Glacier Deep Archive 存储类中。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2018-05-19
    • 1970-01-01
    • 1970-01-01
    • 2011-06-04
    • 2020-09-07
    • 2012-01-29
    • 1970-01-01
    相关资源
    最近更新 更多