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

摘自AWS文档:

We recommend Amazon Kinesis Streams for use cases with requirements that are similar to the following: Routing related records to the same record processor (as in streaming MapReduce). For example, counting and aggregation are simpler when all records for a given key are routed to the same record processor. Ordering of records. For example, you want to transfer log data from the application host to the processing/archival host while maintaining the order of log statements. Ability for multiple applications to consume the same stream concurrently. For example, you have one application that updates a real-time dashboard and another that archives data to Amazon Redshift. You want both applications to consume data from the same stream concurrently and independently. Ability to consume records in the same order a few hours later. For example, you have a billing application and an audit application that runs a few hours behind the billing application. Because Amazon Kinesis Streams stores data for up to 7 days, you can run the audit application up to 7 days behind the billing application. We recommend Amazon SQS for use cases with requirements that are similar to the following: Messaging semantics (such as message-level ack/fail) and visibility timeout. For example, you have a queue of work items and want to track the successful completion of each item independently. Amazon SQS tracks the ack/fail, so the application does not have to maintain a persistent checkpoint/cursor. Amazon SQS will delete acked messages and redeliver failed messages after a configured visibility timeout. Individual message delay. For example, you have a job queue and need to schedule individual jobs with a delay. With Amazon SQS, you can configure individual messages to have a delay of up to 15 minutes. Dynamically increasing concurrency/throughput at read time. For example, you have a work queue and want to add more readers until the backlog is cleared. With Amazon Kinesis Streams, you can scale up to a sufficient number of shards (note, however, that you'll need to provision enough shards ahead of time). Leveraging Amazon SQS’s ability to scale transparently. For example, you buffer requests and the load changes as a result of occasional load spikes or the natural growth of your business. Because each buffered request can be processed independently, Amazon SQS can scale transparently to handle the load without any provisioning instructions from you.

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

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

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

In very simple terms, and keeping costs out of the picture, the real intention of SNS-SQS are to make services loosely coupled. And this is only primary reason to use SQS where the order of the msgs are not so important and where you have more control of the messages. If you want a pattern of job queue using an SQS is again much better. Kinesis shouldn't be used be used in such cases because it is difficult to remove messages from kinesis because kinesis replays the whole batch on error. You can also use SQS as a dead letter queue for more control. With kinesis all these are possible but unheard of unless you are really critical of SQS.

如果你想要一个好的分区，那么SQS将不会有用。

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

常见问题的

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