AWS，EC2 - RunInstances之后的CreateTags

Question

我正在使用.NET SDK并尝试在创建后立即标记新实例 - 在RunInstances之后立即创建CreateTags。

大部分时间它都可以正常工作，但偶尔我会收到实例ID无效的错误（随后在控制台中检查或再次尝试，它是有效的。）

据我所知，对于SQS，SDB等，它们“最终是一致的”并且可能需要重试调用（尽管我相信SDK无论如何都会为你做这件事） - 但是通常调用创建实例我没想到有必要。更重要的是，我认为这不是一件好事;寻找一个特定的异常并几乎无限地重试，直到它工作。

如果创建实例并将其标记的过程必须输入到具有冗余集中系统进行轮询和重试的分布式工作流程中，我认为这是一个糟糕的情况！

我似乎无法在文档中找到与此相关的任何内容。我想如果我调用RunInstances并获得带有实例ID的响应，那么该实例ID应该立即对标记有效。

到目前为止我对可能的解决方案的想法：

• 修复RunInstances后几秒钟的延迟（错误，任意延迟）
• 立即尝试，否则延迟5秒并重试，最多'n'次（OK但任意）
• 创建分布式工作流来处理这样的任何链接API调用，需要EC2实例的中央冗余服务库来管理可靠（糟糕，大规模过度工程）
• 找一些其他解释，我可以调用另一个API方法或在请求上设置一些要么调用才能使其工作

有没有其他人经历过这方面，对该领域有任何了解，等等？

（我在AWS社区论坛上有一个帖子，还没有：https://forums.aws.amazon.com/thread.jspa?threadID=80489&tstart=0）

Answer 1

我担心你的第一个选择是正确的 - 在为RunInstances调用之前需要一个有限的，可变的时间，然后才能为实例分配一个预留标识，开始运行，并可用于进一步调用反对它。

我的控制软件只需在启动程序线程上休息5秒钟，直到实例进入'Running'状态，此时我可以开始发出其他调用。

Answer 2

标记API是在Xen Hypervisor API的标记功能之上实现的，即see the tags field of a VM in the XenAPI。相反，实例id对应于AWS管理基础架构数据库中的条目。因此，实例可以在将实例id返回给调用者之后对VM创建进行排队。这种方法的一个副作用是无法创建某些标记，因为它们是为AWS基础结构保留的。

正如@Jonners所指出的，标记并不是唯一依赖于VM的API。例如。停止一个实例。但是，“管理程序”更有可能避免商标纠纷，因为该术语被NIST接受，例如Guide to Security for Full Virtualization Technologies，而“hipervisor”仅归因于IBM文档。