回答:
この回答は2015年6月に正しかったことを覚えておいてください
同じ質問を念頭に置いてしばらく問題を調査した後、メッセージの順序が重要でない限り（SQSはメッセージのFIFOを保証しない）、SQS（SNS付き）がほとんどのユースケースに適していることがわかりました。
Kinesisには2つの主な利点があります。
SNSをSQSへのファンアウトとして使用することで、両方の利点を実現できます。つまり、メッセージのプロデューサーは1つのメッセージのみをSNSに送信し、SNSはメッセージを複数のSQSにファンアウトします（各コンシューマーアプリケーションごとに1つ）。このようにして、シャーディング容量を考慮せずに、必要な数のコンシューマーを持つことができます。
さらに、メッセージを14日間保持するSNSに登録されているSQSを1つ追加しました。通常は誰もこのSQSから読み取ることはできませんが、データを巻き戻したいバグが発生した場合は、このSQSからすべてのメッセージを簡単に読み取ってSNSに再送信できます。Kinesisは7日間の保持のみを提供します。
結論として、SNS + SQSははるかに簡単で、ほとんどの機能を提供します。IMOあなたはそれよりもキネシスを選択するために本当に強力なケースが必要です。
splitを使用しないでしょうSNS split the message to multiple SQSs。
Kinesisは複数のコンシューマー機能をサポートしています。つまり、同じデータレコードを異なるコンシューマーで24時間以内に同時に処理したり、別の時間に処理したりできます。SQSの同様の動作は、複数のキューに書き込み、コンシューマーは複数のキューから読み取ることができます。ただし、複数のキューに再度書き込むと、システムでサブ秒のレイテンシ（数ミリ秒）が追加されます。
第2に、Kinesisは、特定のEC2インスタンスで処理でき、マイクロバッチ計算を可能にするパーティションキーを使用して、データレコードを異なるシャードに選択的にルーティングするルーティング機能を提供します{カウントと集計}。
AWSソフトウェアでの作業は簡単ですが、SQSを使用するのが最も簡単です。Kinesisでは、事前に十分なシャードをプロビジョニングし、スパイク負荷を管理するために動的にシャード数を増やし、管理に必要なコストを節約するために減らす必要があります。それはキネシスの痛みです、SQSではそのようなことは必要ありません。SQSは無限にスケーラブルです。
これらのテクノロジーは、さまざまなシナリオをサポートするように設計されているため、セマンティクスは異なります。
例で違いを理解しましょう。
1つのアイテムの処理を別のアイテムの処理から分離できない場合、すべてのケースを安全に処理するには、Kinesisセマンティクスが必要です。
AWSドキュメントからの抜粋：
次のような要件のユースケースには、Amazon Kinesis Streamsをお勧めします。
関連するレコードを同じレコードプロセッサにルーティングする（ストリーミングMapReduceの場合と同様）。たとえば、特定のキーのすべてのレコードが同じレコードプロセッサにルーティングされる場合、カウントと集計はより簡単になります。
レコードの順序。たとえば、ログステートメントの順序を維持しながら、アプリケーションホストから処理/アーカイブホストにログデータを転送するとします。
複数のアプリケーションが同じストリームを同時に消費する機能。たとえば、リアルタイムダッシュボードを更新するアプリケーションと、Amazon Redshiftにデータをアーカイブするアプリケーションがあります。両方のアプリケーションが同じストリームからのデータを同時にかつ独立して消費するようにします。
数時間後に同じ順序でレコードを消費する機能。たとえば、請求アプリケーションと、請求アプリケーションの数時間遅れて実行される監査アプリケーションがあるとします。Amazon Kinesis Streamsは最大7日間データを保存するので、請求アプリケーションより最大7日間遅れて監査アプリケーションを実行できます。
次のような要件のユースケースには、Amazon SQSをお勧めします。
メッセージングのセマンティクス（メッセージレベルのack / failなど）と可視性のタイムアウト。たとえば、作業項目のキューがあり、各項目の正常な完了を個別に追跡したいとします。Amazon SQSはack / failを追跡するため、アプリケーションは永続的なチェックポイント/カーソルを維持する必要はありません。Amazon SQSは、構成された可視性タイムアウトの後で、確認されたメッセージを削除し、失敗したメッセージを再配信します。
個々のメッセージの遅延。たとえば、ジョブキューがあり、個々のジョブを遅延してスケジュールする必要があるとします。Amazon SQSを使用すると、個々のメッセージを最大15分の遅延を持つように構成できます。
読み取り時の並行性/スループットを動的に増加させます。たとえば、作業キューがあり、バックログがクリアされるまでリーダーを追加したいとします。Amazon Kinesis Streamsを使用すると、十分な数のシャードにスケールアップできます（ただし、事前に十分なシャードをプロビジョニングする必要があることに注意してください）。
透過的にスケーリングするAmazon SQSの機能を活用します。たとえば、リクエストをバッファリングすると、時々発生するロードスパイクやビジネスの自然な成長の結果としてロードが変化します。バッファリングされた各リクエストは個別に処理できるため、Amazon SQSは透過的にスケーリングして、ユーザーからのプロビジョニングの指示なしで負荷を処理できます。
私にとっての最大の利点は、Kinesisは再生可能なキューであり、SQSはそうではないという事実です。そのため、Kinesisの同じメッセージの複数のコンシューマー（または異なる時点での同じコンシューマー）を持つことができます。SQSでは、メッセージが確認されると、そのキューから削除されます。そのため、SQSはワーカーキューに適しています。
もう1つ：KinesisはLambdaをトリガーできますが、SQSはトリガーできません。そのため、SQSでは、EC2インスタンスを提供してSQSメッセージを処理する（および失敗した場合はそれに対処する）か、スケジュールされたLambda（スケールアップまたはスケールダウンせず、1分あたり1つしか取得しない）が必要です。 。
編集：この答えは正しくありません。2018年6月の時点で、SQSは直接Lambdaをトリガーできます
価格モデルは異なるため、ユースケースに応じてどちらかが安くなる場合があります。最も単純なケース（SNSは含まない）を使用：
現在の料金を差し込み、無料枠を考慮せずに、最大メッセージサイズで1日あたり1 GBのメッセージを送信すると、KinesisはSQSよりもはるかに高くなります（Kinesisの場合は月額$ 10.82対SQSの場合は月額$ 0.20 /） 。ただし、1日あたり1 TBを送信する場合、Kinesisの方がいくらか安くなります（SQSの場合は月額$ 158に対して月額$ 158）。
詳細：SQSは、100万リクエスト（それぞれ64 KB）あたり$ 0.40を請求するため、GBあたり$ 0.00655です。1日あたり1 GBで、これは月額$ 0.20未満です。1日あたり1 TBで、1か月あたり201ドル強になります。
Kinesisは、100万リクエスト（各25 KB）あたり$ 0.014を請求するため、GBあたり$ 0.00059です。1日あたり1 GBで、これは月額$ 0.02未満です。1日あたり1 TBの場合、月額約18ドルです。ただし、Kinesisはシャード時間あたり$ 0.015も請求します。1 MB /秒あたり少なくとも1つのシャードが必要です。1日あたり1 GBの場合、1シャードで十分なので、1日あたり0.36ドルが追加され、1か月あたりの総コストは10.82ドルになります。1日あたり1 TBの場合、少なくとも13個のシャードが必要であり、これにより1日あたりさらに$ 4.68が追加され、合計コストは月あたり$ 158になります。
他に誰も言及していないことをもう1つ追加します。SQSは数桁も高価です。
キネシスのユースケース
SQSの使用例