--- title: "Amazon Data Firehoseとは？旧Kinesis Data Firehoseとの違い・配信先・料金と実装判断を解説【2026年版】" url: "https://www.issoh.co.jp/tech/details/15515/" published: 2026-07-23 updated: 2026-09-27 categories: ["AWS"] publisher: "株式会社一創" --- # Amazon Data Firehoseとは？旧Kinesis Data Firehoseとの違い・配信先・料金と実装判断を解説【2026年版】 Amazon Data Firehose（旧 Amazon Kinesis Data Firehose）は、ストリーミングデータを Amazon S3 や Amazon Redshift などの保存先・分析基盤へ、サーバーの管理なしで届けるフルマネージドの配信サービスです。2024年2月に「Kinesis」を外した現在の名称へ改称されました。本記事では実装者の視点で、定義・対応データソースと配信先・ストリーム作成の手順・データ変換・料金体系を整理し、Kinesis Data Streams との使い分けと採用判断まで解説します。数値は AWS 公式ドキュメント（2026年9月時点）を参照しました。 ## まとめ（先に結論） - Amazon Data Firehose は、データを受け取って宛先へロードすることに特化したフルマネージド配信サービス。保持もシャード管理もなく、ストリームを1つ作れば取り込みから宛先ロードまで自動で動く。 - ソースは Direct PUT・Kinesis Data Streams・Amazon MSK・CloudWatch Logs。宛先は S3・Redshift・検索/ログ可視化サービス・Apache Iceberg・Snowflake・Splunk・HTTPエンドポイント。 - バッファは `SizeInMBs`（既定5・1〜128 MiB）と `IntervalInSeconds`（既定300・0〜900秒）で指定し、片方を書いたらもう片方も必須。 - 配信前の Lambda 変換は戻り値に `recordId`・`result`・`data` の3つが要る。S3 宛てなら JSON を Parquet／ORC へ変換でき、動的パーティショニングは jq 1.6 の式で振り分ける。 - 料金はソースと宛先で計算方法が変わる。Direct PUT／Kinesis Data Streams 由来は5KB単位に丸めて従量課金、Snowflake や Apache Iceberg 宛ては GB 単位。 - S3・データレイク・検索基盤へニアリアルタイムに集約したいなら Firehose。低遅延や複数コンシューマー・リプレイが要るなら Kinesis Data Streams を選ぶ。 ## Amazon Data Firehoseとは何か｜AWSにおける定義と2024年の改称 Amazon Data Firehose は、絶え間なく発生するストリーミングデータを受け取り、指定した保存先や分析サービスへ自動でロードするフルマネージドサービスです。プロデューサー（送信側）が Firehose ストリームへ送ると、バッファリング・任意の変換・圧縮・暗号化を挟んで宛先へ届きます。サーバーの構築・保守は不要で、スループットに応じて自動でスケールする点が土台になる。前提となる概念は[ストリーミングとは？仕組み・種類・配信を支える技術をわかりやすく解説](https://www.issoh.co.jp/column/details/8331/)で確認できます。 ### Amazon Data Firehoseの定義と配信サービスとしての立ち位置 Firehose が担うのは「取り込んだデータを宛先へ確実にロードする」配信の一段です。データの蓄積・保持や、同じデータを複数のアプリケーションが独立して読み進める用途は守備範囲ではありません。到達を保証するリトライ、失敗レコードの S3 バックアップ、圧縮・暗号化はサービス側が引き受けます。[AWS公式の概要ドキュメント](https://docs.aws.amazon.com/firehose/latest/dev/what-is-this-service.html)が挙げる基本概念は「Firehose ストリーム」「レコード（最大1,000 KB）」「データプロデューサー」「バッファサイズとバッファ間隔」の4つで、この4語で構成のほぼ全体を説明できる。 ### 旧Kinesis Data Firehoseからの改称と現行ドキュメント表記 このサービスは長らく「Amazon Kinesis Data Firehose」でしたが、2024年2月に「Kinesis」を外した「Amazon Data Firehose」へ改称されました（時点：2024年2月・AWS公表）。旧称の「配信ストリーム（delivery stream）」も現行ドキュメントでは「Firehose ストリーム」へ寄っています。ただし機能・API・料金の枠組みが変わったわけではありません。API のアクション名は `CreateDeliveryStream`・`PutRecordBatch` のまま据え置かれ、既存の設定は影響を受けずに動きます。旧称でしか記述のない古い記事を読む際は、両者が同一サービスだと押さえておくと混乱を避けられます。 ### Kinesis Data Streamsとの役割分担と使い分けの起点 名前が似ているため混同されがちですが、両者は役割が分かれます。Data Streams は生のストリームを一定期間保持し、シャード単位で並列度を管理しながら複数のコンシューマーが各自のオフセットで読み進める「保持・配信基盤」。Firehose は保持もシャードも持たず、宛先へ届ける「配信の出口」に徹します。境目は保持にも表れていて、公式の[クォータ一覧](https://docs.aws.amazon.com/firehose/latest/dev/limits.html)によれば、ソースが Direct PUT のとき宛先障害時にデータを保持するのは最大24時間、Data Streams がソースならその設定に従う。ファミリー全体の見取り図は[Amazon Kinesisとは｜Data Streams・Firehoseの仕組みと料金・実装・採用判断を解説](https://www.issoh.co.jp/tech/details/15505/)を起点にしてください。 ## AWS CLIでFirehoseストリームを作成しS3へ配信するまでの手順 S3 を宛先にした Direct PUT のストリームなら、IAM ロールとバケットを用意すれば1コマンドで作れる。 ### Firehoseストリームを作成するCLIコマンドと最小の設定項目 [CreateDeliveryStream](https://docs.aws.amazon.com/firehose/latest/APIReference/API%5FCreateDeliveryStream.html) を CLI から叩く形が、設定の全体像をいちばん短く確認できます。以下は S3 を生データ層として使う最小構成で、`Prefix` の時刻式でパーティションを切り、エラー出力は別プレフィックスへ逃がしています。 ``` aws firehose create-delivery-stream \ --delivery-stream-name app-logs-to-s3 \ --delivery-stream-type DirectPut \ --extended-s3-destination-configuration '{ "RoleARN": "arn:aws:iam::123456789012:role/firehose-delivery-role", "BucketARN": "arn:aws:s3:::my-data-lake", "Prefix": "raw/app-logs/!{timestamp:yyyy/MM/dd}/", "ErrorOutputPrefix": "error/!{firehose:error-output-type}/", "BufferingHints": { "SizeInMBs": 64, "IntervalInSeconds": 300 }, "CompressionFormat": "GZIP" }' ``` ロールには対象バケットへの `s3:PutObject` と、暗号化に使う KMS キーの権限が要ります。バケット側の設計は[Amazon S3とは？オブジェクトストレージの仕組み・ストレージクラスと料金・採用判断を実装者目線で解説](https://www.issoh.co.jp/tech/details/15433/)にまとめました。管理系 API は1秒あたり5回が上限（引き上げ不可）です。 ### PutRecordBatchでレコードを送り込み配信結果を確認する 作ったストリームへは [PutRecordBatch](https://docs.aws.amazon.com/firehose/latest/APIReference/API%5FPutRecordBatch.html) でまとめて投入します。1回の呼び出しで最大500レコードまたは4 MiB のいずれか小さい方までで、変更できません。データは base64 エンコードして渡します。 ``` aws firehose put-record-batch \ --delivery-stream-name app-logs-to-s3 \ --records '[ {"Data":"eyJldmVudCI6ImxvZ2luIiwibGV2ZWwiOiJJTkZPIiwidGVuYW50X2lkIjoidC0wMDEifQo="}, {"Data":"eyJldmVudCI6InB1cmNoYXNlIiwibGV2ZWwiOiJJTkZPIiwidGVuYW50X2lkIjoidC0wMDIifQo="} ]' ``` 応答の `FailedPutCount` が0でなければ、`RequestResponses` の同じ添字からエラーコードを特定し、失敗分だけ再送します。Direct PUT のスループット上限は東京を含む多くのリージョンで毎秒10万レコード・毎秒1,000リクエスト・毎秒1 MiB が既定、バージニア北部・オレゴン・アイルランドはその5倍。超過時は自動で引き上げにかかるが、収まるまで時間がかかるため送信側のリトライは必須です。 ### S3宛てのバッファサイズとバッファ間隔の指定範囲と既定値を決める Firehose はレコードを1件ずつ届けるのではなく、一定量または一定時間ぶんをまとめて宛先へ書き込みます。[BufferingHints](https://docs.aws.amazon.com/firehose/latest/APIReference/API%5FBufferingHints.html) の仕様では、`SizeInMBs` が既定5・範囲1〜128 MiB、`IntervalInSeconds` が既定300・範囲0〜900秒。片方だけの指定はできません。公式が示すサイズの決め方は「10秒間に流し込む量より大きくする」で、毎秒1 MiB なら10 MiB 以上が目安です。 まとめて書くほど1オブジェクトが大きくなり後段のクエリ効率は上がるが、遅延は伸びる。間隔を0秒へ寄せればほぼ待たずに届く代わりに、小さなオブジェクトが大量に生まれます。小さなファイルが積み上がると Athena のスキャン効率が落ちるため、遅延許容とファイルサイズのバランスは後段の分析要件から逆算する。費用の動き方は[Amazon Athenaの料金：スキャン量課金の実額とパーティション設計での削減](https://www.issoh.co.jp/tech/details/17347/)の実額と突き合わせます。 ## Amazon Data Firehose が対応するデータソースと配信先のマッピング Firehose の設計は「どこから受け取り、どこへ届けるか」の組み合わせで決まります。ソースと宛先を先に押さえると構成の見通しが立つ。 ### 対応データソース｜Direct PUT・Data Streams・MSK・ログ ソースは主に4系統です。第一に Direct PUT で、SDK やエージェントから `PutRecord`／`PutRecordBatch` API で直接送り込む方式。第二に Kinesis Data Streams を上流に置いて読み取る方式。第三に Amazon MSK（マネージド Kafka）のトピックをソースにする方式で、パーティションあたり毎秒10 MB の読み取りが既定、レコード最大サイズは Lambda 変換を有効にすると6 MB・無効なら10 MB。Kafka 側は[Amazon MSK（Managed Streaming for Apache Kafka）とは？仕組み・料金・使い方とKafka自前運用との比較を解説](https://www.issoh.co.jp/tech/details/15509/)で扱っています。第四に CloudWatch Logs のサブスクリプションフィルター経由。ログのクエリ側の担当範囲は[CloudWatch Logs Insightsの料金と使い方｜スキャン課金・limit上限・3つのクエリ言語【2026年版】](https://www.issoh.co.jp/column/details/2900/)にまとめました。 ### 対応する配信先｜S3・Redshift・データレイクへのロード 宛先は年々増えるため、実装時は[宛先設定のドキュメント](https://docs.aws.amazon.com/firehose/latest/dev/create-destination.html)で確認します。2026年9月時点の主な宛先は次のとおり。 | 配信先 | 主な用途 | 補足 | | ------------------- | ------------ | ---------------------- | | Amazon S3 | データレイクの基盤層 | 変換・分割と相性が良い | | Amazon Redshift | DWHへのロード | 一旦S3へ置きCOPYで取り込む | | 検索/ログ可視化サービス | ログ・全文検索の可視化 | ダッシュボード監視の宛先 | | Apache Iceberg テーブル | テーブル形式のレイク | 更新・スキーマ進化に対応 | | Snowflake | 外部DWHへの直接ロード | Snowpipe Streaming と連携 | | Splunk／各種HTTP宛先 | SaaS監視・独自受信先 | Datadog・New Relic 等も対象 | Redshift 宛てはいったん S3 に置いてから `COPY` で取り込む二段構えで、公式ドキュメントも Firehose が発行する COPY コマンドとして説明しています。受け側の選定は[Amazon Redshift Serverlessとは｜サーバーレスDWHの仕組みと料金・実装・移行判断を解説](https://www.issoh.co.jp/tech/details/15469/)、Iceberg 宛ての前提は[オープンテーブルフォーマットとは？Iceberg・Delta Lake・Hudiの違いと選び方を実装視点で解説【2026年版】](https://www.issoh.co.jp/tech/details/13784/)で揃えます。宛先ごとに認証やバッファの前提が違うので、まず S3 から検証を始める進め方に無理がありません。 ## Lambda変換とParquet変換・動的パーティショニングの実装 処理の順序は公式ドキュメントに明記されていて、KPL のデアグリゲーション、JSON または区切り文字でのデアグリゲーション、Lambda 処理、データパーティショニング、データ形式変換、S3 配信の順に進みます。順序を知らずに設定すると、パーティショニングキーが空振りする。 ### Lambda変換関数がrecordIdとresultを返す実装の書き方 [データ変換のドキュメント](https://docs.aws.amazon.com/firehose/latest/dev/data-transformation.html)によると、Lambda 向けのバッファサイズヒントは0.2 MB〜3 MB（既定1 MB、Splunk と Snowflake だけ既定256 KB）、バッファ間隔ヒントは0〜900秒（既定60秒、Snowflake だけ30秒）。同期呼び出しのためリクエストとレスポンスの双方に6 MB のペイロード上限があり、関数の実行は最大5分まで。戻り値の必須フィールドは [recordId・result・data の3つ](https://docs.aws.amazon.com/firehose/latest/dev/data-transformation-status-model.html)で、`result` には `Ok`・`Dropped`・`ProcessingFailed` のいずれかを入れます。`recordId` が入力と食い違えば変換失敗の扱いです。 ``` import base64 import json def lambda_handler(event, context): output = [] for record in event["records"]: payload = json.loads(base64.b64decode(record["data"])) if payload.get("level") == "DEBUG": output.append({"recordId": record["recordId"], "result": "Dropped"}) continue payload["ingested_at"] = record["approximateArrivalTimestamp"] encoded = base64.b64encode( (json.dumps(payload) + "\n").encode("utf-8") ).decode("utf-8") output.append({"recordId": record["recordId"], "result": "Ok", "data": encoded}) return {"records": output} ``` 末尾に改行を足すのは、S3 のオブジェクトを Athena で読むときにレコード境界を保つためです。ロールとデプロイの手順は[AWS サーバーレス ハンズオン｜Lambda・DynamoDB・API GatewayでREST APIを作る手順【2026年版】](https://www.issoh.co.jp/tech/details/2818/)で先に通すと詰まりません。 ### JSONをParquetへ変換するGlueスキーマとSerDeの選び方 S3 宛てでは JSON レコードを Parquet または ORC の列指向フォーマットへ変換できます。[形式変換のドキュメント](https://docs.aws.amazon.com/firehose/latest/dev/record-format-conversion.html)が挙げる必須要素は、デシリアライザ・スキーマ・シリアライザの3つ。デシリアライザは OpenX JSON SerDe と Apache Hive JSON SerDe の2択で、迷うならタイムスタンプ形式の制約がない OpenX 側を選ぶよう公式が明示しています。Hive 側は列名のピリオド、`uniontype`、スキーマが数値型なのに JSON が文字列、のいずれにも対応しません。スキーマは AWS Glue Data Catalog に作って参照させます。入れ子の JSON は `STRUCT` 型で構造を合わせないと、指定のない属性が変換後に落ちる。 入力が CSV や構造化テキストなら、先に Lambda で JSON へ寄せてから変換します。複数の JSON を1レコードにまとめる場合、配列（`[{"a":1}, {"a":2}]`）は不正で、連結（`{"a": 1}{"b": 1}`）が正しい形です。Glue 側のスキーマ運用は[AWS GlueでETLジョブを動かす手順｜PySparkスクリプトとDPU課金の設計](https://www.issoh.co.jp/tech/details/17472/)が詳しい。[ETLとは？仕組み・ELTとの違い・ツール選定から導入判断まで解説](https://www.issoh.co.jp/column/details/13364/)と併読すると、Firehose がどの段を担うかが明確になります。 ### 動的パーティショニングのjq式とS3プレフィックスの設計と上限 動的パーティショニングは、レコードの中身で宛先 S3 のプレフィックスを振り分ける仕組みです。[公式ドキュメント](https://docs.aws.amazon.com/firehose/latest/dev/dynamic-partitioning.html)によると、サポートする jq は1.6のみ、パーティショニングキーは最大50個。アクティブパーティションは1ストリームあたり500が既定上限で、1パーティションあたり毎秒1 GB まで通る。アクティブ数は「1秒あたりの生成パーティション数×バッファ間隔」で見積もれ、毎秒3・間隔60秒なら平均180という計算です。 ``` { "DynamicPartitioningConfiguration": { "Enabled": true }, "ProcessingConfiguration": { "Enabled": true, "Processors": [ { "Type": "MetadataExtraction", "Parameters": [ { "ParameterName": "MetadataExtractionQuery", "ParameterValue": "{tenant:.tenant_id,level:.level}" }, { "ParameterName": "JsonParsingEngine", "ParameterValue": "JQ-1.6" } ] } ] }, "Prefix": "raw/!{partitionKeyFromQuery:tenant}/!{partitionKeyFromQuery:level}/" } ``` プレフィックスの数はパーティショニングキーの数と一致させる決まりで、ずれていると設定が通りません。送信側で複数イベントを1レコードにまとめている場合は、マルチレコードのデアグリゲーションを有効にしないと効きません。粒度が細かすぎるとアクティブパーティション上限に当たり、粗すぎると後段のスキャン量が減らない。階層設計は[データレイクとは？データウェアハウス・レイクハウスとの違いを実装視点で解説](https://www.issoh.co.jp/tech/details/13388/)に沿わせます。 ## Amazon Data Firehose の料金体系とコスト設計の考え方 Firehose の費用は取り込んだデータ量への従量課金が土台ですが、**ソースと宛先の組み合わせで課金単位が変わる**点に注意します。ここを取り違えると見積もりがずれる。 ### ソースと宛先の組み合わせで変わる課金の単位と5KB丸めルール 課金の考え方は次のように分かれます。単価はリージョンと時点で変わるため、金額は[公式料金ページ](https://aws.amazon.com/jp/firehose/pricing/)で確認してください。 | ソース／宛先 | 課金単位 | 丸めの扱い | | -------------------- | ------------ | -------------- | | Direct PUT／KDS由来 | 取り込みGB量の従量 | レコードを5KB単位に切上げ | | Amazon MSK 由来 | 取り込み／配信の大きい方 | 5KB丸めなし | | Snowflake／Iceberg 宛て | 処理したGB量 | 5KB丸めなし | | Vended Logs（WAF等） | 取り込みGB量 | 5KB丸めなし | 5KB 丸めの効き方は公式クォータのドキュメントが具体例で示しています。同じ5 MiB でも、5,000レコードに分けるより1,000レコードにまとめた方が安くなる。3 KB のレコードは5 KB、12 KB のレコードは15 KB として計上されるためです。加えてフォーマット変換、動的パーティショニング（処理GB量とS3オブジェクト1,000件あたり）、VPC配信（GB量とアベイラビリティーゾーン時間）に追加料金がかかります。 ### 費用を膨らませないための課金単位を踏まえたコスト設計上の判断 費用を抑える勘所は3つに絞れます。第一に、Direct PUT で小口レコードが多いならバッチ化して5KB丸めを薄める。第二に、S3宛てでは Parquet／ORC への変換で後段のスキャン費用まで含めて総額を下げる（変換料金と削減額を比較する）。第三に、宛先を増やすほど配信料金が積み上がるため、必須の宛先で始めて実測してから広げる。取り込み段の設計・構築は、[データ分析基盤構築・MLOps構築支援](https://www.issoh.co.jp/service/ai/data-platform/)でソースから宛先・変換・後段分析まで受託開発の実務として支援します。 ## Amazon Data Firehose を採用すべき場面と見送るべき場面 用途が「配信の出口」に収まるかどうかが、そのまま採否の線になる。 ### Firehoseを採用してよい条件とクォータから見た適用の範囲 **Firehose を採用してよい条件**は、(1) ログ・イベント・メトリクスを S3・検索基盤・Redshift・Snowflake などへ**ニアリアルタイムに集約**したい、(2) ストリーム処理の基盤を自前で運用したくない、(3) 配信前の軽い変換や列指向フォーマット化を宛先ロードとまとめたい、のいずれかです。EC2 上に収集・変換・ロードを自作するより運用負荷と障害リスクを下げやすくなる。規模の当たりも先に付きます。1レコードは base64 エンコード前で最大1,000 KiB、ストリーム数の既定上限は東京・バージニア北部・オレゴン・アイルランドで5,000、他は2,000・500・100と下がる。 ### Kinesis Data Streamsへ倒すべき要件と作り直しの失敗例 一方で**見送るべき場面**もはっきりしています。ミリ秒級の低遅延が要る、同一データを複数のアプリケーションが独立して読み進める、受信後に一定期間保持して再処理（リプレイ）したい——こうした要件では、保持とシャードを持つ Kinesis Data Streams が本来の受け皿になる。Firehose は保持を持たないため、宛先へ届いた後に上流を遡ることはできません。複雑な集計やウィンドウ処理が主目的なら Managed Service for Apache Flink が適します。**失敗しやすいのは、Data Streams で足りる保持・リプレイ要件を Firehose だけで組むパターン**で、後から保持層を足す作り直しが発生する。迷ったら Data Streams を上流、Firehose を出口として並べておけば、後からコンシューマーを足せます。 ## よくある質問 ### Amazon Data Firehose と Amazon Kinesis Data Firehose は違うサービスですか？ 同じサービスです。2024年2月に「Amazon Kinesis Data Firehose」から改称されました。名前から「Kinesis」が外れただけで、機能・API・料金の枠組みは引き継がれています。API のアクション名も `CreateDeliveryStream` のままなので、旧称の資料も現行サービスを指すものとして読めます。 ### Firehose と Kinesis Data Streams はどちらを使うべきですか？ 宛先へ届けるだけで、保持や複数コンシューマーの並列読み取りが不要なら Firehose が向きます。生ストリームを保持して複数のアプリで独立に読んだり再処理したりしたいなら Data Streams が候補です。Data Streams を上流、Firehose を出口として組み合わせる構成も広く使われています。 ### Firehose はリアルタイムに届きますか？ バッファはどう指定しますか？ 厳密なリアルタイムではなくニアリアルタイムです。`SizeInMBs` は1〜128 MiB（既定5）、`IntervalInSeconds` は0〜900秒（既定300）で、既定のままなら5分の待ちが入ります。片方だけの指定はできません。間隔を0まで下げれば待ち時間をほぼ無くせます（宛先により対応範囲は異なる）。 ### Lambda変換が失敗したレコードはどうなりますか？ 戻り値の `result` が `ProcessingFailed`、または `recordId` が入力と一致しないレコードは処理失敗となり、エラー用の S3 プレフィックスへ退避されます。`Dropped` は意図的な破棄なので成功扱いです。実行が5分を超えるとタイムアウトになるため、1バッチの処理は軽く保ちます。 ### 料金はどう計算されますか？ 取り込んだデータ量に対する従量課金が基本ですが、ソースと宛先で単位が変わります。Direct PUT や Kinesis Data Streams 由来はレコードを5KB単位に切り上げて計上し、Snowflake や Apache Iceberg 宛ては GB 単位（5KB丸めなし）。フォーマット変換・動的パーティショニング・VPC配信には追加料金がかかります。単価はリージョン・時点で変わるため公式料金ページで確認してください。 ## 関連記事 - [Amazon Kinesisとは｜Data Streams・Firehoseの仕組みと料金・実装・採用判断を解説](https://www.issoh.co.jp/tech/details/15505/) - [Amazon S3とは？オブジェクトストレージの仕組み・ストレージクラスと料金・採用判断を実装者目線で解説](https://www.issoh.co.jp/tech/details/15433/) - [Amazon Redshift Serverlessとは｜サーバーレスDWHの仕組みと料金・実装・移行判断を解説](https://www.issoh.co.jp/tech/details/15469/) - [Amazon Athenaの料金：スキャン量課金の実額とパーティション設計での削減](https://www.issoh.co.jp/tech/details/17347/) - [ETLとは？仕組み・ELTとの違い・ツール選定から導入判断まで解説](https://www.issoh.co.jp/column/details/13364/) --- 出典: [Amazon Data Firehoseとは？旧Kinesis Data Firehoseとの違い・配信先・料金と実装判断を解説【2026年版】]()（株式会社一創）