--- title: "CloudWatch Logs Insightsの料金｜東京0.0076USDの計算と請求の調べ方・下げ方【2026年11月】" url: "https://www.issoh.co.jp/column/details/2900/" published: 2024-07-02 updated: 2026-11-01 categories: ["インフラ"] publisher: "株式会社一創" --- # CloudWatch Logs Insightsの料金｜東京0.0076USDの計算と請求の調べ方・下げ方【2026年11月】 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のクエリは[クエリ言語にかかわらず、スキャンした非圧縮ログデータの量で課金される](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)と書いています。スキャンの基準になるのは、選択したロググループに含まれる、選択した時間範囲ぶんのログの合計です。条件に合った件数ではありません。`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の料金ページ](https://aws.amazon.com/jp/cloudwatch/pricing/)で「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の料金ページ](https://aws.amazon.com/cloudwatch/omni/pricing/)では、ログとトレースのスキャンが1GBあたり0.005USDで、月のログとスパンの取り込み量の5倍までは無料です。提供開始時はバージニア北部・オレゴン・アイルランドの3リージョンだけでしたが、[2026年10月19日の告知](https://aws.amazon.com/about-aws/whats-new/2026/10/amazon-cloudwatch-omni-8-regions/)で東京を含む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エージェント計装の手順](/tech/details/18243/)で詳しく扱っています。 ## Logs Insightsの請求額を特定する手順 請求書の「CloudWatch」が膨らんだとき、取り込み・保存・スキャンのどれが原因かを分けないと、削る場所を間違えます。スキャン料の増加と取り込み料の増加では、確認する使用タイプも対策も異なります。調べる順番は次の4段です。 ### Cost Explorerの使用タイプ別スキャン料 Cost Explorerでサービスを「CloudWatch」に絞り、グループ化を「使用タイプ」にします。[CloudWatchの請求ガイド](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch%5Fbilling.html)によると、Logs Insightsのスキャンは接尾辞`DataScanned-Bytes`（対応するAPIは`StartQuery`）で計上され、東京なら`APN1-DataScanned-Bytes`です。取り込みは`DataProcessing-Bytes`、保存は`TimedStorage-ByteHrs`なので、どれが伸びたかがここで分かります。 ### bytesScannedによるクエリ単位のスキャン量確認 スキャン料が原因なら、どのクエリが重いかを見ます。APIの`GetQueryResults`が返す`statistics`には、スキャンしたバイト数`bytesScanned`と件数`recordsScanned`、インデックスで読み飛ばした推定量`estimatedBytesSkipped`が入ります。過去に実行したクエリは`DescribeQueries`で一覧でき、各クエリの`bytesScanned`について公式は[「クエリに伴うコストを示す」](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API%5FQueryInfo.html)と説明しています。 ``` aws logs describe-queries --status Complete --max-items 50 \ --query "queries[].[createTime,logGroupName,bytesScanned,userIdentity]" \ --output table ``` `userIdentity`にはクエリを実行したユーザーのARNが入るので、誰の操作かまで分かります。同じ利用者・同じロググループのクエリが数分おきに並ぶ場合は、ダッシュボードの自動更新やスケジュール実行を疑い、クエリ文と実行設定を照合します。 ### IncomingBytesによるロググループ別取り込み量の確認 取り込み料が原因なら、CloudWatchメトリクスの「ログ」→「ロググループメトリクス」で`IncomingBytes`を選び、統計を「合計」にしてロググループ別に並べます。このメトリクスは[CloudWatch Logsに送られた非圧縮のバイト数](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CloudWatch-Logs-Monitoring-CloudWatch-Metrics.html)なので、そのままスキャン量の上限の目安にもなります。突出したグループが見つかったら、出力元のログレベルや送信設定を直します。CloudTrailの証跡をCloudWatch Logsへ送っているとここが跳ねやすく、証跡の設計は[CloudTrailとは？証跡設計と料金実額・Lake新規受付終了後の構成をCLIで解説](/tech/details/17649/)で扱っています。 ### estimateによるスキャン量の事前見積もり クエリを実行せずにスキャン量だけを返す`estimate`コマンドが使えます。AWSの告知は2026年9月29日ですが、ドキュメント履歴ではコマンドの追加が2026年7月22日付で載っています。[公式リファレンス](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL%5FQuerySyntax-Estimate.html)は、`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が追加料金なしで自動的にインデックスする](https://aws.amazon.com/about-aws/whats-new/2026/09/cloudwatch-logs-auto-indexes-fields/)ようになりました。自動分はロググループあたり20個の枠に数えられず、30日保持されます。恒久的に残したいフィールドだけ、コンソールかAPIでインデックスポリシーへ昇格させます。 ### Essentialsログクラスの安くならない部分 Infrequent Accessログクラスは[Essentialsに改称](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CloudWatch%5FLogs%5FLog%5FClasses.html)されました。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](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/cwl%5Fintelligent%5Ftier.html)も使えます。リージョン単位でアカウントごと有効にすると、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年版】](/tech/details/15515/)を参照してください。2025年12月にはCloudWatchのログをS3 Tables（Apache Iceberg形式）として扱いAthenaで検索する連携も加わりましたが、連携後に届いたログだけが対象で、既存ログは遡って入りません。すでにCloudWatch Logsへ収集しているログを障害直後に調べる用途では、S3への転送やAthena用のテーブル準備を追加せずに検索できるLogs Insightsを残す構成が適しています。 どこまでをCloudWatchに残し、どこからS3に逃がすかはログ量と調査頻度で変わります。AWS上のログ基盤の見直しから任せたい場合は、一創の[AWSを含むインフラ構築の支援](/service/system/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](/tech/details/4028/)に、Lambdaログの出し方とコスト削減は[AWS Lambdaのログ運用ガイド｜CloudWatch Logsの見方・JSON構造化・S3出力とコスト削減](/tech/details/4031/)にまとめています。 ## 取得件数の上限と1万件を超えるログの扱い [limitの公式リファレンス](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL%5FQuerySyntax-Limit.html)では、`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`でまとめます。 ## 関連記事 - [AWS Lambdaのログ運用ガイド｜CloudWatch Logsの見方・JSON構造化・S3出力とコスト削減](/tech/details/4031/) - [CloudWatch Omniとは：料金・東京未対応の制約とAIエージェント計装の手順](/tech/details/18243/) - [Fluent Bitとは？読み方・Fluentdとの違い・AWSでの設定例【v5.1対応】](/tech/details/12612/) - [Amazon Data Firehoseとは？旧Kinesis Data Firehoseとの違い・配信先・料金と実装判断を解説【2026年版】](/tech/details/15515/) - [AWS LambdaをCloudWatchで監視する方法｜標準メトリクス・ログ・アラーム・Lambda Insights](/tech/details/4028/) --- 出典: [CloudWatch Logs Insightsの料金｜東京0.0076USDの計算と請求の調べ方・下げ方【2026年11月】]()（株式会社一創）