はじめに
ある日、お客様より以下のような問い合わせをいただきました。
「CloudWatchのFirehose:IncomingBytes※ メトリクスを全て合算してもそこまでのデータ量を取り込んでいないように見えるが、何が原因でコストがかかっているかを教えてほしい。」
本記事では、実際の問い合わせ調査をもとに、なぜデータ量は少ないのに高額請求になるのかを、メトリクスと数式で検証します。
※ IncomingBytes：指定された期間に Firehose ストリームに正常に取り込まれたバイト数。
事象の整理
対象日：2026/XX/XX
請求情報：
APN1-BilledBytes：約2,025 GB
コスト：約 $72.90
CloudWatchメトリクス：
IncomingBytes ：約361 MB
IncomingBytesを見る限り、受信データ量は約0.35GBです。
しかし請求対象は約2,025GBとなっており、受信データ量と請求対象のデータ量に大きな乖離があります。
Firehoseの取り込み課金仕様
Firehoseでは、1レコードが 5KB 未満であっても、請求上は 5KB としてカウントされます。
例えば、500バイトのレコードを1つ送ると、実際のサイズ（0.5KB）ではなく5KB分が課金対象となります。
Amazon Data Firehose のクォータ - 注記
データレコードが小さくなると、コストが高くなる場合があります。Firehose の取り込み料金は、サービスに送信するデータレコードの数、すなわち各レコードのサイズが最も近い 5 KB（5,120 バイト）に切り上げられた回数に基づきます。したがって、同じ量の受信データ (バイト) では、受信レコードの数が多い場合、発生するコストが高くなります。
調査・数値検証
CloudWatch メトリクスを用いて実際に数値を確認します。
CloudWatch メトリクスの確認
・IncomingBytes：全て選び、日付:該当日 統計:合計 期間：1日 グラフ形式を「数値」にして確認。→ 361Mと250Bが表示されている。
・IncomingRecords※：上記と同条件で確認。→ 424Mと524Kが表示されている。
※IncomingRecords：指定された期間に Firehose ストリームに正常に取り込まれたレコード数。
上記の結果から、
・受信データサイズ：約361M（0.35GB）
・レコード件数 ：約4億2452万4000件
であるとわかります。
平均レコードサイズの算出
1レコードあたりのサイズは不明なので、上記の値から平均レコードサイズを算出します。
約361M÷4億2452万4000件 ≒ 約 0.85 バイト
課金対象データ量の算出
平均レコードサイズ：約0.85 バイトなので、ほとんどのレコードのサイズが 5KB 未満と考えられます。そのため、「Firehoseの取り込み課金仕様」のとおり、一律 5KB として計算します。
レコード総数に、1レコードあたりの最小課金単位である 5KB を乗算します。
4億2452万4000件×5KB ≒ 2024.29GB
→ 請求情報のAPN1-BilledBytes：約2,025 GBとほぼ一致しており、請求額は妥当であるということがわかりました。
原因
原因は、1レコードあたりのサイズが極端に小さい（平均1バイト未満）データを、膨大な回数（4億件以上）受信しているためでした。
Firehoseはデータ総量ではなく、レコード単位（5KB丸め）で課金されるため、同じ容量でもレコード数が多いと課金額が増大するため、注意が必要です。
対策
コストを削減するには、Data Firehose に送信する前の段階でレコードを集約するなどし、
送信するレコード数を削減する対応が必要となります。
なお、Data Firehose 側ではなく、ログを出力・送信する側で対策を行う必要があります。DataFirehoseのバッファリングを長くしても、本事案は解決しません。DataFirehoseのバッファリング設定は、Data Firehose から配信先（S3 など）へデータを送信する際の動作を制御するものであり、取り込み時点の課金には直接関与しないためです。
まとめ
本記事のポイントは以下のとおりです。
・Firehose の取り込み課金は 5KB単位で切り上げられる。
・容量の小さいレコードでも、大量送信すると高コストになる。
・Firehose のバッファリング設定は、課金対策にはならない。
・対策は「送信側でのレコード集約」を行い、レコード件数を減らす。
もし「データ量は少ないのに請求が高い」という状況に遭遇した場合はまず、 IncomingRecords を確認してみてください。
原因は、細かいデータを膨大な件数で Firehose へ送信していることにあるのかもしれません。