我已经从当前的Linux EC2实例创建了一个AMI。原始EC2附带有一个EBS。创建AMI时，如何处理EBS？我担心丢失数据。
我正在尝试为我们的dev / test / prod环境实施Blue / Green部署。我们有一个当前且稳定的Linux-EC2实例正在测试中，该实例承载了我们的应用程序。我从该实例创建了一个AMI，以便可以创建第二个EC2。这样可以节省时间并避免重新配置所有内容。一切似乎都正常。
我现在必须针对我们的产品环境执行此操作。我意识到，就像在测试中一样，当前EC2实例上附加了一个EBS实例。我们担心，当我们制作产品EC2的AMI时，AMI和EBS之间可能会断开连接。
我对AWS服务有一定的了解，但我远非专业人士。我想问一下任何AWS专家...我有什么需要担心的吗？创建当前EC2的AMI实例如何影响附加的组件/服务（例如EBS）？
同样，主要担心是数据丢失。我们不希望最终的用户丢失数据，因为我们假设我们的EBS将平稳过渡到新克隆的AMI和我们从该AMI创建的任何EC2。
谢谢！
答案 0 :(得分：0)
AMI由一个或多个EBS卷的一个或多个快照以及少量配置元数据组成。以后，您对AMI所做的操作对作为该AMI或其EBS卷来源的实例没有任何影响。
您可以使用AMI创建新实例，并且在执行此操作时，将从AMI的关联快照中为新实例创建新的EBS卷，并且它们与原始EBS卷没有关系/没有连接。 ）用于制作快照。任何给定的EBS卷一次只能附加到一个实例。
您还可以删除AMI，而不会影响源实例，也不会影响从该AMI启动的任何实例。当然，如果删除AMI，则不能使用它来启动任何新实例，但是一旦从AMI启动实例，该实例就不再需要该源AMI。
基本上没有什么可担心的。
唯一真正关心的是，当您创建AMI时， not 可以选择使该AMI成为源实例的原始克隆的唯一方法是选择“不重新启动”选项。选择“不重新启动”创建的AMI通常很好，但是使用这种AMI创建的计算机将使用硬盘驱动器启动，该硬盘驱动器看起来像突然断电的计算机，并且必须清理文件系统。因此，最好在创建AMI时让系统重新启动源计算机。在生产中，请牢记这一点……但是，不会干扰源实例。