Amazon Data Firehoseとは？旧Kinesis Data Firehoseとの違い・配信先・料金と実装判断を解説【2026年版】

Amazon Data Firehose（旧 Amazon Kinesis Data Firehose）は、ストリーミングデータを Amazon S3 や Amazon Redshift などの保存先・分析基盤へ、サーバーの管理なしで届けるフルマネージドの配信サービスです。2024年2月に「Kinesis」を外した現在の名称へ改称されました。本記事では、実装者の視点で Firehose の定義・対応データソースと配信先・データ変換・バッファリング・料金体系を整理し、Amazon Kinesis Data Streams との使い分けや採用判断まで解説します。

まとめ（先に結論）

• Amazon Data Firehose は、ストリーミングデータを「受け取って宛先へロードする」ことに特化したフルマネージド配信サービス。ストリームの保持やシャード管理はなく、配信ストリームを1つ作れば取り込みから宛先ロードまでが自動で動く。
• データソースは Direct PUT、Amazon Kinesis Data Streams、Amazon MSK、CloudWatch Logs のサブスクリプションフィルターなど。配信先は S3・Redshift・検索/ログ可視化サービス・Apache Iceberg テーブル・Snowflake・Splunk・各種HTTPエンドポイントに対応する。
• 配信前に Lambda でレコードを変換でき、JSON を Parquet／ORC の列指向形式へ変換して S3 に置くこともできる（AWS Glue のスキーマを参照）。動的パーティショニングで宛先S3のプレフィックスを内容に応じて振り分けられる。
• 料金はソースと宛先で計算方法が変わる。Direct PUT／Kinesis Data Streams 由来は取り込みデータ量を5KB単位に丸めて従量課金、Snowflake や Apache Iceberg 宛ては GB 単位（5KB丸めなし）で課金される（単価はリージョン・時点で変わるため公式料金ページで確認する）。
• 「S3・データレイク・検索基盤へニアリアルタイムに集約したい／運用を持ちたくない」なら Firehose が合う。ミリ秒級の低遅延や、同一ストリームの複数コンシューマー・再処理（リプレイ）が要るなら Kinesis Data Streams を選ぶ。

Amazon Data Firehoseとは何か｜AWSにおける定義と2024年の改称

Amazon Data Firehose は、絶え間なく発生するストリーミングデータを受け取り、指定した保存先や分析サービスへ自動でロードするフルマネージドサービスです。プロデューサー（送信側）が配信ストリームへデータを送ると、Firehose がバッファリング・任意の変換・圧縮・暗号化を挟んだうえで宛先へ届けます。クラスターやサーバーを構築・保守する必要はありません。スループットに応じて自動でスケールする点が土台になります。ストリーミング配信そのものの前提を確認したい場合は、ストリーミングとは？仕組み・種類・配信を支える技術をわかりやすく解説もあわせて参照してください。

Amazon Data Firehoseの定義と配信サービスとしての立ち位置

Firehose が担うのは「取り込んだデータを宛先へ確実にロードする」配信の一段です。データの蓄積・保持や、同じデータを複数のアプリケーションが独立して読み進める用途は守備範囲ではありません。宛先への到達を保証するためのリトライ、失敗レコードの S3 へのバックアップ、圧縮・暗号化といった配信まわりの面倒をサービス側が引き受けます。実装者はソースと宛先、変換ロジックの設計に集中できる構成です。運用要素を持たずにデータを届けたい、という用途に照準しています。

旧Kinesis Data Firehoseからの改称（2024年2月）

このサービスは長らく「Amazon Kinesis Data Firehose」という名称でしたが、2024年2月9日に「Kinesis」を外した「Amazon Data Firehose」へ改称されました（時点：2024年2月・AWS公表）。改称はマネジメントコンソール・公式ドキュメント・料金ページの表記に反映されています。ただし機能・API・料金の枠組みそのものが変わったわけではありません。既存の設定やアプリケーションは名称変更の影響を受けず、そのまま動作します。旧称でしか記述のない古い技術記事や社内ドキュメントを読む際は、両者が同一サービスを指す点を押さえておくと混乱を避けられます。

Kinesis Data Streamsとの役割分担と使い分けの起点

名前が似ているため混同されがちですが、Firehose と Kinesis Data Streams は役割が分かれます。Data Streams は生のストリームを一定期間保持し、シャードという単位で並列度を管理しながら、複数のコンシューマーが各自のオフセットで読み進められる「ストリームの保持・配信基盤」です。対して Firehose は保持やシャードの概念を持たず、受け取ったデータを宛先へ届ける「配信の出口」に徹します。Data Streams を含む Kinesis 全体の仕組みや容量モードは、Amazon Kinesisとは｜Data Streams・Firehoseの仕組みと料金・実装・採用判断を解説で整理していますので、Kinesis ファミリー全体から見て Firehose の立ち位置を確認したい場合はそちらを起点にしてください。

