Kinesis解决了流数据典型的映射缩减场景中的映射部分问题。而SQS并不确定这一点。如果你有需要在一个键上聚合的流数据，kinesis可以确保该键的所有数据都到一个特定的分片，并且该分片可以在单个主机上使用，这使得在键上的聚合比SQS更容易

请记住，这个答案在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。

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

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

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

Kinesis解决了流数据典型的映射缩减场景中的映射部分问题。而SQS并不确定这一点。如果你有需要在一个键上聚合的流数据，kinesis可以确保该键的所有数据都到一个特定的分片，并且该分片可以在单个主机上使用，这使得在键上的聚合比SQS更容易

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

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

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).

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