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 ストリームへ送ると、バッファリング・任意の変換・圧縮・暗号化を挟んで宛先へ届きます。サーバーの構築・保守は不要で、スループットに応じて自動でスケールする点が土台になる。前提となる概念はストリーミングとは？仕組み・種類・配信を支える技術をわかりやすく解説で確認できます。

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

Firehose が担うのは「取り込んだデータを宛先へ確実にロードする」配信の一段です。データの蓄積・保持や、同じデータを複数のアプリケーションが独立して読み進める用途は守備範囲ではありません。到達を保証するリトライ、失敗レコードの S3 バックアップ、圧縮・暗号化はサービス側が引き受けます。AWS公式の概要ドキュメントが挙げる基本概念は「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 は保持もシャードも持たず、宛先へ届ける「配信の出口」に徹します。境目は保持にも表れていて、公式のクォータ一覧によれば、ソースが Direct PUT のとき宛先障害時にデータを保持するのは最大24時間、Data Streams がソースならその設定に従う。ファミリー全体の見取り図はAmazon Kinesisとは｜Data Streams・Firehoseの仕組みと料金・実装・採用判断を解説を起点にしてください。

AWS CLIでFirehoseストリームを作成しS3へ配信するまでの手順

S3 を宛先にした Direct PUT のストリームなら、IAM ロールとバケットを用意すれば1コマンドで作れる。

Firehoseストリームを作成するCLIコマンドと最小の設定項目

CreateDeliveryStream を 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とは？オブジェクトストレージの仕組み・ストレージクラスと料金・採用判断を実装者目線で解説にまとめました。管理系 API は1秒あたり5回が上限（引き上げ不可）です。

PutRecordBatchでレコードを送り込み配信結果を確認する

作ったストリームへは PutRecordBatch でまとめて投入します。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 の仕様では、SizeInMBs が既定5・範囲1〜128 MiB、IntervalInSeconds が既定300・範囲0〜900秒。片方だけの指定はできません。公式が示すサイズの決め方は「10秒間に流し込む量より大きくする」で、毎秒1 MiB なら10 MiB 以上が目安です。

まとめて書くほど1オブジェクトが大きくなり後段のクエリ効率は上がるが、遅延は伸びる。間隔を0秒へ寄せればほぼ待たずに届く代わりに、小さなオブジェクトが大量に生まれます。小さなファイルが積み上がると Athena のスキャン効率が落ちるため、遅延許容とファイルサイズのバランスは後段の分析要件から逆算する。費用の動き方はAmazon Athenaの料金：スキャン量課金の実額とパーティション設計での削減の実額と突き合わせます。

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自前運用との比較を解説で扱っています。第四に CloudWatch Logs のサブスクリプションフィルター経由。ログのクエリ側の担当範囲はCloudWatch Logs Insightsの料金と使い方｜スキャン課金・limit上限・3つのクエリ言語【2026年版】にまとめました。

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

宛先は年々増えるため、実装時は宛先設定のドキュメントで確認します。2026年9月時点の主な宛先は次のとおり。

Redshift 宛てはいったん S3 に置いてから COPY で取り込む二段構えで、公式ドキュメントも Firehose が発行する COPY コマンドとして説明しています。受け側の選定はAmazon Redshift Serverlessとは｜サーバーレスDWHの仕組みと料金・実装・移行判断を解説、Iceberg 宛ての前提はオープンテーブルフォーマットとは？Iceberg・Delta Lake・Hudiの違いと選び方を実装視点で解説【2026年版】で揃えます。宛先ごとに認証やバッファの前提が違うので、まず S3 から検証を始める進め方に無理がありません。

Lambda変換とParquet変換・動的パーティショニングの実装

処理の順序は公式ドキュメントに明記されていて、KPL のデアグリゲーション、JSON または区切り文字でのデアグリゲーション、Lambda 処理、データパーティショニング、データ形式変換、S3 配信の順に進みます。順序を知らずに設定すると、パーティショニングキーが空振りする。

Lambda変換関数がrecordIdとresultを返す実装の書き方

データ変換のドキュメントによると、Lambda 向けのバッファサイズヒントは0.2 MB〜3 MB（既定1 MB、Splunk と Snowflake だけ既定256 KB）、バッファ間隔ヒントは0〜900秒（既定60秒、Snowflake だけ30秒）。同期呼び出しのためリクエストとレスポンスの双方に6 MB のペイロード上限があり、関数の実行は最大5分まで。戻り値の必須フィールドは recordId・result・data の3つで、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年版】で先に通すと詰まりません。

JSONをParquetへ変換するGlueスキーマとSerDeの選び方

S3 宛てでは JSON レコードを Parquet または ORC の列指向フォーマットへ変換できます。形式変換のドキュメントが挙げる必須要素は、デシリアライザ・スキーマ・シリアライザの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課金の設計が詳しい。ETLとは？仕組み・ELTとの違い・ツール選定から導入判断まで解説と併読すると、Firehose がどの段を担うかが明確になります。

動的パーティショニングのjq式とS3プレフィックスの設計と上限

動的パーティショニングは、レコードの中身で宛先 S3 のプレフィックスを振り分ける仕組みです。公式ドキュメントによると、サポートする 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レコードにまとめている場合は、マルチレコードのデアグリゲーションを有効にしないと効きません。粒度が細かすぎるとアクティブパーティション上限に当たり、粗すぎると後段のスキャン量が減らない。階層設計はデータレイクとは？データウェアハウス・レイクハウスとの違いを実装視点で解説に沿わせます。

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

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

ソースと宛先の組み合わせで変わる課金の単位と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構築支援でソースから宛先・変換・後段分析まで受託開発の実務として支援します。

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の仕組みと料金・実装・採用判断を解説
• Amazon S3とは？オブジェクトストレージの仕組み・ストレージクラスと料金・採用判断を実装者目線で解説
• Amazon Redshift Serverlessとは｜サーバーレスDWHの仕組みと料金・実装・移行判断を解説
• Amazon Athenaの料金：スキャン量課金の実額とパーティション設計での削減
• ETLとは？仕組み・ELTとの違い・ツール選定から導入判断まで解説