Azure に共有サービスを含むハブスポーク ネットワーク トポロジHub-spoke network topology with shared services in Azure

この参照アーキテクチャは、ハブスポーク参照アーキテクチャに基づいて作成されており、すべてのスポークで利用できる共有サービスがハブに含まれます。This reference architecture builds on the hub-spoke reference architecture to include shared services in the hub that can be consumed by all spokes.

データセンターをクラウドに移行するための最初の手順として、共有する必要のある最初のサービスは ID とセキュリティです。As a first step toward migrating a datacenter to the cloud, the first services that need to be shared are identity and security. この参照アーキテクチャは、Active Directory サービスをオンプレミスのデータセンターから Azure に拡張する方法と、ファイアウォールとして動作可能なネットワーク仮想アプライアンス (NVA) を追加する方法を示しています。This reference architecture shows how to extend Active Directory services from your on-premises datacenter to Azure, and how to add a network virtual appliance (NVA) that can act as a firewall. ファイアウォール機能は、クラウドベースのネットワーク セキュリティ サービスである Azure Firewall を使用して実行することもできます。The firewall functionality can also be accomplished using Azure Firewall, a cloud-based network security service.

Azure での共有サービス トポロジ

このアーキテクチャの Visio ファイルをダウンロードしますDownload a Visio file of this architecture

このトポロジの利点は次のとおりです。The benefits of this topology include:

  • コストの削減: 複数のワークロードを共有するサービス (ネットワーク仮想アプライアンス (NVA) や DNS サーバーなど) を 1 か所に集めます。Cost savings by centralizing services that can be shared by multiple workloads, such as network virtual appliances (NVAs) and DNS servers, in a single location.
  • サブスクリプション数の上限の解消: 中央のハブに別のサブスクリプションから VNet をピアリングします。Overcome subscriptions limits by peering VNets from different subscriptions to the central hub.
  • 問題の分離: 中央の IT (SecOps、InfraOps) とワークロード (DevOps) の間で実施します。Separation of concerns between central IT (SecOps, InfraOps) and workloads (DevOps).

このアーキテクチャの一般的な用途は次のとおりです。Typical uses for this architecture include:

  • DNS、IDS、NTP、AD DS などの共有サービスを必要とするさまざまな環境 (開発、テスト、運用など) でデプロイされるワークロード。Workloads deployed in different environments, such as development, testing, and production, that require shared services such as DNS, IDS, NTP, or AD DS. 共有サービスはハブ VNet に配置され、分離性を維持するために各環境はスポークにデプロイされます。Shared services are placed in the hub VNet, while each environment is deployed to a spoke to maintain isolation.
  • 相互接続が不要であり、共有サービスへのアクセスは必要なワークロード。Workloads that do not require connectivity to each other, but require access to shared services.
  • セキュリティ要素 (DMZ としてのハブのファイアウォールなど) の一元管理、および各スポークにおけるワークロードの分別管理が必要なエンタープライズ。Enterprises that require central control over security aspects, such as a firewall in the hub as a DMZ, and segregated management for the workloads in each spoke.

ArchitectureArchitecture

アーキテクチャは、次のコンポーネントで構成されます。The architecture consists of the following components.

  • オンプレミス ネットワークOn-premises network. 組織内で運用されているプライベートのローカル エリア ネットワーク。A private local-area network running within an organization.

  • VPN デバイスVPN device. オンプレミス ネットワークへの外部接続を提供するデバイスまたはサービス。A device or service that provides external connectivity to the on-premises network. VPN デバイスには、ハードウェア デバイス、または Windows Server 2012 のルーティングとリモート アクセス サービス (RRAS) などのソフトウェア ソリューションがあります。The VPN device may be a hardware device, or a software solution such as the Routing and Remote Access Service (RRAS) in Windows Server 2012. サポートされている VPN アプライアンスの一覧と、Azure への接続用に選択した VPN アプライアンスの構成については、「サイト間 VPN ゲートウェイ接続用の VPN デバイスと IPsec/IKE パラメーターについて」を参照してください。For a list of supported VPN appliances and information on configuring selected VPN appliances for connecting to Azure, see About VPN devices for Site-to-Site VPN Gateway connections.

  • VPN 仮想ネットワーク ゲートウェイまたは ExpressRoute ゲートウェイVPN virtual network gateway or ExpressRoute gateway. 仮想ネットワーク ゲートウェイでは、オンプレミス ネットワークとの接続に使用する VPN デバイス (ExpressRoute 回線) に VNet を接続できます。The virtual network gateway enables the VNet to connect to the VPN device, or ExpressRoute circuit, used for connectivity with your on-premises network. 詳細については、「オンプレミス ネットワークを Microsoft Azure 仮想ネットワークに接続する」を参照してください。For more information, see Connect an on-premises network to a Microsoft Azure virtual network.

