翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon Route 53 のモニタリング
モニタリングは、 AWS ソリューションの信頼性、可用性、パフォーマンスを維持する上で重要な部分です。マルチポイント障害が発生した場合は、その障害をより簡単にデバッグできるように、 AWS ソリューションのすべての部分からモニタリングデータを収集する必要があります。ただし、モニタリングを開始する前に、以下の質問に対する回答を反映したモニタリング計画を作成する必要があります。
+ どのような目的でモニタリングしますか?
+ どのリソースをモニタリングしますか?
+ どのくらいの頻度でこれらのリソースをモニタリングしますか?
+ どのモニタリングツールを利用しますか?
+ 誰がモニタリングタスクを実行しますか?
+ 問題が発生したときに誰が通知を受け取りますか?
**Topics**
+ [パブリック DNS クエリのログ記録](query-logs.md)
+ [リゾルバーでのクエリのログ記録](resolver-query-logs.md)
+ [ドメイン登録のモニタリング](monitoring-domain-registrations.md)
+ [Amazon Route 53 のヘルスチェックと Amazon CloudWatch を使用したリソースのモニタリング](monitoring-cloudwatch.md)
+ [Amazon CloudWatch を使用したホストゾーンのモニタリング](monitoring-hosted-zones-with-cloudwatch.md)
+ [Amazon CloudWatch による Route 53 VPC Resolver エンドポイントのモニタリング](monitoring-resolver-with-cloudwatch.md)
+ [Amazon CloudWatch を使用した Resolver DNS Firewall ルールグループのモニタリング](monitoring-resolver-dns-firewall-with-cloudwatch.md)
+ [を使用したリゾルバー DNS ファイアウォールイベントの管理 Amazon EventBridge](dns-firewall-eventbridge-integration.md)
+ [を使用した Amazon Route 53 API コールのログ記録 AWS CloudTrail](logging-using-cloudtrail.md)
# パブリック DNS クエリのログ記録
Route 53 が受信するパブリック DNS クエリに関する次のような情報をログ記録するように、Amazon Route 53 を設定できます。
+ リクエストされたドメインまたはサブドメイン
+ リクエストの日付と時刻
+ DNS レコードタイプ (A や AAAA など)
+ DNS クエリに応答した Route 53 エッジロケーション
+ DNS レスポンスコード (`NoError` や `ServFail` など)
クエリのログ記録を設定すると、Route 53 により CloudWatch Logs に対しログが送信されるようになります。CloudWatch Logs ツールを使用してクエリログにアクセスします。
クエリログには、DNS リゾルバーが Route 53 に転送したクエリのみが含まれます。DNS リゾルバーが既にクエリ (example.com のロードバランサーの IP アドレスなど) への応答をキャッシュしている場合、リゾルバーは Route 53 へのクエリの送信は行わず、対応するレコードの TTL の有効期限が切れるまで、キャッシュされた応答を返信し続けます。
ドメイン名 (example.com) またはサブドメイン名 (www.example.com) に送信された DNS クエリ数、ユーザーが使用しているリゾルバー、およびレコードの TTL によって、クエリログに含まれる情報は DNS リゾルバーに送信された数千件の各クエリのうち 1 つのクエリのみに関するものである場合があります。DNS の仕組みについては、「[ウェブサイトやウェブアプリケーションへのインターネットトラフィックのルーティング](welcome-dns-service.md)」を参照してください。
詳細なログ情報が必要ない場合は、Amazon CloudWatch メトリクスを使用すると、ホストゾーンのために Route 53 が応答している DNS クエリの総数を確認できます。詳細については、「[パブリックホストゾーンの DNS クエリメトリクスの表示](hosted-zone-public-viewing-query-metrics.md)」を参照してください
**Topics**
+ [DNS クエリのログ記録の設定](#query-logs-configuring)
+ [Amazon CloudWatch を使用して DNS クエリログにアクセスする](#query-logs-viewing)
+ [ログの保持期間の変更と Amazon S3 へのログのエクスポート](#query-logs-changing-retention-period)
+ [クエリログ記録の停止](#query-logs-deleting-configuration)
+ [DNS クエリログに表示される値](#query-logs-format)
+ [クエリログの例](#query-logs-example)
## DNS クエリのログ記録の設定
特定のホストゾーンでの DNS クエリのログ記録を開始するには、Amazon Route 53 コンソールで以下のタスクを実行します。
+ Route 53 がログを発行する先の CloudWatch Logs ロググループを選択するか、新しいロググループを作成します。
**注記**
ロググループは、米国東部 (バージニア北部) リージョンに置かれる必要があります。
+ [**Create (作成) **] を選択して終了します。
**注記**
ユーザーがドメイン宛ての DNS クエリを送信すると、クエリログ記録の設定を作成してから数分以内にログ内にクエリが表示されるはずです。
**DNS クエリのログ記録を設定するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) で Route 53 コンソールを開きます。
1. ナビゲーションペインで [**Hosted zones**] を選択します。
1. クエリのログ記録を設定するホストゾーンを選択します。
1. [**Hosted zone details**] ペインで、[**クエリログ記録の設定**] を選択します。
1. 既存のロググループを選択するか、もしくは新しいロググループを作成します。
1. 許可に関するアラートを受け取った場合 (これは、新しいコンソールでのクエリログ記録の設定が完了していない場合に発生します)、次のいずれかの操作を行います。
+ 既に 10 個のリソースポリシーがある場合、それ以上ポリシーを作成することはできません。リソースポリシーのいずれかを選択し、[**Edit (編集)**] を選択します。編集することで、ロググループにログを書き込む許可が Route 53 に与えられます。[**Save**] を選択します。アラートが消え、次のステップに進むことが可能になります。
+ 以前にクエリのログ記録を設定したことがない場合 (または、リソースポリシーをまだ 10 個まで作成していない場合) は、CloudWatch Logs グループにログを書き込むためのアクセス許可を、Route 53 に付与する必要があります。[**Grant permissions (アクセス許可の付与)**] を選択します。アラートが消え、次のステップに進むことが可能になります。
1. [**アクセス許可 – オプション**] を選択してテーブルを表示し、リソースポリシーが CloudWatch ロググループに一致しているか、CloudWatch にログを発行するためのアクセス許可が Route 53 に付与されているかを確認します。
1. [**Create (作成)**] を選択します。
## Amazon CloudWatch を使用して DNS クエリログにアクセスする
Amazon Route 53 では、クエリログは直接 CloudWatch Logs に送信されます。Route 53 経由でログにアクセスすることはできません。代わりに CloudWatch Logs を使用することで、ほぼリアルタイムでのログの表示、データの検索とフィルタリング、および Amazon S3 へのログのエクスポートが行えます。
Route 53 は、指定されたホストゾーンの DNS クエリに応答するための Route 53 エッジロケーションごとに、1 つの CloudWatch Logs ログストリームを作成し、クエリログを適切なログストリームに送信します。各ログストリームの名前の形式は *hosted-zone-id*/*edge-location-ID* (例: `Z1D633PJN98FT9/DFW3`) です。
各エッジロケーションは、3 文字コードと、割り当てられた任意の数字で識別されます (例: DFW3)。通常、この 3 文字コードは、エッジロケーションの近くにある空港の、国際航空運送協会の空港コードに対応します (これらの略語は今後変更される可能性があります。) エッジロケーションの一覧については、[Route 53 製品の詳細](https://aws.amazon.com/route53/details/)ページの「Route 53 グローバルネットワーク」を参照してください。
**注記**
上記の規則に従わないプレフィックスやサフィックスが表示される場合があります。これらのエンコード属性は、内部使用に限定されます。
詳細については、該当するドキュメントを参照してください。
+ [Amazon CloudWatch Logs ユーザーガイド](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/)
+ [Amazon CloudWatch Logs API リファレンス](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/)
+ [コマンドリファレンスの CloudWatch Logs AWS CLI セクション](https://docs.aws.amazon.com/cli/latest/reference/logs/index.html)
+ [DNS クエリログに表示される値](#query-logs-format)
## ログの保持期間の変更と Amazon S3 へのログのエクスポート
デフォルトでは、CloudWatch Logs のクエリログの保持期限に制限はありません。必要に応じて保持期間を指定することで、 この期間よりも古いログを CloudWatch Logs が削除するようにできます。詳細については、*Amazon CloudWatch ユーザーガイド*の「[CloudWatch Logs でのログデータ保持期間の変更](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/SettingLogRetention.html)」を参照してください。
ログデータを保持しながら、そのデータを CloudWatch Logs ツールにより確認および分析する必要がないという場合は、ログをAmazon S3 にエクスポートすることでストレージコストを削減できます。詳細については、「[Amazon S3 へのログデータのエクスポート](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html)」を参照してください。
料金表の詳細については、該当の料金表ページを参照してください。
+ [CloudWatch 料金表](https://aws.amazon.com/cloudwatch/pricing)ページの「Amazon CloudWatch Logs」
+ [Amazon S3 料金](https://aws.amazon.com/s3/pricing)
**注記**
Route 53 で DNS クエリをログ記録するように設定する場合には、利用料金は発生しません。
## クエリログ記録の停止
CloudWatch Logs に対するクエリログの送信を、Amazon Route 53 に停止させる場合は、以下の手順を実行しクエリログ記録の設定を削除します。
**クエリログ記録設定を削除するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) で Route 53 コンソールを開きます。
1. ナビゲーションペインで [**Hosted zones**] を選択します。
1. クエリログ記録の設定を削除するホストゾーンの名前を選択します。
1. [**Hosted zone details (ホストゾーンの詳細)**] ペインで、[**Delete query logging configuration (クエリログ記録の設定を削除)**] を選択します。
1. [**Delete**] を選択して確定します。
## DNS クエリログに表示される値
各ログファイルには、対応するエッジロケーションで Amazon Route 53 が DNS リゾルバーから受信した DNS クエリごとに、それぞれ 1 つのログエントリが記述されています。各ログエントリには、以下の値が記述されています。
**ログ形式バージョン**
クエリログのバージョン番号。ログにフィールドを追加したり既存のフィールドの形式を変更した場合、この値を増分します。
**クエリのタイムスタンプ**
Route 53 がリクエストに応答した日時。ISO 8601 形式の協定世界時 (UTC) (例: `2017-03-16T19:20:25.177Z`) です。
ISO 8601 形式については、Wikipedia の記事「[ISO 8601](https://en.wikipedia.org/wiki/ISO_8601)」を参照してください。UTC については、Wikipedia の記事「[協定世界時](https://en.wikipedia.org/wiki/Coordinated_Universal_Time)」を参照してください。
**ホストゾーン ID**
このログのすべての DNS クエリに関連付けられるホストゾーンの ID。
**クエリ名**
リクエストで指定されたドメインまたはサブドメイン。
**クエリタイプ**
リクエストで指定された DNS レコードタイプ、または `ANY` のいずれか。Route 53 でサポートされるタイプについては、「[サポートされる DNS レコードタイプ](ResourceRecordTypes.md)」を参照してください。
**Response Code (レスポンスコード)**
DNS クエリに応答して Route 53 が返した DNS レスポンスコード。
**レイヤー 4 プロトコル**
クエリの送信に使用されたプロトコル (`TCP` または `UDP`)。
**Route 53 エッジロケーション**
クエリに応答した Route 53 エッジロケーション。各エッジロケーションは、3 文字コードと、任意の数字で識別されます (例: DFW3)。通常、この 3 文字コードは、エッジロケーションの近くにある空港の、国際航空運送協会の空港コードに対応します (これらの略語は今後変更される可能性があります。)
エッジロケーションの一覧については、[Route 53 製品の詳細](https://aws.amazon.com/route53/details/)ページの「Amazon Route 53 のグローバルネットワーク」を参照してください。
**リゾルバー IP アドレス**
Route 53 にリクエストを送信した DNS リゾルバーの IP アドレス。
**EDNS クライアントサブネット**
リクエストを発信したクライアントの IP アドレスの一部 (DNS リゾルバーから取得できる場合)。
詳細については、IETF ドラフトの「[Client Subnet in DNS Requests](https://tools.ietf.org/html/draft-ietf-dnsop-edns-client-subnet-08)」を参照してください。
## クエリログの例
クエリログの例を次のように表示します (リージョンはプレースホルダーです):
```
1.0 2017-12-13T08:16:02.130Z Z123412341234 example.com A NOERROR UDP Region 192.168.1.1 -
1.0 2017-12-13T08:15:50.235Z Z123412341234 example.com AAAA NOERROR TCP Region 192.168.3.1 192.168.222.0/24
1.0 2017-12-13T08:16:03.983Z Z123412341234 example.com ANY NOERROR UDP Region 2001:db8::1234 2001:db8:abcd::/48
1.0 2017-12-13T08:15:50.342Z Z123412341234 bad.example.com A NXDOMAIN UDP Region 192.168.3.1 192.168.111.0/24
1.0 2017-12-13T08:16:05.744Z Z123412341234 txt.example.com TXT NOERROR UDP Region 192.168.1.2 -
```
# リゾルバーでのクエリのログ記録
次の DNS クエリをログ記録できます。
+ 指定した Amazon Virtual Private Cloud VPC で発生するクエリ、およびこれらの DNS クエリに対する応答。
+ インバウンドの Resolver エンドポイントを使用する、オンプレミスのリソースからのクエリ。
+ 再帰的な DNS 解決にアウトバウンド Resolver のエンドポイントを使用するクエリ。
+ Resolver DNS Firewall ルールを使用してドメインリストをブロック、許可、またはモニタリングするクエリ。
VPC Resolver クエリログには、次のような値が含まれます。
+ VPC が作成された AWS リージョン
+ クエリの発信元である VPC の ID
+ クエリの発信元であるインスタンスの IP アドレス
+ クエリの発信元であるリソースのインスタンス ID
+ クエリが最初に作成された日時
+ リクエストされた DNS 名 (prod.example.com など)
+ DNS レコードタイプ (A や AAAA など)
+ DNS レスポンスコード (`NoError` や `ServFail` など)
+ DNS 応答データ (DNS クエリに応答して返される IP アドレスなど)
+ DNS Firewall ルールのアクションに対する応答
ログに記録されるすべての値の詳細なリストと、その例については、「[VPC Resolver クエリログに表示される値](resolver-query-logs-format.md)」を参照してください。
**注記**
DNS リゾルバーの標準と同様に、リゾルバーはその有効期限 (TTL) に定義されている期間、DNS クエリをキャッシュします。Route 53 VPC Resolver はVPCs から送信されるクエリをキャッシュし、可能な限りキャッシュから応答して応答を高速化します。VPC Resolver クエリログ記録は、VPC Resolver がキャッシュから応答できるクエリではなく、一意のクエリのみをログに記録します。
例えば、クエリのログ記録の設定が機能している VPC の 1 つにある EC2 インスタンスが、accounting.example.com に対しリクエストを送信するとします。VPC Resolver は、そのクエリへのレスポンスをキャッシュし、クエリをログに記録します。同じインスタンスの Elastic Network Interface が VPC Resolver のキャッシュの TTL 内で accounting.example.com に対してクエリを実行すると、VPC Resolver はキャッシュからクエリに応答します。この 2 番目のクエリはログに記録されません。
ログは、次のいずれかの AWS リソースに送信できます。
+ Amazon CloudWatch Logs (CloudWatch Logs) のロググループ
+ Amazon S3 (S3) バケット
+ Firehose 配信ストリーム
詳細については、「[AWS VPC Resolver クエリログを送信できる リソース](resolver-query-logs-choosing-target-resource.md)」を参照してください。
**Topics**
+ [AWS VPC Resolver クエリログを送信できる リソース](resolver-query-logs-choosing-target-resource.md)
+ [Resolver のクエリログ記録の設定の管理](resolver-query-logging-configurations-managing.md)
# AWS VPC Resolver クエリログを送信できる リソース
**注記**
クエリをログ記録するワークロードで、1 秒あたりのクエリ数 (QPS) が多くなることが想定される場合は、Amazon S3 を使用することで、送信先に書き込まれる時点で発生するクエリログのスロットリングを防ぎます。Amazon CloudWatch を使用している場合は、`PutLogEvents` オペレーションのために、1 秒あたりのリクエスト数の上限を引き上げることができます。CloudWatch の制限の引き上げの詳細については、*Amazon CloudWatch ユーザーガイド*の「[CloudWatch Logs のクォータ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/cloudwatch_limits_cwl.html)」を参照してください。
VPC Resolver クエリログは、次の AWS リソースに送信できます。
**Amazon CloudWatch Logs (Amazon CloudWatch Logs) のロググループ**
Logs Insights を使用すると、ログの分析やメトリクスとアラームの作成が可能です。
詳細については、 [Amazon CloudWatch Logs ユーザーガイド](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/)を参照してください。
**Amazon S3 (S3) バケット**
長期間にわたるログのアーカイブには、S3 バケットの使用が経済的です。通常は、高いレイテンシーが得られます。
すべての S3 サーバー側の暗号化オプションがサポートされています。詳細については、「*Amazon S3 ユーザーガイド*」の「[サーバー側の暗号化によるデータの保護](https://docs.aws.amazon.com/AmazonS3/latest/userguide/serv-side-encryption.html)」を参照してください。
AWS KMS キーによるサーバー側の暗号化 (SSE-KMS) を選択した場合は、ログ配信アカウントが Amazon S3 バケットに書き込めるように、カスタマーマネージドキーのキーポリシーを更新する必要があります。SSE-KMS での使用に必要なキーポリシーについては、「*Amazon CloudWatch ユーザーガイド*」の「[Amazon S3 バケットのサーバー側の暗号化](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-infrastructure-V2-S3.html#AWS-logs-SSE-KMS-S3-V2)」を参照してください。
自分が所有するアカウント内に S3 バケットがある場合、必要なアクセス許可がバケットポリシーに自動的に追加されます。自身で所有していないアカウントの S3 バケットにログを送信する場合は、その S3 バケットの所有者が、バケットポリシーの中に必要なアクセス許可を追加する必要があります。次に例を示します。
****
```
{
"Version":"2012-10-17",
"Id": "CrossAccountAccess",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "delivery.logs.amazonaws.com"
},
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::your_bucket_name/AWSLogs/your_caller_account/*"
},
{
"Effect": "Allow",
"Principal": {
"Service": "delivery.logs.amazonaws.com"
},
"Action": "s3:GetBucketAcl",
"Resource": "arn:aws:s3:::your_bucket_name"
},
{
"Effect": "Allow",
"Principal": {
"AWS": "iam_user_arn_or_account_number_for_root"
},
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::your_bucket_name"
}
]
}
```
組織の中心的な S3 バケットにログを保存する場合は、(中心的バケットへの書き込みに必要なアクセス許可を持つ) 中央のアカウントからクエリログ記録を設定した上で、[RAM](query-logging-configurations-managing-sharing.md) を使用しながら、アカウント全体でその構成を共有することをお勧めします。
詳細については、[Amazon Simple Storage Service ユーザーガイド](https://docs.aws.amazon.com/AmazonS3/latest/userguide/)を参照してください。
**Firehose 配信ストリーム**
Amazon OpenSearch Service、Amazon Redshift、またはその他のアプリケーションに対し、リアルタイムでログのストリーミングが可能です。
詳細については、「[Amazon Data Firehose デベロッパーガイド](https://docs.aws.amazon.com/firehose/latest/dev/)」を参照してください。
Resolver でのクエリのログ記録の料金については、[Amazon CloudWatch の料金表](https://aws.amazon.com/cloudwatch/pricing/)を参照してください。
CloudWatch Vended Logs 料金は、ログが Amazon S3 に直接公開されている場合でも、VPC Resolver ログを使用する場合に適用されます。詳細については、「[*Logs pricing* at Amazon CloudWatch pricing](https://aws.amazon.com//cloudwatch/pricing/#Vended_Logs)」を参照してください。
# Resolver のクエリログ記録の設定の管理
## の設定 (VPC Resolver クエリログ記録)
VPC Resolver クエリのログ記録は、次の 2 つの方法で設定できます。
+ **直接 VPC の関連付け** - VPCsに直接関連付けます。
+ **プロファイルの関連付け** - クエリログ記録設定を Route 53 プロファイルに関連付けます。これにより、そのプロファイルに関連付けられているすべての VPCs にログ記録が適用されます。詳細については、「[VPC Resolver クエリログ設定を Route 53 プロファイルに関連付ける](profile-associate-query-logging.md)」を参照してください。
VPC で発生する DNS クエリのログ記録は、Amazon Route 53 コンソールで以下のタスクを実行することで開始できます。
**Resolver のクエリログ記録を設定するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) で Route 53 コンソールを開きます。
1. Route 53 コンソールのメニューを展開します。コンソールの左上隅にある 3 本の水平バー (![\[Menu icon\]](http://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/images/menu-icon.png)) アイコンを選択します。
1. Resolver メニューから、[**Query logging (クエリログ記録)**] を選択します。
1. リージョンセレクターで、クエリログ記録設定を作成する AWS リージョンを選択します。これは、DNS クエリを記録する VPC が作成されているリージョンと同じリージョンでなければなりません。VPC が複数のリージョンに存在する場合は、リージョンごとにクエリログ記録の設定を少なくとも 1 つ作成する必要があります。
1. [**クエリログ記録の設定**] を選択します。
1. 次の値を指定します。
**クエリログ記録設定の名前**
クエリログ記録の設定に使用する名前を入力します。この名前は、コンソールのクエリログ記録の設定リストに表示されます。この設定では、後で検索する際に便利な名前を入力します。
**クエリログの保存先**
VPC Resolver がクエリログを送信する AWS リソースのタイプを選択します。各オプション (CloudWatch Logs ロググループ、S3 バケット、および Firehose 配信ストリーム) から選択する方法については、「[AWS VPC Resolver クエリログを送信できる リソース](resolver-query-logs-choosing-target-resource.md)」を参照してください。
リソースのタイプを選択したら、そのタイプの別のリソースを作成するか、現在の AWS アカウントによって作成された既存のリソースを選択できます。
ステップ 4 で選択した AWS リージョン (クエリログ記録の設定を作成するリージョン) で作成されたリソースのみを選択できます。新しいリソースを作成することを選択した場合、そのリソースは同じリージョンに作成されます。
**クエリをログに記録する VPC**
このクエリログ記録の設定では、選択した VPC で発生した DNS クエリがログに記録されます。VPC Resolver がクエリをログに記録する現在のリージョンの各 VPC のチェックボックスをオンにし、**選択**を選択します。
**代替**: VPCs を直接関連付ける代わりに、このクエリログ記録設定を Route 53 プロファイルに関連付けることができます。これにより、そのプロファイルに関連付けられたすべての VPCs にログ記録が適用されます。詳細については、「[VPC Resolver クエリログ設定を Route 53 プロファイルに関連付ける](profile-associate-query-logging.md)」を参照してください。
VPC ログの配信は、特定の送信先タイプに対して 1 回だけ有効にすることができます。ログを同じタイプの複数の送信先に配信することはできません。例えば、VPC ログを Amazon S3 にある 2 つの送信先に配信することはできません。
1. [**クエリログ記録の設定**] を選択します。
**注記**
クエリログ記録の設定が正常に作成されてから数分以内に、VPC 内のリソースによって作成された DNS クエリがログ内に表示されるようになります。
# VPC Resolver クエリログに表示される値
各ログファイルには、対応するエッジロケーションで Amazon Route 53 が DNS リゾルバーから受信した DNS クエリごとに、それぞれ 1 つのログエントリが記述されています。各ログエントリには、以下の値が記述されています。
**バージョン**
クエリログ形式のバージョン番号。現在のバージョンは `1.1` です。
バージョンの値には、**major\$1version.minor\$1version** の形式でメジャーおよびマイナーのバージョンが含まれています。例えば、`version` の値が `1.7` の場合には、`1 ` がメジャーバージョンを示し、`7` がマイナーバージョンを示します。
ログ構造に後方互換性のない変更が加えられた場合、Route 53 により、メジャーバージョンが増分されます。これには、既に存在する JSON フィールドの削除や、フィールドのコンテンツの表現方法 (日付形式など) の変更が含まれます。
変更によってログファイルに新しいフィールドが追加されると、Route 53 はマイナーバージョンを増分します。この処理は、VPC 内の既存の DNS クエリの一部またはすべてにおいて、新しい情報が利用可能になった時点で発生します。
**account\$1id**
VPC を作成した AWS アカウントの ID。
**リージョン**
VPC を作成した AWS リージョン。
**vpc\$1id**
クエリが発信された VPC の ID。
**query\$1timestamp**
クエリが送信された日時を、ISO 8601 形式の協定世界時 (UTC) で表します (例: `2017-03-16T19:20:177Z`) 。
ISO 8601 形式については、Wikipedia の記事「[ISO 8601](https://en.wikipedia.org/wiki/ISO_8601)」を参照してください。UTC については、Wikipedia の記事「[協定世界時](https://en.wikipedia.org/wiki/Coordinated_Universal_Time)」を参照してください。
**query\$1name**
クエリで指定されたドメイン名 (example.com) またはサブドメイン名 (www.example.com)。
**query\$1type**
リクエストで指定された DNS レコードタイプ、または `ANY` のいずれか。Route 53 でサポートされるタイプについては、「[サポートされる DNS レコードタイプ](ResourceRecordTypes.md)」を参照してください。
**query\$1class**
クエリのクラス。
**rcode**
VPC Resolver が DNS クエリに応答して返した DNS レスポンスコード。応答コードは、クエリが有効であったかどうかを示します。最も一般的な応答コードは、クエリが有効であったことを意味する `NOERROR` です。レスポンスが有効でない場合、Resolver はその理由を示す応答コードを返します。使用される応答コードのリストについては、IANA ウェブサイトで「[DNS RCODES](https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6)」を参照してください。
**answer\$1type**
VPC Resolver がクエリに応答して返す値の DNS レコードタイプ (A、MX、CNAME など）。Route 53 でサポートされるタイプについては、「[サポートされる DNS レコードタイプ](ResourceRecordTypes.md)」を参照してください。
**rdata**
VPC Resolver がクエリに応答して返した値。例えば、A レコードの場合は、IPv4 形式の IP アドレスになります。CNAME レコードの場合には、CNAME レコード内のドメイン名です。
**answer\$1class**
クエリに対する VPC Resolver レスポンスのクラス。
**srcaddr**
クエリの発信元であるホストの IP アドレス。
**srcport**
クエリの発信元であるインスタンスのポート。
**transport**
DNS クエリを送信するために使用されたプロトコル。
**srcids**
`instance`、`resolver_endpoint`、および DNS クエリの発信元、またはそのクエリが通過した `resolver_network_interface`。
**インスタンス**
クエリの発信元であるインスタンスの ID。
Route 53 VPC Resolver クエリログにインスタンス ID が表示されていて、アカウントに表示されない場合は、DNS クエリが AWS CloudShell、ユーザーが使用した AWS Lambda Amazon EKS、または Fargate コンソールのいずれかから発生した可能性があります。
**resolver\$1endpoint**
DNS クエリをオンプレミス DNS サーバーに渡すリゾルバーエンドポイントの ID。
異なるリゾルバーエンドポイントを使用して異なる転送ルール間で連鎖する CNAME レコードがある場合、クエリログにはチェーンで最後に使用されたリゾルバーエンドポイントの ID のみが表示されます。複数のエンドポイントを通じて完全な解決パスを追跡するには、さまざまなクエリログ記録設定間でログを関連付けることができます。
**firewall\$1rule\$1group\$1id**
クエリ内のドメイン名と一致した DNS Firewall ルールグループの ID。この情報は、アクションが alert または block に設定されているルールとの一致が、DNS Firewall により検出された場合にのみ挿入されます。
ファイアウォールルールグループの詳細については、「[DNS Firewall のルールグループとルール](resolver-dns-firewall-rule-groups.md)」を参照してください。
**firewall\$1rule\$1action**
クエリ内のドメイン名に一致したルールが指定しているアクション。この情報は、アクションが alert または block に設定されているルールとの一致が、DNS Firewall により検出された場合にのみ挿入されます。
**firewall\$1domain\$1list\$1id**
クエリ内のドメイン名に一致したルールによって使用されるドメインリスト。この情報は、アクションが alert または block に設定されているルールとの一致が、DNS Firewall により検出された場合にのみ挿入されます。
**additional\$1properties**
ログ配信イベントの追加情報。**is\$1delayed**: ログの配信に遅延がある場合。
# Route 53 VPC Resolver クエリログの例
Resolver のクエリログの例を次に示します。
```
{
"srcaddr": "4.5.64.102",
"vpc_id": "vpc-7example",
"answers": [
{
"Rdata": "203.0.113.9",
"Type": "PTR",
"Class": "IN"
}
],
"firewall_rule_group_id": "rslvr-frg-01234567890abcdef",
"firewall_rule_action": "BLOCK",
"query_name": "15.3.4.32.in-addr.arpa.",
"firewall_domain_list_id": "rslvr-fdl-01234567890abcdef",
"query_class": "IN",
"srcids": {
"instance": "i-0d15cd0d3example"
},
"rcode": "NOERROR",
"query_type": "PTR",
"transport": "UDP",
"version": "1.100000",
"account_id": "111122223333",
"srcport": "56067",
"query_timestamp": "2021-02-04T17:51:55Z",
"region": "us-east-1"
}
```
# Resolver クエリのログ記録設定を他の AWS アカウントと共有する
1 つの AWS アカウントを使用して作成したクエリログ記録設定を他の AWS アカウントと共有できます。設定を共有するには、Route 53 VPC Resolver コンソールを AWS Resource Access Manager と統合します。Resource Access Manager の詳細については、[Resource Access Manager ユーザーガイド](https://docs.aws.amazon.com/ram/latest/userguide/what-is.html)を参照してください。
次の点に注意してください。
**共有されたクエリログ記録の設定と VPC との関連付け**
別の AWS アカウントが 1 つ以上の設定をアカウントと共有している場合、VPC を作成した設定 VPCs に関連付けるのと同じ方法でVPCsを設定に関連付けることができます。
**設定の削除または共有解除**
他のアカウントと設定を共有し、その設定を削除するか、共有を停止し、1 つ以上の VPCs が設定に関連付けられている場合、Route 53 VPC Resolver はそれらの VPCs から送信される DNS クエリのログ記録を停止します。
**1 つの構成で関連付けることができるクエリログ記録の設定と VPC の最大数**
1 つのアカウントで作成した設定を他の単一または複数のアカウントと共有する場合、その設定に関連付けることができる VPC の最大数が各アカウントに適用されます。たとえば、組織内に 10,000 個のアカウントがある場合、中央アカウントにクエリログ記録設定を作成し、 AWS RAM を介して共有して、組織アカウントと共有できます。その後、組織のアカウントは設定を各自の VPC に関連付けます。アカウントにおける AWS リージョン ごとのクエリログ設定の VPC 関連付けは上限が 100 件となっているため、関連付けはその範囲内で行われます。ただし、すべての VPC が単一のアカウントにある場合は、必要に応じてアカウントのサービス制限を引き上げます。
現在の VPC リゾルバーのクォータについては、「」を参照してください[Route 53 VPC リゾルバーのクォータ](DNSLimitations.md#limits-api-entities-resolver)。
**アクセス許可**
ルールを別の AWS アカウントと共有するには、[PutResolverQueryLogConfigPolicy](https://docs.aws.amazon.com/Route53/latest/APIReference/API_route53resolver_PutResolverQueryLogConfigPolicy.html) アクションを使用するアクセス許可が必要です。
**ルールが共有されている AWS アカウントの制限**
ルールを共有するアカウントは、ルールを変更または削除できません。
**タグ付け**
ルールを作成したアカウントのみが、ルールのタグを追加、削除、または表示できます。
ルールの現在の共有ステータス (ルールを共有したアカウントやルールの共有先であるアカウントなど) を確認し、別のアカウントとルールを共有するには、以下の手順を実行します。
**共有ステータスを表示し、クエリログ記録設定を別の AWS アカウントと共有するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) で Route 53 コンソールを開きます。
1. ナビゲーションペイン内で [**Query Logging (クエリログ記録)**] を選択します。
1. ナビゲーションバーで、転送ルールを作成したリージョンを選択します。
[**Sharing status (共有ステータス)**] 列に、現在のアカウントで作成されたルールまたは現在のアカウントと共有されているルールの現在の共有ステータスが表示されます。
+ **Not shared**: 現在の AWS アカウントがルールを作成し、そのルールは他のアカウントと共有されません。
+ **Shared by me (自分が共有)**: 現在のアカウントがルールを作成し、1 つ以上の他のアカウントと共有しています。
+ **Shared with me (自分と共有)**: 別のアカウントがルールを作成し、現在のアカウントと共有しています。
1. 共有情報を表示するルールまたは別のアカウントと共有するルールの名前を選択します。
[**Rule: *rule name* (ルール: rule name)**] ページで、[**Owner (所有者)**] の値として、ルールを作成したアカウントの ID が表示されます。これは現在のアカウントです。ただし、[**Sharing status (共有ステータス)**] の値が [**Shared with me (自分と共有)**] である場合を除きます。その場合の [**Owner (所有者)**] は、ルールを作成して現在のアカウントと共有しているアカウントです。
共有ステータスも表示されます。
1. **共有設定**を選択して AWS RAM コンソールを開きます。
1. 「*AWS RAM ユーザーガイド*」の「[Creating a resource share in AWS RAM](https://docs.aws.amazon.com/ram/latest/userguide/working-with-sharing-create.html)」のステップに従います。
**注記**
共有設定を更新することはできません。以下のいずれかの設定を変更する場合は、新しい設定を使用してルールを共有し直し、古い共有設定を削除する必要があります。
# ドメイン登録のモニタリング
Amazon Route 53 のダッシュボードでは、以下のようなドメイン登録の状態に関する詳細情報を提供します。
+ 新しいドメイン登録の状態
+ Route 53 へのドメイン移管の状態
+ 有効期限に近づいているドメインのリスト
Route 53 コンソールのダッシュボードを定期的に確認することをお勧めします。特に、新しいドメインを登録したり、Route 53 にドメインを移管したりした後には、対処を要する問題がないことを確認してください。
また、ドメインの連絡先情報が最新であることを確認することをお勧めします。ドメインの有効期限が近づくと、ドメインの有効期限日と更新方法に関する情報がドメインの登録者にメールで送信されます。
# Amazon Route 53 のヘルスチェックと Amazon CloudWatch を使用したリソースのモニタリング
Amazon Route 53 のヘルスチェックを作成してリソースをモニタリングできます。ヘルスチェックでは、CloudWatch を使用して生データを収集し、ほぼリアルタイムの読み取り可能なメトリクスに加工します。これらの統計情報は、2 週間記録されるため、履歴情報にアクセスしてリソースの動作をより的確に把握できます。デフォルトでは、Route 53 のヘルスチェックからのメトリクスデータは、 1 分間隔で自動的に CloudWatch に送信されます。
Route 53 ヘルスチェックの詳細については、「[CloudWatch を使用したヘルスチェックのモニタリング](monitoring-health-checks.md)」を参照してください。CloudWatch の詳細については、*Amazon CloudWatch ユーザーガイド*の「[Amazon CloudWatch とは](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/WhatIsCloudWatch.html)」を参照してください。
## Route 53 ヘルスチェックのメトリクスとディメンション
ヘルスチェックを作成すると、Amazon Route 53 は、指定したリソースに関するメトリクスとディメンションを毎分 1 回、 CloudWatch に対し送信し始めます。ヘルスチェックの状態は、Route 53 コンソールにより確認できます。次の手順を使用して、CloudWatch コンソールでメトリクスを表示したり、 AWS Command Line Interface () を使用してメトリクスを表示したりすることもできますAWS CLI。
**CloudWatch コンソールを使用してメトリクスを表示するには**
1. CloudWatch コンソール ([https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)) を開きます。
1. ナビゲーションペインで [**Metrics (メトリクス)**] を選択してください。
1. [**All Metrics**] タブで、[**Route 53**] を選択します。
1. [**Health Check Metrics**] を選択します。
**を使用してメトリクスを表示するには AWS CLI**
+ コマンドプロンプトで、次のコマンドを使用します。
```
1. aws cloudwatch list-metrics --namespace "AWS/Route53"
```
**Topics**
+ [Route 53 のヘルスチェックに関する CloudWatch メトリクス](#cloudwatch-metrics)
+ [Route 53 ヘルスチェックでのメトリクスのディメンション](#cloudwatch-dimensions-route-53-metrics)
### Route 53 のヘルスチェックに関する CloudWatch メトリクス
`AWS/Route53` 名前空間には、Route 53 のヘルスチェックに関する以下のメトリクスが含まれています。
**ChildHealthCheckHealthyCount**
計算されたヘルスチェックについて、正常なヘルスチェックの数。
有効な統計: Average (推奨)、Minimum、Maximum
単位: カウント
**ConnectionTime**
Route 53 のヘルスチェッカーがエンドポイントとの間で TCP 接続を確立するのにかかった平均時間 (ミリ秒)。ヘルスチェックの `ConnectionTime` は、すべてのリージョンまたは選択した地理的リージョンについて確認できます。
有効な統計: Average (推奨)、Minimum、Maximum
単位: ミリ秒
**HealthCheckPercentageHealthy**
選択されたエンドポイントの中で、正常である結果を返した Route 53 のヘルスチェッカーの割合。
有効な統計: Average、Minimum、Maximum
単位: パーセント
**HealthCheckStatus**
CloudWatch がチェックしているヘルスチェックエンドポイントのステータス。**1** の場合は正常であることを、**0** の場合は異常であることを示します。
有効な統計: 最小、平均、最大
単位: なし
**SSLHandshakeTime**
Route 53 のヘルスチェッカーが SSL ハンドシェイクを完了するまでにかかった平均時間 (ミリ秒)。ヘルスチェックの `SSLHandshakeTime` は、すべてのリージョンまたは選択した地理的リージョンについて確認できます。
有効な統計: Average (推奨)、Minimum、Maximum
単位: ミリ秒
**TimeToFirstByte**
Route 53 のヘルスチェッカーが、HTTP または HTTPS リクエストへの応答の先頭バイトを受け取るまでにかかった平均時間 (ミリ秒)。ヘルスチェックの `TimeToFirstByte` は、すべてのリージョンまたは選択した地理的リージョンについて確認できます。
有効な統計: Average (推奨)、Minimum、Maximum
単位: ミリ秒
### Route 53 ヘルスチェックでのメトリクスのディメンション
ヘルスチェックのための Route 53 メトリクスは、`AWS/Route53` 名前空間を使用し、`HealthCheckId` のためのメトリクスを提供します。メトリクスを取得する場合は、`HealthCheckId` ディメンションを入力する必要があります。
さらに、`ConnectionTime`、`SSLHandshakeTime`、および `TimeToFirstByte` に対して、オプションとして `Region` も指定できます。`Region` を省略した場合、CloudWatch は、すべてのリージョンからのメトリクスを返します。`Region` を含めた場合は、指定したリージョンのみのメトリクスが CloudWatch から返されます。
詳細については、「[CloudWatch を使用したヘルスチェックのモニタリング](monitoring-health-checks.md)」を参照してください
# Amazon CloudWatch を使用したホストゾーンのモニタリング
Amazon CloudWatch を使用して生データを収集し、ほぼリアルタイムで読み取り可能なメトリクスに加工することで、パブリックホストゾーンをモニタリングできます。メトリクスは、そのメトリクスが基づいている DNS クエリが Route 53 で受信された直後から利用できます。Route 53 ホストゾーンにおける CloudWatch メトリクスデータの詳細度は 1 分です。
詳細については、次のドキュメントを参照してください。
+ Amazon CloudWatch コンソールでメトリクスを表示する方法、および AWS Command Line Interface (AWS CLI) を使用してメトリクスを取得する方法の概要と詳細については、[パブリックホストゾーンの DNS クエリメトリクスの表示](hosted-zone-public-viewing-query-metrics.md) を参照してください。
+ メトリクスの保持期間の詳細については、*Amazon CloudWatch API リファレンス*の「[GetMetricStatistics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricStatistics.html)」を参照してください。
+ CloudWatch の詳細については、*Amazon CloudWatch ユーザーガイド*の「[Amazon CloudWatch とは](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/WhatIsCloudWatch.html)」を参照してください。
+ CloudWatch メトリクスの詳細については、*Amazon CloudWatch ユーザーガイド*の「[Amazon CloudWatch メトリクスの使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)」を参照してください。
**Topics**
+ [Route 53 パブリックホストゾーンの CloudWatch メトリクス](#cloudwatch-metrics-route-53-hosted-zones)
+ [Route 53 パブリックホストゾーンメトリクスの CloudWatch ディメンション](#cloudwatch-dimensions-route-53-hosted-zones)
## Route 53 パブリックホストゾーンの CloudWatch メトリクス
`AWS/Route53` 名前空間には、Route 53 ホストゾーンについての次のメトリクスが含まれます。
**DNSQueries**
ホストゾーンについて、指定された期間に Route 53 が応答している DNS クエリの数。
有効な統計: Sum、SampleCount
単位: カウント
リージョン: Route 53 はグローバルサービスです。ホストゾーンメトリクスを取得するには、リージョンに米国東部 (バージニア北部) を指定する必要があります。
**DNSSECInternalFailure**
ホストゾーン内に INTERNAL\$1FAILURE 状態のオブジェクトが存在する場合は、値が 1 になります。それ以外の場合は値は 0 です。
有効な統計: Sum
単位: カウント
ボリューム: 各ホストゾーンで 4 時間ごとに 1
リージョン: Route 53 はグローバルサービスです。ホストゾーンメトリクスを取得するには、リージョンに米国東部 (バージニア北部) を指定する必要があります。
**DNSSECKeySigningKeysNeedingAction**
(KMS の障害により) ACTION\$1NEED の状態になっているキー署名キー (KSK) の数。
有効な統計: Sum、SampleCount
単位: カウント
ボリューム: 各ホストゾーンで 4 時間ごとに 1
リージョン: Route 53 はグローバルサービスです。ホストゾーンメトリクスを取得するには、リージョンに米国東部 (バージニア北部) を指定する必要があります。
**DNSSECKeySigningKeyMaxNeedingActionAge**
キー署名キー (KSK) が ACTION\$1NEED 状態に設定されてからの経過時間。
有効な統計: 最大
単位: 秒
ボリューム: 各ホストゾーンで 4 時間ごとに 1
リージョン: Route 53 はグローバルサービスです。ホストゾーンメトリクスを取得するには、リージョンに米国東部 (バージニア北部) を指定する必要があります。
**DNSSECKeySigningKeyAge**
キー署名キー (KSK) が作成されてからの経過時間 (有効になってからではありません)。
有効な統計: 最大
単位: 秒
ボリューム: 各ホストゾーンで 4 時間ごとに 1
リージョン: Route 53 はグローバルサービスです。ホストゾーンメトリクスを取得するには、リージョンに米国東部 (バージニア北部) を指定する必要があります。
## Route 53 パブリックホストゾーンメトリクスの CloudWatch ディメンション
ホストゾーンに関する Route 53 メトリクスは `AWS/Route53` 名前空間を使用し、`HostedZoneId` に関するメトリクスを提供します。DNS クエリの数を取得するには、`HostedZoneId` ディメンションでホストゾーンの ID を指定する必要があります。
# Amazon CloudWatch による Route 53 VPC Resolver エンドポイントのモニタリング
Amazon CloudWatch を使用して、Route 53 VPC Resolver エンドポイントによって転送される DNS クエリの数をモニタリングできます。Amazon CloudWatch では、生データを収集し、ほぼリアルタイムの読み取り可能なメトリクスに加工します。これらの統計情報は、2 週間記録されるため、履歴情報にアクセスしてリソースの動作をより的確に把握できます。デフォルトでは、Resolver エンドポイントのメトリクスデータは、5 分間隔で CloudWatch に自動的に送信されます。5 分間隔は、メトリクスデータを送信できる最小間隔でもあります。
VPC Resolver の詳細については、「」を参照してください[Route 53 VPC Resolver とは](resolver.md)。CloudWatch の詳細については、「*Amazon CloudWatch ユーザーガイド*」の「[Amazon CloudWatch とは](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/WhatIsCloudWatch.html)」を参照してください。
## Route 53 VPC Resolver のメトリクスとディメンション
DNS クエリをネットワークに転送するように VPC リゾルバーを設定すると、VPC リゾルバーは 5 分に 1 回、転送されるクエリの数に関する[メトリクス](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/monitoring-resolver-with-cloudwatch.html#cloudwatch-metrics-resolver)と[ディメンション](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/monitoring-resolver-with-cloudwatch.html#cloudwatch-dimensions-resolver)を CloudWatch に送信し始めます。次の手順を使用して、CloudWatch コンソールでメトリクスを表示するか、 AWS Command Line Interface () を使用してメトリクスを表示できますAWS CLI。
**CloudWatch コンソールを使用して VPC Resolver メトリクスを表示するには**
1. CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。
1. ナビゲーションバーで、エンドポイントを作成したリージョンを選択します。
1. ナビゲーションペインで [**Metrics (メトリクス)**] を選択します。
1. [**すべてのメトリクス**] タブで、[**Route 53 Resolver**] を選択します。
1. 指定したエンドポイントに対するクエリの数を表示するには、[**By Endpoint (エンドポイント別)**] を選択します。次に、クエリ数を表示するエンドポイントを選択します。
**すべてのエンドポイントで** を選択すると、現在の AWS アカウントによって作成されたすべてのインバウンドエンドポイントまたはすべてのアウトバウンドエンドポイントのクエリ数が表示されます。次に、[**InboundQueryVolume**] または [**OutboundQueryVolume**] を選択すると、必要な数が表示されます。
**を使用してメトリクスを表示するには AWS CLI**
+ コマンドプロンプトで、次のコマンドを使用します。
```
1. aws cloudwatch list-metrics --namespace "AWS/Route53Resolver"
```
**Topics**
+ [Route 53 VPC リゾルバーの CloudWatch 基本メトリクス](#cloudwatch-metrics-resolver)
+ [Route 53 VPC リゾルバーの CloudWatch 詳細メトリクス Route 53](#cloudwatch-detailed-metrics-resolver)
+ [Route 53 VPC Resolver メトリクスのディメンション](#cloudwatch-dimensions-resolver)
### Route 53 VPC リゾルバーの CloudWatch 基本メトリクス
`AWS/Route53Resolver` 名前空間には、Route 53 VPC Resolver エンドポイントと IP アドレスの基本的なメトリクスが無料で含まれています。
**Topics**
+ [Route 53 VPC Resolver エンドポイントのメトリクス](#cloudwatch-metrics-resolver-endpoint)
+ [Route 53 VPC Resolver の IP アドレスのメトリクス](#cloudwatch-metrics-resolver-ip-address)
#### Route 53 VPC Resolver エンドポイントのメトリクス
`AWS/Route53Resolver` 名前空間には、Route 53 VPC Resolver エンドポイントの次のメトリクスが含まれます。
**EndpointHealthyENICount**
`OPERATIONAL` ステータスの Elastic Network Interface の数です。(`EndpointId` が指定した) エンドポイントの Amazon VPC ネットワークインターフェイスが正しく設定されており、ネットワークと Resolver の間での、インバウンドまたはアウトバウンドの DNS クエリを通過させることができます。
有効な統計: Minimum、Maximum、Average
単位: カウント
**EndpointUnhealthyENICount**
`AUTO_RECOVERING` ステータスの Elastic Network Interface の数です。
Resolver は、(`EndpointId` が指定した) エンドポイントに関連付けられている 1 つ以上の Amazon VPC ネットワークインターフェイスを復旧しようとしています。復旧プロセス中は、エンドポイントは容量が制限された状態で機能し、復旧が完了するまで DNS クエリを処理できません。
有効な統計: Minimum、Maximum、Average
単位: カウント
**InboundQueryVolume**
インバウンドエンドポイントを対象とし、`EndpointId` で指定されたエンドポイントを介してネットワークから VPC に転送された DNS クエリの数。
有効な統計: Sum
単位: カウント
**OutboundQueryVolume**
アウトバウンドエンドポイントを対象とし、`EndpointId` で指定されたエンドポイントを介して VPC からネットワークに転送された DNS クエリの数。
有効な統計: Sum
単位: カウント
**OutboundQueryAggregateVolume**
アウトバウンドエンドポイントの場合、Amazon VPC からネットワークに転送された DNS クエリの総数 (以下を含む)。
+ `EndpointId` で指定されたエンドポイントを介して VPC からネットワークに転送された DNS クエリの数。
+ 現在のアカウントが他のアカウントと Resolver ルールを共有する場合、`EndpointId` によって指定されたエンドポイントを介してネットワークに転送される他のアカウントによって作成された VPC からのクエリ。
有効な統計: Sum
単位: カウント
**ResolverEndpointCapacityStatus**
Resolver エンドポイントの容量ステータス。このメトリクスは現在の容量使用率の状態を示します。これは、0 = OK (通常の運用容量）、1 = Warning (少なくとも 1 つの Elastic Network Interface が容量使用率 50% を超過）、2 = Critical (少なくとも 1 つの Elastic Network Interface が容量使用率 75% を超過) で示されます。
容量ステータスは、クエリボリューム、クエリレイテンシー、DNS プロトコル、DNS パケットサイズ、接続追跡ステータスなど、複数の要因によって決まります。
有効な統計: Maximum
単位: なし
**VPC リゾルバーエンドポイント容量管理のベストプラクティス**
容量の問題に対処するには、通常、Resolver エンドポイントの Elastic Network Interface の数を増やすことをお勧めします。ただし、特定のエンドポイントタイプには重要な考慮事項があります。
**インバウンドエンドポイント**の場合、トラフィックの負荷分散はお客様によって異なります。したがって、容量の警告や重要なアラートは、Elastic Network Interface のサブセットが不釣り合いに使用されている「ホットスポット」を示している可能性があります。
+ 潜在的な負荷分散の問題を特定するには、各 Elastic Network Interface の [InboundQueryVolume](#cloudwatch-metrics-resolver-ip-address) メトリクスを個別に調べます。
**アウトバウンドエンドポイント**の場合、トラフィックは Elastic Network Interface 間で自動的に分散されます。容量の問題は、ターゲットネームサーバーの問題、またはタイムアウトの高レイテンシークエリが Resolver ネットワークインターフェイスを圧迫していることが原因である可能性があります。
+ このような場合は、単に Elastic Network Interface を増やすだけでは効果がない可能性があるため、ターゲットネームサーバーを修正することをお勧めします。
#### Route 53 VPC Resolver の IP アドレスのメトリクス
`AWS/Route53Resolver` 名前空間には、Resolver のインバウンドエンドポイント、またはアウトバウンドエンドポイントに関連付けられた IP アドレスごとに、次のメトリクスが含まれています。(エンドポイントを指定すると、VPC Resolver は Amazon VPC [Elastic Network Interface](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html) を作成します）。
**InboundQueryVolume**
インバウンドエンドポイントの IP アドレスごとに、ネットワークから、指定された IP アドレスに転送された DNS クエリの数。各 IP アドレスは、IP アドレス ID で識別されます。この値は Route 53 コンソールを使用して取得できます。該当するエンドポイントのページの [IP アドレス] セクションで、[**IP アドレス ID**] 列を参照してください。また、[ListResolverEndpointIpAddresses](https://docs.aws.amazon.com/Route53/latest/APIReference/API_route53resolver_ListResolverEndpointIpAddresses.html) を使用してプログラムで値を取得することもできます。
有効な統計: Sum
単位: カウント
**OutboundQueryAggregateVolume**
アウトバウンドエンドポイントの IP アドレスごとに、Amazon VPC からネットワークに転送された DNS クエリの総数 (以下を含む)。
+ 指定された IP アドレスを使用して VPC からネットワークに転送された DNS クエリの数。
+ 現在のアカウントが他のアカウントと Resolver ルールを共有する場合、指定された IP アドレスを介してネットワークに転送される他のアカウントによって作成された VPC からのクエリ。
各 IP アドレスは、IP アドレス ID で識別されます。この値は Route 53 コンソールを使用して取得できます。該当するエンドポイントのページの [IP アドレス] セクションで、[**IP アドレス ID**] 列を参照してください。また、[ListResolverEndpointIpAddresses](https://docs.aws.amazon.com/Route53/latest/APIReference/API_route53resolver_ListResolverEndpointIpAddresses.html) を使用してプログラムで値を取得することもできます。
有効な統計: Sum
単位: カウント
### Route 53 VPC リゾルバーの CloudWatch 詳細メトリクス Route 53
Route 53 VPC Resolver は、エンドポイントのオプトイン機能として RNI Enhanced および Target Name Server メトリクスを提供します。これらのメトリクスは 1 分間隔で CloudWatch に送信されます。
**注記**
詳細なメトリクスはデフォルトでは有効になっていませんが、エンドポイントレベルで有効にすることができます。これらのメトリクスは、RniEnhancedMetricsEnabled フラグと TargetNameServerMetricsEnabled フラグを使用してエンドポイントを作成または更新するときにプログラムで有効にできます。詳細については、「[CreateResolverEndpoint](https://docs.aws.amazon.com/Route53/latest/APIReference/API_route53resolver_CreateResolverEndpoint.html)」および「[UpdateResolverEndpoint](https://docs.aws.amazon.com/Route53/latest/APIReference/API_route53resolver_UpdateResolverEndpoint.html)」を参照してください。
Route 53 Resolver エンドポイントの詳細メトリクスの使用には、標準の CloudWatch 料金と料金が適用されます。詳細については、「[Amazon CloudWatch 料金表](https://aws.amazon.com/cloudwatch/pricing/)」をご覧ください。
**Topics**
+ [RNI 拡張メトリクス](#cloudwatch-detailed-metrics-resolver-endpoints-ip-addresses)
+ [ターゲットネームサーバーのメトリクス](#cloudwatch-detailed-metrics-resolver-endpoints-target-nameservers)
#### RNI 拡張メトリクス
Route 53 Resolver は、RNI 拡張メトリクスを Amazon CloudWatch に公開して、Resolver エンドポイントと Resolver IP アドレスのパフォーマンスとヘルスをモニタリングします。`AWS/Route53Resolver` 名前空間には、、 `EndpointId``RniId`ディメンションの Route 53 Resolver インバウンドエンドポイントとアウトバウンドエンドポイントの次の RNI 拡張メトリクスが含まれます。
**P90ResponseTime**
Resolver エンドポイント (`RniId`) に関連付けられた Resolver IP () が受信した DNS クエリの 90 パーセンタイルレスポンスレイテンシー`EndpointId`
有効な統計: Maximum
単位: マイクロ秒
**ServFailQueries**
Resolver エンドポイントに関連付けられた Resolver IP (`RniId`) に送信された DNS クエリの SERVFAIL レスポンスの数 (`EndpointId`)
有効な統計: Sum
単位: カウント
**NxDomainQueries**
Resolver エンドポイントに関連付けられた Resolver IP (`RniId`) に送信された DNS クエリの NXDOMAIN レスポンスの数 (`EndpointId`)
有効な統計: Sum
単位: カウント
**RefusedQueries**
Resolver エンドポイントに関連付けられた Resolver IP (`RniId`) に送信された DNS クエリの REFUSED レスポンスの数 (`EndpointId`)
有効な統計: Sum
単位: カウント
**FormErrorQueries**
Resolver エンドポイントに関連付けられた Resolver IP (`RniId`) に送信された DNS クエリの FORMERR レスポンスの数 (`EndpointId`)
有効な統計: Sum
単位: カウント
**TimeoutQueries**
Resolver エンドポイントに関連付けられた Resolver IP (`RniId`) に送信された DNS クエリのタイムアウト数 (`EndpointId`)
有効な統計: Sum
単位: カウント
#### ターゲットネームサーバーのメトリクス
Route 53 Resolver は、Resolver エンドポイントに関連付けられたターゲットネームサーバーのパフォーマンスと可用性をモニタリングするために、ターゲットネームサーバーメトリクスを Amazon CloudWatch に発行します。`AWS/Route53Resolver` 名前空間には、、 `EndpointID``TargetNameServerIP`ディメンションの Route 53 Resolver アウトバウンドエンドポイントに関する以下の詳細なメトリクスが含まれます。
**P90ResponseTime**
Resolver エンドポイントを介して送信される DNS クエリのターゲットネームサーバー IP (`TargetNameServerIP`) の 90 パーセンタイルレスポンスレイテンシー (`EndpointID`)
有効な統計: Maximum
単位: マイクロ秒
**RequestQueries**
Resolver エンドポイント (`TargetNameServerIP`) を介してターゲットネームサーバー IP () に送信された DNS クエリの数`EndpointID`。
有効な統計: Sum
単位: カウント
**TimeoutQueries**
ターゲットネームサーバー IP (`EndpointID`) でタイムアウトしたリゾルバーエンドポイント () を介して送信された DNS クエリの数`TargetNameServerIP`。
有効な統計: Sum
単位: カウント
**注記**
場合によっては、VPC Resolver メトリクス (ResolverEndpointCapacityStatus) と RNI 拡張メトリクスにギャップが見られることがあります。これらのギャップは、ネットワークインターフェイスが連続してスケジュールされたメンテナンスまたは更新を受けるときに発生する可能性があります。ネットワークインターフェイスをサービスに返した後、サービスが運用データを収集し、これらのメトリクスを発行するまでに少なくとも 1 分かかります。これらのギャップは、VPC Resolver エンドポイントで停止が発生していることを示すものではありません。これらのメトリクスに対して CloudWatch アラームを設定する場合は、次のことをお勧めします。
アラームを「欠落データを無視として扱う」に設定する、または
アラームしきい値の評価期間を 5 分以上に設定します。
これらの設定は、通常のメンテナンスアクティビティ中の誤アラームを減らすのに役立ちます。
### Route 53 VPC Resolver メトリクスのディメンション
インバウンドエンドポイントとアウトバウンドエンドポイントの Route 53 VPC Resolver メトリクスは、 `AWS/Route53Resolver`名前空間を使用し、次のディメンションのメトリクスを提供します。
+ `EndpointId`: `EndpointId`ディメンションの値を指定すると、CloudWatch は指定されたエンドポイントの DNS クエリの数を返します。を指定しない場合`EndpointId`、CloudWatch は現在の AWS アカウントによって作成されたすべてのエンドポイントの DNS クエリの数を返します。
+ `RniId` ディメンションは、 `OutboundQueryAggregateVolume` および `InboundQueryVolume`メトリクスでサポートされています。
+ `EndpointId`、`RniId`ディメンションは`P90ResponseTime`、リゾルバーエンドポイントに関連付けられたリゾルバー IP アドレス`TimeoutQueries`の `ServFailQueries` `NxDomainQueries``FormErrorQueries`、、`RefusedQueries`、、および でサポートされています。
+ `EndpointID`、 `TargetNameServerIP`ディメンションは`P90ResponseTime`、リゾルバーエンドポイントに関連付けられた`TimeoutQueries`ターゲットネームサーバーの 、`RequestQueries`、および でサポートされています。
# Amazon CloudWatch を使用した Resolver DNS Firewall ルールグループのモニタリング
Amazon CloudWatch を使用して、Resolver DNS Firewall ルールグループによってフィルタリングされた DNS クエリの数をモニタリングできます。Amazon CloudWatch では、生データを収集し、ほぼリアルタイムの読み取り可能なメトリクスに加工します。これらの統計情報は、2 週間記録されるため、履歴情報にアクセスしてリソースの動作をより的確に把握できます。デフォルトでは、DNS Firewall ルールグループについてのメトリクスデータは、5 分間隔で CloudWatch に対し自動的に送信されます。
DNS Firewallの詳細については、「[DNS ファイアウォールを使用してアウトバウンド DNS トラフィックをフィルタリングする](resolver-dns-firewall.md)」 を参照してください。CloudWatch の詳細については、*Amazon CloudWatch ユーザーガイド*の「[Amazon CloudWatch とは](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/WhatIsCloudWatch.html)」を参照してください。
## Resolver DNS Firewall のメトリクスとディメンション
Resolver DNS Firewall ルールグループを VPC に関連付けて DNS クエリをフィルタリングすると、DNS Firewall はフィルタリングするクエリに関するメトリクスとディメンションを 5 分ごとに CloudWatch に送信し始めます。DNS Firewall のメトリクスとディメンションの詳細については、「[Resolver DNS Firewall の CloudWatch メトリクス](#cloudwatch-metrics-resolver-dns-firewall)」を参照してください。
次の手順を使用して、CloudWatch コンソールでメトリクスを表示するか、 AWS Command Line Interface () を使用してメトリクスを表示できますAWS CLI。
**CloudWatch コンソールを使用して DNS Firewall のメトリクスを表示するには**
1. CloudWatch コンソール ([https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)) を開きます。
1. ナビゲーションバーで、表示するリージョンを選択します。
1. ナビゲーションペインで [**Metrics (メトリクス)**] を選択してください。
1. **すべてのメトリクス**タブで、**Route 53 VPC Resolver** を選択します。
1. 目的のメトリクスを選択します。
**を使用してメトリクスを表示するには AWS CLI**
+ コマンドプロンプトで、次のコマンドを使用します。
```
1. aws cloudwatch list-metrics --namespace "AWS/Route53Resolver"
```
**Topics**
+ [Resolver DNS Firewall の CloudWatch メトリクス](#cloudwatch-metrics-resolver-dns-firewall)
### Resolver DNS Firewall の CloudWatch メトリクス
`AWS/Route53Resolver` 名前空間には、Resolver DNS Firewall ルールグループのメトリクスが含まれます。
**Topics**
+ [Resolver DNS Firewall ルールグループのメトリクス](#cloudwatch-metrics-resolver-dns-firewall-rule-group)
+ [VPC に関するメトリクス](#cloudwatch-metrics-resolver-vpc)
+ [ファイアウォールルールグループと VPC の関連付けに関するメトリクス](#cloudwatch-metrics-resolver-firewall-vpc)
+ [ファイアウォールルールグループ内のドメインリストに関するメトリクス](#cloudwatch-metrics-domain-list-firewall)
#### Resolver DNS Firewall ルールグループのメトリクス
**FirewallRuleGroupQueryVolume**
ファイアウォールルールグループ (`FirewallRuleGroupId` で指定) と一致する DNS Firewall のクエリ数。
ディメンション: `FirewallRuleGroupId`
有効な統計: Sum
単位: カウント
#### VPC に関するメトリクス
**VpcFirewallQueryVolume**
VPC (`VpcId` で指定) からの DNS Firewall のクエリ数
ディメンション: `VpcId`
有効な統計: Sum
単位: カウント
#### ファイアウォールルールグループと VPC の関連付けに関するメトリクス
**FirewallRuleGroupVpcQueryVolume**
ファイアウォールルールグループ (`VpcId` で指定) と一致する、(`FirewallRuleGroupId` で指定された) VPC からの DNS Firewall のクエリ数
ディメンション: `FirewallRuleGroupId, VpcId`
有効な統計: Sum
単位: カウント
#### ファイアウォールルールグループ内のドメインリストに関するメトリクス
**FirewallRuleQueryVolume**
ファイアウォールルールグループ (`FirewallDomainListId` で指定) 内の、ファイアウォールドメインリスト (`FirewallRuleGroupId` で指定) と一致する DNS Firewall のクエリ数。
ディメンション: `FirewallRuleGroupId, FirewallDomainListId`
有効な統計: Sum
単位: カウント
# を使用したリゾルバー DNS ファイアウォールイベントの管理 Amazon EventBridge
Amazon EventBridge は、イベントを使用してアプリケーションコンポーネントを接続するサーバーレスサービスであり、スケーラブルなイベント駆動型アプリケーションを簡単に構築できます。イベント駆動型アーキテクチャとは、イベントの発信と応答によって連携する、疎結合のソフトウェアシステムを構築するスタイルです。イベントとは、リソースまたは環境で発生した変更を指します。
多くの AWS サービスと同様に、DNS Firewall はイベントを生成してデフォルトのイベントバスに送信します EventBridge 。(デフォルトのイベントバスは、すべての AWS アカウントで自動的にプロビジョニングされます)。イベントバスは、イベントを受信して、ゼロ個以上の送信先 (*ターゲット*) に配信するルーターです。イベントが受信されると、ユーザーがイベントバスに対して指定したルールによって評価されます。各ルールは、イベントがルールの*イベントパターン*に一致するかどうかをチェックします。一致する場合、イベントバスはそのイベントを指定されたターゲットに送信します。
![\[AWS サービスは EventBridge 、デフォルトのイベントバスにイベントを送信します。イベントがルールのイベントパターンと一致する場合、 はそのルールに指定されたターゲットにイベント EventBridge を送信します。\]](http://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/images/eventbridge-integration-how-it-works.png)
**Topics**
+ [リゾルバー DNS ファイアウォールイベント](#supported-events)
+ [EventBridge ルールを使用したリゾルバー DNS ファイアウォールイベントの送信](#eventbridge-using-events-rules)
+ [Amazon EventBridge アクセス許可](#eventbridge-permissions)
+ [その他の EventBridge リソース](#eventbridge-additonal-resources)
+ [Resolver DNS Firewall イベントの詳細リファレンス](events-detail-reference.md)
## リゾルバー DNS ファイアウォールイベント
VPC Resolver は、DNS Firewall イベントをデフォルトの EventBridge イベントバスに自動的に送信します。イベントバスにルールを作成できます。各ルールには、イベントパターンと 1 つ以上のターゲットが含まれます。ルールのイベントパターンに一致するイベントは、[ベストエフォートベース](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-service-event.html#eb-service-event-delivery-level)で指定されたターゲットに配信されます。イベントは順序どおりに配信される可能性があります。
次のイベントは DNS ファイアウォールによって生成されます。詳細については、「*Amazon EventBridge ユーザーガイド*」の「[EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-events.html)」を参照してください。
| イベントの詳細のタイプ | 説明 |
| --- | --- |
| [DNS ファイアウォールブロック](events-detail-reference.md#dns-firewall-alert) | ドメインに対して実行されるブロックアクション。 |
| [DNS ファイアウォールアラート](events-detail-reference.md#dns-firewall-block) | ドメインに対して実行されるアラートアクション。 |
## EventBridge ルールを使用したリゾルバー DNS ファイアウォールイベントの送信
EventBridge デフォルトのイベントバスが DNS Firewall イベントをターゲットに送信するには、目的の DNS Firewall イベントのデータと一致するイベントパターンを含むルールを作成する必要があります。
ルールの作成ステップは以下のとおりです。
1. 以下を指定するルールのイベントパターンを作成します。
+ VPC Resolver は、ルールによって評価されるイベントのソースです。
+ (オプション): 照合対象となるその他のイベントデータ。
詳細については、[Resolver DNS Firewall イベントのイベントパターンの作成](#eventbridge-using-events-rules-patterns)を参照してください。
1. (オプション): がルールのターゲットに情報を EventBridge 渡す前に、イベントからのデータをカスタマイズする*入力トランスフォーマー*を作成します。
詳細については、「*EventBridge ユーザーガイド*」の「[入力変換](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-transform-target-input.html)」を参照してください。
1. イベントパターンに一致するイベント EventBridge を配信するターゲット (複数可) を指定します。
ターゲットは、他の AWS サービス、software-as-a-service (SaaS) アプリケーション、API 送信先、またはその他のカスタムエンドポイントです。詳細については、*EventBridge ユーザーガイド*の[ターゲット](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-targets.html)を参照してください。
イベントバスルールの詳細な作成方法については、「*EventBridge ユーザーガイド*」の「[イベントに反応するルールの作成](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-create-rule.html)」を参照してください。
### Resolver DNS Firewall イベントのイベントパターンの作成
DNS Firewall がデフォルトのイベントバスにイベントを配信すると、 は各ルールに定義されたイベントパターン EventBridge を使用して、イベントをルールのターゲット (複数可) に配信するかどうかを決定します。イベントパターンは、目的の DNS ファイアウォールイベントのデータに一致します。各イベントパターンは JSON 形式のオブジェクトで、以下が含まれています。
+ イベントを送信するサービスを識別する `source` 属性。DNS ファイアウォールイベントの場合、ソースは `aws.route53resolver` です。
+ (オプション): 照合するイベントタイプの配列を含む `detail-type` 属性。
+ (オプション): 照合対象となるその他のイベントデータを含む `detail` 属性。
例えば、次のイベントパターンは、DNS ファイアウォールからのアラートイベントとブロックイベントの両方に一致します。
```
{
"source": ["aws.route53resolver"],
"detail-type": ["DNS Firewall Block", "DNS Firewall Alert"]
}
```
次のイベントパターンが BLOCK アクションと一致している間:
```
{
"source": ["aws.route53resolver"],
"detail-type": ["DNS Firewall Block"]
}
```
DNS ファイアウォールは、6 時間以内に同じドメインに対して同じイベントを 1 回だけ送信します。例えば、次のようになります。
1. インスタンス i-123 は、T1 に DNS クエリ exampledomain.com を送信しました。DNS ファイアウォールは、これが最初の発生であるため、アラートイベントまたはブロックイベントを送信します。
1. インスタンス i-123 は、T1\$130 分に DNS クエリ exampledomain.com を送信しました。DNS ファイアウォールは、6 時間の時間枠内に繰り返し発生するため、アラートまたはブロックイベントを送信しません。
1. インスタンス i-123 は T1\$17 時間に DNS クエリ exampledomain.com を送信しました。DNS ファイアウォールは、6 時間の時間枠外に発生したアラートイベントまたはブロックイベントを送信します。
詳細については、「*EventBridge ユーザーガイド*」の「[イベントパターン](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-event-patterns.html)」を参照してください。
### での DNS Firewall イベントのイベントパターンのテスト EventBridge
EventBridge サンドボックスを使用すると、ルールを作成または編集する大規模なプロセスを完了することなく、イベントパターンをすばやく定義してテストできます。サンドボックスを使用すると、イベントパターンを定義し、サンプルイベントを使用して、そのパターンが目的のイベントと一致することを確認できます。サンドボックスから直接、そのイベントパターンを使用して新しいルールを作成するオプション EventBridge が提供されます。
詳細については、 *EventBridge ユーザーガイド*[の EventBridge 「サンドボックスを使用したイベントパターンのテスト](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-event-pattern-sandbox.html)」を参照してください。
### DNS ファイアウォールの EventBridge ルールとターゲットの作成
次の手順では、EventBridge がすべての DNS Firewall アラートアクションとブロックアクションのイベントを送信し、ルールのターゲットとして AWS Lambda 関数を追加できるようにするルールを作成する方法を示します。
1. AWS CLI を使用して EventBridge ルールを作成します。
```
aws events put-rule \
--event-pattern "{\"source\":
[\"aws.route53resolver\"],\"detail-type\":
[\"DNS Firewall Block\", \"DNS Firewall Alert\"]}" \
--name dns-firewall-rule
```
1. ルールのターゲットとして Lambda 関数をアタッチします。
`AWS events put-targets --rule dns-firewall-rule --targets Id=1,Arn=arn:aws:lambda:us-east-1:111122223333:function:`
1. ターゲットを呼び出すために必要なアクセス許可を追加するには、次の Lambda AWS CLI コマンドを実行します。
`AWS lambda add-permission --function-name --statement-id 1 --action 'lambda:InvokeFunction' --principal events.amazonaws.com`
## Amazon EventBridge アクセス許可
DNS ファイアウォールでは、 Amazon EventBridgeにイベントを配信するために追加のアクセス許可は必要ありません。
指定するターゲットに、特定のアクセス許可または設定が必要になることがあります。ターゲットに特定のサービスを使用する方法の詳細については、「*Amazon EventBridge ユーザーガイド*」の「[Amazon EventBridge ターゲット](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-targets.html)」を参照してください。
## その他の EventBridge リソース
EventBridge を使用してイベントを処理および管理する方法の詳細については、 [https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html)の以下のトピックを参照してください。
+ イベントバスの仕組みに関する詳細は、「[Amazon EventBridge イベントバス](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-event-bus.html)」を参照してください。
+ イベント構造については、「[Amazon EventBridge イベント](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-events.html)」を参照してください。
+ ルールとイベント EventBridge を照合するときに が使用するイベントパターンの構築については、[「イベントパターン](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-event-patterns.html)」を参照してください。
+ EventBridge が処理するイベントを指定するルールの作成方法については、「[Amazon EventBridge ルール](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-rules.html)」を参照してください。
+ 一致するイベント EventBridge を送信するサービスまたは他の送信先を指定する方法については、[「ターゲット](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-targets.html)」を参照してください。
# Resolver DNS Firewall イベントの詳細リファレンス
AWS サービスからのすべてのイベントには、イベントのソースである AWS サービス、イベントが生成された時刻、イベントが発生したアカウントとリージョンなど、イベントに関するメタデータを含む共通のフィールドセットがあります。これらの一般的なフィールドの定義については、「*Amazon EventBridge ユーザーガイド*」の「[イベント構造リファレンス](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-events-structure.html)」を参照してください。
さらに、各イベントには、その特定のイベントに固有のデータを含む `detail` フィールドがあります。以下のリファレンスでは、さまざまな DNS ファイアウォールイベントの詳細フィールドを定義しています。
EventBridge を使用して DNS Firewall イベントを選択および管理する場合は、次の点に注意してください。
+ DNS ファイアウォールのすべてのイベントの `source` フィールドは、`aws.route53resolver` に設定されています。
+ `detail-type` フィールドはイベントタイプを指定します。
例えば、`DNS Firewall Block`、`DNS Firewall Alert` です。
+ `detail` フィールドには、その特定のイベントに固有のデータが含まれます。
DNS ファイアウォールイベントに一致するようにルールを有効化するイベントパターンの作成方法については、「*Amazon EventBridge ユーザーガイド*」の「[イベントパターン](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-event-patterns.html)」を参照してください。
イベントとその EventBridge 処理方法の詳細については、*Amazon EventBridge 「 ユーザーガイド*」の[Amazon EventBridge 「 イベント](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-events.html)」を参照してください。
**Topics**
+ [DNS ファイアウォールアラートイベントの詳細](#dns-firewall-alert)
+ [DNS ファイアウォールブロックイベントの詳細](#dns-firewall-block)
## DNS ファイアウォールアラートイベントの詳細
以下は、アラートステータスイベントの詳細の詳細フィールドです。
`source` と `detail-type` のフィールドがあるのは、Route 53 イベントに、これらに固有の値が含まれているためです。
```
{...,
"detail-type": "DNS Firewall Alert",
"source": "aws.route53resolver",
...,
"detail": {
"account-id": "string",
"last-observed-at": "string",
"query-name": "string",
"query-type": "string",
"query-class": "string",
"transport": "string",
"firewall-rule-action": "string",
"firewall-rule-group-id": "string",
"firewall-domain-list-id": "string",
"firewall-protection": "string",
"resources": [{
"resource-type": "string",
"instance-details": {
"id": "string",
}
},
{
"resource-type": "string",
"resolver-endpoint-details": {
"id": "string"
}
}
]
```
`detail-type`
イベントのタイプを示します。
このイベントの場合、この値は `DNS Firewall Alert` です。
`source`
イベントを発生させたサービスを識別します。DNS ファイアウォールイベントの場合、この値は `aws.route53resolver` です。
`detail`
イベントに関する情報を含む JSON オブジェクト。このフィールドの内容は、イベントを生成するサービスによって決まります。
このイベントの場合、このデータには以下が含まれます。
`account-id`
VPC AWS アカウント を作成した の ID。
`last-observed-at`
VPC でアラート/ブロッククエリが行われた時刻のタイムスタンプです。
`query-name`
クエリで指定されたドメイン名 (example.com) またはサブドメイン名 (www.example.com)。
`query-type`
リクエストで指定された DNS レコードタイプ、またはいずれか。Route 53 でサポートされるタイプについては、「[サポートされる DNS レコードタイプ](ResourceRecordTypes.md)」を参照してください。
`query-class`
クエリのクラス。
`transport`
DNS クエリを送信するために使用されたプロトコル。
`firewall-rule-action`
クエリ内のドメイン名に一致したルールが指定しているアクション。`ALERT` または `BLOCK` です。
`firewall-rule-group-id`
クエリ内のドメイン名と一致した DNS Firewall ルールグループの ID。ファイアウォールルールグループの詳細については、「DNS Firewall [DNS Firewall のルールグループとルール](resolver-dns-firewall-rule-groups.md)」を参照してください。
`firewall-domain-list-id`
クエリ内のドメイン名に一致したルールによって使用されるドメインリスト。
`firewall-protection`
DNS Firewall Advanced 保護: DGA、DICTIONARY\$1DGA、または DNS\$1TUNNELING。詳細については、「DNS Firewall [リゾルバー DNS Firewall Advanced](firewall-advanced.md)」を参照してください。
`resourcese`
リソースタイプとそれらの追加の詳細が含まれます。
`resource-type`
リゾルバーエンドポイントまたは VPC インスタンスなどのリソースタイプを指定します。
`resource-type-detail`
リソースに関するその他の詳細。
**Example DNS ファイアウォールアラートイベント**
以下に示しているのは、アラートイベントの例です。
```
{
"version": "1.0",
"id": "8e5622f9-d81c-4d81-612a-9319e7ee2506",
"detail-type": "DNS Firewall Alert",
"source": "aws.route53resolver",
"account": "123456789012",
"time": "2023-05-30T21:52:17Z",
"region": "us-west-2",
"resources": [],
"detail": {
"account-id": "123456789012",
"last-observed-at": "2023-05-30T20:15:15.900Z",
"query-name": "15.3.4.32.in-addr.arpa.",
"query-type": "A",
"query-class": "IN",
"transport": "UDP",
"firewall-rule-action": "ALERT",
"firewall-rule-group-id": "rslvr-frg-01234567890abcdef",
"firewall-domain-list-id": "rslvr-fdl-01234567890abcdef",
"firewall-protection": "DGA",
"resources": [{
"resource-type": "instance",
"instance-details": {
"id": "i-05746eb48123455e0",
}
},
{
"resource-type": "resolver-endpoint",
"resolver-endpoint-details": {
"id": "i-05746eb48123455e0"
}
}
],
"src-addr": "4.5.64.102",
"src-port": "56067",
"vpc-id": "vpc-7example"
}
}
```
## DNS ファイアウォールブロックイベントの詳細
以下は、*イベント名*の詳細フィールドです。
`source` と `detail-type` のフィールドがあるのは、Route 53 イベントに、これらに固有の値が含まれているためです。
```
{...,
"detail-type": "DNS Firewall Block",
"source": "aws.route53resolver",
...,
"detail": {
"account-id": "string",
"last-observed-at": "string",
"query-name": "string",
"query-type": "string",
"query-class": "string",
"transport": "string",
"firewall-rule-action": "string",
"firewall-rule-group-id": "string",
"firewall-domain-list-id": "string",
"firewall-protection": "string",
"resources": [{
"resource-type": "string",
"instance-details": {
"id": "string",
}
},
{
"resource-type": "string",
"resolver-endpoint-details": {
"id": "string"
}
}
]
```
`detail-type`
イベントのタイプを示します。
このイベントの場合、この値は `DNS Firewall Alert` です。
`source`
イベントを発生させたサービスを識別します。DNS ファイアウォールイベントの場合、この値は `aws.route53resolver` です。
`detail`
イベントに関する情報を含む JSON オブジェクト。このフィールドの内容は、イベントを生成するサービスによって決まります。
このイベントの場合、このデータには以下が含まれます。
`account-id`
VPC AWS アカウント を作成した の ID。
`last-observed-at`
VPC でアラート/ブロッククエリが行われた時刻のタイムスタンプです。
`query-name`
クエリで指定されたドメイン名 (example.com) またはサブドメイン名 (www.example.com)。
`query-type`
リクエストで指定された DNS レコードタイプ、またはいずれか。Route 53 でサポートされるタイプについては、「[サポートされる DNS レコードタイプ](ResourceRecordTypes.md)」を参照してください。
`query-class`
クエリのクラス。
`transport`
DNS クエリを送信するために使用されたプロトコル。
`firewall-rule-action`
クエリ内のドメイン名に一致したルールが指定しているアクション。`ALERT` または `BLOCK` です。
`firewall-rule-group-id`
クエリ内のドメイン名と一致した DNS Firewall ルールグループの ID。ファイアウォールルールグループの詳細については、「DNS Firewall [DNS Firewall のルールグループとルール](resolver-dns-firewall-rule-groups.md)」を参照してください。
`firewall-domain-list-id`
クエリ内のドメイン名に一致したルールによって使用されるドメインリスト。
`firewall-protection`
DNS Firewall Advanced 保護: DGA、DICTIONARY\$1DGA、または DNS\$1TUNNELING。詳細については、「DNS Firewall [リゾルバー DNS Firewall Advanced](firewall-advanced.md)」を参照してください。
`resourcese`
リソースタイプとそれらの追加の詳細が含まれます。
`resource-type`
リゾルバーエンドポイントまたは VPC インスタンスなどのリソースタイプを指定します。
`resource-type-detail`
リソースに関するその他の詳細。
**Example イベントの例**
以下に示しているのは、ブロックイベントの例です。
```
{
"version": "1.0",
"id": "8e5622f9-d81c-4d81-612a-9319e7ee2506",
"detail-type": "DNS Firewall Block",
"source": "aws.route53resolver",
"account": "123456789012",
"time": "2023-05-30T21:52:17Z",
"region": "us-west-2",
"resources": [],
"detail": {
"account-id": "123456789012",
"last-observed-at": "2023-05-30T20:15:15.900Z",
"query-name": "15.3.4.32.in-addr.arpa.",
"query-type": "A",
"query-class": "IN",
"transport": "UDP",
"firewall-rule-action": "BLOCK",
"firewall-rule-group-id": "rslvr-frg-01234567890abcdef",
"firewall-domain-list-id": "rslvr-fdl-01234567890abcdef",
"firewall-protection": "DNS_TUNNELING",
"resources": [{
"resource-type": "instance",
"instance-details": {
"id": "i-05746eb48123455e0"
}
},
{
"resource-type": "resolver-endpoint",
"resolver-endpoint-details": {
"id": "i-05746eb48123455e0",
}
}
],
"src-addr": "4.5.64.102",
"src-port": "56067",
"vpc-id": "vpc-7example"
}
}
```
# を使用した Amazon Route 53 API コールのログ記録 AWS CloudTrail
Route 53 は AWS CloudTrail、Route 53 のユーザー、ロール、または サービスによって実行されたアクションを記録する AWS サービスである と統合されています。CloudTrail は、 Route 53 コンソールからのコールや、 Route 53 API へのコードのコールを含む Route 53 のすべての API コールを、イベントとしてキャプチャします。証跡を作成する場合は、Route 53 のイベントなど、Amazon S3 バケットへの CloudTrail イベントの継続的な配信を有効にすることができます。証跡を設定しない場合でも、CloudTrail コンソールの [**Event history (イベント履歴)**] で最新のイベントを表示できます。CloudTrail で収集された情報を使用して、Route 53 に対するリクエスト、そのリクエストが発信された IP アドレス、リクエストの作成者、リクエスト作成日時、その他の詳細情報などを確認できます。
**Topics**
+ [CloudTrail での Route 53 の情報](#route-53-info-in-cloudtrail)
+ [イベント履歴での Route 53 イベントの表示](#route-53-events-in-cloudtrail-event-history)
+ [Route 53 のログファイルエントリを理解する](#understanding-route-53-entries-in-cloudtrail)
## CloudTrail での Route 53 の情報
CloudTrail は、 AWS アカウントの作成時にアカウントで有効になります。Route 53 でアクティビティが発生すると、そのアクティビティはイベント**履歴**の他の AWS サービスイベントとともに CloudTrail イベントに記録されます。 AWS アカウントで最近のイベントを表示、検索、ダウンロードできます。詳細については、「[CloudTrail Event 履歴でのイベントの表示](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html)」を参照してください。
Route 53 のイベントなど、 AWS アカウントのイベントの継続的な記録については、証跡を作成します。証跡により、ログファイルを CloudTrail で Amazon S3 バケットに配信できます。デフォルトでは、コンソールで追跡を作成するときに、追跡がすべてのリージョンに適用されます。証跡は、 AWS パーティション内のすべてのリージョンからのイベントをログに記録し、指定した Amazon S3 バケットにログファイルを配信します。さらに、CloudTrail ログで収集されたイベントデータをさらに分析して処理するように他の AWS サービスを設定できます。詳細については、以下を参照してください。
+ [証跡を作成するための概要](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html)
+ [CloudTrail がサポートされているサービスと統合](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-aws-service-specific-topics.html#cloudtrail-aws-service-specific-topics-integrations)
+ 「[CloudTrail の Amazon SNS 通知の設定](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/getting_notifications_top_level.html)」
+ 「[CloudTrail ログファイルを複数のリージョンから受け取る](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/receive-cloudtrail-log-files-from-multiple-regions.html)」、「[複数のアカウントから CloudTrail ログファイルを受け取る](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-receive-logs-from-multiple-accounts.html)」
すべての Route 53 アクションが CloudTrail により記録されます。また、これらのアクションは [Amazon Route 53 API リファレンス](https://docs.aws.amazon.com/Route53/latest/APIReference/)で説明されています。例えば、`CreateHostedZone`、`CreateHealthCheck`、`RegisterDomain` の各アクションを呼び出すと、CloudTrail ログファイルにエントリが生成されます。
各イベントまたはログエントリには、リクエストの生成者に関する情報が含まれます。同一性情報は次の判断に役立ちます。
+ リクエストが、ルートと IAM ユーザー認証情報のどちらを使用して送信されたか。
+ リクエストがロールまたはフェデレーションユーザーの一時的なセキュリティ認証情報を使用して行われたかどうか。
+ リクエストが別の AWS サービスによって行われたかどうか。
詳細については、「[CloudTrail userIdentity エレメント](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-user-identity.html)」を参照してください。
## イベント履歴での Route 53 イベントの表示
CloudTrail では、[**イベント履歴**] に最近のイベントが表示されます。Route 53 API リクエストのイベントを表示するには、コンソールの上部にあるリージョンセレクターで、 **米国東部 (バージニア北部)** を指定する必要があります。詳細については、*AWS CloudTrail ユーザーガイド*の「[CloudTrail イベント履歴でのイベントの表示](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html)」を参照してください。
## Route 53 のログファイルエントリを理解する
証跡は、指定した Amazon S3 バケットにイベントをログファイルとして配信するように設定できます。CloudTrail のログファイルは、単一か複数のログエントリを含みます。イベントはあらゆるソースからの単一のリクエストを表し、リクエストされたアクション、アクションの日時、リクエストのパラメータなどの情報が含まれます。CloudTrail ログファイルは、パブリック API コールの順序付けられたスタックトレースではないため、特定の順序では表示されません。
`eventName` 要素は、発生したアクションを示します。(CloudTrail Logs では、アクション名の最初の文字が大文字ですが、ドメイン登録アクションでは小文字です。例えば、`UpdateDomainContact` はログ内で `updateDomainContact` としてあらわされます。CloudTrail は、すべての Route 53 API アクションをサポートしています。次の例では、次に示したアクションを表す CloudTrail ログエントリを確認できます。
+ AWS アカウントに関連付けられているホストゾーンを一覧表示する
+ ヘルスチェックの作成
+ 2 つのレコードの作成
+ ホストゾーンの削除
+ 登録済みドメインの情報の更新
+ Route 53 VPC Resolver アウトバウンドエンドポイントを作成する
```
{
"Records": [
{
"apiVersion": "2013-04-01",
"awsRegion": "us-east-1",
"eventID": "1cdbea14-e162-43bb-8853-f9f86d4739ca",
"eventName": "ListHostedZones",
"eventSource": "route53.amazonaws.com",
"eventTime": "2015-01-16T00:41:48Z",
"eventType": "AwsApiCall",
"eventVersion": "1.02",
"recipientAccountId": "444455556666",
"requestID": "741e0df7-9d18-11e4-b752-f9c6311f3510",
"requestParameters": null,
"responseElements": null,
"sourceIPAddress": "192.0.2.92",
"userAgent": "Apache-HttpClient/4.3 (java 1.5)",
"userIdentity": {
"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
"accountId": "111122223333",
"arn": "arn:aws:iam::111122223333:user/smithj",
"principalId": "A1B2C3D4E5F6G7EXAMPLE",
"type": "IAMUser",
"userName": "smithj"
}
},
{
"apiVersion": "2013-04-01",
"awsRegion": "us-east-1",
"eventID": "45ec906a-1325-4f61-b133-3ef1012b0cbc",
"eventName": "CreateHealthCheck",
"eventSource": "route53.amazonaws.com",
"eventTime": "2018-01-16T00:41:57Z",
"eventType": "AwsApiCall",
"eventVersion": "1.02",
"recipientAccountId": "444455556666",
"requestID": "79915168-9d18-11e4-b752-f9c6311f3510",
"requestParameters": {
"callerReference": "2014-05-06 64832",
"healthCheckConfig": {
"iPAddress": "192.0.2.249",
"port": 80,
"type": "TCP"
}
},
"responseElements": {
"healthCheck": {
"callerReference": "2014-05-06 64847",
"healthCheckConfig": {
"failureThreshold": 3,
"iPAddress": "192.0.2.249",
"port": 80,
"requestInterval": 30,
"type": "TCP"
},
"healthCheckVersion": 1,
"id": "b3c9cbc6-cd18-43bc-93f8-9e557example"
},
"location": "https://route53.amazonaws.com/2013-04-01/healthcheck/b3c9cbc6-cd18-43bc-93f8-9e557example"
},
"sourceIPAddress": "192.0.2.92",
"userAgent": "Apache-HttpClient/4.3 (java 1.5)",
"userIdentity": {
"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
"accountId": "111122223333",
"arn": "arn:aws:iam::111122223333:user/smithj",
"principalId": "A1B2C3D4E5F6G7EXAMPLE",
"type": "IAMUser",
"userName": "smithj"
}
},
{
"additionalEventData": {
"Note": "Do not use to reconstruct hosted zone"
},
"apiVersion": "2013-04-01",
"awsRegion": "us-east-1",
"eventID": "883b14d9-2f84-4005-8bc5-c7bf0cebc116",
"eventName": "ChangeResourceRecordSets",
"eventSource": "route53.amazonaws.com",
"eventTime": "2018-01-16T00:41:43Z",
"eventType": "AwsApiCall",
"eventVersion": "1.02",
"recipientAccountId": "444455556666",
"requestID": "7081d4c6-9d18-11e4-b752-f9c6311f3510",
"requestParameters": {
"changeBatch": {
"changes": [
{
"action": "CREATE",
"resourceRecordSet": {
"name": "prod.example.com.",
"resourceRecords": [
{
"value": "192.0.1.1"
},
{
"value": "192.0.1.2"
},
{
"value": "192.0.1.3"
},
{
"value": "192.0.1.4"
}
],
"tTL": 300,
"type": "A"
}
},
{
"action": "CREATE",
"resourceRecordSet": {
"name": "test.example.com.",
"resourceRecords": [
{
"value": "192.0.1.1"
},
{
"value": "192.0.1.2"
},
{
"value": "192.0.1.3"
},
{
"value": "192.0.1.4"
}
],
"tTL": 300,
"type": "A"
}
}
],
"comment": "Adding subdomains"
},
"hostedZoneId": "Z1PA6795UKMFR9"
},
"responseElements": {
"changeInfo": {
"comment": "Adding subdomains",
"id": "/change/C156SRE0X2ZB10",
"status": "PENDING",
"submittedAt": "Jan 16, 2018 12:41:43 AM"
}
},
"sourceIPAddress": "192.0.2.92",
"userAgent": "Apache-HttpClient/4.3 (java 1.5)",
"userIdentity": {
"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
"accountId": "111122223333",
"arn": "arn:aws:iam::111122223333:user/smithj",
"principalId": "A1B2C3D4E5F6G7EXAMPLE",
"type": "IAMUser",
"userName": "smithj"
}
},
{
"apiVersion": "2013-04-01",
"awsRegion": "us-east-1",
"eventID": "0cb87544-ebee-40a9-9812-e9dda1962cb2",
"eventName": "DeleteHostedZone",
"eventSource": "route53.amazonaws.com",
"eventTime": "2018-01-16T00:41:37Z",
"eventType": "AwsApiCall",
"eventVersion": "1.02",
"recipientAccountId": "444455556666",
"requestID": "6d5d149f-9d18-11e4-b752-f9c6311f3510",
"requestParameters": {
"id": "Z1PA6795UKMFR9"
},
"responseElements": {
"changeInfo": {
"id": "/change/C1SIJYUYIKVJWP",
"status": "PENDING",
"submittedAt": "Jan 16, 2018 12:41:36 AM"
}
},
"sourceIPAddress": "192.0.2.92",
"userAgent": "Apache-HttpClient/4.3 (java 1.5)",
"userIdentity": {
"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
"accountId": "111122223333",
"arn": "arn:aws:iam::111122223333:user/smithj",
"principalId": "A1B2C3D4E5F6G7EXAMPLE",
"type": "IAMUser",
"userName": "smithj"
}
},
{
"eventVersion": "1.05",
"userIdentity": {
"type": "IAMUser",
"principalId": "A1B2C3D4E5F6G7EXAMPLE",
"arn": "arn:aws:iam::111122223333:user/smithj",
"accountId": "111122223333",
"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
"userName": "smithj",
"sessionContext": {
"attributes": {
"mfaAuthenticated": "false",
"creationDate": "2018-11-01T19:43:59Z"
}
},
"invokedBy": "test"
},
"eventTime": "2018-11-01T19:49:36Z",
"eventSource": "route53domains.amazonaws.com",
"eventName": "updateDomainContact",
"awsRegion": "us-west-2",
"sourceIPAddress": "192.0.2.92",
"userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Firefox/52.0",
"requestParameters": {
"domainName": {
"name": "example.com"
}
},
"responseElements": {
"requestId": "034e222b-a3d5-4bec-8ff9-35877ff02187"
},
"additionalEventData": "Personally-identifying contact information is not logged in the request",
"requestID": "015b7313-bf3d-11e7-af12-cf75409087f6",
"eventID": "f34f3338-aaf4-446f-bf0e-f72323bac94d",
"eventType": "AwsApiCall",
"recipientAccountId": "444455556666"
},
{
"eventVersion": "1.05",
"userIdentity": {
"type": "IAMUser",
"principalId": "A1B2C3D4E5F6G7EXAMPLE",
"arn": "arn:aws:iam::111122223333:user/smithj",
"accountId": "111122223333",
"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
"sessionContext": {
"attributes": {
"mfaAuthenticated": "false",
"creationDate": "2018-11-01T14:33:09Z"
},
"sessionIssuer": {
"type": "Role",
"principalId": "AROAIUZEZLWWZOEXAMPLE",
"arn": "arn:aws:iam::123456789012:role/Admin",
"accountId": "123456789012",
"userName": "Admin"
}
}
},
"eventTime": "2018-11-01T14:37:19Z",
"eventSource": "route53resolver.amazonaws.com",
"eventName": "CreateResolverEndpoint",
"awsRegion": "us-west-2",
"sourceIPAddress": "192.0.2.176",
"userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Firefox/52.0",
"requestParameters": {
"creatorRequestId": "123456789012",
"name": "OutboundEndpointDemo",
"securityGroupIds": [
"sg-05618b249example"
],
"direction": "OUTBOUND",
"ipAddresses": [
{
"subnetId": "subnet-01cb0c4676example"
},
{
"subnetId": "subnet-0534819b32example"
}
],
"tags": []
},
"responseElements": {
"resolverEndpoint": {
"id": "rslvr-out-1f4031f1f5example",
"creatorRequestId": "123456789012",
"arn": "arn:aws:route53resolver:us-west-2:123456789012:resolver-endpoint/rslvr-out-1f4031f1f5example",
"name": "OutboundEndpointDemo",
"securityGroupIds": [
"sg-05618b249example"
],
"direction": "OUTBOUND",
"ipAddressCount": 2,
"hostVPCId": "vpc-0de29124example",
"status": "CREATING",
"statusMessage": "[Trace id: 1-5bd1d51e-f2f3032eb75649f71example] Creating the Resolver Endpoint",
"creationTime": "2018-11-01T14:37:19.045Z",
"modificationTime": "2018-11-01T14:37:19.045Z"
}
},
"requestID": "3f066d98-773f-4628-9cba-4ba6eexample",
"eventID": "cb05b4f9-9411-4507-813b-33cb0example",
"eventType": "AwsApiCall",
"recipientAccountId": "123456789012"
}
]
}
```