AWS Amazon EC2 现货定价
我想要一个非亚马逊的答案来解决这个难题...
看起来，通过现货实例定价，您可以以每小时 22 或 23 美分的价格运行一个实例，运行时间不限，因为历史图表小时/天/月显示现货价格永远不会超过每小时 21（22？） 美分。这相当于相同大小实例的非预留实例成本的一半，甚至低于预留实例每小时的成本。没有任何承诺。
我是否遗漏了一些东西，我对现货/出价/要价实例机制是否有完全的误解？或者，在亚马逊拥有大量额外容量的情况下，这是获得 24/7 实例的廉价方式吗？
杰里米
I'd like a non-amazon answer to this quandry...
It looks like, via spot instance pricing, you could run an instance for 22 or 23 cents an hour, for as many hours as you want, because the historical charts for hours/days/months show the spot price never goes over 21 (22?) cents per hour. That's like half of the non-reserved instance cost for the same sized instance and its even less than a reserved instance would ever work out to be per hour. With no commitment.
Am I missing something, do I have a complete and total misunderstanding of the spot/bid/ask instance mechanisim? Or is this a cheap way to get an 24/7 instance while Amazon has a bunch of extra capacity?
Jeremy
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
不，您没有错过任何东西。当我第一次查看 Spot 时，我多次问过同样的问题，然后是“为什么不是每个人都一直使用这个？”
那么有什么缺点？亚马逊保留随时以任何理由终止 Spot 实例的权利。现在，正常的“按需”实例也可能随时死亡，但亚马逊竭尽全力让它们保持在线状态，并在主机服务器需要关闭时提前（几天/几周）向客户发出警告用于维护。如果您有一个在服务器上运行的 Spot 实例，他们想要重新启动……他们只会将其关闭。在实践中，两者都相当可靠（但不是 100%！！），并且许多角色可以 24/7 现场运行而不会出现问题。只是不要向亚马逊抱怨您的 Spot 实例已关闭并且您的整个数据库存储在临时驱动器上......当然，如果您在任何实例上这样做，您就会冒巨大（而且非常愚蠢）的风险。
一些公司通过 Spot 节省了大量资金。这是关于 Vimeo 节省 50%，Pinterest 节省 60% 以上（54 美元/小时 => 20 美元/小时）。
为什么没有更多的公司在其实例中使用 Spot？ 许多购买 EC2 实例时间的公司对价格不太敏感，并且非常不愿意承担风险，特别是在出现中断和运营问题时削弱工程努力的事件。他们不想为了节省一些钱而陷入麻烦，尤其是当 AWS 费用相对于人员来说不是一个重要的成本中心时。对于 24/7 实例，他们已经通过“预留实例”支付 1/2 的价格，因此与全价“按需”实例相比，节省的费用并不像看起来那么巨大。 Spot 与大客户并不完全相关。您几乎可以肯定，当客户的规模达到 Netflix 的规模时，他们 1) 需要与 Amazon 进行容量规划协调，因为您不能随心所欲地启动 1/2 的数据中心，并且 2)大幅的批量折扣无论如何都会将其使用成本降低到现货价格范围内。另外，第一层成本削减是回收并不真正需要的硬件；在我上一家公司，一个人发现了一个错误，当我们循环浏览盒子时，我们会“忘记”其中一些盒子，然后关闭它每月节省 100 多美元（哎呀）。一旦公司消耗掉这些脂肪，他们就会开始关注 Spot。
Spot 没有被使用还有第二个较少讨论的原因......这是一个不同的 API。想想这如何与“组织惯性”相互作用……在一家持续在 EC2 上花费 XX 美元/小时的公司工作（并且来自一家花费 XXXX 美元/小时的公司），工程师使用他们提供的工具启动实例。我们的 Chef 部署不知道如何与 Spot 对话。 Rightscale（上一个位置）默认启动按需实例。通过一些工作量，我可能可以弄清楚如何创建一个现货实例，但如果我的首要任务是在明天之前启动并运行角色 XYZ，那为什么还要麻烦呢？我不打算只为我的一个角色设计一个基于现场的解决方案，然后宣传为什么这是一个好主意；这必须是整个组织范围内的决定。如果您阅读我上面链接的 Pinterest 案例研究，您会注意到他们谈论将整个部署从 54 美元/小时迁移到 20 美元/小时。从字里行间看出，他们并没有选择一一启动 Spot 实例；而是选择了启动 Spot 实例。有一天，他们一觉醒来，做出了一项全公司范围的决定，“解决 Spot 问题”，并将其部署工具“迁移”为默认使用 Spot（可能支持一个标志，使其数据库实例远离 Spot）。我无法想象亚马逊通过将 Spot 打造成一个不同的 API 而不是普通 EC2 API 上的一个标志，赚了多少钱；提示：这是一船的货物......就像，你可以买一艘船，然后用现金装满它，直到它沉没。
因此，如果您愿意承受稍高的风险和/或您对价格有些敏感……那么，是的，您绝对可以通过在 Spot 24/7 下运行服务来节省大量资金。
只要确保您做好双重准备，意外丢失您的实例（即进行备份）...您已经需要为“按需”实例做好准备，而该实例也没有 100.0% 的正常运行时间。
这样想：
你不是得到 99.9% 可靠的东西，而是得到 99.5% 可靠的东西并支付半价
（我编出这些数字是为了传达这个想法，但它们可能与事实相差不远）。
No, you are not missing anything. I asked the same question many times when I first looked at Spot, followed by "why doesn't everyone use this all the time?"
So what's the downside? Amazon reserves the right to terminate a Spot instance at any time for any reason. Now, a normal "on-demand" instance might die at any time too, but Amazon goes to great efforts to keep them online and to serve customers with warnings well in advance (days / weeks) if the host server needs to be powered down for maintenance. If you have a Spot instance running on a server they want to reboot ... they will just shut it off. In practice, both are pretty reliable (but NOT 100%!!), and many roles can run 24/7 on spot without issues. Just don't go whining to Amazon that your Spot instance got shut off and your entire database was stored on the ephemeral drive... of course if you do that on ANY instance, you are taking a HUGE (and very stupid) risk.
Some companies are saving tons of money with Spot. Here's a writeup on Vimeo saving 50%, and one on Pinterest saving 60%+ ($54/hr => $20/hr).
Why don't more companies use Spot for their instances? Many of the companies buying EC2 instance hours aren't very price sensitive and are very very risk-adverse, especially when it comes to outages and to operational events that sap engineering effort. They don't want to deal with the hassle to save a few bucks, especially if AWS fees aren't a significant cost-center versus personel. And for 24/7 instances, they already pay 1/2 price via "reserved instances", so the savings aren't as dramatic as they seem versus full-priced "on-demand" instances. Spot isn't fully relevant to large customers. You can be nearly certain that when a customer gets to be the size of a Netflix, they 1) need to coordinate with Amazon on capacity planning because you can't just spin up 1/2 a datacenter on a whim, and 2) getting significant volume discounts that bring their usage costs down into the Spot price range anyways. Plus, the first tier of cost cutting is to reclaim hardware that isn't really needed; at my last company, one guy found a bug where as we cycled through boxes we would "forget" about some of them and shutting that down saved $100+k / month (yikes). Once companies burn through that fat, they start looking at Spot.
There's a second, less discussed reason Spot doesn't get used... It's a different API. Think about how this interacts with "organizational inertia" .... Working at a company that continuously spends $XX / hr on EC2 (and coming from a company that spent $XXXX / hr), engineers start instances with the tools they are given. Our Chef deployment doesn't know how to talk to spot. Rightscale (prev place) defaulted to launching on-demand instances. With some quantity of work, I could probably figure out how to make a spot instance, but why bother if my priority is to get role XYZ up and running by tomorrow? I'm not about to engineer a spot-based solution just for my one role and then evangelize why that was a good idea; it's gotta be an org-wide decision. If you read the Pinterest case-study I linked above, you'll notice they talk about migrating their whole deployment over from $54/hr to $20/hr on spot. Reading between the lines, they didn't choose to launch Spot instances 1-by-1; one day, they woke up and made a company-wide decision to "solve the spot problem" and 'migrate' their deployment tools to using Spot by default (probably with support for a flag that keeps their DB instances off Spot). I can't imagine how much money Amazon has made by making Spot a different API instead of being a flag on the normal EC2 API; Hint: it's boatloads .. as in, you could buy a boat and then fill it with cash until it sinks.
So if you are willing to tolerate slightly higher risk and / or you are somewhat price-sensitive ... then, yes, you absolutely can save a crapton of money by running your service under Spot 24/7.
Just make sure you are double-prepared to unexpectedly lose your instance (ie, take backups) .... something you ALREADY need to be prepared for with an "on-demand" instance that doesn't have 100.0% uptime either.
Think of it this way:
Instead of getting something 99.9% reliable, you are getting something 99.5% reliable and paying half-price
(I made those numbers up to convey the idea, but they probably aren't too far off from the truth).
只要您的出价高于现货实例市场价格，您就可以继续运行您想要的任何现货实例，并且只需支付市场价格。
但是，当市场价格高于您的出价时，您将失去实例。没有任何警告。他们只是终止。虽然现货价格很少飙升，而且一旦出现，它往往会迅速回落，但对于许多应用程序来说，在没有变暖的情况下丢失所有实例的可能性是不可接受的。你可以通过提高出价来避免这种可能性，但随后你就面临着必须支付那么多钱的风险。
TL;DR：如果您的应用程序能够容忍突然终止，那么现货实例就很棒。但使用它们存在风险。
So long as your bid price is above the spot instance market price, you can continue to run whatever spot instances you want, and only pay the market price.
However, when the market price goes above your bid price, you lose your instances. Without any warning. They just terminate. While the spot price rarely spikes, and when it does it tends to come back down again quickly, for many applications the possibility of losing all your instances without warming is unacceptable. You can insulate yourself against that possibility by bidding higher, but then you risk having to pay that much.
TL;DR: If your application is tolerant to sudden termination, then spot instances are great. But there is a risk involved in using them.
我认为这些答案有点没有抓住重点......
您需要为您的工作负载选择最合适的定价，并考虑到这一点来构建您的解决方案。 AWS 提供 3 种定价类型：
预留实例
- 使用这些可以节省长时间运行/恒定/可预测工作负载的成本。
按需实例
- 将它们用于临时工作负载，例如开发/概念验证/无法中断的不可预测的工作负载。
Spot 实例
- 将它们用于临时工作负载。确保应用程序在设计时考虑到这一点（例如，在某个地方永久保持状态并支持新实例从先前实例停止的位置恢复的能力）。
一种有用的设计模式可以是拥有一个“指示灯”实例，并使用自动缩放功能来根据需要启用竞价实例，如果竞价实例未能出现，则可以使用一点狡猾的方法来启用按需实例。
TL;DR：Spot 实例适用于可以暂停和恢复的工作负载，但不是任务关键型。它们可能会受到异常峰值的影响（例如，北加州 m2.2xlarge 现货价格通常为 0.11 美元/小时，但持续峰值为 10.00 美元/小时！）。
I think these answers are slightly missing the point...
You need to select the most appropriate pricing for your workload and architect your solution with this in mind. AWS offers 3 pricing types:
Reserved Instances
- Use these for cost savings on long running / constant / predictable workloads.
On-demand Instances
- Use these for temporary workloads e.g. development / proof of concept / unpredictable workloads that can't be interrupted.
Spot Instances
- Use these for transitory workloads. Ensure applications are designed with this in mind (e.g. maintain state somewhere permanent and support the ability for new instances to resume where previous ones left off).
A useful design pattern can be to have a "pilot light" instance and use auto-scaling to bring spot instances on as required, and with a bit of cunning bring on-demand instances on if spot-instances fail to appear.
TL;DR: Spot Instances are suitable for workloads that can pause and resume, but are not mission critical. They can be subject to extraordinary peaks (e.g. N. California m2.2xlarge spot price is usually $0.11/hr but has sustained peaks of $10.00/hr!).
如果您的出价始终高于现货价格，那就准确无误。
我找不到任何其他明确提及他们何时终止您的实例的信息。
我本以为他们会要求客户愿意为实例支付全额费用，但话又说回来，现货价格在技术上可能会高于按需价格。
Spot on, if your bid price always remains above the spot price.
I couldn't find any other explicit mention of when they will terminate your instance.
I would have assumed it would be when they would require that capacity for customers willing to pay full charges for the instance, but then again, the spot price could technically go above the on-demand price.