Kinesis Data Streams と Firehose の違いを整理する
AWS を勉強していると、Kinesis Data Streams と Kinesis Data Firehose の違いで一度は引っかかります。
どちらも「データを流すサービス」に見えるので、雑に覚えると同じ箱に入ってしまいがちです。ですが、実際には役割がかなり違います。
この記事では、自由に処理したいのか、それとも運用負荷を減らして配送したいのかという軸で、Kinesis Data Streams と Firehose を整理します。試験対策でも実務でも、この切り分けができるだけで判断がかなり安定します。
まず結論
先に結論を書くと、考え方はかなりシンプルです。
- Kinesis Data Streams：ストリーミングデータを自分で取り回し、独自のコンシューマーで処理したいときに向く
- Kinesis Data Firehose：S3 や Amazon Redshift などへ、できるだけ少ない運用で配送したいときに向く
つまり、
- 細かく制御したいなら Streams
- まず届けたいなら Firehose
です。
Kinesis Data Streams の役割
Kinesis Data Streams は、リアルタイムデータを取り込み、アプリケーション側で自由に処理するための基盤です。
たとえば、
- 複数のコンシューマーで同じデータを別々に処理したい
- Lambda や独自アプリケーションで加工したい
- データの取り方や再処理の流れを細かく制御したい
といったケースで向いています。
Streams は、いわば生のデータストリームを自分で料理するための材料置き場です。自由度は高いですが、そのぶんコンシューマー設計、スケーリング、再処理の考慮など、こちら側で面倒を見る範囲も増えます。
Streams が向いている場面
- リアルタイム分析を自前で組みたい
- Lambda やアプリで独自ロジックを挟みたい
- 同じデータを複数用途で使いたい
- 処理順序や消費方法を自分で設計したい
Kinesis Data Firehose の役割
一方の Kinesis Data Firehose は、ストリーミングデータを S3、Amazon Redshift、OpenSearch Service などに、なるべく運用を軽くして届けるためのサービスです。
Firehose では、コンシューマーを自前で育てるより、配達をかなり任せられるのが大きな特徴です。
たとえば、
- ログをまず S3 に蓄積したい
- データを Redshift に流し込みたい
- バッファリングや配信の運用をなるべく減らしたい
という場面では、Firehose の方が素直です。
Firehose が向いている場面
- まず安全に S3 に蓄積したい
- Redshift 連携を早く作りたい
- 配送基盤の自前実装を避けたい
- 運用コストを下げたい
比較表で整理する
| 観点 | Kinesis Data Streams | Kinesis Data Firehose |
|---|---|---|
| 主な役割 | 自由に処理するためのストリーム基盤 | 配送を簡素化する配信基盤 |
| 処理の自由度 | 高い | 比較的低い |
| コンシューマー設計 | 自前で考える | かなり任せられる |
| 代表的な配送先 | Lambda、独自アプリ、分析基盤 | S3、Amazon Redshift など |
| 向いている問い | どう処理するか？ | どこへ楽に届けるか？ |
この表だけでも、かなり迷いにくくなります。
典型ユースケースでの見分け方
1. アプリで独自処理を入れたい
この場合は Kinesis Data Streams が有力です。
たとえば、受け取ったイベントを Lambda で整形したり、複数のマイクロサービスへ流したりするなら、Streams の自由度が効きます。
2. とにかく S3 にためたい
この場合は Kinesis Data Firehose が素直です。
ログやイベントをまず S3 に集め、その後 Athena や Redshift 側で活用したいなら、Firehose の方が実装も運用も軽くなりやすいです。
3. Redshift までまとめて持っていきたい
これも Firehose を先に疑う場面です。配信の土台を自前で細かく組むより、まず届けることを優先した方が楽なケースが多いからです。
例えばどう考えるか
- 処理を作り込みたい → Streams
- 配送を省力化したい → Firehose
ここを曖昧にすると、試験でも実務でも「自由度は欲しいのに Firehose を選ぶ」「運用を減らしたいのに Streams で抱え込む」というズレが起きます。
試験で迷いやすいポイント
AWS 認定試験では、名前の似たサービスを並べて、どちらが要件に合うかを問う問題がよく出ます。
- 独自コンシューマーでリアルタイム処理したい → Kinesis Data Streams
- S3 や Amazon Redshift に素早く配送したい → Kinesis Data Firehose
- 運用を減らしたい → Firehose 寄り
- 細かい制御が必要 → Streams 寄り
この切り分けができれば、かなり安定します。
実務ではどう使い分けるか
実務では、両者は競合というより役割分担で考える方が自然です。
たとえば、
- イベントを Kinesis Data Streams に入れる
- Lambda で加工する
- 必要に応じて S3 や分析基盤へ送る
という構成もあれば、
- ログを Firehose で受ける
- S3 に蓄積する
- Athena や Amazon Redshift で分析する
という構成もあります。
つまり、柔軟性を取るか、配送の楽さを取るかで選ぶのが基本です。
まとめ
Kinesis Data Streams と Kinesis Data Firehose は、どちらもデータを流すサービスですが、見ている役割が違います。
- Streams：自由に処理するための基盤
- Firehose：届けることを楽にする基盤
この切り分けを押さえておくと、試験でも実務でも判断がかなり楽になります。