はじめに

ある日、お客様より以下のような問い合わせをいただきました。

「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 へ送信していることにあるのかもしれません。