# Kinesis Data Streams と Firehose の違いを整理する

AWS でストリーミング処理を学び始めると、Kinesis Data Streams と Kinesis Data Firehose の役割の違いで迷いやすくなります。

どちらもデータを流すサービスですが、同じことをするわけではありません。ここを曖昧にすると、試験では問題文に振り回され、実務では必要以上に重い構成を選びがちです。

この記事では、処理の自由度 と 配送の省力化 という軸で、Kinesis Data Streams と Firehose の違いを整理します。

結論：自由に処理したいなら Streams、楽に届けたいなら Firehose

まず結論として、役割は次のように分かれます。

  • Kinesis Data Streams：リアルタイムデータを取り込み、アプリケーションや Lambda で自由に処理したいときに向く
  • Kinesis Data Firehose：S3 や Amazon Redshift などへ、少ない運用でデータを配送したいときに向く

同じ Kinesis 系でも、見ている重点はかなり違います。

Kinesis Data Streams の役割

Kinesis Data Streams は、リアルタイムデータを受け取り、その後の処理を自分で組み立てるためのサービスです。

たとえば次のようなケースで向いています。

  • 独自コンシューマーを作りたい
  • Lambda で加工ロジックを入れたい
  • 同じデータを複数の処理系で使いたい
  • 再処理や消費方法を細かく制御したい

要するに Streams は、データの流れを自分で設計したいときの土台です。

そのぶん自由度は高いですが、コンシューマーの設計や運用負荷はこちら側に寄ります。

Kinesis Data Firehose の役割

Kinesis Data Firehose は、取り込んだデータを配信先へまとめて届けることに強いサービスです。

代表的な配送先としては、

  • Amazon S3
  • Amazon Redshift
  • OpenSearch Service

などがあります。

Firehose の良さは、配信基盤を細かく自前実装しなくても、まず届けるところまでをかなり単純化できる点です。

向いているケース

  • ログをまず S3 に蓄積したい
  • Redshift に取り込みたい
  • 配送まわりの運用を軽くしたい
  • できるだけ少ない実装で流したい

比較表で整理する

| 観点 | Kinesis Data Streams | Kinesis Data Firehose |

|---|---|---|

| 主な役割 | 処理のためのストリーム基盤 | 配送のための配信基盤 |

| 自由度 | 高い | 比較的低い |

| 実装負荷 | 高くなりやすい | 比較的軽い |

| 代表的な連携 | Lambda、独自アプリ | S3、Amazon Redshift |

| 向いている問い | どう処理するか | どこへ楽に届ける�� |

この表で見ると、役割の違いがかなりはっきりします。

典型パターンでの見分け方

独自処理を入れたい場合

イベントに対して独自ロジックを入れたり、複数コンシューマーで別々の処理をしたりするなら、Streams を先に疑うべきです。

まず S3 に蓄積したい場合

ログやイベントをまず S3 にため、その後に Athena や分析基盤で使いたいなら Firehose が素直です。

Redshift に届けたい場合

Redshift までの配信を簡素にしたいなら、Firehose はかなり相性がいい選択肢です。

例えばどう整理するか

  • 処理を作り込みたい → Streams
  • 配信を省力化したい → Firehose

この軸を持っていると、サービス名に引っ張られにくくなります。

試験対策としての見方

AWS 認定試験では、次の切り分けを問われやすいです。

  • リアルタイムに独自処理したい → Kinesis Data Streams
  • S3 や Amazon Redshift に届けたい → Kinesis Data Firehose
  • 運用負荷を減らしたい → Firehose
  • 柔軟性が必要 → Streams

単に「Kinesis を使う」ではなく、どこまで自前で持つか を意識して選ぶのがコツです。

実務ではどう使い分けるか

実務では、どちらか一方が常に正解というより、要件次第で選び分けます。

たとえば、

1. Streams でデータを受ける

2. Lambda で加工する

3. その後 S3 に蓄積する

という形もありますし、

1. Firehose でログを受ける

2. S3 に集める

3. 分析基盤で後から使う

という形もあります。

ここで大事なのは、自由度を優先するなら Streams、運用の軽さを優先するなら Firehose という基本線を崩さないことです。

まとめ

Kinesis Data Streams と Kinesis Data Firehose は、どちらもストリーミング関連サービスですが、役割は同じではありません。

  • Streams は 処理の自由度を取るサービス
  • Firehose は 配送の省力化を取るサービス

この切り分けを押さえておくと、試験でも実務でも判断がかなり安定します。