はじめに
- Datadogの利用料金とは別に隠れているAWS側のコストを削減する方法を紹介します
- 読書時間:約5分
- 技術スタック:AWS、Datadog
対象読者
- DatadogでAWSモニタリングを実施している方
- AWSとDatadogの連携コストを最適化したい方
- クラウド監視コストに悩んでいるインフラ/SRE担当者
技術背景
AWS環境を監視するとき、多くの組織はDatadogのような監視ツールを利用しています。しかし、Datadogの月額料金だけでなく、意外と見落としがちなのがAWS側で発生するAPI呼び出しコストです。Datadogは定期的にAWSのCloudWatch APIを呼び出してメトリクスを収集していますが、この部分にもコストが発生しています。
Datadogの公式ドキュメントによると、AWSインテグレーションではデフォルトで10分ごとにクローラーがメトリクスを収集します。CloudWatchから5分間隔のメトリクスを受け取る場合、CloudWatchの処理に5〜10分、Datadogのデフォルトポーリング間隔に10分、さらにキューイングとCloudWatch APIの制限により最大5分が加わり、合計で15〜20分の遅延が発生する場合があります。
課題詳細
- Datadogの利用料とは別に、AWS CloudWatch APIの呼び出しコストが発生している
- デフォルト設定ではすべてのリージョンから10分間隔でデータを収集している
- 使用していないリージョンや必要以上に頻繁なポーリングによる無駄なコストが発生
AWS re:Postの記事によると、DatadogのAWS統合による追加コストは、主にCloudWatch APIの呼び出し頻度と範囲に大きく影響されます。デフォルト設定のままでは、すべてのリージョンとサービスからメトリクスを収集するため、使用していないリソースに対してもコストが発生しています。
解決アプローチ
私が実際に行った2つのコスト削減アプローチを紹介します:
- メトリクス取得間隔の変更:デフォルトの10分間隔を延長することでAPI呼び出し回数を削減
- 収集リージョンの限定:実際に使用しているリージョンのみにメトリクス収集を限定
これらは設定変更のみで実現でき、監視品質を大きく下げることなくコスト削減が可能です。
実装手順
1. メトリクス取得間隔の変更
Datadogはデフォルトで10分ごとにAWS CloudWatch APIを呼び出してメトリクスを収集しています。この間隔を延長することで、API呼び出し回数とそれに伴うコストを削減できます。
# 変更前
ポーリング間隔: 10分(デフォルト設定)
1日あたりのAPI呼び出し回数: 144回/日/メトリクス
# 変更後
ポーリング間隔: 30分(例)
1日あたりのAPI呼び出し回数: 48回/日/メトリクス
- 実装意図:不要なほど頻繁なメトリクス取得を避け、コストを削減
- 動作原理:Datadogサーバー側で設定されたポーリング間隔を変更
- 注意点:この変更はDatadog Supportへの依頼が必要です
多くの場合、10分→30分程度の延長でも運用上の問題はありません。ただし、クリティカルなメトリクスや迅速な検知が必要な場合は、バランスを考慮してください。
Datadogの用語集によると、コレクション間隔(Collection interval)はエージェントやインテグレーションがメトリクスを収集する頻度を指します。この間隔を延長することで、リソース使用量とコストを削減できますが、時系列データの粒度が低下するトレードオフがあります。
2. 収集リージョンの限定
デフォルトでは、DatadogはAWSのすべてのリージョンからメトリクスを収集します。実際には利用していない、あるいは重要度の低いリージョンからの収集を停止することで、コストを削減できます。
# Datadogの設定例
integration:
aws:
regions:
- ap-northeast-1 # 東京リージョン
- us-east-1 # バージニアリージョン(CloudFrontなどで利用)
# その他のリージョンは無効化
Terraformを使用している場合は、以下のようにリソースを定義できます:
resource "datadog_integration_aws" "integration" {
account_id = "123456789012" # AWSアカウントID
role_name = "DatadogAWSIntegrationRole"
# 監視対象リージョンを東京とバージニアに限定
host_tags = ["region:ap-northeast-1", "region:us-east-1"]
# 他のリージョンを除外
excluded_regions = [
"ap-northeast-2", # ソウル
"ap-northeast-3", # 大阪
"ap-southeast-1", # シンガポール
"ap-southeast-2", # シドニー
"eu-central-1", # フランクフルト
"eu-west-1", # アイルランド
"eu-west-2", # ロンドン
"sa-east-1", # サンパウロ
"us-east-2", # オハイオ
"us-west-1", # 北カリフォルニア
"us-west-2", # オレゴン
# その他必要に応じて追加
]
}
- 実装意図:不要なリージョンのAPI呼び出しを削減
- 動作原理:Datadogの設定でポーリング対象リージョンを限定
- 注意点:後から新しいリージョンを使い始めた場合、監視設定の追加を忘れないこと
実際に利用しているのは主に東京リージョン(ap-northeast-1)とCloudFront利用のためのバージニアリージョン(us-east-1)だけという場合も多いでしょう。それ以外からの収集を停止することで、コストを削減できます。
結果と効果
これらの変更を適用することで期待できる効果:
- API呼び出しコストの削減
- 重要なメトリクスの監視品質は維持
- リージョン数や収集頻度に応じたコスト削減効果
まとめ
Datadogを使ったAWS監視では、Datadog自体の料金だけでなく、AWS側で発生するAPI呼び出しコストも意識することが重要です。メトリクス取得間隔の調整とリージョンの限定という2つの簡単な設定変更だけで、コスト削減が可能です。特に大規模な環境や複数アカウントを監視している場合は、効果がより顕著になります。
監視の品質を維持しながらコストを最適化するために、ぜひ設定を見直してみてください。これらの調整はDatadogのパフォーマンスにほとんど影響を与えず、AWS請求額の削減につながります。
参考資料
- Datadog AWS Integration Documentation
- AWS Cloudwatch API Pricing
- AWS Cost Optimization Best Practices
- Terraform Datadog Provider Documentation
- クラウドメトリクスの遅延 – DatadogのAWSクローラーとメトリクス遅延について説明
- Collection Interval – Datadog Glossary – メトリクス収集間隔に関する説明
- Optimizing Amazon CloudWatch Spend for Your Datadog AWS Integration – AWS re:Postによる最適化ガイド
- AWS IntegrationとCloudWatch FAQ – メトリクス遅延削減のためのDatadogガイド