更新20140512
AWS 同时添加了更详细的文档API 请求错误故障排除，包括一个寻址部分最终一致性，这基本上证实了我下面最初答案中的分析：
由于支持 API 的系统的分布式特性，Amazon EC2 API 遵循最终一致性模型。这意味着您运行的影响 Amazon EC2 资源的 API 命令的结果可能不会立即对您运行的所有后续命令可见. [...]
[...] 例如， [...]如果您运行命令来修改或描述刚刚创建的资源，其 ID 可能不会在整个系统中传播，并且您将收到一条错误消息，指出该资源不存在.
要管理最终一致性，您可以执行以下操作：
[强调我的]
请注意: Most AWS SDKs同时自动应用这些建议，包括调整默认重试策略或添加自定义实现的选项 - 请参阅AWS 中的错误重试和指数退避如果需要的话，获取有关如何自行实施的指导。
更新20130719
各种大型 AWS 用户越来越多地遇到 AWS API 最终一致的设计，他们自然需要更深入地研究并相应地解决它，例如，请参阅以下文章：
-
处理 AWS EC2 API 中的最终一致性（作者：Cloud Foundry 的 Martin Englund）
-
处理不一致的 EC2 API（作者：Aaron Staley，PiCloud）
初步答复
正如已经评论了作者：@datasage，AWS API 显然需要被普遍视为最终一致只是 - 这在第一次遇到时肯定是出乎意料的，但事后看来，对于大规模服务（即工程服务）来说实际上并不太令人惊讶。运营权衡以解决CAP定理.
另请参阅我对 Alex Ciminian 问题的评论为 AWS Spot 实例请求实现幂等性，他在其中讨论了有关类似一致性问题的测试结果：
有趣的问题 - [...] 我遇到过各种类似的 API 延迟
的背景Bamboo AWS 插件并得出结论：AWS API
需要被视为最终一致只能跨越
木板;例如，我什至遇到过收到资源的情况
来自创建调用的 id，可以根据资源的 id 标记资源，但不能
此后仍然描述它，因为它据说不存在
（然而）。
- 我在这里描述的似乎表明，事实上，每一个 API 操作都是完全由 AWS 独立操作的（不仅在外部可见的服务中，甚至在像 EC2 这样的单个服务中），因此可能会受到最终一致性的影响，并且必须予以相应对待。
有关上述案例的详细信息，您可能需要研究AWS API 频繁轮询导致油门限制，我总结了我们的分析和方法，通过可用但有限的重试/退避功能来改进处理适用于 Java 的 AWS 开发工具包- 该解决方案几乎是理想的，但目前似乎大大改善了情况。
类似地，重新设计的适用于 PHP 2 的 AWS 开发工具包推出专用“Waiter”对象允许您轮询资源，直到其处于所需状态要解决该问题，请参阅部分Waiters内快速开始详情：
SDK 提供的高级抽象之一是以下概念
的“服务员”。服务员帮助最终让合作变得更容易
通过提供一种简单的方法来等待资源来实现一致的系统
通过轮询资源进入特定状态。 [...] 任何
以“waitUntil”开头的@method标签将使用服务员。
$client->waitUntil('BucketExists', array('Bucket' => 'my-bucket'));