注意

この参照アーキテクチャのデプロイ スクリプトでは、VPN ゲートウェイを使用して接続し、Azure の VNet を使用してオンプレミス ネットワークをシミュレートします。The deployment scripts for this reference architecture use a VPN gateway for connectivity, and a VNet in Azure to simulate your on-premises network.

  • ハブ VNetHub VNet. ハブスポーク トポロジのハブとして使用する Azure VNet。Azure VNet used as the hub in the hub-spoke topology. ハブは、オンプレミス ネットワークへの主要な接続ポイントであり、スポーク VNet でホストされるさまざまなワークロードによって消費できるサービスをホストする場所です。The hub is the central point of connectivity to your on-premises network, and a place to host services that can be consumed by the different workloads hosted in the spoke VNets.

  • ゲートウェイ サブネットGateway subnet. 仮想ネットワーク ゲートウェイは、同じサブネット内に保持されます。The virtual network gateways are held in the same subnet.

  • 共有サービス サブネットShared services subnet. DNS や AD DS など、すべてのスポーク間で共有できるサービスをホストするために使用されるハブ VNet 内のサブネットです。A subnet in the hub VNet used to host services that can be shared among all spokes, such as DNS or AD DS.

  • DMZ サブネットDMZ subnet. ファイアウォールなどの、セキュリティ アプライアンスとして動作できる NVA をホストするために使用されるハブ VNet のサブネットです。A subnet in the hub VNet used to host NVAs that can act as security appliances, such as firewalls.

  • スポーク VNetSpoke VNets. ハブスポーク トポロジでスポークとして使用される 1 つ以上の Azure VNet です。One or more Azure VNets that are used as spokes in the hub-spoke topology. スポークを使用すると、独自の VNet にワークロードを分離して、その他のスポークから個別に管理できます。Spokes can be used to isolate workloads in their own VNets, managed separately from other spokes. 各ワークロードには複数の階層が含まれる場合があります。これらの階層には、Azure ロード バランサーを使用して接続されている複数のサブネットがあります。Each workload might include multiple tiers, with multiple subnets connected through Azure load balancers. アプリケーション インフラストラクチャの詳細については、「Windows VM ワークロードの実行」と「Linux VM ワークロードの実行を参照してください。For more information about the application infrastructure, see Running Windows VM workloads and Running Linux VM workloads.

  • VNet ピアリングVNet peering. ピアリング接続を使用して、2 つの VNet を接続できます。Two VNets can be connected using a peering connection. ピアリング接続は、VNet 間の待機時間の短い非推移的な接続です。Peering connections are non-transitive, low latency connections between VNets. ピアリングが完了すると、VNet は、ルーターがなくても Azure のバックボーンを使用してトラフィックを交換します。Once peered, the VNets exchange traffic by using the Azure backbone, without the need for a router. ハブスポーク ネットワーク トポロジでは、VNet ピアリングを使用して、ハブを各スポークに接続します。In a hub-spoke network topology, you use VNet peering to connect the hub to each spoke. 同じリージョンまたは異なるリージョンの仮想ネットワークをピアリングできます (グローバル VNet ピアリング)。You can peer virtual networks in the same region, or different regions (Global VNet Peering). 詳細については、「要件と制約」を参照してください。For more information, see Requirements and constraints.

注意

この記事で説明するのは Resource Manager のデプロイのみですが、クラシック VNet を同じサブスクリプションの Resource Manager VNet に接続することもできます。This article only covers Resource Manager deployments, but you can also connect a classic VNet to a Resource Manager VNet in the same subscription. これにより、クラシック デプロイ をスポークでホストして、ハブで共有するサービスのメリットを引き続き得ることができます。That way, your spokes can host classic deployments and still benefit from services shared in the hub.

RecommendationsRecommendations

ハブスポーク参照アーキテクチャのすべての推奨事項が、共有サービスの参照アーキテクチャにも適用されます。All the recommendations for the hub-spoke reference architecture also apply to the shared services reference architecture.

