Datadog のAWS インテグレーションでCloudWatch メトリクスの収集対象Namespace が自動的に増える原因と対処法
こんにちは、なおにしです。
Datadog のAWS インテグレーションで、有効化していないはずのCloudWatch メトリクスが収集対象になっていた原因を調査する機会がありましたのでご紹介します。
はじめに
Datadog のAWS インテグレーションがCloudWatch メトリクスを収集する標準的な方法は、CloudWatch API のポーリングです。そのため、収集対象のAWS サービス(Namespace)を増やすとその分だけGetMetricDataのAPI コールが増えることになるので、必要なものだけに絞りたくなります。
実際に、例えばDatadog のTerraform プロバイダーのドキュメントでは、AWS/SQS・AWS/ElasticMapReduce・AWS/Usageの3つについて、GetMetricDataのAPI コールによるCloudWatch のコストを抑えるためにデフォルトで収集対象から除外していることが記載されています。
というわけで、私がDatadog との連携検証で使用しているAWS アカウントの一つでは、Metric Collection の対象をAWS/Lambdaのみに絞っていました。
ところがある日、Datadog のAWS インテグレーション設定を開いたところ、以下のようにEnabled (2)となっており、AWS/Lambdaに加えて/aws/sagemaker/InferenceComponentsが有効になっていました。当該アカウントではSageMaker を使用しておらず、私がこのNamespace を有効化した覚えもありません。

なお、以前にも同じように収集対象が増えていたことがあり、その時はMetric Collection タブから該当のNamespace を無効化してAWS/Lambdaのみに戻して対応していました。つまり、UI から無効化し直すだけでは同じことが繰り返されているという状態です。
そこで、なぜ有効化されるのかと、UI での操作以外に恒久的な対処方法がないのかを確認してみました。
先に結論
Metric Collection タブでの有効/無効の操作は、内部的にはnamespace_filtersという設定として保存されます。
このnamespace_filtersには以下の2つのモードがあり、デフォルトはexclude_onlyです。
| モード | 動作 | Datadog が新しいNamespace に対応したとき |
|---|---|---|
exclude_only(デフォルト) |
リストに含まれるNamespace のみを収集対象から除外する | リストに載っていないため、収集対象になる |
include_only |
リストに含まれるNamespace のみを収集対象にする | リストに載っていないため、収集対象にならない |
Metric Collection タブでの操作はexclude_onlyモードのまま除外リストを書き換えるものになるため、Datadog が新しいNamespace に対応するたびに収集対象が増えることになります。したがって、UI から無効化し直す対応では再発します。
収集対象を特定のNamespace のみに固定したい場合は、API からinclude_onlyモードに切り替えます。
なお、include_onlyモードに切り替えた後でもMetric Collection タブからの有効化操作は可能で、その場合もモードはinclude_onlyのまま維持されました。
やってみた
事前準備
以下の環境で確認しています。
- Datadog サイト:
datadoghq.com - AWS インテグレーション: CloudFormation テンプレートで設定済み
- Metric Collection:
AWS/Lambdaのみを有効化する運用 - 確認時期: 2026年6月および2026年8月
API を実行するため、API キーとアプリケーションキー、および対象のAWS アカウントIDを環境変数に設定しておきます。
export DD_API_KEY="<your-api-key>"
export DD_APP_KEY="<your-app-key>"
export AWS_ACCOUNT_ID="123456789012"
① 収集対象になり得るNamespace は増え続けている
まず、先ほどの画面でAll (133)となっていた点に着目します。これはDatadog がMetric Collection の対象として認識しているNamespace の総数です。
以下は同じアカウントの2026年6月時点のMetric Collection タブです。

