![[アップデート] AWS Resilience Hub v2 の依存関係ディスカバリに「依存関係インサイト」が追加されたので使ってみた](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-e90f2d5df93382d762eade0c5c825299/23a404c74b6ff29c464743064259e87a/amazon-resilience-hub?w=3840&fm=webp)
[アップデート] AWS Resilience Hub v2 の依存関係ディスカバリに「依存関係インサイト」が追加されたので使ってみた
いわさです。
AWS Resilience Hub は、2026 年 5 月に次世代版というやつが GA になってまして、現在は旧版と新版を利用可能です。互換性はなくて全然別のリソース群になっています。
この Resilience Hub v2 には依存関係ディスカバリという機能があって、コンピュートリソースから出される DNS クエリを自動で分析し、サービスが依存している AWS サービス・内部エンドポイント・サードパーティのエンドポイントを洗い出してくれる機能です。
なるほどね、DNS クエリで依存関係洗い出すのおもしろいですね。
先日のアップデートで、この依存関係ディスカバリに「依存関係インサイト（Dependency insights）」が追加されました。
この機能を使うと、生成 AI を使って依存関係を分析して、注目すべきパターンだけを要約でまとめてくれます。
有用かはわかないのですが、今回はこれを確認してみたので紹介します。
なお、同じアナウンスには EKS ラベルによるサービスソース対応と、AWS Organizations 経由のレジリエンスポリシー共有も含まれていますが、今回はこのうち依存関係インサイトを試してみることにしました。
使ってみる
検出対象となるサンプルのコンピュートリソースを作成
依存関係ディスカバリが対象にするのは、Route 53 リゾルバー経由で DNS クエリを出しているコンピュート（EC2 インスタンス、ECS タスク、EKS の Pod、VPC に接続された Lambda 関数）とされています。
Your service must have compute resources (Amazon Elastic Compute Cloud instances, Amazon Elastic Container Service tasks, Amazon Elastic Kubernetes Service pods, or VPC bound Lambda functions) that make DNS queries through Route 53 resolvers.
今回は依存関係ディスカバリ/インサイトの対象となる EC2 を 1 台構築しておきました。
稼働しているコンピュートが DNS クエリを出している必要があるとのことなので、今回は検証のためにいろいろな宛先へ DNS クエリを出し続けるようにユーザーデータで設定しておきました。
#!/bin/bash
# Emit diverse DNS queries continuously so Resilience Hub dependency discovery
# can attribute cross-region, third-party, and multi-service dependencies.
cat > /usr/local/bin/dns-noise.sh <<'EOS'
#!/bin/bash
# AWS services in multiple regions (cross-region dependencies)
HOSTS_AWS=(
"s3.ap-northeast-1.amazonaws.com"
"dynamodb.ap-northeast-1.amazonaws.com"
"sqs.ap-northeast-1.amazonaws.com"
"sns.ap-northeast-1.amazonaws.com"
"s3.us-east-1.amazonaws.com"
"dynamodb.us-east-1.amazonaws.com"
"sts.us-east-1.amazonaws.com"
"s3.eu-west-1.amazonaws.com"
"kinesis.us-west-2.amazonaws.com"
"secretsmanager.ap-northeast-1.amazonaws.com"
)
# Third-party endpoints (third-party dependencies)
HOSTS_TP=(
"api.datadoghq.com"
"api.pagerduty.com"
"api.stripe.com"
"hooks.slack.com"
"api.github.com"
)
while true; do
for h in "${HOSTS_AWS[@]}" "${HOSTS_TP[@]}"; do
getent hosts "$h" >/dev/null 2>&1 || nslookup "$h" >/dev/null 2>&1
done
sleep 60
done
EOS
chmod +x /usr/local/bin/dns-noise.sh
cat > /etc/systemd/system/dns-noise.service <<'EOS'
[Unit]
Description=DNS noise generator for Resilience Hub dependency discovery
After=network-online.target
[Service]
ExecStart=/usr/local/bin/dns-noise.sh
Restart=always
[Install]
WantedBy=multi-user.target
EOS
systemctl daemon-reload
systemctl enable --now dns-noise.service
AWS サービス（別リージョンの S3 や DynamoDB など）とサードパーティ（Datadog、PagerDuty、Stripe など）のホスト名を、1 分おきに名前解決させています。
Resilience Hub v2 からこの EC2 を拾う必要があるので、インスタンスにはblog=resilience-hubというタグをつけておきました。
依存関係ディスカバリを有効にする
依存関係インサイトは、依存関係ディスカバリを有効にして初回のディスカバリが完了しているサービスでのみ使えます。
ということで、続いて依存関係ディスカバリを有効にしておきます。
まず Resilience Hub v2 のコンソールを開きます。本日時点ではまだ Resilience Hub のトップ画面で v1 と v2 どちらを使うか切り替えが可能です。
サービスを作成します。今回は検証用に適用なシステムとユーザージャーニーを用意し、その下に hoge-blog-service というサービスを作成しました。
サービスリソースの検出では先ほどの blog=resilience-hub のタグを付けた EC2 インスタンスをリソースタグで指定しました。
サービス作成ウィザードの同じ画面には「依存関係の検出」のセクションもあり、ここで依存関係ディスカバリを有効にできます。
なお、「このサービスの依存関係の検出を有効にする」にチェックを入れると、追加料金がかかる旨と、DNS クエリ履歴を調べる仕組みの説明が表示されます。
依存関係ディスカバリは 1 サービスあたり月 10 USD のオプション料金が発生します。
有効にすると、対象コンピューティングリソースの過去 35 日分の DNS クエリをさかのぼって依存関係を洗い出し、その後は 1 時間ごとに継続して監視してくれるとのこと。
今回は新規サービスに対して有効化しましたが、作成済みのサービスに対して後から有効化する場合は、サービスのアセスメントタブから「Enable dependency discovery」を選ぶ手順になるようです。
Navigate to your service in the console and choose the Assessment tab. Then choose Enable dependency discovery.
有効化した直後は、依存関係の一覧は空です。
依存関係ディスカバリは DNS クエリを 1 時間ごとに集計するので、少し待つ必要があります。
一晩（約 14 時間）置いてから確認したところ、21 件の依存関係が発見されていました。
確認してみると意図的にクエリ出させていたものが一通り含まれていそうです。
| 依存関係 | DNS名 | ロケーション | プロバイダー |
|---|---|---|---|
| S3 | s3.eu-west-1.amazonaws.com | eu-west-1 | AWS |
| STS | sts.us-east-1.amazonaws.com | us-east-1 | AWS |
| S3 | s3.ap-northeast-1.amazonaws.com | ap-northeast-1 | AWS |
| inspector2-telemetry | inspector2-telemetry.ap-northeast-1.api.aws | ap-northeast-1 | AWS |
| SNS | sns.ap-northeast-1.amazonaws.com | ap-northeast-1 | AWS |
| Kinesis | kinesis.us-west-2.amazonaws.com | us-west-2 | AWS |
| Secrets Manager | secretsmanager.ap-northeast-1.amazonaws.com | ap-northeast-1 | AWS |
| DynamoDB | dynamodb.ap-northeast-1.amazonaws.com | ap-northeast-1 | AWS |
| Systems Manager | ssmmessages.ap-northeast-1.amazonaws.com | ap-northeast-1 | AWS |
| Slack | hooks.slack.com | ap-northeast-1 | AWS |
| Systems Manager | ssm.ap-northeast-1.amazonaws.com | ap-northeast-1 | AWS |
| PagerDuty | api.pagerduty.com | us-west-2 | AWS |
| GitHub | api.github.com | japaneast | Azure |
| S3（aws-ssm-document-attachments） | aws-ssm-document-attachments-ap-northeast-1.s3.ap-northeast-1.amazonaws.com | ap-northeast-1 | AWS |
| S3 | s3.us-east-1.amazonaws.com | us-east-1 | AWS |
| Datadog Metrics | api.datadoghq.com | us-east-1 | AWS |
| Stripe | api.stripe.com | Unknown | (空) |
| DynamoDB | dynamodb.us-east-1.amazonaws.com | us-east-1 | AWS |
| time.aws.com | time.aws.com | ap-northeast-3 | AWS |
| S3（al2023-repos） | al2023-repos-ap-northeast-1-de612dc2.s3.dualstack.ap-northeast-1.amazonaws.com | ap-northeast-1 | AWS |
| SQS | sqs.ap-northeast-1.amazonaws.com | ap-northeast-1 | AWS |
| Systems Manager | ec2messages.ap-northeast-1.amazonaws.com | ap-northeast-1 | AWS |
また、クロスリージョンで解決されている依存関係にはコンソール上で「クロスリージョン」のタグが付いて表示されていますね。
サードパーティは DNS 名から名前が識別されていて、api.datadoghq.com が「Datadog Metrics」、api.pagerduty.com が「PagerDuty」のように表示されました。
GitHub は location が Azure の japaneast、Stripe は location が Unknown と出ていて、DNS の解決先からプロバイダーやリージョンまで推定してくれていそうです。すごい。
依存関係インサイトを生成する
さて依存関係が抽出できたので、今回のアップデートである依存関係インサイトを生成してみましょうか。
サービスの依存関係セクションから Generate insights ボタンを押します。
生成には少し時間がかかります。
しばらく待つと要約が返ってきました。発見された 21 件のうち 20 件を対象に、4 件のインサイトが生成されたようです。
4 insights generated for service 'hoge-blog-service' across 20 dependencies, surfacing cross-region, third-party, and new dependency patterns.
4 件のインサイトは、パターンで見るとクロスリージョン依存・サードパーティ依存・新規依存の 3 種類でした。クロスリージョン依存だけ、AWS サービスとサードパーティで 1 件ずつに分かれて 2 件になっています。
- クロスリージョン依存（AWS サービス）: DynamoDB（us-east-1）、Kinesis（us-west-2）、STS（us-east-1）、S3（us-east-1・eu-west-1）が東京から別リージョン経由で呼ばれていて、3 つの別リージョンに可用性が結びついている、と指摘されました。
- クロスリージョン依存（サードパーティ）: Datadog と PagerDuty も別リージョン経由で、障害時にアラートや監視に影響しうる点が挙がっています。
- サードパーティ依存: GitHub と Stripe が同一リージョンで解決される、DNS クエリ量の少ないサードパーティ依存として抽出されれました。
- 新規依存: 20 件すべてが直近 7 日以内に初めて現れた依存関係、と出ました。今回は新しく立てた EC2 なので、当たり前ですけど全部が新規扱いになりましたね。
対象が 21 件でなく 20 件になっているのは、time.aws.com（NTP）が要約から除外されたためだと思われます。
公式ドキュメントによると CloudWatch・NTP・SSM のような、たいていのサービスに出てきてレジリエンスリスクになりにくい AWS サービスは、要約から除外される仕様のようです。SSM は除外されなかったのでよくわからないが...
To keep the summary focused, Dependency insights filters out common AWS service noise – such as CloudWatch, NTP, and SSM – that does not typically indicate a resilience risk.
なお、インサイトは 24 時間に 1 回だけ再生成できます。依存関係データは 1 時間ごとに集計されますが、同じ日に生成し直しても結果はほぼ変わらないとのことです。
コンソール上も 24 時間は再生成できない旨の記載があり、ボタンが押せなくなっています。
さいごに
本日は AWS Resilience Hub v2 に依存関係インサイトが追加されたので確認してみました。
依存関係ディスカバリが集めた大量の依存関係を、生成 AI がレジリエンスの観点で 4 つのパターンに要約してくれる機能でした。
今回のように21 件くらいであれば目視で把握できそうですが、大量に依存関係がある場合はクロスリージョン依存やサードパーティ依存とか「見ておきたいところ」に要約から直接たどり着けるので助かるのかもしれないです。
Datadog とかサードパーティ依存まで洗い出してくれるのはおもしろいですね。DNS クエリで洗い出ししてるのはなるほどって感じです。
あくまでも DNS クエリでの依存関係抽出なので、リソース特定まではしてくれるものではありません。公式ドキュメントによると S3 や DynamoDB など DNS 名にリソース名が含まれている場合は依存関係としての特定もできるっぽいです。
