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

常见问题的

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

对我来说，最大的优势是Kinesis是一个可重玩的队列，而SQS不是。因此，您可以有多个Kinesis的相同消息的消费者(或在不同时间的相同消费者)，而在SQS中，一旦消息被ack，它就从队列中消失了。 因此，SQS更适合工作者队列。

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

常见问题的

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

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

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

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