CloudWatch Logs Insightsの料金は、スキャンした非圧縮ログ1GBあたり0.0076USD（東京リージョン）です。単価だけ見ると安いのですが、請求が膨らむ主な原因は、広い時間範囲や多数のロググループを繰り返しスキャンすることです。この記事では、東京の単価で月額を計算する式、請求の出どころをCost Explorerとクエリ履歴で突き止める手順、2026年に加わった無料のスキャン量見積もりまでを、AWSの公式資料と料金APIの値で整理します。後半ではlimitの上限やcount_ifの代わりになる書き方など、クエリ構文でつまずく点も扱います。
まとめ
- 課金はスキャンした非圧縮データ1GBあたり0.0076USD（東京）。無料枠は月5GBで、リージョンごとには増えない。
- スキャン量は選んだロググループと時間範囲を基準とするが、フィールドインデックスや
limit anyで減らせる。通常のlimitを付けても減らない。 - 取り込みは1GBあたり0.76USDでスキャンの100倍。ただし調査クエリや自動更新ダッシュボードを重ねると、スキャン料が取り込み料に並ぶ。
- 請求の出どころはCost Explorerの使用タイプ
DataScanned-Bytesで分け、クエリごとの量はbytesScannedで確かめる。 - 実行前の見積もりは
| estimateで取れ、この見積もりクエリ自体は課金されない（2026年に追加）。 - 取得件数は
limit省略で最大1万件、指定すれば10万件まで。count_ifは無く、日付文字列での期間指定は効かない。
Logs Insightsの課金の仕組みと東京リージョンの単価
課金対象は選んだ範囲の非圧縮バイト
AWSのユーザーガイドは、Logs Insightsのクエリはクエリ言語にかかわらず、スキャンした非圧縮ログデータの量で課金されると書いています。スキャンの基準になるのは、選択したロググループに含まれる、選択した時間範囲ぶんのログの合計です。条件に合った件数ではありません。filterで1件まで絞っても、limit 20を付けても、フィールドインデックスによる読み飛ばしやlimit anyによる走査の打ち切りがなければ、通常のフィルタや件数制限だけでは読む量は減りません。
もう一つの誤解が圧縮です。CloudWatch Logsは保存時に圧縮するため、ロググループ画面の保存バイト数はスキャン量よりかなり小さく出ます。2024年8月のクラスメソッドの記事は「元データの15%程度」と書いていますが、AWS自身の料金例は30GBが6GBに圧縮される仮定（約20%）を、CloudWatch Omniの料金例は0.15の係数を使っていて、公式の例同士でも数字が揃っていません。圧縮率はログの中身で変わるので、保存容量からスキャン量を逆算しないでください。スキャン量の目安になるのは、非圧縮の取り込み量を表すメトリクスIncomingBytesです。
東京リージョンの単価表と無料枠
AWSのPrice List API（ap-northeast-1、2026年10月7日版）から取った単価です。取り込みは自前のアプリが送るカスタムログの値、保存の下2行は後述のIntelligent Tieringを有効にしたときの単価で、VPCフローログやLambdaの関数ログのようなAWSサービスが出すログ（vended logs）は量に応じた段階料金になります。
| 課金対象 | 東京の単価 |
|---|---|
| Logs Insightsのスキャン | 0.0076 USD/GB |
| 取り込み（Standard） | 0.76 USD/GB |
| 取り込み（Essentials・旧Infrequent Access） | 0.38 USD/GB |
| vended logs（Standard・最初の10TB） | 0.76 USD/GB |
| vended logs（10TB超〜50TB超） | 0.38→0.152→0.076 USD/GB |
| 保存（Standard階層） | 0.033 USD/GB-月 |
| 保存（Intelligent TieringのInfrequent Access階層） | 0.0198 USD/GB-月 |
| 保存（Intelligent TieringのArchive Instant Access階層） | 0.0066 USD/GB-月 |
無料枠はCloudWatchの料金ページで「5GBのデータ（取り込み、アーカイブ保存、Logs Insightsのスキャン）」とされ、料金APIではスキャン・取り込み・保存のそれぞれに0〜5GBの無料区分があります。この区分はリージョン別ではなく「Global」なので、複数リージョンで使っても枠は増えません。Lambdaの関数ログは2025年5月1日から、この段階料金の対象になりました。
月額の計算例
無料枠適用前の計算式は「1回のスキャン量（GB）×回数×0.0076USD/GB」です。以下は1か月30日、ログが均等に1日20GB発生し、対象期間のログがすべて保持され、インデックス等で読み飛ばさない場合の概算です。取り込み料金の参考行だけは、未使用の月5GB無料枠を適用しています。
| 使い方 | 月のスキャン量 | 月額（東京） |
|---|---|---|
| 直近1時間を1日20回調べる | 約500GB | 約3.8USD |
| 直近7日を1日10回調べる | 42,000GB | 約319USD |
| 24時間範囲のウィジェットを5分ごとに更新 | 172,800GB | 約1,313USD |
| （参考）同じログの取り込み | 600GB | 約452USD |
直近1時間に絞った調査なら数ドルで済みます。一方、時間範囲を直近7日、実行回数を1日10回にすると、月のスキャン量は直近1時間を1日20回調べる場合の84倍になり、取り込み料に迫ります。スキャン料が最も高いのは表の3行目のウィジェット自動更新で、更新のたびにクエリを実行するため、24時間範囲のまま監視モニターに映しっぱなしにすると、取り込み料の3倍近いスキャン料が立ちます。ダッシュボードに置くウィジェットは、時間範囲を短くするか自動更新の間隔を延ばしてください。
CloudWatch Omniのスキャン料金との違い
2026年9月23日にGAしたCloudWatch Omniは、Logs Insightsとは別の料金体系です。Omniの料金ページでは、ログとトレースのスキャンが1GBあたり0.005USDで、月のログとスパンの取り込み量の5倍までは無料です。提供開始時はバージニア北部・オレゴン・アイルランドの3リージョンだけでしたが、2026年10月19日の告知で東京を含む8リージョンが加わり、料金APIにも東京のOmniスキャン（0.005USD/GB）の区分があります。
Omniの料金ページはスキャン料を「Omniの機能を使ったときの料金」と位置づけていて、料金APIでもLogs Insightsのスキャン（APN1-DataScanned-Bytes・0.0076USD/GB）とOmniのスキャン（APN1-Omni-DataScanned-Bytes・0.005USD/GB）は別の区分です。請求でどちらが動いているかは、次章のCost Explorerで使用タイプ名を見れば分かります。Omniの構成は、東京提供開始前の情報を含むCloudWatch Omniとは：料金・東京未対応の制約とAIエージェント計装の手順で詳しく扱っています。
Logs Insightsの請求額を特定する手順
請求書の「CloudWatch」が膨らんだとき、取り込み・保存・スキャンのどれが原因かを分けないと、削る場所を間違えます。スキャン料の増加と取り込み料の増加では、確認する使用タイプも対策も異なります。調べる順番は次の4段です。
Cost Explorerの使用タイプ別スキャン料
Cost Explorerでサービスを「CloudWatch」に絞り、グループ化を「使用タイプ」にします。CloudWatchの請求ガイドによると、Logs Insightsのスキャンは接尾辞DataScanned-Bytes（対応するAPIはStartQuery）で計上され、東京ならAPN1-DataScanned-Bytesです。取り込みはDataProcessing-Bytes、保存はTimedStorage-ByteHrsなので、どれが伸びたかがここで分かります。
bytesScannedによるクエリ単位のスキャン量確認
スキャン料が原因なら、どのクエリが重いかを見ます。APIのGetQueryResultsが返すstatisticsには、スキャンしたバイト数bytesScannedと件数recordsScanned、インデックスで読み飛ばした推定量estimatedBytesSkippedが入ります。過去に実行したクエリはDescribeQueriesで一覧でき、各クエリのbytesScannedについて公式は「クエリに伴うコストを示す」と説明しています。
aws logs describe-queries --status Complete --max-items 50 \
--query "queries[].[createTime,logGroupName,bytesScanned,userIdentity]" \
--output table
userIdentityにはクエリを実行したユーザーのARNが入るので、誰の操作かまで分かります。同じ利用者・同じロググループのクエリが数分おきに並ぶ場合は、ダッシュボードの自動更新やスケジュール実行を疑い、クエリ文と実行設定を照合します。
IncomingBytesによるロググループ別取り込み量の確認
取り込み料が原因なら、CloudWatchメトリクスの「ログ」→「ロググループメトリクス」でIncomingBytesを選び、統計を「合計」にしてロググループ別に並べます。このメトリクスはCloudWatch Logsに送られた非圧縮のバイト数なので、そのままスキャン量の上限の目安にもなります。突出したグループが見つかったら、出力元のログレベルや送信設定を直します。CloudTrailの証跡をCloudWatch Logsへ送っているとここが跳ねやすく、証跡の設計はCloudTrailとは？証跡設計と料金実額・Lake新規受付終了後の構成をCLIで解説で扱っています。
estimateによるスキャン量の事前見積もり
クエリを実行せずにスキャン量だけを返すestimateコマンドが使えます。AWSの告知は2026年9月29日ですが、ドキュメント履歴ではコマンドの追加が2026年7月22日付で載っています。公式リファレンスは、estimateはクエリの最後に置く必要があり、このコマンドを使うクエリにはLogs Insightsのクエリ料金がかからないと明記しています。コンソールでは、ロググループ・時間範囲・クエリ文を変えるたびにエディタに見積もりが自動で出ます。
fields @timestamp, @message
| filter @message like /error/
| estimate
返る値は概算で、実際のスキャン量とずれることがあります。それでも、7日範囲で数百GBと出た時点で範囲を絞り直せるので、重いクエリやスケジュール実行を新しく作る前には必ず通してください。
スキャン料金を下げる設定
時間範囲とロググループの限定によるスキャン量削減
最も効くのは範囲の指定です。クエリ文の中で@timestampを絞っても、時間範囲セレクタが7日のままなら7日ぶんを読みます。範囲はセレクタかAPIのstartTime・endTimeで最初から狭め、ロググループもサービス単位に分けておけば、調査対象だけを読めます。サンプルを見るだけならlimit any 20のように書くと、20件見つかった時点で走査を打ち切ります。結果の順序や時間帯の偏りは保証されないので、「エラーが出ているか」を見る用途に限ってください。
フィールドインデックスと自動インデックス
フィールドインデックスは、指定したフィールドを含まないログの処理をスキップさせる仕組みで、効くのはfilter フィールド = 値とINだけです。公式はlikeを使うクエリはインデックスを使わず常に全件を読むと書いています。インデックスはポリシー作成後に取り込んだJSONとサービスログにだけ付き、取り込みから30日間有効です。2026年9月29日からは、=とINでよく絞り込むフィールドをCloudWatch Logsが追加料金なしで自動的にインデックスするようになりました。自動分はロググループあたり20個の枠に数えられず、30日保持されます。恒久的に残したいフィールドだけ、コンソールかAPIでインデックスポリシーへ昇格させます。
Essentialsログクラスの安くならない部分
Infrequent AccessログクラスはEssentialsに改称されました。APIにはINFREQUENT_ACCESSとESSENTIALSのどちらも渡せ、2026年12月からはDescribeLogGroupsなどの応答がESSENTIALSを返します。名前が変わるだけで、機能と料金は変わりません。
Essentialsで安くなるのは取り込みだけです。公式は、保存料金とLogs Insightsの料金はどちらのクラスでも同じと書いています。スキャン代は下がりません。さらにEssentialsではフィールドインデックス、メトリクスフィルタ、サブスクリプションフィルタ、Live Tail、異常検出、前期間との比較が使えず、GetLogEvents・FilterLogEventsでも読めません（中身はLogs Insightsで見る）。ログクラスは作成後に変えられないので、アラームや転送の経路に乗っているログには向かず、「保管はするが常時は見ない」ログ向けの選択です。
保存のIntelligent Tieringとクエリの関係
2026年7月15日からは、保存料金を下げるIntelligent Tieringも使えます。リージョン単位でアカウントごと有効にすると、30日間アクセスされなかったログはInfrequent Access階層、90日間アクセスされなかったログはArchive Instant Access階層へ自動で移り、東京の保存単価は上の表のとおり0.033USDから0.0198USD、0.0066USDへ下がります。有効化と階層の移動に追加料金はかからず、クエリの速度も変わりません。
aws logs put-storage-tier-policy --storage-tier INTELLIGENT_TIERING
Logs Insightsとの関係で押さえたいのは、StartQueryやスケジュールクエリで古いログを読むと、そのログがStandard階層へ戻り、30日間はStandardの保存単価になる点です。半年分を毎週横断するスケジュールクエリを置くと、読んだ範囲は下の階層へ落ちきらず、保存の節約がほとんど出ません。長期の横断集計は下のS3とAthenaへ逃がし、CloudWatchでは直近の調査だけを回すと、スキャン料と保存料の両方が下がります。
大量・長期の分析をS3とAthenaへ移す判断
Athenaの東京単価は1TBあたり5USD（料金API）で、1GBに直すと約0.0049USDとLogs Insightsの約3分の2です。ただし差が大きいのはスキャンより取り込みで、S3へ直接送ればCloudWatch Logsの0.76USD/GBがかかりません。数か月分を何度も横断集計するログ、監査で年単位に残すログは、Firehose経由でS3へ出してAthenaで読む構成のほうが、Firehoseの料金を足しても総額で安くなることが多いです。転送の組み方はAmazon Data Firehoseとは？旧Kinesis Data Firehoseとの違い・配信先・料金と実装判断を解説【2026年版】を参照してください。2025年12月にはCloudWatchのログをS3 Tables（Apache Iceberg形式）として扱いAthenaで検索する連携も加わりましたが、連携後に届いたログだけが対象で、既存ログは遡って入りません。すでにCloudWatch Logsへ収集しているログを障害直後に調べる用途では、S3への転送やAthena用のテーブル準備を追加せずに検索できるLogs Insightsを残す構成が適しています。
どこまでをCloudWatchに残し、どこからS3に逃がすかはログ量と調査頻度で変わります。AWS上のログ基盤の見直しから任せたい場合は、一創のAWSを含むインフラ構築の支援でも相談を受けています。
CloudWatch・CloudWatch Logs・Logs Insightsの違い
三者は競合ではなく層が違います。Amazon CloudWatchはメトリクス・アラーム・ダッシュボードを束ねる監視サービス全体、CloudWatch Logsはログの収集・保存・保持期間を担う部分、Logs Insightsは溜まったログを検索・集計するクエリ機能です。コンソールでは「ログ」配下の「ログのインサイト」として表示されます。2026年6月には、Logs Insights・Live Tail・Contributor Insightsを1画面にまとめたLog Analyticsも追加されましたが、料金はそれぞれの機能と同じです。
常時の異常検知は、メトリクスフィルタとアラームの役割です。2026年7月からはログクエリに直接しきい値を設定するアラームも作れるようになり、メトリクスフィルタを経由しない選択肢が増えました。Lambdaの監視設計はAWS LambdaをCloudWatchで監視する方法｜標準メトリクス・ログ・アラーム・Lambda Insightsに、Lambdaログの出し方とコスト削減はAWS Lambdaのログ運用ガイド｜CloudWatch Logsの見方・JSON構造化・S3出力とコスト削減にまとめています。
取得件数の上限と1万件を超えるログの扱い
limitの公式リファレンスでは、limitを省略すると最大10,000件、指定すれば100,000件まで返せます。10万件への拡張は2026年5月15日の告知で、それ以前の記事にある「1万件が上限」は古い情報です。APIのGetQueryResultsは1回10,000件までなので、10万件はページングで取ります。
fields @timestamp, @message
| sort @timestamp desc
| limit 100000
10万件を超える上限の引き上げはできません。件数・上位・推移を見たいならstatsで集計すれば結果行は激減します。生ログが要るなら時間範囲を分けてStartQueryを繰り返すか、S3へエクスポートします。クエリは60分でタイムアウトし、結果は7日間参照できます。
実務で使うクエリ構文
以下のstatusCodeのようなフィールドは、JSONログなら自動で検出されます。プレーンテキストのログはparseで切り出してから参照します。
filterのin・like・正規表現
inは完全一致の集合判定で、部分一致には使えません。部分一致はlikeか=~で、大文字小文字を無視するときはパターンの先頭に(?i)を置きます。インデックスが効く=やinで先に母集団を切り、その後にlikeを重ねる順に書きます。
fields @timestamp, @message, httpMethod
| filter httpMethod in ["POST", "PUT", "DELETE"]
| filter @message like /(?i)exception/
| sort @timestamp desc
| limit 50
count_ifの代わりになる条件付きカウント
Logs Insights QLの集計関数はcount・countDistinct・sum・avg・min・max・pct・stddev・variance・values・topkで、count_ifはありません。条件付きカウントはcase()でラベル列を作ってグループ化するか、1か0を返すstrcontains()をsum()に渡します。
fields case(statusCode >= 500, "5xx",
statusCode >= 400, "4xx",
"other") as statusClass
| stats count(*) as cnt by statusClass, bin(1h) as t
| sort t asc
bin(1h)にas tと別名を付けるのは、statsの後で参照できるのはそのstatsで定義したフィールドだけだからです。sort @timestampと書くと成立しません。
日付文字列の比較が効かない期間指定
公式は「人が読める形式のタイムスタンプによる絞り込みはサポートしていない」と明記しています。filter @timestamp >= '2026-10-01T00:00:00Z'は意図どおりに絞れません。期間はセレクタかAPIで指定し、クエリ内で相対的に絞るならエポックミリ秒で比べます。
fields @timestamp, @message
| filter toMillis(@timestamp) >= (now() * 1000 - 7200000)
| sort @timestamp desc
ただし、この例のようにクエリ内で時刻を絞るだけでは、セレクタで指定したスキャン対象範囲は狭まりません。
クエリ言語の選び分けとスケジュール実行
Logs Insights QL・OpenSearch PPL・SQLの選定基準
Logs Insightsは3つのクエリ言語を使えます。同時実行の上限はLogs Insights QLが100（2026年3月に30から引き上げ）、OpenSearch PPLとSQLは15です。QLには2026年にlookup（3月）、JOINとサブクエリ（4月）、limit anyと最大10個のstats（6月）が加わり、ロググループをまたぐ結合もQLで書けます。SQLを選ぶ理由は機能ではなく、チームがSELECTやGROUP BYのほうが速く正確に書けるかどうかです。インデックスを使うfilterIndexや前期間との比較を行うdiffはQLだけの機能なので、QLを既定にし、必要な場面だけ切り替えるのが無難です。
スケジュールクエリによる定期実行
2025年11月19日から、Logs Insightsのクエリを決まった時刻に自動実行し、結果行をS3へ、クエリ統計を含むメタデータ（結果行は含まない）をEventBridgeへ届けるスケジュールクエリが使えます。以前のようにEventBridgeとLambdaでStartQueryを叩く仕組みを自作する必要はありません。スケジュールはcron式でUTC基準なので、日本時間の朝9時ならcron(0 0 * * ? *)と書きます。実行のたびにスキャン量は通常どおり課金されるため、毎時500GBを読むクエリなら月約360TB・約2,700USDになります。作る前にestimateで1回の量を測り、頻度を掛けてから決めてください。
よくある質問
CloudWatch Logs Insightsの料金はいくらですか？
東京リージョンでスキャンした非圧縮データ1GBあたり0.0076USDで、月5GBまでは無料枠があります。別途、CloudWatch Logs側で取り込み（Standardのカスタムログで0.76USD/GB）と保存（0.033USD/GB-月）がかかります。
クエリを実行する前に料金を知る方法はありますか？
あります。クエリの最後に| estimateを付けると、実行せずにスキャン量の概算が返り、このクエリ自体は課金されません。コンソールではエディタに見積もりが自動で表示されます。返されたバイト数を課金単位のGBに換算し、東京の単価0.0076USD/GBを掛けると、無料枠適用前の1回の料金の目安になります。
CloudWatch LogsとLogs Insightsの違いは何ですか？
ログを送って保存する先がCloudWatch Logs、保存したログに問い合わせるのがLogs Insightsです。課金も、取り込み・保存はCloudWatch Logs、スキャンはLogs Insightsと別建てです。
1万件を超えるログを取得するにはどうすればよいですか？
limitを明示すれば100,000件まで指定でき、10,000件は省略時の既定値です。APIでは1回10,000件ずつページングで取得します。10万件を超える場合はstatsで集計するか、時間範囲を分けて実行するか、S3へエクスポートします。
Logs Insightsでgroup byのような集計はできますか？
できます。stats count(*) by フィールド名のようにbyで指定したフィールドごとに集計され、SQLのGROUP BYに当たります。時間ごとの推移ならby bin(1h)を使います。count_ifは無いので、条件付きの件数はcase()でラベル列を作ってからbyでまとめます。
