マルチクラウド環境でDNS障害が発生した話

マルチクラウド環境でDNS障害が発生した話 〜AD統合ゾーンとDNSフォワーダーの落とし穴〜 2026/9/18 JAWS-UG横浜 #103 SRE支部コラボLT会 ムカイヤマ ※本スライドの内容は個人の見解であり、所属組織とは無関係です。 1

自己紹介 ムカイヤマ ・所属：SIer(AWSを中心としたインフラの設計構築) - オンプレからAWSの移行 - 脆弱性対応 ・好きなAWSサービス： System Manager、AWSサポート ・2026 Japan AWS Jr. Champions 登壇資料は上記のQRコードより ご覧いただけます。 最後のスライドでも再度QRコード をご案内いたします ※本スライドの内容は個人の見解 であり、所属組織とは無関係です。

本日お話しすること／お話ししないこと お話しすこと ・マルチクラウド環境で外部名前解決が全断した障害の実例 ・AD統合ゾーン ・Amazon Provided DNS ・Route 53 Resolver お話ししないこと ・Active Directory自体の構築・設定手順 ・Route 53の全機能の網羅的な解説 ・他社クラウド固有のDNS実装の詳細 2

前提知識① AD・AD DCとは ・Active Directory（AD） ユーザー認証・認可、グループポリシーを一元管理するディレクトリサービス ・AD DC（ドメインコントローラー） ADのデータベースを保持し、認証要求・DNSクエリに応答する実体サーバー 可用性確保のため、通常は複数台のAD DCを異なる場所に 配置してレプリケーションを行う AD DCが1台のみの構成は、停止すると認証もDNS解決も 止まる単一障害点（SPOF）になる 3

前提知識② DNSフォワーダーとは ・DNSフォワーダーとは、自身が答えを持たないDNSクエリを、指定した別の DNSサーバーに転送する仕組み 代表例:「自ドメイン以外は上位（インターネット向け）DNSへ転送」 ・転送先はドメイン単位で指定でき（条件付きフォワーディング）、AD DCやオ ンプレDNSの「転送設定」もこの一種 ポイント：AWSでも、Route 53 ResolverのInbound/Outboundエンドポイントや条件付き転 送ルール（Resolver Rule）は、VPCとオンプレミス・他クラウド間の名前解決を橋渡しする、 まさに「DNSフォワーダー」の考え方そのもの

前提知識③ Amazon Provided DNSの制約 Amazon Provided DNS（VPC+2）：VPCが自動提供するDNSリゾルバー ・VPCのCIDRブロックの先頭から2番目のIPアドレスで応答 ・VPC内のプライベートホストゾーンやパブリックDNSの名前解決を無料で提供 ・現在の正式名称は、Route 53 VPC Resolver 重要な制約： 同一VPC内からしかアクセスできない VPCの外部（オンプレミスや他クラウド）から直接問い合わせることはできない 5

環境構成 AWS VPC 他社クラウド オンプレミス DNSフォワーダー DNSフォワーダー AD DC AD DC EC2上のAD DC DNSクエリ 実際の通信 NAT Gateway Internet Gateway インターネット Amazon Provided DNS (VPC+2 / 同一VPC内限定) Public DNS

発生した事象①：メンテナンスで停止したら… ・AWS上のEC2で稼働していたAD DC（1台のみ）をメンテナンス目的で 停止 ・その結果、他社クラウドおよびオンプレミス拠点からインターネットへ の名前解決ができなくなった 影響範囲： オンプレミス／他社クラウドの両拠点から、外部（インターネット）の名前解決が全断 7

発生した事象②：内部の名前解決は無事 ・社内ドメインなど内部の名前解決は、AD統合ゾーンのレプリケーション により他拠点のAD DCが応答を継続 ・そのため内部通信への影響はなかった AD統合ゾーンとは ・DNSのゾーン情報をADのデータベース自体に格納する仕組み ・複数のAD DC間で自動的にレプリケーションされ、どのAD DCでも同じゾーン 情報を参照できる ・そのため内部の名前解決（社内ドメイン名の解決）は特定の1台に依存しない 8

