请记住，这个答案在2015年6月是正确的

在研究了这个问题一段时间后，我心里有同样的问题，我发现SQS(带SNS)是大多数用例的首选，除非消息的顺序对您很重要(SQS不保证消息的FIFO)。

Kinesis有2个主要优势:

您可以从多个应用程序读取相同的消息 如果需要的话，您可以重新阅读邮件。

这两个优点都可以通过使用SNS作为SQS的扇出来实现。这意味着消息的生产者只向SNS发送一条消息，然后SNS将消息分散到多个SQSs，每个使用者应用程序一个SQSs。通过这种方式，您可以拥有尽可能多的消费者，而无需考虑分片容量。

此外，我们还增加了一个订阅SNS的SQS，可以保存14天的消息。在正常情况下，没有人从这个SQS中读取数据，但如果出现让我们想要倒带数据的错误，我们可以轻松地从这个SQS中读取所有消息，并将它们重新发送到SNS。而Kinesis仅提供7天的留存。

总之，SNS+SQSs更简单，提供了大部分功能。在我看来，你需要一个非常有力的案例来选择Kinesis。

这些技术的语义不同，因为它们是为支持不同的场景而设计的:

SNS/SQS:流中的项之间没有关联 运动:流中的项目相互关联

让我们通过例子来理解其中的区别。

Suppose we have a stream of orders, for each order we need to reserve some stock and schedule a delivery. Once this is complete, we can safely remove the item from the stream and start processing the next order. We are fully done with the previous order before we start the next one. Again, we have the same stream of orders, but now our goal is to group orders by destinations. Once we have, say, 10 orders to the same place, we want to deliver them together (delivery optimization). Now the story is different: when we get a new item from the stream, we cannot finish processing it; rather we "wait" for more items to come in order to meet our goal. Moreover, if the processor process crashes, we must "restore" the state (so no order will be lost).

一旦一个项目的处理不能与另一个项目的处理分离，我们就必须有运动语义，以便安全地处理所有的情况。

我还要补充一件没人提到过的事情——SQS要贵几个数量级。

Kinesis用例

日志和事件数据收集 实时分析 移动数据采集 “物联网”数据馈送

SQS用例

应用程序集成 解耦microservices 将任务分配给多个工作节点 将实时用户请求与密集的后台工作分离 批处理消息以供将来处理

另一件事:Kinesis可以触发Lambda，而SQS不能。因此，对于SQS，您要么必须提供一个EC2实例来处理SQS消息(并在失败时处理它)，要么必须有一个预定的Lambda(它不能扩大或缩小—每分钟只能得到一个)。

编辑:这个答案不再正确。自2018年6月起，SQS可以直接触发Lambda

https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html

从表面上看，它们有点相似，但是用例将决定哪种工具是合适的。在我看来，如果你可以使用SQS，那么你应该——如果它能做你想做的事情，它会更简单、更便宜，但这里有一个来自AWS FAQ的更好解释，它给出了两个工具的适当用例示例，以帮助你决定:

常见问题的