1. 意思決定の背景と実務上の重要課題
企業のITインフラおよびセキュリティ運用において、ログの収集・分析基盤（SIEM: Security Information and Event Management）の選定は、単なる技術的な仕様比較にとどまらず、財務構造に直結する極めて経営リスクの高い意思決定である。近年、マルチクラウド環境の拡大、マイクロサービス化による分散トレーシングログの急増、SOC（Security Operations Center）による全社監査ログの集約義務化に伴い、処理対象となるログデータ量は年率30%〜50%以上のペースで増大し続けている。
このログ急増環境において、インフラ責任者やCIO（最高情報責任者）を最も悩ませているのが、いわゆる「ログ取り込みギガ単価による課金爆発（Bill Shock）」である。クラウド型ログ監視ソリューションやSIEM製品の多くは、取り込んだログのデータ量（GB/日 または GB/月）に連動して課金が発生する。
例えば、デバッグログの出力レベル設定ミス（INFO/DEBUGログの過剰吐き出し）や、DDoS攻撃・ポートスキャン等の外部攻撃に伴う一時的なアクセスログの急増によって、一晩で数TBのログがSIEMへ吸い上げられ、翌月の請求額が当初予算の3倍から5倍に跳ね上がるという惨事が頻発している。
一方で、コストカットを優先して収集対象ログを過度に絞り込んだ場合、万が一のセキュリティインシデント発生時に「痕跡が追えない」「フォレンジック調査に必要な監査ログが欠損している」といった致命的な法令違反・リスクを招くことになる。
本稿では、市場の主要プロダクトであるDatadog、Splunk Cloud、そしてAWS標準環境（Amazon CloudWatch Logs / Amazon S3）の3プラットフォームについて、料金構造のメカニズム、運用上の機能差、および実質TCO（総保有コスト）を冷徹な数値データに基づき徹底分析する。感覚論や無難な総論を一切排除し、どのようなログ運用要件においてどの選択肢が損得分岐点を迎えるのか、定量的かつ実践的な意思決定基準を提示する。
2. 【条件別】損得分岐マトリクス（早見表）
ログ基盤選定における「最適解」は、ログデータの「目的」「保存期間」「検索頻度」「リアルタイム性の要求度」によって明確に分かれる。以下のマトリクスは、企業の典型的なユースケースとログ容量に応じた推奨構成および損得分岐を示している。
条件別損得分岐マトリクス
| 評価軸・利用シナリオ | ログ要件と運用スタイル | 推奨ソリューション | コスト構造と費用感 | 選定の決定的理由（損得分岐のロジック） |
|---|---|---|---|---|
| 長期監査・コールド保管重視 | 監査・コンプライアンス用に1〜3年間保管。平常時は参照せず、調査時のみSQL検索。 | AWS S3 (Glacier Instant Retrieval) + Amazon Athena | 1GBあたり月数銭〜十数円（保管$0.004〜$0.005/GB/月、Kinesis経由転送費別途） | 高価なSIEMのデータ取り込み・インデックス化課金を回避。必要時のみAthenaでSQLスキャン課金（$5/TB）に抑えることでコストを90%以上圧縮可能。 |
| リアルタイムインフラ・APM連携 | 障害対応・APM・ログを同一画面で一気通貫分析。異常検知とメトリクス相関を即座に把握。 | Datadog Log Management + Cloud SIEM | 取り込み$0.10/GB、インデックス化（15日保管）$1.70/100万イベント | 「Logging Without Limits」により取り込みとインデックス保管を分離。全件取り込みつつ、必要なログのみを選択してインデックス化し課金爆発を防ぐ。 |
| 高度セキュリティ分析・大規模SOC | ペタバイト級の全社ログ集約。複雑な相関分析、SPLによる高度脅威狩り、既存SOCの定着。 | Splunk Cloud (ワークロード課金: SVCモデル) | SVC（Splunk Virtual Compute）単位の固定年額 ＋ 追加コンピュート費 | データ取り込み量（GB）ではなくコンピュート処理能力（SVC）で契約。超大量ログを取り込んでも検索・処理の最適化により容量課金爆発を回避。 |
| AWSネイティブ・低コスト構築 | AWS環境主体。外部SaaSを増やさず、標準機能とアイデンティティ（IAM）管理でシンプル化。 | AWS CloudWatch Logs + Subscription Filters | 取り込み$0.76/GB（東京）、保管$0.033/GB/月（標準） | アカウントまたぎの統合や標準メトリクス連携が容易。取り込み単価がやや高めのため、長期・大容量はS3へ即時リダイレクトする設計が必須。 |
損得分岐ポイントの要約
- 月間取り込み量が1TB未満で、リアルタイム検知とダッシュボード化が必須: Datadogが最も導入障壁が低く、運用工数を考慮した総合TCOで優位。
- 月間取り込み量が10TBを超え、監査目的の保存が9割を占める: AWS S3（Glacier Instant Retrieval）へ直接転送し、SIEMへの取り込みを全体の10%以下に絞り込む構成が圧倒的コスト最適解。
- 複雑な相関分析を伴う大規模セキュリティ監視（SOC運用）: データ量がGB単価課金の限度を超えた場合、Splunk CloudのSVCモデル（コンピュート課金）への移行がコスト予測可能性を高める。
3. 【徹底対比】主要選択肢の構造・スペック・料金比較
各ソリューションの課金メカニズムとアーキテクチャの相違点を解剖する。課金の「単位」と「構造」が根本的に異なるため、定量的比較にあたっては前提条件を明確にする必要がある。
詳細スペック・機能・料金の対比表
| 比較項目 | Datadog Log Management | Splunk Cloud | AWS CloudWatch Logs / S3 |
|---|---|---|---|
| 基本料金モデル | 2段階従量制（Ingestion ＋ Indexing） | ワークロード課金（SVC）または容量課金（GB/日） | 完全従量制（Ingestion ＋ Storage ＋ Scan） |
| ログ取り込み単価（Ingestion） | $0.10 / GB | 容量課金の場合：契約GB/日（例：$1,000〜/GB/日/年） | $0.76 / GB（東京リージョン CloudWatch Logs） |
| ログ保持・分析単価（Indexing / Storage） | $1.70 / 100万イベント（15日間保持の場合） | 契約範囲内のストレージ（超過分はストレージ追加費用） | CloudWatch: $0.033/GB/月 S3 IR: $0.005/GB/月 |
| 課金爆発に対する防御機構 | 「Logging Without Limits」（排除ルール・サンプリング） | ワークロード（SVC）契約による容量制限の無効化 | 抑止機構なし（転送フィルタをKinesis/Lambda等で自作要） |
| クエリ・検索言語 | Datadog Search Syntax（直感的・簡易的） | SPL (Search Processing Language - 高度かつ強力) | CloudWatch Logs Insights / Amazon Athena (SQL) |
| セキュリティ分析・SIEM機能 | Cloud SIEM（ルールベース自動検知、APM連携） | Enterprise Security (ES)（業界最高水準の相関分析） | Amazon GuardDuty / Security Lake との連携構築要 |
| 障害・メトリクス連携 | 非常に優れる（Datadog APM/Infrastructureと統合） | 高い（Splunk IT Service Intelligence等が必要） | AWS生態系（CloudWatch Metrics/X-Ray）に限定 |
| 運用・構築工数 | 低い（Agent導入およびSaaS標準機能で完了） | 中〜高い（ダッシュボード設計・SPL習熟が必要） | 中〜高い（Kinesis Firehose, S3, Athenaのパイプライン構築要） |
課金体系の構造的違いにおける注意点
1. Datadogの構造的強みと罠
Datadogの最大の特徴は、「ログの取り込み（Ingestion）」と「検索用インデックス作成（Indexing）」の分離である。 取り込み単価は$0.10/GBと極めて安価に設定されている。取り込んだログに対して動的にルールを適用し、90%の定常ログ（ヘルスチェックや正常アクセス）を捨て、残り10%の異常・エラーログのみをインデックス化（15日間〜15か月間保持）する設定が可能である。
しかし、注意すべきは「イベント数課金」であることだ。1GBのデータであっても、ショートメッセージ（1行が短いログ）が大量に含まれる場合、イベント数が膨れ上がりインデックス化費用（100万イベントあたり$1.70）が急増するリスクがある。
2. Splunk Cloudの構造的強みと罠
Splunkは歴史的に「1日あたりの取り込み容量（GB/日）」での年間契約（Ingest Model）が主流であったが、現在は「SVC（Splunk Virtual Compute）」という処理能力単位のワークロード課金へ移行している。
SVCモデルの場合、どれだけ大量のログを過剰に取り込んでも突発的な追加請求は発生しない。一方で、検索クエリの効率性が低い（非効率なSPLを頻繁に実行する）場合、コンピュート能力（SVC）が枯渇し、検索パフォーマンスが着底する。能力増強のためには高額な追加SVCの契約が必要となる。
3. AWS（CloudWatch / S3）の構造的強みと罠
AWSにおける罠は、CloudWatch Logsの取り込み単価（$0.76/GB）がSaaSのログ取り込み単価（Datadogの$0.10/GB）と比較して7倍以上高価である点にある。
全ログをCloudWatch Logsに安易に流し込んで長期間保持する運用を行うと、SaaSを導入するよりもはるかに高額な請求が発生する。AWS環境で低コスト化を実現するには、Fluent BitやKinesis Data Firehoseを経由して、CloudWatch Logsをバイパスし、直接Amazon S3（Glacier Instant Retrievalなど）へパケット単位で集約する設計が絶対に不可欠となる。
4. 【規模別・年数別】3年間の実額TCO（総保有コスト）シミュレーション
企業の成長フェーズおよびログ容量の規模に応じ、3年間で発生する「ツール直接費用」と「運用人件費・構築費」を合算した実額TCOを試算する。
試算の前提条件
- ドル円レート: 1USD = 150円で換算。
- ログの性質: 10%が検索用インデックス（15日間保持）、90%が長期間（3年間）の監査用保管ログ。
- 人件費パラメータ: エンジニア1名の年間人件費を1,200万円（月額100万円）とし、インフラ維持・構築にかかる工数を加算。
- 規模定義:
- 中規模: ログ取り込み量 300GB/日（約9TB/月）
- 大規模: ログ取り込み量 3,000GB/日（約90TB/月）
シミュレーション1: 中規模環境（ログ取り込み量 300GB/日 ＝ 月間9TB）
3年間の実額TCO対比（中規模）
| 費用項目 | Datadog（Optimized構成） | Splunk Cloud（SVC契約） | AWS S3＋Athena（ハイブリッド構成） |
|---|---|---|---|
| 年間ツール費用（1年目） | 約310万円 | 約900万円 | 約120万円 |
| 年間ツール費用（2年目） | 約310万円 | 約900万円 | 約140万円（保管蓄積加算） |
| 年間ツール費用（3年目） | 約310万円 | 約900万円 | 約160万円（保管蓄積加算） |
| ツール費用 3年間合計 | 約930万円 | 約2,700万円 | 約420万円 |
| 構築・運用工数（3年間） | 約360万円（0.1人月/月） | 約720万円（0.2人月/月） | 約1,080万円（0.3人月/月） |
| 3年 TCO 総額 | 約1,290万円 | 約3,420万円 | 約1,500万円 |
分析（中規模）
中規模環境において、Datadogは取り込みとインデックスの分離（Optimized構成）を適用することで、ツール費用を年間310万円程度に抑えることができる。
AWS標準構成（S3+Athena）はツール利用料自体は3年間で420万円と極めて安価だが、ログパイプラインの構築・維持・Athena用パーティション自動化などの運用保守工数（人件費）が発生するため、実額TCOで見るとDatadog（約1,290万円）がAWS自作構成（約1,500万円）を逆転して最安解となる。
シミュレーション2: 大規模環境（ログ取り込み量 3,000GB/日 ＝ 月間90TB）
3年間の実額TCO対比（大規模）
| 費用項目 | Datadog（Optimized構成） | Splunk Cloud（SVC契約） | AWS S3＋Athena（ハイブリッド構成） |
|---|---|---|---|
| 年間ツール費用（1年目） | 約3,100万円 | 約4,500万円 | 約1,100万円 |
| 年間ツール費用（2年目） | 約3,100万円 | 約4,500万円 | 約1,300万円（保管蓄積加算） |
| 年間ツール費用（3年目） | 約3,100万円 | 約4,500万円 | 約1,500万円（保管蓄積加算） |
| ツール費用 3年間合計 | 約9,300万円 | 約1億3,500万円 | 約3,900万円 |
| 構築・運用工数（3年間） | 約720万円（0.2人月/月） | 約1,080万円（0.3人月/月） | 約1,800万円（0.5人月/月） |
| 3年 TCO 総額 | 約1億20万円 | 約1億4,580万円 | 約5,700万円 |
分析（大規模）
月間90TBクラスの大規模環境に達すると、DatadogやSplunkのツール費用が年間数千万円規模へ膨れ上がる。このスケールにおいては、AWS S3（Glacier Instant Retrieval）へ直接ログを掃き出し、運用工数を投じてAthenaでのオンデマンド検索体制を構築するアーキテクチャが、人件費を含めたTCO（約5,700万円）で圧倒的な優位性を確立する。
DatadogやSplunkを採用する場合は、全ログをSIEMに入れるのを止め、「S3へ全件出力＋SIEMへはセキュリティアラートと重要ログのみ転送」というアーキテクチャの変更を行わなければ、年間数千万円単位の無駄金が発生し続けることになる。
🧭 【この分岐とあわせて検討したい意思決定バイブル】
関連する周辺領域の損得分岐点もあわせて確認し、全体の費用対効果を最大化してください。
- 🔗 【条件別】クラウドサーバー移行（AWS vs Google Cloud vs さくらのクラウド）の中小企業Webシステム月額維持費分岐マトリクス
【損得分岐】データ転送量課金（ドル建て為替変動リスク）vs 日本円請求・パケット定額制（さくらのクラウド）の3年TCO対比- 🔗 【条件別】CDN・DDoS対策（Cloudflare Pro/Business vs AWS CloudFront vs Fastly）の転送量課金とキャッシュヒット率損得分岐マトリクス
【損得分岐】月間転送量（1TB・10TB・50TB）ごとの従量課金爆発リスクとCloudflareの「転送量無制限定額プラン」の圧倒的優位性
5. 実務で直面する「3大失敗パターン」と生々しい回避策
SIEMおよびログ管理基盤の運用において、現場が陥る典型的な失敗事例と、それを防ぐための具体的な泥臭い運用回避策を解説する。
失敗パターン1: デバッグログ放置と突発的攻撃による「1000万円超の課金爆発」
発生メカニズム
システム障害の調査のためにアプリケーションのログレベルを一時的にINFOからDEBUGに変更し、調査終了後に元に戻し忘れる。
あるいは、外部からの総当たり攻撃（ブラウトフォース）や外部IPからのDDoS攻撃を受け、Webサーバーのアクセスログが通常の100倍のペースで出力される。これがそのままDatadogやSplunkへ転送され、わずか数日で1か月分の課金上限を突破する。
生々しいリスク回避策
- 送信側での動的フィルタリング（Fluent Bit / Vectorの導入）:
SaaSに送る手前のエージェント層（VectorやFluent Bit）で、
DEBUGレベルのログおよび特定エンドポイント（/healthz,/metrics）のログを非同期でドロップするルールを厳格化する。 - Datadog「Inclusion/Exclusion Rules」の強制適用:
Datadog管理画面で、
status:info以下のログを100%取り込まない排除ルールを設定するか、取り込んだログのうちインデックス化率を10%に制限する「Sample Rate Limit」をプロダクション環境全体に固定適用する。 - AWS Billing / Budgetsのアラート自動化: 日次の利用料が想定ベースラインの20%を超えた段階で、PagerDuty経由でオンコールエンジニアへ電話通知（Autocall）が飛ぶ仕組みを構築する。
失敗パターン2: 全ログをSIEMに取り込み「検索が重すぎて使い物にならなくなる」
発生メカニズム
セキュリティコンプライアンスを満たすため、ファイアウォール、VPC Flow Logs、Windowsイベントログ、Kubernetesコンテナログなど、社内のすべてのログをそのままSplunkやDatadogのインデックスへ流し込む。
結果として、インデックスのカーディナリティ（値の種類数）が爆発し、セキュリティアナリストがいざインシデント調査で検索クエリを実行した際、タイムアウトが連発して1回の検索に15分以上かかる状態に陥る。
生々しいリスク回避策
- ログのティアリング（2階層分離構成）の徹底:
- Tier 1 (Hot/Index): セキュリティ脅威検知・障害対応に必要な「ログイン失敗」「権限変更」「エラーログ」のみ（全ログの5〜10%）。これをSIEMのインデックスに保持。
- Tier 2 (Cold/Archive): パケットログ、アクセスログ、正常系システムログ（全ログの90〜95%）。これを直接S3（Glacier Instant Retrieval）へ集約。
- ログ構造のプレインデックス変換（JSON正規化）:
ログ取り込み時に、生テキストのまま保存するのではなく、不要なスタックトレースを削ぎ落とし、検知に必要なキー（
src_ip,user,event_id）のみを構造化JSONとして抽出してからSIEMへ送信する。
失敗パターン3: クラウド標準ログ（CloudWatch）の放置による「隠れ高額請求」
発生メカニズム
DatadogやSplunkなどのサードパーティSaaSの導入を回避し、「AWS純正だから安心」とすべてのAWSアカウントのログをCloudWatch Logsに集約する。
しかし、CloudWatch Logsは取り込み単価が$0.76/GBと非常に高く、さらに標準設定ではログの保持期間が「無期限（Never Expire）」にセットされている。気づいた時には、毎月数十万円の取り込み費用と、過去数年分の蓄積ログストレージ費用がボディブローのように会社財務を圧迫する。
生々しいリスク回避策
- CloudWatch Logs 保持期間（Retention）の一括制限ポリシー: AWS ConfigまたはTerraformを使用し、全CloudWatch Log Groupの保持期間を強制的に「14日」または「30日」に設定する組織ポリシーを自動適用する。
- Kinesis Data FirehoseによるS3直送りパイプラインへの切替: 大量に出力されるVPC Flow LogsやALBアクセスログは、CloudWatch Logsを経由させず、Amazon Data Firehoseから直接S3 bucketへストリーミング配送するアーキテクチャへ全面的に改修する。これにより取り込みコストを$0.76/GBから$0.035/GBへと約95%削減できる。
6. あなたの最適解を導く「意思決定フローチャート」
自社が選択すべきログ基盤アーキテクチャを決定するための意思決定フローである。4つの質問に答えることで、選定すべきソリューションが客観的に導き出される。
[START: ログ管理・SIEMの選定検討]
|
v
【Q1】主なログ収集目的は何か？
|-- (A) 監査・コンプライアンス（普段は見ず、監査・調査時のみ利用）
| |
| +--> [推奨: AWS S3 (Glacier Instant) + Athena 構成]
| (理由: SaaSの取り込み課金を全回避し、保管単価を極小化)
|
|-- (B) リアルタイム監視・障害対応・セキュリティ検知
|
v
【Q2】月間のログ取り込み量はどの規模か？
|-- (A) 10TB未満（中規模・スタートアップ〜中堅）
| |
| v
| 【Q3】インフラ監視・APM（性能監視）とログを同一画面で統合管理したいか？
| |-- (YES) --> [推奨: Datadog Log Management + Cloud SIEM]
| | (理由: Logging Without Limitsで課金爆発を防ぎつつ、運用効率最大化)
| |
| |-- (NO) --> [推奨: AWS CloudWatch Logs + S3 Direct 構成]
| (理由: AWSネイティブで構築し、外部SaaS契約コストを抑制)
|
|-- (B) 10TB以上（大規模・エンタープライズ）
|
v
【Q4】専任SOCチームが存在し、高度なSPL相関分析や厳格な固定予算化が必要か？
|-- (YES) --> [推奨: Splunk Cloud (SVC ワークロード課金)]
| (理由: 容量無制限のコンピュート契約で、突発大量ログによる課金パンクを防止)
|
|-- (NO) --> [推奨: S3 Direct (Cold) + Datadog/Splunk (Hot 10%のみ)]
(理由: ログの2階層分離アーキテクチャでSaaS利用料を90%削る)
7. 現場で迷ったときのFAQ（よくある質問5選とズバリ回答）
Q1: Datadogの「Logging Without Limits」を使えば、ログ課金爆発は100%防げますか？
回答: 排除ルール（Exclusion Rules）を正しく設定しない限り、100%は防げない。 取り込み（Ingestion）自体に$0.10/GBのコストがかかるため、DDoS攻撃などでテラバイト級のログが届けば取り込み費用だけで数十万円単位の請求が発生する。送信元（Vector/Fluent Bit）での前処理フィルターと、Datadog側でのサンプリングレート制限（例: インデックス化率5%固定）を組み合わせることが必須条件である。
Q2: Amazon AthenaでS3上のログを検索すると、クエリ費用が高額になりませんか？
回答: パーティション化（日付・時間・サービス別）とParquetフォーマット変換を行えば、費用は数十円レベルに収まる。
Athenaは「スキャンしたデータ量」に対して$5.00/TBの課金が発生する。テキスト（生ログ）のままS3に置くと全スキャンで高額になるが、Kinesis Data FirehoseでParquet（列指向フォーマット）に変換し、year/month/day/hourでS3キーを分割しておけば、必要な時間帯のログ数GB分のみをスキャンするため、1回の検索費用は数銭〜数十円で完了する。
Q3: Splunk Cloudの容量課金（Ingest）とSVC課金は、どちらを選ぶべきですか？
回答: ログ量が月間5TBを超えている、または前年比1.5倍以上で増加している場合は「SVC課金」一択である。 Ingest（容量）課金は、契約容量を超過した際に警告や追加ペナルティ、あるいは契約変更を迫られる。SVCモデル（コンピュート課金）であれば、ログの取り込み量自体には制限がないため、ログ急増による突発的な請求が発生しない。
Q4: セキュリティ監査（PCI DSSやSOC2）で「1年間のログ保持」を求められた場合、どう構築するのが最も安価ですか？
回答: SIEM内に1年間保持するのは悪手。「SIEMに15日〜30日保存 ＋ S3 Glacier Instant Retrievalに1年保管」が業界の定石である。 SIEM製品のロングタームインデックス保持機能は極めて高価である。監査要件は「アクセス可能な状態で保管されていること」であり、即座のリアルタイム検索が1年後も維持されている必要はない。S3 Glacier Instant Retrievalへ転送しておけば、保管費用を月額$0.004〜$0.005/GBに抑えられ、監査が入った際も数秒でAthenaからアクセス可能である。
Q5: CloudWatch LogsからDatadogへログを転送する際、AWS側のデータ転送費（Egress）で損をしませんか？
回答: AWS Lambda経由のDatadog Forwarderではなく、Datadog Agentによる直接送信へ切り替えることでネットワークコストを削減できる。 CloudWatch Logs Subscription FiltersからDatadog Forwarder（Lambda）を挟んで送る方式は、Lambda実行費用とデータ転送費がダブルで発生する。EC2やEKS上のDatadog Agentから直接Datadogのエンドポイントへ送信（HTTPS）することで、AWS側の余計な中間処理コストを排除できる。
8. 結論と今すぐできるアクションプラン
結論
ログ基盤の選定において「すべてのログを単一の高機能SaaSに放り込む」という時代は終わった。 課金爆発を防ぎつつ、インシデント発生時の即座な検知とトレーサビリティを両立させる唯一の解は、「ログの2階層分離（Hot/Cold Split）アーキテクチャ」の導入である。
- リアルタイム検知・分析（Hot Data）: 全ログの10%以下に絞り込み、Datadog Cloud SIEMやSplunk Cloudへインデックス化する。
- 長期間監査保管（Cold Data）: 全ログの100%を、S3 Glacier Instant Retrieval等の超低コストオブジェクトストレージへ直接ストリーミング保管し、必要な時だけAthena等でSQL検索する。
今すぐ実行すべき「4ステップ・アクションプラン」
- 現行ログ取り込み量の内訳調査（明日実行）
- Datadog/Splunk/CloudWatchの管理画面を開き、データ量を最も圧迫している「上位3つのログソース（例: ALBアクセスログ、KubernetesコンテナSTDOUT、VPC Flow Logs）」を特定する。
- 送信元（エージェント）での不要ログ間引き
- Fluent BitまたはVectorのコンフィグを見直し、
200 OKの正常ヘルスチェックログやDEBUGレベルログを、SaaSへ送信する前にローカルで廃棄（Drop）する設定を追加する。
- Fluent BitまたはVectorのコンフィグを見直し、
- AWS S3直接退避パイプラインの構築
- ALBログやVPC Flow Logsなど、日常的に検索しない大容量ログの送信先をCloudWatch Logs/SIEMから、Amazon Data Firehose経由のS3直接保存へ変更する。
- Datadog / Splunkの課金ガードレール（上限値）設定
- Datadogの「Log Management Exclusion Rules」を有効化し、日次のインデックス制限上限を設定する。また、AWS Billingでログ関連費用が閾値を超えた際の即時アラートを設定する。