--- title: マルチクラウド環境でDNS障害が発生した話 tags: #aws author: [ムカイヤマ](https://image.docswell.com/user/mkymdk) site: [Docswell](https://www.docswell.com/) thumbnail: https://bcdn.docswell.com/page/87DKQ1KYJG.jpg?width=480 description: 本資料では、AWS上の単一AD DCがメンテナンスで停止したことにより、オンプレミスや他社クラウドからインターネットへの名前解決が全断した障害を取り上げます。内部の名前解決はAD統合ゾーンで冗長化されていたため影響がありませんでしたが、外部名前解決は1台のAD DCに依存していました。そこで、Route 53 ResolverのInbound Endpointを複数AZに配置し、各拠点のDNSフォワーダーがそのエンドポイントを参照する構成に変更することで、AWS外部からも名前解決できるように冗長化を実現しました。導入後の構成や費用比較、残る課題としてマルチクラウドの可用性がAWSに偏りがちになる点、パブリックDNS併用の検討事項についても説明しています。 published: September 18, 26 canonical: https://image.docswell.com/s/mkymdk/59N7LX-2026-09-18-124103 --- # Page. 1 ![Page Image](https://bcdn.docswell.com/page/87DKQ1KYJG.jpg) マルチクラウド環境でDNS障害が発生した話 〜AD統合ゾーンとDNSフォワーダーの落とし穴〜 2026/9/18 JAWS-UG横浜 #103 SRE支部コラボLT会 ムカイヤマ ※本スライドの内容は個人の見解であり、所属組織とは無関係です。 1 # Page. 2 ![Page Image](https://bcdn.docswell.com/page/VJPKLQK2E8.jpg) 自己紹介 ムカイヤマ ・所属：SIer(AWSを中心としたインフラの設計構築) - オンプレからAWSの移行 - 脆弱性対応 ・好きなAWSサービス： System Manager、AWSサポート ・2026 Japan AWS Jr. Champions 登壇資料は上記のQRコードより ご覧いただけます。 最後のスライドでも再度QRコード をご案内いたします ※本スライドの内容は個人の見解 であり、所属組織とは無関係です。 # Page. 3 ![Page Image](https://bcdn.docswell.com/page/2EVVQ5VXEQ.jpg) 本日お話しすること／お話ししないこと お話しすこと ・マルチクラウド環境で外部名前解決が全断した障害の実例 ・AD統合ゾーン ・Amazon Provided DNS ・Route 53 Resolver お話ししないこと ・Active Directory自体の構築・設定手順 ・Route 53の全機能の網羅的な解説 ・他社クラウド固有のDNS実装の詳細 2 # Page. 4 ![Page Image](https://bcdn.docswell.com/page/57GLW6LREL.jpg) 前提知識① AD・AD DCとは ・Active Directory（AD） ユーザー認証・認可、グループポリシーを一元管理するディレクトリサービス ・AD DC（ドメインコントローラー） ADのデータベースを保持し、認証要求・DNSクエリに応答する実体サーバー 可用性確保のため、通常は複数台のAD DCを異なる場所に 配置してレプリケーションを行う AD DCが1台のみの構成は、停止すると認証もDNS解決も 止まる単一障害点（SPOF）になる 3 # Page. 5 ![Page Image](https://bcdn.docswell.com/page/4EQY34YYJP.jpg) 前提知識② DNSフォワーダーとは ・DNSフォワーダーとは、自身が答えを持たないDNSクエリを、指定した別の DNSサーバーに転送する仕組み 代表例:「自ドメイン以外は上位（インターネット向け）DNSへ転送」 ・転送先はドメイン単位で指定でき（条件付きフォワーディング）、AD DCやオ ンプレDNSの「転送設定」もこの一種 ポイント：AWSでも、Route 53 ResolverのInbound/Outboundエンドポイントや条件付き転 送ルール（Resolver Rule）は、VPCとオンプレミス・他クラウド間の名前解決を橋渡しする、 まさに「DNSフォワーダー」の考え方そのもの # Page. 6 ![Page Image](https://bcdn.docswell.com/page/KJ4W1QWZ71.jpg) 前提知識③ Amazon Provided DNSの制約 Amazon Provided DNS（VPC+2）：VPCが自動提供するDNSリゾルバー ・VPCのCIDRブロックの先頭から2番目のIPアドレスで応答 ・VPC内のプライベートホストゾーンやパブリックDNSの名前解決を無料で提供 ・現在の正式名称は、Route 53 VPC Resolver 重要な制約： 同一VPC内からしかアクセスできない VPCの外部（オンプレミスや他クラウド）から直接問い合わせることはできない 5 # Page. 7 ![Page Image](https://bcdn.docswell.com/page/LE1YGPYD7G.jpg) 環境構成 AWS VPC 他社クラウド オンプレミス DNSフォワーダー DNSフォワーダー AD DC AD DC EC2上のAD DC DNSクエリ 実際の通信 NAT Gateway Internet Gateway インターネット Amazon Provided DNS (VPC+2 / 同一VPC内限定) Public DNS # Page. 8 ![Page Image](https://bcdn.docswell.com/page/GEWGK2G8J2.jpg) 発生した事象①：メンテナンスで停止したら… ・AWS上のEC2で稼働していたAD DC（1台のみ）をメンテナンス目的で 停止 ・その結果、他社クラウドおよびオンプレミス拠点からインターネットへ の名前解決ができなくなった 影響範囲： オンプレミス／他社クラウドの両拠点から、外部（インターネット）の名前解決が全断 7 # Page. 9 ![Page Image](https://bcdn.docswell.com/page/47ZLZDL9J3.jpg) 発生した事象②：内部の名前解決は無事 ・社内ドメインなど内部の名前解決は、AD統合ゾーンのレプリケーション により他拠点のAD DCが応答を継続 ・そのため内部通信への影響はなかった AD統合ゾーンとは ・DNSのゾーン情報をADのデータベース自体に格納する仕組み ・複数のAD DC間で自動的にレプリケーションされ、どのAD DCでも同じゾーン 情報を参照できる ・そのため内部の名前解決（社内ドメイン名の解決）は特定の1台に依存しない 8 # Page. 10 ![Page Image](https://bcdn.docswell.com/page/YJ6WZ1WDJV.jpg) 原因分析：外部名前解決は1台に依存していた ✕ オンプレミス／他社 DNSフォワーダー EC2上のAD DC (停止中) Amazon Provided DNS (VPC+2) インターネット ・AWS(VPC)外部からAmazon Provided DNSの名前解決は不可 ・外部名前解決は「EC2上のAD DC 1台」に完全依存した構成になっていた ・内部（AD統合ゾーン）は冗長化されていたが、外部名前解決の経路だけは冗長化され ていなかった 9 # Page. 11 ![Page Image](https://bcdn.docswell.com/page/GJ5MW4M8J4.jpg) 解決策：Route 53 Resolver Inbound Endpoint ・Inbound Endpoint：VPC外部（オンプレミスや他クラウド）からのDNSク エリを受け付ける入り口 ・複数のAZにまたがるENI（Elastic Network Interface）で構成される ・他拠点のDNSフォワーダーの参照先を、EC2上のAD DCからInbound EndpointのIPに変更 これにより「AWS外からDNSの名前解決ができる構成」に変わる 10 # Page. 12 ![Page Image](https://bcdn.docswell.com/page/LE3W4GWGE5.jpg) 導入後の構成とポイント オンプレミス 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 # Page. 13 ![Page Image](https://bcdn.docswell.com/page/8EDKQ1KN7G.jpg) その他の対策案と料金比較 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 # Page. 14 ![Page Image](https://bcdn.docswell.com/page/V7PKLQKNJ8.jpg) 残る課題：マルチクラウドの利点を活かせない ・ここまでの3つの対策案には共通点がある：いずれも「AWS経由でインターネ ットへの名前解決をさせる」前提 ・外部名前解決という重要な機能が、実質的にAWS単独の可用性に依存してし まう ・マルチクラウドを採用している意義の一部が薄れてしまう、という論点が残る 13 # Page. 15 ![Page Image](https://bcdn.docswell.com/page/2JVVQ5VYJQ.jpg) 追加の検討案：パブリックDNSの併用 ・各拠点のDNSフォワーダーに、AWS以外のパブリックDNS （例：Google Public DNS 8.8.8.8）を追加する案 ・AWS側に障害が発生しても、他拠点は独立して外部名前解決を継続できる ただし、以下に注意が必要 ・セキュリティ／監査ログ：外部DNSへの問い合わせを許可していない組織では採用しづらい ・スプリットホライズンDNSとの整合性：想定外のゾーンが公開DNSに転送されるリスク ・可用性設計の一貫性：既存対策と併用する場合、フォワーダーの優先順位設計が必要 14 # Page. 16 ![Page Image](https://bcdn.docswell.com/page/5EGLW6LWJL.jpg) まとめ ・AWS(VPC)外部からAmazon Provided DNSの名前解決は不可 ・外部からの名前解決をするには Route 53 Resolver Inbound Endpointの導入が必要 15 # Page. 17 ![Page Image](https://bcdn.docswell.com/page/4JQY34YQ7P.jpg) 参考リンク ・「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 # Page. 18 ![Page Image](https://bcdn.docswell.com/page/K74W1QWYE1.jpg) ご清聴ありがとうございました。 資料は下記に公開しています。 https://www.docswell.com/user/mkymdk ※本スライドの内容は個人の見解であり、 所属組織とは無関係です。