また、共有サービスのほとんどのシナリオには、次の推奨事項が適用されます。Also, the following recommendations apply for most scenarios under shared services. これらの推奨事項には、オーバーライドする特定の要件がない限り、従ってください。Follow these recommendations unless you have a specific requirement that overrides them.

IDIdentity

ほとんどの企業組織のオンプレミス データセンターには Active Directory Domain Services (AD DS) 環境があります。Most enterprise organizations have an Active Directory Domain Services (AD DS) environment in their on-premises datacenter. AD DS に依存しているオンプレミスのネットワークから Azure に移動される資産の管理を容易にするには、Azure で AD DS ドメイン コントローラーをホストすることをお勧めします。To facilitate management of assets moved to Azure from your on-premises network that depend on AD DS, it is recommended to host AD DS domain controllers in Azure.

Azure とオンプレミスの環境を別々に管理するグループ ポリシー オブジェクトを使用する場合は、Azure リージョンごとに別の AD サイトを使用します。If you use Group Policy Objects, that you want to control separately for Azure and your on-premises environment, use a different AD site for each Azure region. 依存するワークロードがアクセスできる中心の VNet (ハブ) に、ドメイン コントローラーを配置します。Place your domain controllers in a central VNet (hub) that dependent workloads can access.

SecuritySecurity

オンプレミスの環境から Azure にワークロードを移動すると、これらのワークロードの一部を VM でホストする必要があります。As you move workloads from your on-premises environment to Azure, some of these workloads will require to be hosted in VMs. コンプライアンス上の理由から、これらのワークロードを通過するトラフィックを制限することが必要になる場合があります。For compliance reasons, you may need to enforce restrictions on traffic traversing those workloads.

Azure では、ネットワーク仮想アプライアンス (NVA) を使用して、さまざまな種類のセキュリティおよびパフォーマンス サービスをホストできます。You can use network virtual appliances (NVAs) in Azure to host different types of security and performance services. 現在、オンプレミスで特定のアプライアンスのセットを使い慣れている場合は、可能であれば、Azure で同じ仮想アプライアンスを使用することをお勧めします。If you are familiar with a given set of appliances on-premises today, it is recommended to use the same virtualized appliances in Azure, where applicable.

注意

この参照アーキテクチャのデプロイ スクリプトでは、IP 転送が有効な Ubuntu VM を使用してネットワーク仮想アプライアンスを模倣します。The deployment scripts for this reference architecture use an Ubuntu VM with IP forwarding enabled to mimic a network virtual appliance.

コストに関する考慮事項Cost considerations

この参照アーキテクチャは、ハブスポーク参照アーキテクチャに基づいて構築されています。This reference architecture builds on the hub-spoke reference architecture. これには、すべてのスポークで使用できるハブ内の共有サービスが含まれます。It includes shared services in the hub that can be consumed by all spokes. たとえば、複数のワークロードで使用される共有サービスとして Active Directory ドメイン サービスを使用するとコスト効率が高くなります。For example, having Active Directory Domain services as a shared service consumed by multiple workloads is cost effective. 価格情報については、AD DS 価格に関するページをご覧ください。See AD DS pricing for pricing info.

コストに関するその他の考慮事項については、ハブスポーク ネットワーク トポロジ - コストに関する考慮事項に関するページをご覧ください。For other cost considerations, see Hub-spoke network topology - cost considerations.

ソリューションのデプロイ方法Deploy the solution

このアーキテクチャのデプロイについては、GitHub を参照してください。A deployment for this architecture is available on GitHub. デプロイによってサブスクリプション内に作成されるリソース グループは、次のとおりです。The deployment creates the following resource groups in your subscription:

  • hub-adds-rghub-adds-rg
  • hub-nva-rghub-nva-rg
  • hub-vnet-rghub-vnet-rg
  • onprem-vnet-rgonprem-vnet-rg
  • spoke1-vnet-rgspoke1-vnet-rg
  • spoke2-vnet-rgspoke2-vnet-rg

テンプレート パラメーター ファイルは、これらの名前を参照します。したがって、名前を変更する場合は、それに合わせてパラメーター ファイルも更新します。The template parameter files refer to these names, so if you change them, update the parameter files to match.