Amazon Data Firehose が対応するデータソースと配信先のマッピング

Firehose の設計は「どこから受け取り、どこへ届けるか」の組み合わせで決まります。ソースと宛先を先に押さえると、構成の見通しが立ちます。

対応データソース｜Direct PUT・Data Streams・MSK・ログ

ソースは主に4系統です。第一に Direct PUT で、SDK やエージェントから PutRecord API で直接送り込む方式。第二に Kinesis Data Streams を上流に置き、そのストリームを Firehose が読み取って宛先へ流す方式。第三に Amazon MSK（マネージド Kafka）のトピックをソースにする方式。第四に CloudWatch Logs のサブスクリプションフィルター経由で、ログをそのまま S3 やデータレイクへ流す方式です。特にログ集約の用途では CloudWatch と組み合わせる構成が扱いやすく、収集済みログのクエリ側は CloudWatch Logs Insightsの概要と機能で扱う仕組みと役割分担させると設計が整理できます。

対応する配信先｜S3・Redshift・データレイクへのロード

宛先は年々増えており、実装時は公式ドキュメントで最新の対応を確認するのが前提です。2026年7月時点で選べる主な宛先を整理します。

宛先ごとに認証やバッファの前提が異なるため、まず主要な配信先（多くの場合 S3）から検証を始め、要件に応じて Redshift や検索基盤を足していく進め方が無理がありません。

Lambda によるデータ変換とフォーマット変換（Parquet／ORC）

Firehose は宛先へ届ける前にレコードを加工できます。Lambda 関数を呼び出して、フィルタリング・整形・項目の付与といった変換を挟む方式が基本です。この変換の実装イメージは、AWSサーバーレスアーキテクチャ：DynamoDBの構築からAPI Gatewayの設定までで扱う Lambda 中心の構成が参考になります。加えて、S3 宛てでは JSON レコードを Parquet または ORC の列指向フォーマットへ変換する機能があり、その際は AWS Glue Data Catalog のスキーマを参照する仕組みです。列指向へ変換しておくと、後段の Amazon Athena などでのスキャン量が減り、クエリ費用を抑えやすくなります。変換とロードの関係を整理したい場合は、ETLとは？仕組み・ELTとの違い・ツール選定から導入判断まで解説で ETL／ELT の考え方を確認すると、Firehose がどの段を担うかが明確になります。

バッファサイズとバッファ間隔・ゼロバッファリング設定の考え方

Firehose はレコードを即時に1件ずつ届けるのではなく、一定量または一定時間ぶんをまとめて宛先へ書き込みます。この単位がバッファサイズ（MB単位）とバッファ間隔（秒単位）です。宛先やソースにより設定できる範囲は異なり、S3宛てでは概ねサイズ1〜128MiB・間隔0〜900秒の範囲で指定する形になります。まとめて書くほど1オブジェクトが大きくなり後段の効率は上がりますが、宛先に届くまでの遅延は伸びる。より低遅延が要る用途向けには、バッファ間隔を最小に寄せてほぼ待たずに届ける構成（ゼロバッファリング、2023年12月提供・時点情報）も選べます。遅延許容とファイルサイズのバランスを、後段の分析要件から逆算して決めるのが実務の勘所です。

Amazon Data Firehose の料金体系とコスト設計の考え方

Firehose の費用は、取り込んだデータ量に対する従量課金が土台ですが、ソースと宛先の組み合わせで課金単位が変わる点に注意します。設計時にここを取り違えると見積もりがずれます。

ソースと宛先の組み合わせで変わる課金の単位と5KB丸めルール

課金の考え方は大きく次のように分かれます。単価はリージョンと時点で変わるため、金額は必ず公式料金ページで確認してください。

小さなレコードを大量に送る Direct PUT 構成では、5KB切り上げの影響で「実データ量より課金対象が膨らむ」場合がある。この場合は送信側でレコードをある程度まとめてから送ると、丸めの無駄を減らせます。フォーマット変換や動的パーティショニング、VPC内の宛先への配信には追加料金がかかるため、機能を足す前に費用への跳ね返りを見積もります。

費用を膨らませないための課金単位を踏まえたコスト設計上の判断