原因分析：外部名前解決は1台に依存していた ✕ オンプレミス／他社 DNSフォワーダー EC2上のAD DC (停止中) Amazon Provided DNS (VPC+2) インターネット ・AWS(VPC)外部からAmazon Provided DNSの名前解決は不可 ・外部名前解決は「EC2上のAD DC 1台」に完全依存した構成になっていた ・内部（AD統合ゾーン）は冗長化されていたが、外部名前解決の経路だけは冗長化され ていなかった 9

解決策：Route 53 Resolver Inbound Endpoint ・Inbound Endpoint：VPC外部（オンプレミスや他クラウド）からのDNSク エリを受け付ける入り口 ・複数のAZにまたがるENI（Elastic Network Interface）で構成される ・他拠点のDNSフォワーダーの参照先を、EC2上のAD DCからInbound EndpointのIPに変更 これにより「AWS外からDNSの名前解決ができる構成」に変わる 10

導入後の構成とポイント オンプレミス AWS (ap-northeast-1) VPC 参照先を変更 DNS フォワーダー Inbound Endpoint ENI (AZ-a) 他社クラウド Inbound Endpoint ENI (AZ-c) Amazon Provided DNS DNS フォワーダー ・可用性確保のため、異なるAZに最低2つのENIを配置することが推奨 ・Inbound Endpoint自体がVPC内からAmazon Provided DNSへ問い合わせるため、「同一VPC 内」の制約をクリア 11

その他の対策案と料金比較 2026年9月時点／ap-northeast-1（東京）リージョン 対策案 概算コスト 特徴 Resolver Inbound Endpoint ENI $0.125/時間×2で 月額約$182.50＋クエリ課金 AWS公式推奨。既存AD DCに 手を入れず構成可能 (参考)Resolver Outbound Endpoint Inbound同様の ENI課金体系 オンプレ等への 転送に利用 Route 53 Global Resolver リージョン単位＋ クエリ量の2段階課金 複数リージョンの 高可用性向け（オーバースペック気味） EC2上のAD DC を1台追加 追加インスタンスの 利用料次第 根本的な冗長化だが 運用コストは増加 料金は変動する可能性があるため、最新情報は Amazon Route 53 料金ページでご確認ください 12

残る課題：マルチクラウドの利点を活かせない ・ここまでの3つの対策案には共通点がある：いずれも「AWS経由でインターネ ットへの名前解決をさせる」前提 ・外部名前解決という重要な機能が、実質的にAWS単独の可用性に依存してし まう ・マルチクラウドを採用している意義の一部が薄れてしまう、という論点が残る 13

追加の検討案：パブリックDNSの併用 ・各拠点のDNSフォワーダーに、AWS以外のパブリックDNS （例：Google Public DNS 8.8.8.8）を追加する案 ・AWS側に障害が発生しても、他拠点は独立して外部名前解決を継続できる ただし、以下に注意が必要 ・セキュリティ／監査ログ：外部DNSへの問い合わせを許可していない組織では採用しづらい ・スプリットホライズンDNSとの整合性：想定外のゾーンが公開DNSに転送されるリスク ・可用性設計の一貫性：既存対策と併用する場合、フォワーダーの優先順位設計が必要 14

まとめ ・AWS(VPC)外部からAmazon Provided DNSの名前解決は不可 ・外部からの名前解決をするには Route 53 Resolver Inbound Endpointの導入が必要 15

参考リンク ・「Amazon Route 53 の料金」AWS Documentation https://aws.amazon.com/jp/route53/pricing/ ・「Route 53 VPC Resolver とは」 AWS Documentation https://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/resolver.html 16

• https://aws.amazon.com/jp/route53/pricing/
• https://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/resolver.html

ご清聴ありがとうございました。 資料は下記に公開しています。 https://www.docswell.com/user/mkymdk ※本スライドの内容は個人の見解であり、 所属組織とは無関係です。

• https://www.docswell.com/user/mkymdk