AWS亚马逊EC2 Spot定价

Question

AWS亚马逊EC2 Spot定价

amazon-ec2amazon-web-services

27

我希望得到一个非亚马逊的答案来解决这个困惑...

通过竞价实例价格，你可以以每小时22或23美分的价格运行一个实例，无限制地使用多少小时，因为历史图表显示，每小时的竞价价格从未超过21（22？）美分。这相当于同样大小的非保留实例成本的一半，甚至比保留实例的每小时成本还要低。没有任何承诺。

我是否错过了什么？我是否完全误解了竞价实例机制？还是这是一种廉价的方式在亚马逊有大量额外容量的情况下获得24/7实例？

Jeremy

- Jeremy

4个回答

8

只要您的出价高于现货实例市场价格，您就可以继续运行任何想要的现货实例，并且只需支付市场价格。但是，当市场价格高于您的出价时，您将失去您的实例，而没有任何警告。它们只是终止了。尽管现货价格很少会飙升，而且当它这样做时往往很快就会回落，但对于许多应用程序来说，失去所有实例的可能性是无法接受的。您可以通过提高出价来保护自己免受这种可能性的影响，但这样做会存在支付更高费用的风险。简而言之，如果您的应用程序能够容忍突然终止，那么使用现货实例是非常好的选择。但是使用它们存在风险。

- Kevin Ballard

1

将核心自动缩放组与最少的按需/预留实例相结合，再加上只有竞价实例的另一个组，将是一种更可行的解决方案。 - Kostas Demiris

4

我认为这些答案略有偏差...

您需要根据负载选择最合适的定价，并在此基础上设计架构。AWS提供三种定价类型：

- 预留实例（成本低，可靠性高，但需预付款） - 按需实例（成本最高，可靠性高，按需付费） - 竞价实例（通常成本最低，但可能意外终止）

针对长时间运行、持续稳定和可预测工作负载，使用预留实例以节约成本。

针对临时工作负载（例如开发/概念验证）或不可中断的不可预测工作负载，使用按需实例。

针对短暂的工作负载，使用竞价实例。确保应用程序考虑到这一点（例如，在某个永久位置维护状态并支持新实例恢复之前停止的旧实例的能力）。

一种有用的设计模式是拥有一个“ pilot light”实例，并使用自动缩放按需加入竞价实例，如果竞价实例未出现则带有一定技巧地加入按需实例。

简而言之，竞价实例适用于可以暂停和恢复但非关键任务的工作负载。它们可能会遭受非常高峰值（例如，北加利福尼亚州的m2.2xlarge竞价价格通常为每小时0.11美元，但持续高峰可达10.00美元/小时！）。

- user1066510

1

这是一种廉价的方式，利用亚马逊多余的容量获得全天候实例吗？
如果您的出价始终高于市场价格，那就没错了。
我找不到任何其他明确提到他们何时会终止您的实例的信息。
我原本认为当他们需要为愿意支付全额费用的客户提供实例时，他们会终止您的实例，但话说回来，市场价格在技术上可能会高于按需价格。

- Ryan Fernandes

当市场价格高于您的出价时，他们将终止您的实例。事实上，市场价格经常高于按需价格。 - steve cook

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Dave Dopson · Accepted Answer

不，你没有错过什么。 当我第一次看到Spot时，我也问了同样的问题，接着便是“为什么不是每个人都一直使用它呢？”

那有什么缺点呢？ 亚马逊保留随时因任何原因终止Spot实例的权利。现在，普通的“按需”实例也可能随时停止运行，但是亚马逊会付出很大的努力来保持它们在线并提前（几天/几周）向客户发出警告，如果主机服务器需要关闭以进行维护。如果你有一个运行在他们想要重新启动的服务器上的Spot实例……他们只会将其关闭。在实践中，两者都非常可靠（但不是100％！），许多角色可以在Spot上无问题地运行24/7。只是不要向亚马逊抱怨您的Spot实例被关闭，并且您的整个数据库存储在暂时性驱动器中……当然，如果您在任何实例上这样做，您就承担了巨大（而且很愚蠢）的风险。

一些公司正在通过Spot节省大量资金。 以下是关于Vimeo节省50％和Pinterest节省60％以上（$ 54/小时 => $ 20/小时）的文章。

为什么不有更多的公司使用Spot实例？许多购买EC2实例小时数的公司并不是非常在意价格，而且非常注重风险，特别是当涉及到可能耗费工程力量的故障和运营事件时。他们不想为了省几个钱而处理麻烦事，特别是如果AWS费用不是与人员相比的显著成本中心。对于24/7实例，他们已经通过“预留实例”支付半价，因此与全价的“按需”实例相比，节省的金额并不像看起来那么惊人。Spot对于大型客户来说并不完全相关。几乎可以肯定，当一个客户像Netflix这样的规模时，他们需要与亚马逊协调容量规划，因为你不能凭空启动1/2个数据中心，并且他们正在获得大量折扣，将他们的使用成本降至Spot价格范围内。此外，第一层成本削减是回收不真正需要的硬件；在我上一家公司，有个人发现一个错误，当我们循环使用机箱时，我们会“忘记”其中一些机箱，关闭它可以每月节省10万美元（天哪）。一旦公司消除了这些浪费，他们开始考虑使用Spot。

有一个不太被讨论的原因是Spot没有被使用，那就是因为它是一个不同的API。想一想这是如何与“组织惯性”互动的.... 在公司持续花费$XX /小时在EC2上工作（并来自一家每小时花费$XXXX的公司），工程师使用他们所给予的工具启动实例。我们的厨师部署不知道如何与Spot交流。Rightscale（之前）默认启动按需实例。虽然通过某些工作量，我可能可以弄清楚如何制作一个Spot实例，但如果我的优先事项是在明天让XYZ角色运行起来，为什么要费心去做呢？我不会只为我的一个角色设计基于Spot的解决方案，然后传教为什么这是个好主意；这必须是一个全组织的决定。如果你阅读我上面链接的Pinterest案例研究，你会注意到他们谈到了将整个部署从每小时$54迁移到每小时$20的问题。读懂其中的潜台词，他们没有选择逐个启动Spot实例；有一天，他们醒来，做出了一个全公司的决定，即“解决Spot问题”，并通过默认使用Spot来“迁移”他们的部署工具（可能支持一个标志，使他们的DB实例不使用Spot）。我无法想象亚马逊通过将Spot成为一个不同的API而不是EC2 API上的标志赚了多少钱；提示：它是巨额财富...例如，你可以买一艘船，然后用现金把它装满直到沉没。

因此，如果您愿意容忍稍微高一点的风险和/或您对价格比较敏感...... 那么，是的，您绝对可以通过在Spot下运行您的服务24/7来节省大量资金。

只需确保您已经做好了双重准备以意外地失去实例（即，备份）.... 这也是您已经需要准备的“按需”实例，其可靠性也不是100.0%。

这样想：

与其得到99.9％的可靠性，您得到了99.5％的可靠性，并且支付了半价

（我编造了这些数字来表达这个想法，但它们可能离真相并不太远）。