費用を抑える勘所は3つに絞れます。第一に、Direct PUT で小口レコードが多いならバッチ化して5KB丸めの影響を薄める。第二に、S3宛てでは Parquet／ORC への変換で後段のスキャン費用まで含めて総額を下げる（変換料金と削減額を比較する）。第三に、宛先を増やすほど配信料金が積み上がるため、まず必須の宛先だけで始めて実測してから広げる。ストリーミングデータを分析基盤へ取り込む段の設計・構築を相談したい場合は、データ分析基盤構築・MLOps構築支援で、ソースから宛先・変換・後段分析までを受託開発の実務として支援します。

Amazon Data Firehose を採用すべき場面と見送るべき場面

ここは判断を言い切ります。Firehose を採用すべき条件は、(1) ログ・イベント・メトリクスを S3・検索基盤・Redshift・Snowflake などへニアリアルタイムに集約したい、(2) ストリーム処理の基盤を自前で運用したくない、(3) 配信前の軽い変換や列指向フォーマット化を宛先ロードとまとめて済ませたい、のいずれかに当てはまる場合です。この条件では、EC2 上に収集・変換・ロードの仕組みを自作するより、運用負荷と障害リスクを下げやすくなります。

一方で見送るべき場面もはっきりしています。ミリ秒級の低遅延が要る、同一データを複数のアプリケーションが独立して読み進める、あるいは受信後に一定期間保持して再処理（リプレイ）したい——こうした要件では、保持とシャードを持つ Kinesis Data Streams が本来の受け皿になる。Firehose は保持を持たないため、宛先へ届いた後に上流を遡って読み直すことはできません。また、複雑なストリーム集計やウィンドウ処理が主目的なら、Managed Service for Apache Flink のような処理エンジンが適します。失敗しやすいのは、Data Streams で足りる保持・リプレイ要件を Firehose だけで組もうとするパターンで、後から保持層を足す作り直しが発生する。「配信の出口」に用途を絞れるかどうかで採否を決めてください。

よくある質問

Amazon Data Firehose と Amazon Kinesis Data Firehose は違うサービスですか？

同じサービスです。2024年2月9日に「Amazon Kinesis Data Firehose」から「Amazon Data Firehose」へ改称されました。名前から「Kinesis」が外れただけで、機能・API・料金の枠組みは引き継がれています。旧称で書かれた資料も現行サービスを指すものとして読めます。

Firehose と Kinesis Data Streams はどちらを使うべきですか？

宛先へ届けるだけで、保持や複数コンシューマーの並列読み取りが不要なら Firehose が向きます。生ストリームを一定期間保持し、複数のアプリで独立に読んだり再処理したりしたいなら Kinesis Data Streams が候補です。Data Streams を上流、Firehose を配信の出口として組み合わせる構成も一般的に使われます。

Firehose はリアルタイムに届きますか？

厳密なリアルタイムではなく、ニアリアルタイムです。バッファサイズ（MB）とバッファ間隔（秒）でまとめて配信するため、既定では数十秒〜数分の遅延が生じます。バッファ間隔を最小に寄せたゼロバッファリング構成にすると、待ち時間をほぼ無くして届けられます（宛先により対応範囲は異なる）。

どんな配信先に対応していますか？

Amazon S3、Amazon Redshift、全文検索・ログ可視化サービス、Apache Iceberg テーブル、Snowflake、Splunk、Datadog や New Relic といったパートナー、独自の HTTP エンドポイントなどに対応します。対応先は追加されるため、実装時は公式ドキュメントで最新の一覧を確認してください。

料金はどう計算されますか？

取り込んだデータ量に対する従量課金が基本ですが、ソースと宛先で単位が変わります。Direct PUT や Kinesis Data Streams 由来はレコードを5KB単位に切り上げて計上し、Snowflake や Apache Iceberg 宛ては GB 単位（5KB丸めなし）です。フォーマット変換・動的パーティショニング・VPC配信には追加料金がかかります。単価はリージョン・時点で変わるため公式料金ページで確認してください。

関連記事

• Amazon Kinesisとは｜Data Streams・Firehoseの仕組みと料金・実装・採用判断を解説（Kinesisファミリー全体からの位置づけ）
• ストリーミングとは？仕組み・種類・配信を支える技術をわかりやすく解説（ストリーミング配信の前提概念）
• ETLとは？仕組み・ELTとの違い・ツール選定から導入判断まで解説（変換とデータ連携の位置づけ）
• AWSサーバーレスアーキテクチャ：DynamoDBの構築からAPI Gatewayの設定まで（Lambda変換の実装参考）
• クラウドとは？AWSとは何かを仕組み・料金・移行の判断まで事業者向けに解説（AWS前提の基礎理解）