概要
VPC内のリソースがどのドメインにDNSクエリを送信しているかを把握することは、セキュリティ監視や異常検知において重要です。Route 53 Resolverクエリログを有効にすることでDNSクエリの記録は可能ですが、大量のログデータから「最も多くクエリされているドメインは何か」「どのEC2インスタンスが最も多くDNSクエリを発行しているか」といったパターンを即座に把握するのは容易ではありません。
この課題を解決するのが CloudWatch Contributor Insights です。Contributor Insightsは、CloudWatch Logsのログデータをリアルタイムで分析し、上位のコントリビューター（寄与者）を時系列のグラフで可視化する機能です。Route 53 Resolverクエリログと組み合わせることで、DNSアクティビティの傾向を素早く把握できます。
本記事では、Route 53 Resolverクエリログの送信先としてCloudWatch Logsを設定し、Contributor Insightsルールを作成してDNSクエリのトップコントリビューターを分析する手順を解説します。
この記事のメリット
- CloudWatch Contributor Insightsの概念と用途を理解できる
- Route 53 ResolverクエリログのJSON構造を把握し、分析に必要なキーフィールドを特定できる
- Contributor Insightsルールの作成方法と、ログフォーマットに基づくキー指定の手順を習得できる
- 「最もクエリされたドメイン」「最もDNSクエリを発行したインスタンス」をリアルタイムで可視化できる
- SCS試験で「DNSクエリの分析方法」に関する問いに正確に答えられるようになる
執筆者とキャラクター紹介
執筆者：土肥（とひ）
株式会社ジェニュインの代表であり元エンジニア。これまでオンプレミスと AWS 環境のインフラ業務を担当。AWS 認定資格の学習で得た知識を、ハンズオンとともに解説するのが得意。直近では新人の教育も行っており、これから技術を学ぶ方が納得できる解説を心がけています。基礎編・Cloud Practitioner の記事では、解説役としても登場します。
クラウドおさる
クラウドおさるはじめましてでござる。弊猿はクラウドおさる。IT インフラが異常に発達した猿山から、雲に乗って地上の AWS を学びに降りてきたのでござる。
クラウドおさる基礎編や Cloud Practitioner の記事では、とひさんに素朴な疑問をぶつける役でござるな。Security - Specialty などの記事では、要所でワンポイントや注意点をひとこと添えるでござる。
クラウドおさる猿山にもデータセンターや監視当番があって、地上で起きることはだいたい猿山にも同じ仕組みがあるのでござる。例え話がつい猿山に寄るのは、弊猿の癖でござる。
技術解説
CloudWatch Contributor Insightsとは
CloudWatch Contributor Insightsは、CloudWatch Logsのログデータを分析し、システムパフォーマンスに影響を与えている上位のコントリビューターを特定する機能です。ルールを定義することで、ログの特定のフィールドを集計キーとして指定し、上位N件のコントリビューターを時系列グラフで表示できます。
主な特徴は以下の通りです。
- リアルタイム分析: ログデータが到着するたびに自動的に集計される
- カスタムルール: 任意のログフィールドをキーとして指定できる
- 時系列可視化: トップコントリビューターの推移をグラフで確認できる
- アラーム連携: 特定のコントリビューターが閾値を超えた場合にCloudWatchアラームをトリガーできる
Route 53 Resolverクエリログの構造
Route 53 Resolverクエリログは、VPC内のリソースが行ったDNSクエリの詳細をJSON形式で記録します。Contributor Insightsで分析する際に重要なフィールドは以下の通りです。
| フィールド | 説明 | 分析での用途 |
|---|---|---|
query_name | クエリ対象のドメイン名 | 最も多くクエリされたドメインの特定 |
srcaddr | クエリ送信元のIPアドレス | 最も多くDNSクエリを発行したインスタンスの特定 |
query_type | クエリタイプ（A、AAAA、MXなど） | クエリタイプ別の傾向分析 |
rcode | レスポンスコード（NOERROR、NXDOMAINなど） | エラーの多いドメインの特定 |
srcids.instance | クエリ送信元のEC2インスタンスID | インスタンスID別の分析 |
以下は、Route 53 Resolverクエリログのレコード例です。
{
"version": "1.100000",
"account_id": "123456789012",
"region": "ap-northeast-1",
"vpc_id": "vpc-0abc1234def56789",
"query_timestamp": "2026-03-22T10:00:00Z",
"query_name": "example.com.",
"query_type": "A",
"query_class": "IN",
"rcode": "NOERROR",
"answers": [
{
"Rdata": "93.184.216.34",
"Type": "A",
"Class": "IN"
}
],
"srcaddr": "10.0.1.50",
"srcport": "12345",
"transport": "UDP",
"srcids": {
"instance": "i-0abc1234def56789"
}
}Contributor Insightsルールの仕組み
Contributor Insightsルールは、以下の要素で構成されます。
| 要素 | 説明 |
|---|---|
| ロググループ | 分析対象のCloudWatch Logsロググループ |
| ログフォーマット | ログの形式（JSON またはCLF） |
| コントリビューションのキー（Keys） | 集計に使用するフィールド（最大4つ）。この組み合わせが「寄稿者（コントリビューター）」になる |
| フィルター | 分析対象を絞り込む条件（オプション） |
| 集計（AggregateOn） | 「カウント」＝出現回数でランク付け／「合計」＝指定したログフィールドの数値の合計でランク付け |
Route 53 Resolverクエリログの場合、ログフォーマットは JSON を選択し、キーには query_name や srcaddr などのフィールドを指定します。
実践
ここでは、Route 53 ResolverクエリログをCloudWatch Logsに送信し、Contributor Insightsルールを作成してDNSクエリのトップコントリビューターを分析する手順を説明します。
前提条件
- リージョン:
ap-northeast-1（東京） - VPCが1つ存在し、EC2インスタンスが起動済みの状態を前提とします
- Route 53 Resolverクエリログの基本的な設定手順については、別記事「Route 53 Resolverクエリログの有効化とDNSアクティビティ監視」を参照してください
| リソース種別 | リソース名 | 用途 |
|---|---|---|
| CloudWatch Logsロググループ | /aws/route53resolver/query-logs | Resolverクエリログの送信先 |
| Route 53 Resolverクエリログ設定 | vpc-dns-query-log | VPCのDNSクエリを記録 |
| Contributor Insightsルール | TopDNSQueries | 最もクエリされたドメインの分析 |
| Contributor Insightsルール | TopDNSClients | 最もDNSクエリを発行したインスタンスの分析 |
CloudWatch Logsロググループの作成
AWSマネジメントコンソールにログインし、リージョンが ap-northeast-1（東京）であることを確認します。
上部の検索バーに CloudWatch と入力し、表示された「CloudWatch」を選択します。
左側ナビゲーションの「ログ」→「ログ管理」を選択します。
「ロググループを作成」をクリックし、以下を入力します。
- ロググループ名:
/aws/route53resolver/query-logs - 保持期間の設定:
1 週間 (7 日)
「作成」をクリックします。
ロググループ一覧に /aws/route53resolver/query-logs が表示されることを確認します。
Route 53 Resolverクエリログの設定
Route 53 Resolverクエリログを設定し、先ほど作成したCloudWatch Logsロググループにログを送信します。
上部の検索バーに Route 53 と入力し、表示された「Route 53」を選択します。
左側ナビゲーションの「VPC リゾルバー」→「クエリのログ記録」を選択します。
「クエリログ記録の設定」をクリックし、以下を入力します。
- 名前:
vpc-dns-query-log - クエリログの送信先: 「CloudWatch Logs のロググループ」を選択（デフォルト。ほかに「S3 バケット」「Amazon Data Firehose 配信ストリーム」があります）
- CloudWatch Logs ログのグループ:
/aws/route53resolver/query-logsを選択 - 「クエリをログ記録する VPC – オプション」で「VPC を追加」をクリックし、開いたダイアログで対象のVPCにチェックを入れて「追加」をクリック
「クエリログの設定」をクリックします。
ステータスが「作成済み」になることを確認します。
Note: クエリログが実際にCloudWatch Logsに到着するまで数分かかります。EC2インスタンスにSSH接続してDNSクエリを発生させると、ログの確認が早くなります。以下のコマンドでDNSクエリを発生させることができます。
>
“
bash # 複数のドメインにDNSクエリを送信 nslookup example.com nslookup amazon.com nslookup google.com nslookup aws.amazon.com # 同じドメインに繰り返しクエリを送信（トップコントリビューター確認用） for i in $(seq 1 20); do nslookup example.com; done for i in $(seq 1 10); do nslookup amazon.com; done“
Contributor Insightsルールの作成（トップクエリドメイン）
CloudWatch Contributor Insightsルールを作成し、最もクエリされたドメインを分析します。
上部の検索バーに CloudWatch と入力し、表示された「CloudWatch」を選択します。
左側ナビゲーションの「インサイト」→「Contributor Insights」を選択します。
「ルールを作成」をクリックすると、3ステップのウィザードが開きます。
ステップ1: ルールの定義
- 「ウィザード」タブが選択されていることを確認します（「構文」タブではルール定義のJSONを直接書けます）
- 「ロググループを選択」の検索ボックスに
/aws/route53resolver/query-logsと入力し、候補から選択します - ルールタイプ: 「カスタムルール」を選択します
- ログの形式: 「JSON」を選択します
- 「コントリビューション」セクションで「新しいキーを追加」をクリックし、キーに
query_nameを入力します - 「フィルター – オプション」は設定しません
- 「集計」は「カウント」（デフォルト）のままにします
「次へ」をクリックします。
ステップ2: ルールの詳細を指定
- ルール名:
TopDNSQueries - ルールの状態: 「有効化」にチェックが入っていることを確認します
「次へ」をクリックします。
ステップ3: プレビューと作成
ルール定義の内容（ロググループ・ログの形式・フィールド $.query_name・集計）を確認し、「ルールを作成」をクリックします。
ルール一覧に TopDNSQueries が有効な状態で表示されることを確認します。データのレポートが表示されるまでに最大5分かかります。
Contributor Insightsルールの作成（トップDNSクライアント）
同様の手順で、最もDNSクエリを発行したクライアントIPを分析するルールを作成します。
Contributor Insights画面で「ルールを作成」をクリックし、ステップ1で以下を設定します。
- ロググループ:
/aws/route53resolver/query-logs - ルールタイプ: 「カスタムルール」
- ログの形式:
JSON - コントリビューションのキー:
srcaddr - 集計: 「カウント」
ステップ2でルール名に TopDNSClients を入力し、ステップ3で「ルールを作成」をクリックします。
Contributor Insightsダッシュボードでの確認
ルール作成後、DNSクエリログが蓄積されると、Contributor Insightsダッシュボードにトップコントリビューターが表示されます。
Contributor Insights画面で TopDNSQueries ルールを選択します。
画面上部の「時間範囲」で 30分 を選択します（5分 / 30分 / 1時間 / 3時間 / 12時間 / カスタム から選べます）。
ダッシュボードには以下の情報が表示されます。
- 時系列グラフ: 上位の寄稿者ごとのクエリ数の推移
- ランキング表:
$.query_nameごとの「データポイントの合計」（選択した期間内のクエリ数）
「寄稿者」「期間」「順序」「ウィジェットタイプ」のプルダウンで、表示する上位件数・集計間隔・並び順・グラフ種別を変更できます。
続いて、TopDNSClients ルールを選択して確認します。
送信元IPアドレス別のDNSクエリ数のランキングと推移が表示されます。特定のインスタンスが異常に多くのDNSクエリを発行している場合、マルウェア感染やDNSトンネリングの兆候として検知に活用できます。
ルール定義の確認（JSON構文）
作成したルールの定義は、JSON構文でも確認できます。ルール作成ウィザードのステップ1で「構文」タブに切り替えると、以下のようなJSON定義を直接編集できます。
{
"Schema": {
"Name": "CloudWatchLogRule",
"Version": 1
},
"AggregateOn": "Count",
"Contribution": {
"Filters": [],
"Keys": [
"$.query_name"
]
},
"LogFormat": "JSON",
"LogGroupARNs": [
"arn:aws:logs:ap-northeast-1:<アカウントID>:log-group:/aws/route53resolver/query-logs"
]
}キーは $.query_name のように JSON プロパティ形式（$ 始まり）で指定します。ロググループの指定は LogGroupNames（ロググループ名）と LogGroupARNs（ARN）のどちらか一方だけを使用します。ウィザードで作成すると LogGroupARNs が使われます。
このJSON定義を直接編集してルールを作成することも可能です。たとえば、レスポンスコードが NXDOMAIN（ドメインが存在しない）のクエリだけを分析したい場合、Filters にフィルター条件を追加できます。
"Filters": [
{
"Match": "$.rcode",
"EqualTo": "NXDOMAIN"
}
]この応用により、存在しないドメインへのクエリが多いインスタンスを検出し、マルウェアやDGAドメイン（Domain Generation Algorithm）による不審なDNSアクティビティの兆候を捉えることができます。
まとめ
- CloudWatch Contributor Insights は、CloudWatch Logsのログデータから上位のコントリビューターをリアルタイムで可視化する機能である
- Route 53 ResolverクエリログをCloudWatch Logsに送信することで、Contributor Insightsによる分析が可能になる
query_nameをキーに指定することで、最も多くクエリされたドメインを特定できるsrcaddrをキーに指定することで、最も多くDNSクエリを発行したインスタンスを特定できる- フィルター条件を組み合わせることで、NXDOMAINレスポンスの分析など、セキュリティ監視に応用できる
- 異常なDNSクエリパターンの検出は、マルウェア感染やDNSトンネリングの早期発見に有効である
参照先
- Amazon CloudWatch Contributor Insights を使用した高カーディナリティデータの分析
- Contributor Insights ルール構文
- Resolver クエリログ記録の設定
- Resolver クエリログに記録される値
