为什么AWS EC2的现货价格大于按需价格?


27

我昨天试图通过Ansible设置现货实例,即使我将现货价格==该实例的按需价格,几乎所有请求都失败了。

因此,当我查看现货价格图表时,发现了一些非常有趣的东西:

在此处输入图片说明

us-east-1a中该实例的现货价格高于按需价格,这使我感到困惑。[实际上,高出约5倍]

现货实例不是以低成本为首选吗?如果是,那么价格为什么高于按需价格?

根据AWS的文档

竞价型实例使您可以以相对于按需价格的大幅折扣访问未使用的Amazon EC2容量。

另外,这是否意味着人们正在按需出价? 如果是,那为什么呢?他们不是按需实例更好吗?

还是我理解竞价型实例的概念错了?


如果现货价格总是小于按需价格,为什么按需价格会存在?
扎克·利普顿

2
Zach,因为如果出价更高,Amazon可以随意终止您的实例。
熊加米奥夫

1
不管是什么背后的原因-你可以最大限度地减少通过实施现场情况的最佳实践规则的风险- aws.amazon.com/ec2/spot/getting-started -用于创建请求尽可能多的实例类型以及多达AZS这样,您就可以减轻支付更多费用的可能性。如果您在短时间内支付多一点钱,而在其他所有情况下却少得多,这仍然对您有利。另外,看起来有很多小实例的算法对于大型单节点工作负载aws.amazon.com/ec2/spot/instance-advisor
Petr Chloupek

Answers:


23

这实际上是人们稍微滥用现场的一个很好的例子。人们说“我们的工作量确实很重要,但我们不想全额支付按需价格”,因此他们在假设竞价很不可能终止的情况下将竞价设置为高于按需价格,但仍然希望获得“最便宜”的现货价格。

在某些情况下,人们输入,例如$ 1000(我听说过至少发生过一次),因为他们想从现货市场中受益。当然,自然会在某个时候出现需求,而SOARS的现货价格使人们支付的费用高于按需支付的价格。

现货市场运作的方式是,亚马逊拥有X实例的备用容量,并且它们从上到下依次计数,直到满足所有X实例的需求为止。那么,“价格”是他们可以满足这X个实例的最低价格。

因此,想象一下亚马逊有10,000个实例-那么它们将递减至(说)0.43美元,直到满足这10,000个实例为止。但是,如果供应量突然下降到100个实例,那么也许有人将100个实例的出价设为10,000美元,突然,他们将每小时支付1万美元。

Tl; dr了解现货的运作方式,并设定您准备支付的上限。


12

有两个原因:

  • 很多用户有时会使用竞价型实例(考虑批处理,将100台机器作为竞价型实例启动并处理掉)。

  • 对于现货实例,您不支付出价,而在当前价位。投标价格是截止点。如果当前现货价格超过竞标价格,AWS将终止该实例。

最后一点也是某些用户将大量竞标现货价格的原因。他们不希望实例频繁关闭,因此他们出价很高,以至于现货价格将永远无法达到。由于他们只会支付当前的现货价格,因此实例将在99%的时间内便宜很多。


因此,在我所问的这张图中,18:00的现货价格为2.15美元,对吗?这意味着当人们可以按需支付价格时,人们仍然需要为每个实例支付2.15美元。为什么这样?
Dawny33

1
看到我的回答(即将发布)
亨利

@ Dawny33有时,价格仅在短时间内上升到阈值以上。从现货定价转换为按需定价涉及在普通ec2实例上重新创建实例。如果价格再次下降,则按需实例已被销毁,新的现货实例等。因此,浪费的时间使该实例变得有用。某些人认为这样做不值得,只会使用现场实例
Thern

6

可以在竞价型实例简介中找到一些有用的信息,以了解为什么有人会竞标按需价格:

竞价型实例可用于帮助您满足偶尔需要大量计算能力的需求(请注意,竞价型实例的默认限制为100,而按需实例的默认限制为20。)如果您的需求很紧急,则可以指定较高的最高价格(可能甚至高于按需价格),这将提高请求的相对优先级,并在给定其他请求和当时可用的竞价型实例容量的情况下,允许您获得尽可能多的即时容量。

如果您对服务的需求量激增(也许已从另一个受欢迎的网站链接到此商品,请参阅Slashdot效果),则以即时价格竞价购买竞价型实例将有助于您访问更多实例,例如在文件中注明。

当然,从长远来看,这是不可持续的,仅购买按需实例就可以为长期计算带来更好的交易(而且竞价的风险更低!)。

如果你在你需要的情况下大量的计算能力,快速 -超过你可以从点播情况下,出价过高可能是有意义的只是购买得到。


3

如果仔细查看图表,您会发现峰值总是持续很短的时间-足够的时间让所有者编写的自动监视系统正常终止这些系统。此外,您偶尔会发现价格在飙升后立即跌至0。这是因为该数据中心中的所有系统都按需使用,没有可用的现货定价系统,价格实际上为零。

当您的竞价型实例标记为终止时,指示该消息的消息将在系统上的http://169.254.169.254/latest/meta-data/spot/termination-time的本地元数据uri上可用。它将持续3分钟。在大多数情况下,有足够的时间来自动处理终止。仅在需要花费几分钟时间才能正常终止的部署中,才需要以高于需求价的价格竞标。

如果无法在3分钟内将系统设计为正常终止,归档数据等,则可以将出价提高到高于需求价格的水平,从而节省时间。该系统甚至可以设计为主动监视当前现货价格,并在价格结束之前进行交换。但是在那些时候,您需要做出一个业务决策,以决定这段时间里优雅终止的价值是多少。

为了保持系统状态而在4-5个小时内每小时支付$ 100是愚蠢的。但是,如果您的系统需要30分钟才能正常终止所有流程,则您可以做出业务决策,以决定丢失任何数据或降低水平扩展服务的价值。一个电子商务站点每小时的净利润为10,000美元,一定可以支付1000美元来保持两个现场实例在15到30分钟内运行,同时启动需求系统和归档数据。

基于Web的应用程序可以使用Elastic Load Balancer帮助自动解决终止问题。一个聪明的实现者将放置一组脚本来处理警报。他们可以维持2个负载均衡的低成本按需实例,然后通过竞价型实例使用多达六种中等成本的系统来维持高性能,并花费少于同容量的单个按需系统。

让其中3个人支付最高$ 100 /小时的费用,其中3个人仅支付最高按需价格的一半。随着AWS终止实例,ELB将自动进行调整。只需200美元,就可以让自动系统最多调动一个小时。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.