Amazon竞价型实例不一致的定价

可以通过实例定价历史图表的屏幕快照最好地解释这一点。

如果您查看现货实例的很多实例价格，您会注意到峰值的常规模式。看这里：

如您所见，此计算介质实例的价格通常会高于按需价格。

一个c1.medium实例（按需）仅$0.186每小时需要花费一次。但在B区的几个星期内，价格通常会飙升至1.20美元。这是实际按需价格的6倍。

它也不是孤立的。如果再次查看b区域的小型实例，则经常出现类似的尖峰。这是按需定价的4倍。

有人知道为什么会这样吗？

这里有一些建议

• 有人输入了$ 1.2，而不是$ 0.12（我会打折，因为它在3周内发生了20次）。

• 亚马逊通常会通过对自己的实例进行出价来人为地抬高价格，以期获得最大的收益。（我会打折，因为这将是荒谬和糟糕的事情）

• 某公司一次启动了1000台服务器，并希望确保它们全部启动。（我会打折，因为他们大概会以低于最低需求价格的价格推出它们。为什么您要为单个服务器支付高于需求的价格？）。

• 他们的报告有错误吗？

以色列理工学院的人发表了一篇论文，分析了现货市场。他们的结论是，现货价格不是由出价驱动的，而是由AR（1）函数生成的。因此，在这种情况下，这不是由于其他人的出价，而是由于所使用的算法。

http://www.cs.technion.ac.il/~ladypine/spotprice-ieee.pdf

不过，我认为如果现货市场真正达到可以从需求/供应中获得良好价格的水平，情况可能会有所改变。正如Matt所言，降低现货成本和许多按需出价的价格来避免停机是降低成本的一种普遍做法。从长远来看，它仍然具有成本效益……但仍然吗？真正的问题是，除了亚马逊以外，没有人真正知道价格是如何产生的。

这不是错误，这是优先级/可用性问题，因为按需实例的优先级高于竞价型实例，而与竞价型投标无关。这源于您对“ 备用Amazon EC2实例出价 ”的Amazon EC2声明。

因此，当按需实例的需求增加时，可用的备件就更少了，现货实例的可用性降低了，从而根据竞争现货竞价提高了现货定价。

许多竞价竞标者未能理解按需实例的较高优先级，并且出价高于按需定价，以试图获得高于按需实例请求的优先级，但这失败了，因为按需实例的优先级更高，无论现货竞价。

反过来，这些按需定价竞标价格相互竞争，导致现货价格低时，最高价格比按需定价高出好几倍。

尽管没有提出以下要求，但我对长期工作负载的最低成本现场实例管理的建议是：

1. 设计应用程序以实现故障（连续备份/复制）和快速恢复
2. 将即时实例出价设置为按需定价
3. 现货实例终止后，请按需实例或在现货价格较低的其他区域/区域中将其重新启动。
4. 监控现货定价，直到其低于按需定价
5. 停止按需实例并转到上面的2。

EC2不再使用人工AR（1）流程来控制最低价格。即使他们这样做了，他们也只是更改了最低价格-AR（1）流程是固定的，并且从未导致价格跳升到按需价格之上。此类上涨可能来自指定高价的用户（可能超出了他们实际支付的价格），也可能来自希望关闭部分现货实例的亚马逊，就像他们在2010年夏天为m1.small所做的那样。

您可以在我们的论文的期刊版本中阅读更多内容，在最后更新的部分（尸体剖析部分）中：

这不是报告中的错误。有时，现货价格会飙升。过去，它们已猛增至惊人的数量。从那时起，亚马逊改进了竞价实例的竞价和分配算法，但即使如此，竞价价格有时还是会飙升。

早在2011年9月，美国东部1区AZ中m2.2xlarge的现货价格飙升至每小时999美元。

原因很简单：人们指定的最高现货价格高于按需价格，而需求则将价格推高了。

许多人将竞价型实例用作将运行中的EC2实例的成本降至最低的方法。通常，他们会指定较高的最高现货价格，以减少其现货实例出价过高并终止的机会。从长远来看，这是一场赌博，但如果他们不小心，就会冒着很快变得非常昂贵的风险。