我的客户使用AWS作为他的VPS。他遇到问题的一件事是，如果现场实例的出价高于他的出价，那么他的实例就会被终止。看起来并不是什么大不了的，除了现场实例不是持久性的，所以每次发生这种情况时我们都必须从图像中恢复。
他希望我做的是写一些会在每X个时间内检查已终止实例的内容，并自动重启它们。更重要的是，他想要某种方式来假装“坚持”。我最好的想法是每隔Y时间从每个服务器创建一个图像，然后从该图像启动（如果/当该实例终止时）。
任何其他想法都会很高兴听到。我想我的问题是，我是否在正确的轨道上，您是否知道可能已经存在的任何解决方案？
更新：差不多一年后，我回到这里寻找所有这些精彩的回应，并且比我预期的更多地关注这个话题。以下很多答案虽然内容丰富且有帮助，但却质疑我的推理。我想说，即使在那个时候，我100％同意这不是一个明智的想法，但我的客户要求尽管我有任何尝试，但要把事情转向更好的方向。
非常感谢你的帮助。我最终确定了如何完全按照自己的意愿行事，并且能够编写一些自动重新启动已终止实例的代码。这从来都不容易，但是当我转移到新客户端时它运作良好。
祝你们中任何一个有同样问题的人好运，你们正在进行（可能通过武力，就像我的情况一样）并不容易。现场请求更便宜，因为这里的一些人提到了他们的回复，特别是因为没有提供持久性。否则，我认为“现货要求”市场的定价会大不相同。
尽管如此，有可能，我做到了，这是一次很棒的经历。如果没有办法，你必须伪造它！如果你不这样做，别人会。
更新II：我只想提醒大家，这是我基本上的任务。虽然当时许多人只是驳回了整个概念，但我最终得到了一个或多或少功能的SaaS，允许人们轻松管理和监控所有现场实例，包括启用/禁用自动持续重启的能力实例，单个实例的调度时间（它们应该或不应该启动它们）等。
虽然我完全同意，从开发人员的角度来看，这是一个不优雅的需求，当时，我不想这样做，我仍然会说它在某种程度上是好的，被要求努力工作，因为我不仅学到了很多东西，而且不仅对我的能力和代码有了很大的信心，而且我制作了一个非常有用的东西，据我所知，我的软件非常有价值。客户（即使他们要求错误的东西，因为他们不知道更好）。
我试图说服他，但他坚持说，因为他是那个付钱的人，我把注意力集中在那里，不仅完成了许多人在这里被贬低的愚蠢行为，而且还使某人有利可图。
如果那是愚蠢的话，它就不会为任何人省钱。
看，我现在读这篇文章并且稍微畏缩一下。那时我更天真。我知道AWS好多了，现在，我现在代码好多了，等等。当然。
但我仍然为解决这个问题而感到骄傲，特别是因为正是这些同事，年龄更大，经验更丰富，无疑是伟大的程序员，他们告诉我它不能或不应该完成。你是那些对我提出挑战的人，谢谢！
如果可以盈利的话怎么办？你确定它不应该吗？
我们最终找到了解决方案，这就是我们必须做的事情。我将逐步列出这一点，以便为那些可能正在寻找类似解决方案的人重新创建这个...
如果您按照上述步骤操作T，您将在旧实例终止时的同一点上有一个新实例。因此，我们已经实现了某种形式的持久性。
（感谢Ethan Barron的一些原创想法。这是一个有一些更正和澄清的版本。）
[1]。创建一个新的专色实例。取消激活根设备的“终止时删除”。记下体系结构（x86_64）和内核ID。
[2]。 SSH进入新实例并创建一些文件，这些文件应该在重新启动后持续存在。不要终止实例。
[3]。在实例仍在运行时创建实例的快照（这可能会在极少数情况下导致文件系统不一致，因此限制写入启动卷）。记下该快照的名称。
[4]。现在退出SSH连接并终止实例。
[5]。从步骤3中创建的快照创建AMI（AWS不支持从卷创建AMIS;它必须是快照。如果您使用的是剩余卷，则还有一个步骤：创建该快照）。
[6]。根据步骤1中的体系结构，步骤1中的内核ID和步骤5中创建的AMI请求新的现场实例。
这应该工作。
如果你使用的是ubuntu，我找到了解决这个问题的方便方法。它使用了一个名为'overlayroot'的功能，该功能包含在ubuntu发行版中。我们的想法是将根文件系统保持为只读，并将所有更改写入EBS支持的覆盖文件系统。由于root是只读的，因此可以在终止时删除它，并且所有更改都将保留在overlay文件系统中。
overlayroot=device:dev=/dev/xvdf,timeout=180,recurse=0使用AWS从您的实例“Instances-> Actions-> Image-> Create Image”创建自定义AMI
现在创建并将EBS卷附加到实例。 “Volumes-> Actions-> Attach Volume”然后初始化卷。
mkfs.ext4 /dev/xvdf
第一个实例仅用于创建自定义AMI并初始化卷，因此可以终止它。在创建自定义图像之前，请勿附加EBS卷，以使其不包含在图像中。
每次启动现场实例时都应遵循以下步骤。
ubuntu@ip-10-178-74-83:~$ mount
overlayroot on / type overlayfs (rw,discard)
...
/dev/xvda1 on /media/root-ro type ext4 (ro,relatime,data=ordered)
/dev/xvdf on /media/root-rw type ext4 (rw,relatime,data=ordered)更新：时间已经改变
现在可以将EC2竞价型实例请求配置为stop而不是terminate，这是一个高价竞价型实例，或者是用于导致竞价型实例中断的任何其他与容量相关的事件。
请参阅EC2开发人员指南中的Interruption Behavior。某些类的实例也可以在安装了适当的代理的情况下休眠。
请注意，此新功能不保证实例将继续运行，而只是保证它们将以其先前的EBS卷，专用IP，弹性IP和实例ID重新启动。
以前的答案如下：
竞价型实例不能持久，但是现货请求可以。
持久性竞价请求：当您将竞价出价请求指定为“持久性”时，您可以确保在您的实例终止后 - 由您或Amazon EC2自动重新提交它 - 直到您取消出价请求为止。这使您可以在竞价价格低于最高价格时自动启动竞价型实例。
http://aws.amazon.com/ec2/spot-instances/#4
这使得机器在价格在范围内的任何时候运行，但就其余部分而言，考虑你的现场实例在做什么，你认为磁盘的持久性是要走的路。想想“云”。想想“短暂的”。竞价型实例旨在成为启动，获取工作，工作，提交工作的短暂机器，如果它们消失，工作仍然在那里等待下一个实例再次获取它，完成它并提交它。您可以“使用”它们与EBS一起使用并保留卷，但如果这样做，则无法重新启动这些实例（正如您所注意到的那样）。
如果您的AMI使用实例存储，并存储需要在外部持久化的所有内容（例如，在S3中），那么您不需要破解AWS架构，并且可以坐下来看看您的机器在价格时启动是的，做他们的工作，并在价格超出范围时再次关闭。而且，没有任何腐烂，因为每个靴子都是一个闪亮的清洁系统。
或者，您的实例可以挂载由始终打开的计算机导出的NFS共享。
或者这个：https://serverfault.com/questions/448043/auto-attach-ebs-volume-to-a-new-spot-instance
spot实例的本质是它们是瞬态的，所以不能让你的实例“持久”。但是，您可以使用EBS使数据持久化。
你对这些图片的想法很好，我不确定是否有任何其他方法可以做到这一点。
您可以随时查看spot instances上的文档或跳到forums，看看是否有任何AWS工程师有任何想法。
- 编辑 -
不确定这是否会起作用 - 因为它会产生额外的成本，但是你可以随时立即从你生成的图像中启动一个实例并终止现有实例。它会给出持久性的假象，特别是如果您不依赖于EBS卷来保留数据。
AWS最近推出了一个新的Spot实例仪表板，使您可以更轻松地将实例保持在持久状态。这还包括自动定价和地区支持，因此人们不必担心竞标理想价格。启动实例后，创建实例的AMI，就是这样。下次请求现场实例时，只需从“保存的实例”列表中选择该实例。内核和EBS按原样恢复。