この参照アーキテクチャは、オンプレミスおよび Microsoft Azure でホストされているワークロードの名前を解決するためのハイブリッド ドメイン ネーム システム (DNS) ソリューションを設計する方法を示しています。 このアーキテクチャは、オンプレミスおよびパブリック インターネットから接続しているユーザーおよびその他のシステムに対して機能します。
アーキテクチャ
このアーキテクチャの Visio ファイルをダウンロードします。
ワークフロー
アーキテクチャは、次のコンポーネントで構成されています。
- オンプレミス ネットワーク。 オンプレミス ネットワークは、Azure ExpressRoute または仮想プライベート ネットワーク (VPN) 接続を介して Azure に接続されている単一のデータセンターを表します。 このシナリオでは、次のコンポーネントによってオンプレミス ネットワークが構成されています。
- DNS サーバー。 これらのサーバーは、リゾルバーまたはフォワーダーとして機能する、DNS サービスがインストールされている 2 台のサーバーを表します。 これらの DNS サーバーは、オンプレミス ネットワーク内のすべてのコンピューターに DNS サーバーとして使用されます。 Azure とオンプレミスのすべてのエンドポイントについて、これらのサーバーにレコードを作成する必要があります。
- ゲートウェイ。 ゲートウェイは、Azure への接続に使用される VPN デバイスまたは ExpressRoute 接続を表します。
- ハブ サブスクリプション。 ハブ サブスクリプションは、Azure でホストされる複数のワークロード間で共有される接続、管理、およびネットワーク リソースをホストするために使用される Azure サブスクリプションを表します。 これらのリソースは、エンタープライズ規模のアーキテクチャに関するページで説明されているように、複数のサブスクリプションに分けることができます。
注意
ハブ仮想ネットワークは、仮想ワイド エリア ネットワーク (WAN) ハブに置き換えることができます。その場合、DNS サーバーは、別の Azure 仮想ネットワーク (VNet) でホストする必要があります。 エンタープライズ規模のアーキテクチャでは、その VNet は、ID サブスクリプションという名前の独自のサブスクリプションに保持されます。
- Azure Bastion サブネット。 ハブ仮想ネットワーク内の Azure Bastion サービスは、メンテナンスのためにパブリック インターネットからハブおよびスポーク VNet の仮想マシン (VM) へのリモート処理を行うために使用されます。
- プライベート エンドポイント サブネット。 プライベート エンドポイント サブネットは、ハブとピアリングされていない VNet で、Azure でホストされているワークロードのプライベート エンドポイントをホストします。 この種類の切断された VNet では、その IP アドレスが、Azure とオンプレミスで使用される他の IP アドレスと競合することがあります。
- ゲートウェイ サブネット: ゲートウェイ サブネットは、オンプレミスのデータセンターに戻る接続を提供するために使用される Azure VPN ゲートウェイまたは ExpressRoute ゲートウェイをホストします。
- 共有サービス サブネット: 共有サービス サブネットは、複数の Azure ワークロード間で共有されるサービスをホストします。 このシナリオでは、このサブネットは、DNS サーバーとしても使用される、Windows または Linux を実行する仮想マシンをホストします。 これらの DNS サーバーは、オンプレミス サーバーと同じ DNS ゾーンをホストします。
- 接続されているサブスクリプション。 接続されているサブスクリプションは、仮想ネットワークとオンプレミス ネットワークへの接続を必要とするワークロードのコレクションを表します。
- VNet ピアリング: このコンポーネントは、ハブ VNet に戻るピアリング接続です。 この接続により、オンプレミス ネットワークからスポークへの接続と、ハブ VNet を経由して戻る接続が可能になります。
- 既定のサブネット。 既定のサブネットには、サンプルのワークロードが含まれています。
- web-vmss。 このサンプル仮想マシン スケール セットでは、オンプレミス、Azure、およびパブリック インターネットからアクセスできる、Azure のワークロードをホストします。
- ロード バランサー。 ロード バランサーは、一連の VM がホストするワークロードへのアクセスを提供します。 Azure およびオンプレミスのデータセンターからワークロードにアクセスするには、既定のサブネットにおけるこのロード バランサーの IP アドレスを使用する必要があります。
- AppGateway サブネット。 このサブネットは、Azure Application Gateway サービスに必要なサブネットです。
- AppGateway。 Application Gateway を使用すると、既定のサブネット内のサンプル ワークロードへのアクセスをパブリック インターネットのユーザーに提供できます。
- wkld1-pip。 このアドレスは、パブリック インターネットからサンプル ワークロードへのアクセスに使用されるパブリック IP アドレスです。
- 切断されたサブスクリプション。 切断されたサブスクリプションは、オンプレミス データセンターに戻る接続を必要とせず、プライベート リンク サービスを使用するワークロードのコレクションを表します。
- PLSSubnet。 プライベート リンク サービス サブネット (PLSSubnet) には、接続されているサブスクリプションでホストされているワークロードへの接続を提供する、1 つ以上のプライベート リンク サービス リソースが含まれています。
- 既定のサブネット。 既定のサブネットには、サンプルのワークロードが含まれています。
- web-vmss。 このサンプル仮想マシン スケール セットでは、オンプレミス、Azure、およびパブリック インターネットからアクセスできる、Azure のワークロードをホストします。
- ロード バランサー。 ロード バランサーは、一連の VM がホストするワークロードへのアクセスを提供します。 このロード バランサーは、Azure とオンプレミスのデータセンターからのユーザーにアクセスを提供するために、プライベート リンク サービスに接続されています。
- AppGateway サブネット。 このサブネットは、Application Gateway サービスに必要なサブネットです。
- AppGateway。 Application Gateway を使用すると、既定のサブネット内のサンプル ワークロードへのアクセスをパブリック インターネットのユーザーに提供できます。
- wkld2-pip。 このアドレスは、パブリック インターネットからサンプル ワークロードへのアクセスに使用されるパブリック IP アドレスです。
- Azure Bastion サブネット。 切断された仮想ネットワーク内の Azure Bastion サービスは、メンテナンスのためにパブリック インターネットからハブおよびスポーク VNet の VM へのリモート処理を行うために使用されます。
コンポーネント
Virtual Network。 Azure Virtual Network (VNet) は、Azure 内のプライベート ネットワークの基本的な構成要素です。 VNet により、Azure Virtual Machines (VM) などのさまざまな種類の Azure リソースが、他の Azure リソース、インターネット、およびオンプレミスのネットワークと安全に通信することができます。
Azure Bastion。 Azure Bastion は、パブリック IP アドレスを介して公開されることなく、仮想マシン (VM) へのより安全でシームレスなリモート デスクトップ プロトコル (RDP) および Secure Shell プロトコル (SSH) アクセスを提供するフル マネージド サービスです。
VPN Gateway。 VPN Gateway は、Azure 仮想ネットワークとオンプレミスの場所の間で、パブリック インターネットを介して暗号化されたトラフィックを送信します。 VPN Gateway を使用すると、Microsoft ネットワークを経由して Azure 仮想ネットワーク間で暗号化されたトラフィックを送信することもできます。 VPN ゲートウェイは仮想ネットワーク ゲートウェイの特定の種類です。
Private Link。 Azure Private Link により、仮想ネットワークから Azure のサービスとしてのプラットフォーム (PaaS)、お客様の所有するサービス、または Microsoft パートナーの各サービスへのプライベート接続が可能になります。 ネットワーク アーキテクチャが簡素化され、パブリック インターネットへのデータの公開をなくすことで Azure でのエンドポイント間の接続がセキュリティで保護されます。
Application Gateway。 Azure Application Gateway は、Web アプリケーションに対するトラフィックを管理できる Web トラフィック ロード バランサーです。 従来のロード バランサーはトランスポート レイヤー (OSI レイヤー 4 - TCP と UDP) で動作し、送信元 IP アドレスとポートに基づくトラフィックを送信先 IP アドレスとポートにルーティングします。
Recommendations
ほとんどのシナリオには、次の推奨事項が適用されます。 これらの推奨事項には、オーバーライドする特定の要件がない限り、従ってください。
注意
以下の推奨事項では、接続されているワークロードをワークロード 1 と表記し、切断されたワークロードをワークロード 2 と表記します。 また、これらのワークロードにアクセスするユーザーおよびシステムを、オンプレミス ユーザー、インターネット ユーザー、および Azure システムと表記します。
AD DS を Azure に拡張する (オプション)
オンプレミスのデータセンターと Azure の DNS レコードをホストするには、AD DS の統合 DNS ゾーンを使用します。 このシナリオでは、AD DS DNS サーバーの 2 つのセットがあります。1 つはオンプレミス、もう 1 つはハブ VNet 内にあります。
AD DS ドメインを Azure に拡張することをお勧めします。 また、Azure 内のすべての VM に対してハブ VNet の AD DS DNS サーバーを使用するには、ハブおよびスポーク VNet を構成することもお勧めします。
注意
この推奨事項は、名前解決に Active Directory 統合 DNS ゾーンを使用する組織にのみ適用されます。 それ以外の場合は、リゾルバーまたはフォワーダーとして機能する DNS サーバーの実装を検討できます。
スプリットブレイン DNS を構成する
Azure システム、オンプレミス ユーザー、インターネット ユーザーがどこから接続しているかに基づいてワークロードにアクセスできるように、スプリットブレイン DNS を確実に配置します。
接続されている、および切断されたワークロードの両方で、DNS 解決には以下のコンポーネントをお勧めします。
- インターネット ユーザーには、Azure DNS ゾーン。
- オンプレミス ユーザーと Azure システムには、DNS サーバー。
- Azure VNet 間の解決には、Azure プライベート DNS ゾーン。
このスプリットブレインの推奨事項について理解を深めるには、ワークロード 1 を検討してください。この場合は、wkld1.contoso.com 完全修飾ドメイン名 (FQDN) を使用します。
このシナリオでは、インターネット ユーザーがその名前を、Application Gateway が Wkld1-pip から公開するパブリック IP アドレスに解決する必要があります。 この解決を行うには、接続されているサブスクリプションに対して、Azure DNS でアドレス レコード (A レコード) を作成します。
オンプレミスのユーザーは、同じ名前を、接続されているサブスクリプションのロード バランサーの内部 IP アドレスに解決する必要があります。 この解決を行うには、ハブ サブスクリプションで DNS サーバーに A レコードを作成します。
Azure システムは同じ名前を、接続されているサブスクリプションのロード バランサーの内部 IP アドレスに解決できます。そのためには、ハブ サブスクリプションの DNS サーバーに A レコードを作成するか、プライベート DNS ゾーンを使用します。 プライベート DNS ゾーンを使用している場合は、プライベート DNS ゾーンに A レコードを手動で作成するか、自動登録を有効にします。
プライベート リンクにプライベート DNS ゾーンを使用する
このシナリオでは、切断されたサブスクリプションでワークロード 2 がホストされており、オンプレミス ユーザーおよび接続されている Azure システムによるこのワークロードへのアクセスは、ハブ VNet のプライベート エンドポイントを介して可能になります。 ただし、このワークロードには 3 つ目の接続の可能性があります。それは、ワークロード 2 と同じ VNet 内の Azure システムです。
ワークロード 2 に対する DNS の推奨事項について理解を深めるために、wkld2.contoso.com FQDN を使用し、個々の推奨事項について説明します。
このシナリオでは、インターネット ユーザーがその名前を、Application Gateway によって Wkld2-pip を通じて公開されるパブリック IP アドレスに解決する必要があります。 この解決を行うには、接続されているサブスクリプションの Azure DNS で、A レコードを作成します。
ハブ VNet およびスポーク VNet に接続されているオンプレミス ユーザーと Azure システムは、同じ名前を、ハブ VNet のプライベート エンドポイントの内部 IP アドレスに解決する必要があります。 この解決を行うには、ハブ サブスクリプションで DNS サーバーに A レコードを作成します。
Workload 2 と同じ VNet 内の Azure システムは、名前を、切断されたサブスクリプションのロード バランサーの IP アドレスに解決する必要があります。 この解決を行うには、そのサブスクリプションの Azure DNS でプライベート DNS ゾーンを使用します。
異なる VNet にある Azure システムでも、それらの VNet を、ワークロード 2 の A レコードをホストしているプライベート DNS ゾーンとリンクすれば、ワークロード 2 の IP アドレスを解決できます。
自動登録を有効にする
プライベート DNS ゾーンを使用して VNet リンクを構成する場合は、必要に応じて、すべての仮想マシンに対する自動登録を構成できます。
注意
自動登録は、仮想マシンに対してのみ機能します。 VNet から IP アドレスを使用して構成されるその他すべてのリソースについては、プライベート DNS ゾーンで DNS レコードを手動で作成する必要があります。
AD DS DNS サーバーを使用している場合は、AD DS DNS サーバーで独自の DNS レコードを最新の状態で維持するために、Windows コンピューターの動的更新を使用できるよう Windows VM を構成します。 動的更新を有効にし、セキュリティで保護された更新のみを許可するように DNS サーバーを構成することをお勧めします。
Linux VM は、セキュリティで保護された動的更新をサポートしていません。 オンプレミスの Linux コンピューターの場合は、動的ホスト構成プロトコル (DHCP) を使用して、DNS レコードを AD DS DNS サーバーに登録します。
Azure での Linux VM の場合は、自動化されたプロセスを使用します。
考慮事項
以降の考慮事項には、ワークロードの品質向上に使用できる一連の基本原則である Azure "Well-Architected Framework" の要素が組み込まれています。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。
スケーラビリティ
- Azure リージョンごとまたはオンプレミスのデータセンターごとに、少なくとも 2 つの DNS サーバーを使用することを検討してください。
- 前のシナリオで、オンプレミスおよびハブ仮想ネットワークの DNS サーバーを使用して、これをどのように行ったかを確認してください。
可用性
- DNS サーバーの配置を検討します。 スケーラビリティに関する考慮事項のセクションで説明したように、DNS サーバーは、このサーバーへのアクセスを必要とするユーザーおよびシステムの近くに配置する必要があります。
- Azure リージョンごとに。 各 Azure リージョンには、独自のハブ VNet または vWAN ハブがあります。 ここに、DNS サーバーをデプロイする必要があります。
- オンプレミスのデータセンターごと。 また、オンプレミスのデータセンターごとに、それらの場所のユーザーおよびシステムのために DNS サーバーのペアが必要です。
- 分離された (切断された) ワークロードの場合は、スプリットブレイン DNS レコードを管理するために、各サブスクリプションのプライベート DNS ゾーンとパブリック DNS ゾーンをホストします。
管理の容易性
- サービスとしてのプラットフォーム (PaaS) サービスの DNS レコードの必要性を検討します。
- また、プライベート エンドポイントを使用する PaaS サービスの DNS 解決を検討する必要もあります。 そのためにプライベート DNS ゾーンを使用し、DNS サーバーにレコードを作成するために DevOps パイプラインを使用します。
セキュリティ
セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。 詳細については、「セキュリティの重要な要素の概要」を参照してください。
- DNSSEC を使用する必要がある場合、現在はそれが Azure DNS でサポートされていないことを考慮してください。
- DNSSEC 検証のために、カスタム DNS サーバーをデプロイし、DNSEC 検証を有効にします。
- Azure DDoS Protection では、アプリケーションの設計に関するベスト プラクティスと組み合わせることにより、DDoS 攻撃からの保護を向上させるための強化された DDoS 軽減機能が提供されます。 すべての境界仮想ネットワークで Azure DDOS Protection を有効にする必要があります。
DevOps
- すべてのリソースを構成するために Azure Resource Manager テンプレートを組み合わせることによって、このアーキテクチャの構成を自動化します。 プライベートとパブリックの両方の DNS ゾーンでは、Azure CLI、PowerShell、.NET、REST API からの完全な管理がサポートされています。
- 継続的インテグレーションと継続的開発 (CI/CD) パイプラインを使用して、Azure とオンプレミスのワークロードをデプロイおよび管理する場合は、DNS レコードの自動登録を構成することもできます。
コストの最適化
コストの最適化とは、不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳しくは、コスト最適化の柱の概要に関する記事をご覧ください。
- Azure DNS ゾーンのコストは、Azure でホストされている DNS ゾーンの数と、受信される DNS クエリの数に基づきます。
- コストの見積もりには、Azure 料金計算ツールをご利用ください。 Azure DNS の価格モデルについては、こちらで説明されています。
- Azure ExpressRoute の課金モデルは、従量制課金データ (アウトバウンド データ転送では、ギガバイト単位で課金されます)、または無制限データ (すべてのデータ転送を含む月額料金が課金されます) に基づいています。
- ExpressRoute ではなく VPN を使用している場合、コストは仮想ネットワーク ゲートウェイの SKU に依存し、時間単位で課金されます。
次のステップ
コンポーネントのテクノロジの詳細については、次を参照してください。
関連リソース
次の関連するアーキテクチャを確認してください。