前提条件Prerequisites

  1. 参照アーキテクチャ GitHub リポジトリに ZIP ファイルを複製、フォーク、またはダウンロードします。Clone, fork, or download the zip file for the reference architectures GitHub repository.

  2. Azure CLI 2.0 をインストールします。Install Azure CLI 2.0.

  3. ノードと NPM をインストールするInstall Node and NPM

  4. Azure の構成要素 npm パッケージをインストールします。Install the Azure building blocks npm package.

    npm install -g @mspnp/azure-building-blocks
    
  5. コマンド プロンプト、bash プロンプト、または PowerShell プロンプトから、次のように Azure アカウントにサインインします。From a command prompt, bash prompt, or PowerShell prompt, sign into your Azure account as follows:

    az login
    

シミュレートされたオンプレミスのデータセンターを azbb を使用してデプロイするDeploy the simulated on-premises datacenter using azbb

このアーキテクチャをデプロイするには、次の手順を実行します。Follow these steps to deploy the architecture:

  1. GitHub リポジトリの hybrid-networking\shared-services-stack\ フォルダーに移動します。Navigate to the hybrid-networking\shared-services-stack\ folder of the GitHub repository.

  2. shared-services-stack.json ファイルを開きます。Open the shared-services-stack.json file.

  3. [replace-with-username][replace-with-safe-mode-username][replace-with-password]、および [replace-with-safe-mode-password] のすべてのインスタンスを検索します。Search for all instances of [replace-with-username], [replace-with-safe-mode-username],[replace-with-password], and [replace-with-safe-mode-password]. パラメーターにユーザー名とパスワードの値を入力し、ファイルを保存します。Enter values for the user name and password in the parameters and save the file.

  4. [replace-with-shared-key] のすべてのインスタンスを検索し、共有キーの値を入力します。Search for all instances of [replace-with-shared-key] and enter a value for a shared key. 値は一致する必要があります。The values must match.

  5. ファイルを保存します。Save the file.

  6. 次のコマンドを実行します。Run the following command:

    azbb -s <subscription_id> -g onprem-vnet-rg -l <location> -p shared-services-stack.json --deploy
    
  7. デプロイが完了するのを待機します。Wait for the deployment to finish. このデプロイで、4 つの仮想ネットワーク、ジャンプ ボックスとして機能する 4 つの仮想マシン、Active Directory ドメイン コントローラーとして動作する 4 つの仮想マシン、2 つの VPN ゲートウェイ、および Azure Firewall が作成されます。This deployment creates four virtual networks, four virtual machines to function as jumpboxes, four virtual machines to act as Active Directory domain controllers, two VPN Gateways, and Azure Firewall. VPN ゲートウェイの作成の完了には 40 分以上かかる場合があります。The VPN gateway creation can take more than 40 minutes to complete.

接続をテストするTest connectivity

シミュレートされたオンプレミスの環境からハブ VNet への接続をテストします。Test connectivity from the simulated on-premises environment to the hub VNet.

  1. Azure Portal を使用して、onprem-jb-rg リソース グループで jb-vm1 という名前の VM を見つけます。Use the Azure portal to find the VM named jb-vm1 in the onprem-jb-rg resource group.

  2. Connect をクリックして、VM に対するリモート デスクトップ セッションを開きます。Click Connect to open a remote desktop session to the VM. onprem.json パラメーター ファイルで指定したパスワードを使用します。Use the password that you specified in the onprem.json parameter file.

  3. VM で PowerShell コンソールを開き、Test-NetConnection コマンドレットを使用して、ハブ VNet の ジャンプボックス VM に接続できることを確認します。Open a PowerShell console in the VM, and use the Test-NetConnection cmdlet to verify that you can connect to the jumpbox VM in the hub VNet.

    Test-NetConnection 10.0.0.36 -CommonTCPPort RDP
    

出力は次のようになります。The output should look similar to the following:

ComputerName     : 10.0.0.36
RemoteAddress    : 10.0.0.36
RemotePort       : 3389
InterfaceAlias   : Ethernet 2
SourceAddress    : 192.168.1.000
TcpTestSucceeded : True

注意

既定で、Windows Server VM では Azure の ICMP 応答が許可されていません。By default, Windows Server VMs do not allow ICMP responses in Azure. 接続のテストに ping を使用する場合は、VM ごとに Windows の高度なファイアウォールで ICMP トラフィックを有効にする必要があります。If you want to use ping to test connectivity, you need to enable ICMP traffic in the Windows Advanced Firewall for each VM.

スポーク VNet への接続をテストするには、同じ手順を繰り返します。Repeat the same steps to test connectivity to the spoke VNets:

Test-NetConnection 10.1.0.36 -CommonTCPPort RDP
Test-NetConnection 10.2.0.36 -CommonTCPPort RDP