All (119)となっており、8月時点のAll (133)と比べて14 少ないことが分かります。そしてEnabled (6)ということで、この時もAWS/Lambdaだけのはずが、Aurora DSQL・HealthLake・Q Developer・S3 Tables・Secrets Manager が収集対象になっていました。
つまり、Datadog が対応するNamespace は継続的に追加されており、そのたびに収集対象が増えているように見えます。この時はMetric Collection タブから該当のNamespace を無効化してAWS/Lambdaのみに戻しましたが、約2ヶ月後にまた同じことが起きたわけです。
② namespace_filters のモードを確認する
Metric Collection タブでの操作結果は、AWS インテグレーションのAPI で確認できます。
このAPI で設定するmetrics_configのnamespace_filtersが、Metric Collection タブの有効/無効に対応する設定項目です。同じ設定はTerraform プロバイダーからも指定できるため、そちらのドキュメントにも記載があります。
namespace_filters(Block) AWS metrics namespace filters. Defaults to a pre-setexclude_onlylist if block is empty.(機械翻訳)
namespace_filters(ブロック) AWS メトリクスのNamespace フィルター。ブロックが空の場合は、あらかじめ用意されたexclude_onlyのリストがデフォルトになります。
exclude_only(List of String) Exclude only these namespaces from metrics collection. Usedatadog_integration_aws_available_namespacesdata source to get allowed values. Defaults to["AWS/SQS", "AWS/ElasticMapReduce", "AWS/Usage"].AWS/SQS,AWS/ElasticMapReduce, andAWS/Usageare excluded by default to reduce your AWS CloudWatch costs fromGetMetricDataAPI calls.
include_only(List of String) Include only these namespaces for metrics collection. Usedatadog_integration_aws_available_namespacesdata source to get allowed values.(機械翻訳)
exclude_only(文字列のリスト) これらのNamespace のみをメトリクス収集から除外します。指定できる値はdatadog_integration_aws_available_namespacesデータソースで取得してください。デフォルトは["AWS/SQS", "AWS/ElasticMapReduce", "AWS/Usage"]です。AWS/SQS、AWS/ElasticMapReduce、AWS/Usageは、GetMetricDataAPI コールによるAWS CloudWatch のコストを削減するため、デフォルトで除外されています。
include_only(文字列のリスト) これらのNamespace のみをメトリクス収集の対象にします。指定できる値はdatadog_integration_aws_available_namespacesデータソースで取得してください。
exclude_onlyは除外リスト方式、include_onlyは許可リスト方式ということになります。そしてnamespace_filtersのデフォルトはexclude_onlyです。
ここで、UI から/aws/sagemaker/InferenceComponentsを無効化してAWS/Lambdaのみの状態に戻します。

Enabled (1)・Disabled (132)となりました。この状態で現在の設定を確認します。後続の手順で必要になるconfig_idも併せて取得しておきます。
curl -s -X GET "https://api.datadoghq.com/api/v2/integration/aws/accounts" \
-H "DD-API-KEY: $DD_API_KEY" \
-H "DD-APPLICATION-KEY: $DD_APP_KEY" \
| jq --arg id "$AWS_ACCOUNT_ID" \
'.data[] | select(.attributes.aws_account_id==$id)
| {config_id: .id,
aws_account_id: .attributes.aws_account_id,
namespace_filters: .attributes.metrics_config.namespace_filters}'
レスポンスは以下のとおりです。
{
"config_id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"aws_account_id": "123456789012",
"namespace_filters": {
"exclude_only": [
"AWS/ApiGateway",
"AWS/Glue",
"AWS/AmplifyHosting",
"AWS/AppRunner",
"AWS/AppStream",
(略)
"AWS/SageMaker",
"/aws/sagemaker/Endpoints",
"/aws/sagemaker/InferenceComponents",
"AWS/Sagemaker/LabelingJobs",
"AWS/Sagemaker/ModelBuildingPipeline",
(略)
"AWS/WAFV2",
"AWS/WorkSpaces",
"AWS/X-Ray"
]
}
}
キー名がexclude_onlyであることから、除外リスト方式になっていることが分かります。そしてリストの要素数は132 で、Metric Collection タブのDisabled (132)と一致します。また、リストの中にAWS/Lambdaは含まれていません。
つまり、Metric Collection タブで「AWS/Lambdaのみを有効化した」状態は、内部的には**exclude_onlyモードのまま、AWS/Lambda以外の132 個のNamespace を除外リストに列挙した形**で保存されているということになります。UI 上で無効化操作をしてもinclude_onlyモードには切り替わりません。
そうすると、Datadog が新しいNamespace に対応した際、そのNamespace はこの除外リストには載っていないため、除外されずに収集対象となります。SageMaker を使用していないアカウントで/aws/sagemaker/InferenceComponentsが有効になっていたのも、これで説明が付きます。
③ include_only モードに切り替える
除外リスト方式が原因であれば、許可リスト方式であるinclude_onlyモードに切り替えれば解決します。Metric Collection タブにモードを選択する項目は見当たらなかったため、API から設定します。<CONFIG_ID>には先ほど取得したconfig_idを指定します。
curl -X PATCH "https://api.datadoghq.com/api/v2/integration/aws/accounts/<CONFIG_ID>" \
-H "DD-API-KEY: $DD_API_KEY" \
-H "DD-APPLICATION-KEY: $DD_APP_KEY" \
-H "Content-Type: application/json" \
-d '{
"data": {
"type": "account",
"attributes": {
"metrics_config": {
"namespace_filters": {
"include_only": ["AWS/Lambda"]
}
}
}
}
}'
PATCH のレスポンスでは、変更後のAWS インテグレーション設定の全体が返ってきます。整形すると以下のとおりです。
{
"data": {
"id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"type": "account",
"attributes": {
"account_tags": [
"aws_account:123456789012"
],
"auth_config": {
"role_name": "DatadogIntegrationRole",
"external_id": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
},
"aws_account_id": "123456789012",
"aws_partition": "aws",
"aws_regions": {
"include_only": [
"ap-northeast-1"
]
},
"created_at": "2026-08-20T03:05:01.610133Z",
"logs_config": {
"lambda_forwarder": {
"lambdas": [],
"sources": [],
"log_source_config": {
"tag_filters": []
}
}
},
"metrics_config": {
"enabled": true,
"automute_enabled": true,
"collect_custom_metrics": false,
"collect_cloudwatch_alarms": false,
"tag_filters": [],
"namespace_filters": {
"include_only": [
"AWS/Lambda"
]
}
},
"modified_at": "2026-08-26T08:32:59.345285142Z",
"resources_config": {
"cloud_security_posture_management_collection": false,
"extended_collection": false
},
"traces_config": {
"xray_services": {
"include_only": []
}
}
}
}
}
metrics_configのnamespace_filtersがinclude_onlyキーに変わっていることが分かります。念のため、改めて先ほどのGET を実行して確認します。
{
"config_id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"aws_account_id": "123456789012",
"namespace_filters": {
"include_only": [
"AWS/Lambda"
]
}
}
exclude_onlyに列挙されていた132 個のNamespace は無くなり、include_onlyにAWS/Lambdaのみが指定された状態になりました。
なお、PATCH のリクエストボディにはnamespace_filtersしか指定していませんが、レスポンスを見ると収集対象リージョンを絞っているaws_regionsや、IAM ロールの情報を保持しているauth_configはそのまま維持されています。変更したい項目のみを指定すれば良さそうです。
この状態であれば、Datadog が新しいNamespace に対応しても許可リストには追加されないため、収集対象が勝手に増えることはありません。
一方で、今後収集したいNamespace が増えた場合は明示的にリストへ追加する必要がありますのでご注意ください。
④ include_only モードはUI からの操作でも維持される
API でモードを切り替えた後、Metric Collection タブから操作した場合にモードがexclude_onlyに戻ってしまうと元も子もありません。そこで、include_onlyに切り替えた状態からMetric Collection タブでAWS/S3を有効化してみます。
その後に設定を確認すると、以下のとおりでした。
"namespace_filters": {
"include_only": [
"AWS/Lambda",
"AWS/S3"
]
}
モードはinclude_onlyのまま維持され、リストにAWS/S3が追加されています。したがって、いったんAPI でinclude_onlyに切り替えてしまえば、以降の追加や削除はMetric Collection タブから操作しても問題ないことが確認できました。
補足:include_only に指定するNamespace 名の調べ方
include_onlyに指定するNamespace 名は、Metric Collection タブでサービス名の右側に表示されている文字列(AWS/Lambdaや/aws/sagemaker/InferenceComponentsなど)がそのまま使用できます。ただし、133 件の中から目的のものを探すのは大変なので、API で一覧を取得する方法もあります。
AWS インテグレーションのAPI にはList available namespaces(GET /api/v2/integration/aws/available_namespaces)が用意されており、収集対象として指定できるNamespace の一覧を取得できます。
curl -s -X GET "https://api.datadoghq.com/api/v2/integration/aws/available_namespaces" \
-H "DD-API-KEY: $DD_API_KEY" \
-H "DD-APPLICATION-KEY: $DD_APP_KEY" \
| jq '.data.attributes.namespaces'
Terraform で管理する場合は、同じ情報をdatadog_integration_aws_available_namespacesデータソースから参照できます。
補足:Terraform で管理する場合
AWS インテグレーションをTerraform で管理している場合も、metrics_configのnamespace_filtersブロックでinclude_onlyを指定できます。
metrics_config {
namespace_filters {
include_only = ["AWS/Lambda"]
}
}
前述のとおりnamespace_filtersブロックを空にするとデフォルトのexclude_onlyが適用されるため、収集対象を固定したい場合はinclude_onlyを明示する必要があります。既にTerraform で管理している環境であれば、API を直接叩くよりもこちらの方が管理しやすいかと思います。
まとめ
Metric Collection タブの表示からは、内部的に除外リスト方式と許可リスト方式のどちらで保存されているかは分からず、そもそもそのような挙動になっていることもAWS インテグレーションを使い始めたばかりでは気付けないかと思います(私は気付けませんでした)。
CloudWatch API のポーリングはコストに直結するという面以外にも、連携対象のAWS アカウントからは明示的に指定したサービス以外のメトリクスは収集しない、といったガバナンスが必要な場面でも、収集対象を限定する運用を検討されることはあるかもしれません。そのような場合は、一度namespace_filtersのモードを確認いただければと思います。
本記事がどなたかのお役に立てれば幸いです。








