ネットワーク トポロジと接続Network topology and connectivity

この記事では、Microsoft Azure との間や、その内部でのネットワークと接続に関する主要な設計上の考慮事項と推奨事項について説明します。This article examines key design considerations and recommendations surrounding networking and connectivity to, from, and within Microsoft Azure.

IP アドレス指定を計画するPlan for IP addressing

組織では、オンプレミスの場所と Azure リージョンの間で IP アドレス空間が重複しないように、Azure での IP アドレスを計画することが重要です。It's vital that your organization plans for IP addressing in Azure to ensure that IP address space doesn't overlap across on-premises locations and Azure regions.

設計上の考慮事項:Design considerations:

  • オンプレミスと Azure リージョンの間で IP アドレス空間が重複すると、競合の大きな問題が生じます。Overlapping IP address spaces across on-premises and Azure regions will create major contention challenges.

  • 仮想ネットワークを作成した後で、アドレス空間を追加できます。You can add address space after you create a virtual network. このプロセスでは、ピアリングを削除して再作成する必要があるため、既に仮想ネットワークが仮想ネットワーク ピアリングを使用して別の仮想ネットワークに接続されている場合、停止が必要になります。This process requires an outage if the virtual network is already connected to another virtual network via virtual network peering because the peering must be deleted and re-created.

  • Azure では、各サブネット内に 5 つの IP アドレスが予約されています。Azure reserves five IP addresses within each subnet. 仮想ネットワークとそれに含まれるサブネットのサイズを決定するときは、それを考慮してください。Factor in those addresses when you're sizing virtual networks and encompassed subnets.

  • 一部の Azure サービスでは、専用のサブネットが必要になります。Some Azure services require dedicated subnets. このようなサービスとしては、Azure Firewall や Azure VPN Gateway などがあります。These services include Azure Firewall and Azure VPN Gateway.

  • サブネットを特定のサービスにデリゲートして、サブネット内にサービスのインスタンスを作成することができます。You can delegate subnets to certain services to create instances of a service within the subnet.

設計上の推奨事項:Design recommendations:

  • Azure リージョンとオンプレミスの場所の間で、重複しない IP アドレス空間を事前に計画します。Plan for non-overlapping IP address spaces across Azure regions and on-premises locations well in advance.

  • プライベート インターネットに対するアドレス割り当てから IP アドレスを使用します (RFC 1918)。Use IP addresses from the address allocation for private internets (RFC 1918).

  • 使用できるプライベート IP アドレスに制限がある環境では (RFC 1918)、IPv6 の使用を検討します。For environments that have limited availability of private IP addresses (RFC 1918), consider using IPv6.

  • IP アドレス空間が無駄にならないよう、不必要に大きな仮想ネットワーク (例: /16) を作成しないでください。Don't create unnecessarily large virtual networks (for example, /16) to ensure that IP address space isn't wasted.

  • 前もって必要なアドレス空間を計画することなく仮想ネットワークを作成することはやめてください。Don't create virtual networks without planning the required address space in advance. アドレス空間を追加すると、仮想ネットワーク ピアリングを介して仮想ネットワークに接続した後で、停止が発生します。Adding address space will cause an outage after a virtual network is connected via virtual network peering.

  • 仮想ネットワークにはパブリック IP アドレスを使用しないでください。パブリック IP アドレスがお客様の組織に属していない場合は特にそうです。Don't use public IP addresses for virtual networks, especially if the public IP addresses don't belong to your organization.

オンプレミスと Azure のリソースに対して DNS と名前解決を構成するConfigure DNS and name resolution for on-premises and Azure resources

ドメイン ネーム システム (DNS) は、エンタープライズ規模のアーキテクチャ全体における重要な設計トピックです。Domain Name System (DNS) is a critical design topic in the overall enterprise-scale architecture. DNS への既存の投資を使用することを望む組織があります。Some organizations might want to use their existing investments in DNS. または、クラウドの導入を、内部 DNS インフラストラクチャを最新化し、Azure のネイティブ機能を使用する機会と考える組織もあります。Others might see cloud adoption as an opportunity to modernize their internal DNS infrastructure and use native Azure capabilities.

設計上の考慮事項:Design considerations:

  • DNS リゾルバーを Azure プライベート DNS と組み合わせて使用し、クロスプレミスの名前解決を実現できます。You can use a DNS resolver in conjunction with Azure Private DNS for cross-premises name resolution.

  • お客様は、オンプレミスと Azure の間で既存の DNS ソリューションの使用を必須とすることもできます。You might require the use of existing DNS solutions across on-premises and Azure.

  • 自動登録を使用して仮想ネットワークをリンクできるプライベート DNS ゾーンの最大数は 1 です。The maximum number of private DNS zones to which a virtual network can link with auto-registration is one.

  • 自動登録を有効にしないで仮想ネットワークをリンクできるプライベート DNS ゾーンの最大数は 1,000 です。The maximum number of private DNS zones to which a virtual network can link is 1,000 without auto-registration enabled.

設計上の推奨事項:Design recommendations:

  • Azure での名前解決だけが必要な環境の場合は、解決のための Azure プライベート DNS を使用します。For environments where name resolution in Azure is all that's required, use Azure Private DNS for resolution. 名前解決用にデリゲートされたゾーンを作成します (azure.contoso.com など)。Create a delegated zone for name resolution (such as azure.contoso.com).

  • Azure とオンプレミスの間で名前解決が必要な環境では、少なくとも 2 つの Azure 仮想マシン (VM) にデプロイされた既存の DNS インフラストラクチャ (たとえば Active Directory 統合 DNS) を使用します。For environments where name resolution across Azure and on-premises is required, use existing DNS infrastructure (for example, Active Directory integrated DNS) deployed onto at least two Azure virtual machines (VMs). それらの DNS サーバーを使用するように、仮想ネットワークで DNS の設定を構成します。Configure DNS settings in virtual networks to use those DNS servers.

  • その場合でも、Azure プライベート DNS ゾーンを仮想ネットワークにリンクし、オンプレミスの DNS サーバーを使用することで、オンプレミスの DNS 名 (onprem.contoso.com など) への条件付き転送によるハイブリッド リゾルバーとして、DNS サーバーを使用することができます。You can still link an Azure Private DNS zone to the virtual networks and use DNS servers as hybrid resolvers with conditional forwarding to on-premises DNS names, such as onprem.contoso.com, by using on-premises DNS servers. Azure プライベート DNS ゾーン (azure.contoso.com など) に対する Azure 内のリゾルバー VM への条件付きフォワーダーを使用して、オンプレミスのサーバーを構成できます。You can configure on-premises servers with conditional forwarders to resolver VMs in Azure for the Azure Private DNS zone (for example, azure.contoso.com).

  • 独自の DNS (Red Hat OpenShift など) をデプロイする必要がある特殊なワークロードでは、優先 DNS 解決を使用する必要があります。Special workloads that require and deploy their own DNS (such as Red Hat OpenShift) should use their preferred DNS solution.

  • 仮想ネットワーク内にデプロイされている仮想マシンの DNS レコードのライフサイクルを自動的に管理するには、Azure DNS に対する自動登録を有効にします。Enable auto-registration for Azure DNS to automatically manage the lifecycle of the DNS records for the virtual machines deployed within a virtual network.

  • Azure プライベート DNS でのクロスプレミスの DNS 解決には、リゾルバーとして仮想マシンを使用します。Use a virtual machine as a resolver for cross-premises DNS resolution with Azure Private DNS.

  • グローバル接続サブスクリプション内に Azure プライベート DNS ゾーンを作成します。Create the Azure Private DNS zone within a global connectivity subscription. 他の Azure プライベート DNS ゾーンを作成する場合があります (たとえば、Azure Private Link 用の privatelink.database.windows.netprivatelink.blob.core.windows.net)。You might create other Azure Private DNS zones (for example, privatelink.database.windows.net or privatelink.blob.core.windows.net for Azure Private Link).

Azure のネットワーク トポロジを定義するDefine an Azure network topology

ネットワーク トポロジは、アプリケーションの相互通信方法が定義されているため、エンタープライズ規模のアーキテクチャの重要な要素です。Network topology is a critical element of the enterprise-scale architecture because it defines how applications can communicate with each other. このセクションでは、エンタープライズ Azure デプロイのためのテクノロジとトポロジのアプローチについて説明します。This section explores technologies and topology approaches for enterprise Azure deployments. 2 つの主要なアプローチである、Azure Virtual WAN に基づくトポロジと従来のトポロジに焦点を当てます。It focuses on two core approaches: topologies based on Azure Virtual WAN, and traditional topologies.

次のいずれかに該当する場合は、Azure Virtual WAN に基づくネットワーク トポロジを使用します。Use a network topology based on Azure Virtual WAN if any of the following are true:

  • 組織は、複数の Azure リージョンにリソースをデプロイすることを予定しており、Azure とオンプレミスの両方にグローバルな場所から接続する必要がある。Your organization intends to deploy resources across several Azure regions and needs to connect your global locations to both Azure and on-premises.
  • 組織は、Azure と完全に統合されたソフトウェアによる WAN (SD-WAN) デプロイを使用することを予定している。Your organization intends to use software-defined WAN (SD-WAN) deployments fully integrated with Azure.
  • 1 つの Azure Virtual WAN ハブに接続されたすべての VNet で最大 2,000 の仮想マシン ワークロードをデプロイすることを予定している。You intend to deploy up to 2,000 virtual machine workloads across all VNets connected to a single Azure Virtual WAN hub.

Virtual WAN は、大規模な相互接続の要件を満たすために使用されます。Virtual WAN is used to meet large-scale interconnectivity requirements. Microsoft の管理サービスであるため、ネットワークの全体的な複雑さが軽減され、組織のネットワークの近代化にも役立ちます。Because it's a Microsoft-managed service, it also reduces overall network complexity and helps to modernize your organization's network.

次のいずれかに該当する場合は、従来の Azure ネットワーク トポロジを使用します。Use a traditional Azure network topology if any of the following are true:

  • 組織では、複数の Azure リージョンにわたってリソースをデプロイする予定である。Your organization intends to deploy resources across several Azure regions.
  • グローバル VNet ピアリングを使用して、Azure リージョン間で仮想ネットワークを接続できる。You can use global VNet peering to connect virtual networks across Azure regions.
  • リージョンあたりのリモートまたはブランチの場所が少ない。You have a low number of remote or branch locations per region. つまり、必要な IP セキュリティ (IPsec) トンネルが 30 未満である。That is, you need fewer than 30 IP security (IPsec) tunnels.
  • Azure ネットワークの手動構成を、完全にきめ細かく制御する必要がある。You require full control and granularity for manually configuring your Azure network.

従来のネットワーク トポロジは、Azure でセキュリティ保護された大規模なネットワークを構築するのに役立ちます。A traditional network topology helps you build a secure large-scale network in Azure.

Virtual WAN ネットワーク トポロジ (Microsoft 管理)Virtual WAN network topology (Microsoft-managed)

Virtual WAN ネットワーク トポロジを示す図。

"図 1:Virtual WAN のネットワーク トポロジ。Figure 1: Virtual WAN network topology.

設計上の考慮事項:Design considerations:

  • Azure Virtual WAN は Microsoft のマネージド ソリューションであり、エンド ツー エンドのグローバル トランジット接続が既定で提供されます。Azure Virtual WAN is a Microsoft-managed solution that provides end-to-end global transit connectivity by default. Virtual WAN ハブにより、ネットワーク接続を手動で構成する必要がなくなります。Virtual WAN hubs eliminate the need to manually configure network connectivity. たとえば、お客様は、グローバル トランジット接続を有効にするために、ユーザー定義ルーティング (UDR) またはネットワーク仮想アプライアンス (NVA) を設定する必要はありません。For example, you don't need to set up user-defined routing (UDR) or network virtual appliances (NVAs) to enable global transit connectivity.

  • Virtual WAN を使用すると、ハブ アンド スポークのネットワーク アーキテクチャが作成されることにより、Azure とクロスプレミスでのエンド ツー エンドのネットワーク接続が大幅に簡素化されます。Virtual WAN greatly simplifies end-to-end network connectivity in Azure and cross-premises by creating a hub-and-spoke network architecture. 次の図に示すように、そのアーキテクチャは、既定の状態で複数の Azure リージョンとオンプレミスの場所にまたがります (Any-to-Any 接続)。The architecture spans multiple Azure regions and on-premises locations (any-to-any connectivity) out of the box, as shown in this figure:

    Virtual WAN でのグローバル トランジット ネットワークを示す図。

    "図 2:Virtual WAN でのグローバル トランジット ネットワーク。Figure 2: Global transit network with Virtual WAN.

  • Virtual WAN の Any-to-Any の推移的な接続では、(同じリージョン内およびリージョン間での) 次のパスがサポートされています。Virtual WAN any-to-any transitive connectivity supports the following paths (within the same region and across regions):

    • 仮想ネットワークから仮想ネットワークVirtual network to virtual network
    • 仮想ネットワークからブランチVirtual network to branch
    • ブランチから仮想ネットワークBranch to virtual network
    • ブランチからブランチBranch to branch
  • Virtual WAN ハブはロックダウンされています。Virtual WAN hubs are locked down. お客様がその中にデプロイできるリソースは、仮想ネットワーク ゲートウェイ (ポイント対サイト VPN、サイト間 VPN、Azure ExpressRoute)、Firewall Manager を介した Azure Firewall、ルート テーブルだけです。The only resources that you can deploy within them are virtual network gateways (point-to-site VPN, site-to-site VPN, and Azure ExpressRoute), Azure Firewall via Firewall Manager, and route tables.

  • Virtual WAN では、ExpressRoute プライベート ピアリングを介して Azure からオンプレミスにアドバタイズされるプレフィックスに対する最大 200 の制限が、Virtual WAN ハブあたり 10,000 プレフィックスに増えます。Virtual WAN increases the limit of up to 200 prefixes advertised from Azure to on-premises via ExpressRoute private peering to 10,000 prefixes per Virtual WAN hub. 10,000 万プレフィックスの制限には、サイト間 VPN とポイント対サイト VPN も含まれます。The limit of 10,000 prefixes also includes site-to-site VPN and point-to-site VPN.

  • ネットワーク間の推移的な接続 (リージョン内およびリージョン間) は、現在一般提供 (GA) されています。Network-to-network transitive connectivity (within a region and across regions) is now in general availability (GA).

  • Virtual WAN のハブ間接続は現在一般提供されています。Virtual WAN hub-to-hub connectivity is now in GA.

  • すべての仮想ハブにはルーターが存在するため、Standard Virtual WAN の仮想ネットワーク間でトランジット接続が有効になります。Transit connectivity between the virtual networks in Standard Virtual WAN is enabled due to the presence of a router in every virtual hub. 各仮想ハブ ルーターは、最大 50 Gbps の集約スループットをサポートしています。Every virtual hub router supports an aggregate throughput up to 50 Gbps.

  • すべての VNet で最大 2,000 の VM ワークロードを 1 つの Virtual WAN ハブに接続できます。A maximum of 2,000 VM workloads across all VNets can be connected to a single Virtual WAN hub.

  • Virtual WAN は、さまざまな SD-WAN プロバイダーと統合されています。Virtual WAN integrates with a variety of SD-WAN providers.

  • 多くの管理サービス プロバイダーから、Virtual WAN 向けの管理サービスが提供されています。Many managed service providers offer managed services for Virtual WAN.

  • Virtual WAN 内の VPN ゲートウェイは、仮想ハブあたり最大 20 Gbps および 20,000 接続までスケールアップできます。VPN gateways in Virtual WAN can scale up to 20 Gbps and 20,000 connections per virtual hub.

  • Premium アドオンを使用する ExpressRoute 回線が必要です。ExpressRoute circuits with the premium add-on are required. ExpressRoute Global Reach の場所からのものである必要があります。They should be from an ExpressRoute Global Reach location.

  • 現在一般提供されている Azure Firewall Manager を使用すると、Virtual WAN ハブに Azure Firewall をデプロイできます。Azure Firewall Manager, now in GA, allows the deployment of Azure Firewall in the Virtual WAN hub.

  • Azure Firewall を経由する Virtual WAN のハブ間のトラフィックは、現在はサポートされていません。Virtual WAN hub-to-hub traffic via Azure Firewall is currently not supported. 代わりの方法としては、Virtual WAN でネイティブのハブ間トランジット ルーティング機能を使用します。As alternative, use the native hub-to-hub transit routing capabilities in Virtual WAN. ハブ間の仮想ネットワーク トラフィックを許可またはブロックするには、ネットワーク セキュリティ グループ (NSG) を使用します。Use network security groups (NSGs) to allow or block virtual network traffic across hubs.

設計上の推奨事項:Design recommendations:

  • Azure リージョンとオンプレミスの場所にわたってグローバルなトランジット接続を必要とする、Azure での新しく大規模な、またはグローバルなネットワーク デプロイには Virtual WAN をお勧めします。We recommend Virtual WAN for new large or global network deployments in Azure where you need global transit connectivity across Azure regions and on-premises locations. そのようにすると、Azure ネットワークに対して推移的なルーティングを手動で設定する必要がありません。That way, you don't have to manually set up transitive routing for Azure networking.

    次の図では、ヨーロッパと米国にデータセンターが分散している、グローバルなエンタープライズのデプロイの例を示します。The following figure shows a sample global enterprise deployment with datacenters spread across Europe and the United States. そのデプロイでは、両方のリージョンに多数のブランチ オフィスもあります。The deployment also has a large number of branch offices within both regions. 環境は、Virtual WAN と ExpressRoute Global Reach によってグローバルに接続されています。The environment is globally connected via Virtual WAN and ExpressRoute Global Reach.

    ネットワーク トポロジの例の図。

    "図 3:ネットワーク トポロジのサンプル。Figure 3: Sample network topology.

  • グローバル接続リソースとしては Virtual WAN を使用します。Use Virtual WAN as a global connectivity resource. Azure リージョンごとに Virtual WAN ハブを使用し、ローカルな Virtual WAN ハブを介して Azure リージョン間で複数のランディング ゾーンを接続します。Use a Virtual WAN hub per Azure region to connect multiple landing zones together across Azure regions via the local Virtual WAN hub.

  • ExpressRoute を使用して、Virtual WAN ハブをオンプレミスのデータセンターに接続します。Connect Virtual WAN hubs to on-premises datacenters by using ExpressRoute.

  • DNS サーバーなど、必要な共有サービスを専用のランディング ゾーンにデプロイします。Deploy required shared services, like DNS servers, in a dedicated landing zone. 必要な共有リソースを Virtual WAN ハブにデプロイすることはできません。Required shared resources can't be deployed on a Virtual WAN hub.

  • サイト間 VPN を介してブランチとリモートの場所を最も近い Virtual WAN ハブに接続するか、SD-WAN パートナー ソリューションを使用してブランチを Virtual WAN に接続できるようにします。Connect branches and remote locations to the nearest Virtual WAN hub via site-to-site VPN, or enable branch connectivity to Virtual WAN via an SD-WAN partner solution.

  • ポイント対サイト VPN を使用して、ユーザーを Virtual WAN ハブに接続します。Connect users to the Virtual WAN hub via a point-to-site VPN.

  • リソースが異なるリージョンにある場合でも、Azure 内のリソース間の通信が Microsoft のバックボーン ネットワーク経由で行われるように、"Azure 内のトラフィックは Azure 内に留まる" の原則に従います。Follow the principle "traffic in Azure stays in Azure" so that communication across resources in Azure occurs via the Microsoft backbone network, even when the resources are in different regions.

  • Azure リージョン内での East/West トラフィックおよび South/North トラフィックの保護とフィルター処理のために、Virtual WAN ハブに Azure Firewall をデプロイします。Deploy Azure Firewall in Virtual WAN hubs for east/west and south/north traffic protection and filtering within an Azure region.

  • East/West トラフィックまたは South/North トラフィックの保護とフィルター処理のためにパートナーの NVA が必要な場合は、NVA 仮想ネットワークなどの別の仮想ネットワークに NVA をデプロイします。If partner NVAs are required for east/west or south/north traffic protection and filtering, deploy the NVAs to a separate virtual network such as an NVA virtual network. それを、リージョンの Virtual WAN ハブと、NVA にアクセスする必要があるランディング ゾーンに接続します。Connect it to the regional Virtual WAN hub and to the landing zones that need access to NVAs. 詳細については、NVA 用の Virtual WAN ハブ ルート テーブルの作成に関するページを参照してください。For more information, see Create a Virtual WAN hub route table for NVAs.

  • パートナーのネットワーク テクノロジと NVA をデプロイするときは、パートナー ベンダーのガイダンスに従って、Azure ネットワークと競合する構成がないようにします。When you're deploying partner networking technologies and NVAs, follow the partner vendor's guidance to ensure there are no conflicting configurations with Azure networking.

  • Azure Virtual WAN 上にトランジット ネットワークを構築しないでください。Don't build a transit network on top of Azure Virtual WAN. Virtual WAN は、サードパーティの NVA を使用する機能など、推移的ネットワーク トポロジの要件を満たしています。Virtual WAN satisfies transitive network topology requirements such as the ability to use third-party NVAs. Azure Virtual WAN 上に転送ネットワークを構築すると、冗長性が向上し、複雑さも増します。Building a transit network on top of Azure Virtual WAN would be redundant and increase complexity.

  • Azure のネットワーク テクノロジでは、Microsoft のバックボーンを通じて複数のリージョンにわたる Azure リソースの相互接続がサポートされているため、Azure リージョン間の Azure リソースの接続には、Multiprotocol Label Switching (MPLS) などの既存のオンプレミス ネットワークを使用しないでください。Don't use existing on-premises networks like multiprotocol label switching (MPLS) to connect Azure resources across Azure regions, as Azure networking technologies support the interconnection of Azure resources across regions through the Microsoft backbone. これは、Microsoft バックボーンのパフォーマンスとアップタイムの特性、およびルーティングの簡単さによるものです。This is because of the performance and uptime characteristics of the Microsoft backbone as well as routing simplicity. この提案は、Microsoft バックボーンのパフォーマンスとアップタイムの特性に対応しています。This suggestion addresses the performance and uptime characteristics of the Microsoft backbone. また、簡単なルーティングも推奨されます。It also encourages routing simplicity.

  • Virtual WAN に基づいていないハブ アンド スポーク ネットワーク トポロジから移行するブラウンフィールドのシナリオについては、「Azure Virtual WAN に移行する」を参照してください。For brownfield scenarios where you're migrating from a hub-and-spoke network topology not based on Virtual WAN, see Migrate to Azure Virtual WAN.

  • 接続サブスクリプション内に Azure Virtual WAN リソースと Azure Firewall リソースを作成します。Create Azure Virtual WAN and Azure Firewall resources within the connectivity subscription.

  • Virtual WAN の仮想ハブごとに、500 より多くの仮想ネットワーク接続を作成しないでください。Don't create more than 500 virtual network connections per Virtual WAN virtual hub.

  • デプロイを慎重に計画し、ネットワーク アーキテクチャが Azure Virtual WAN の制限内であることを確認します。Plan your deployment carefully, and ensure that your network architecture is within the Azure Virtual WAN limits.

従来の Azure ネットワーク トポロジTraditional Azure networking topology

Virtual WAN では幅広い強力な機能が提供されていますが、従来の Azure ネットワーク アプローチが最適な場合もあります。Although Virtual WAN offers a wide range of powerful capabilities, a traditional Azure networking approach might be optimal in some cases:

  • 複数の Azure リージョンにまたがる、またはクロスプレミスの、グローバルな推移的ネットワークが必要ない場合。If a global transitive network across multiple Azure regions or cross-premises isn't required. たとえば、ヨーロッパの仮想ネットワークに接続する必要がある米国内のブランチなどの場合です。An example is a branch in the United States that requires connectivity to a virtual network in Europe.

  • 複数の Azure リージョンにわたってグローバル ネットワークをデプロイする必要がある場合は、グローバル VNet ピアリングを使用して、リージョン間で仮想ネットワークを接続できます。If you need to deploy a global network across multiple Azure regions, and you can use global VNet peering to connect virtual networks across regions.

  • VPN または SD-WAN ソリューションとの統合を介して多数のリモートの場所に接続する必要がない場合。If there's no need to connect to a large number of remote locations via VPN or integration with an SD-WAN solution.

  • お客様の組織が Azure でネットワーク トポロジをセットアップするときにきめ細かく制御および構成することを望まれる場合。If your organization's preference is to have granular control and configuration when setting up a network topology in Azure.

従来の Azure ネットワーク トポロジを示す図。

"図 4:従来の Azure ネットワーク トポロジ。Figure 4: A traditional Azure network topology.

設計上の考慮事項:Design considerations:

  • さまざまなネットワーク トポロジで、複数のランディング ゾーン仮想ネットワークを接続できます。Various network topologies can connect multiple landing zone virtual networks. たとえば、1 つの大きなフラット仮想ネットワーク、複数の ExpressRoute 回線または接続で接続された複数の仮想ネットワーク、ハブ アンド スポーク、フル メッシュ、ハイブリッドなどです。Examples are one large flat virtual network, multiple virtual networks connected with multiple ExpressRoute circuits or connections, hub and spoke, full mesh, and hybrid.

  • 仮想ネットワークがサブスクリプションの境界を横断することはありません。Virtual networks don't traverse subscription boundaries. ただし、仮想ネットワーク ピアリング、ExpressRoute 回線、または VPN ゲートウェイを使用することで、異なるサブスクリプションの仮想ネットワーク間の接続を実現できます。But, you can achieve connectivity between virtual networks in different subscriptions by using virtual network peering, an ExpressRoute circuit, or VPN gateways.

  • 仮想ネットワーク ピアリングを使用して、同じリージョン内で、異なる Azure リージョン間で、および異なる Azure Active Directory (Azure AD) テナント間で、仮想ネットワークを接続できます。You can use virtual network peering to connect virtual networks in the same region, across different Azure regions, and across different Azure Active Directory (Azure AD) tenants.

  • 仮想ネットワーク ピアリングとグローバル仮想ネットワーク ピアリングは推移的ではありません。Virtual network peering and global virtual network peering aren't transitive. トランジット ネットワークを可能にするには UDR と NVA が必要です。UDRs and NVAs are required to enable a transit network. 詳細については、「Azure のハブスポーク ネットワーク トポロジ」を参照してください。For more information, see Hub-spoke network topology in Azure.

  • ExpressRoute 回線を使用すると、同じ地政学的地域内の仮想ネットワーク間の接続や、Premium アドオンを使用して異なる地政学的地域間の接続を確立することができます。You can use ExpressRoute circuits to establish connectivity across virtual networks within the same geopolitical region or by using the premium add-on for connectivity across geopolitical regions. 次の点に留意してください。Keep these points in mind:

    • ネットワーク間のトラフィックでは、Microsoft エンタープライズ エッジ (MSEE) ルーターでトラフィックが折り返す必要があるため、待機時間が長くなる可能性があります。Network-to-network traffic might experience more latency because traffic must hairpin at the Microsoft enterprise edge (MSEE) routers.

    • 帯域幅は、ExpressRoute ゲートウェイの SKU に制限されます。Bandwidth will be constrained to the ExpressRoute gateway SKU.

    • 仮想ネットワーク間のトラフィックの検査やログ記録が必要な場合は、やはり UDR をデプロイして管理する必要があります。You must still deploy and manage UDRs if they require inspection or logging for traffic across virtual networks.

  • Border Gateway Protocol (BGP) を使用する VPN ゲートウェイは、Azure 内およびオンプレミス内では推移的ですが、ExpressRoute ゲートウェイ間では推移されません。VPN gateways with Border Gateway Protocol (BGP) are transitive within Azure and on-premises, but they don't transit across ExpressRoute gateways.

  • 複数の ExpressRoute 回線が同じ仮想ネットワークに接続されている場合は、接続の重みと BGP 手法を使用して、オンプレミスと Azure の間のトラフィックに最適なパスになるようにします。When multiple ExpressRoute circuits are connected to the same virtual network, use connection weights and BGP techniques to ensure an optimal path for traffic between on-premises and Azure. 詳細については、「ExpressRoute ルーティングの最適化」を参照してください。For more information, see Optimize ExpressRoute routing.

  • ExpressRoute のルーティングに影響を与える BGP の手法の使用は、Azure プラットフォームの外部での構成です。Using BGP techniques to influence ExpressRoute routing is a configuration outside the Azure platform. お客様の組織またはその接続プロバイダーは、それに応じてオンプレミスのルーターを構成する必要があります。Your organization or your connectivity provider must configure the on-premises routers accordingly.

  • Premium アドオンを使用する ExpressRoute 回線では、グローバルな接続が提供されます。ExpressRoute circuits with premium add-ons provide global connectivity. ただし、ExpressRoute ゲートウェイあたりの ExpressRoute 接続の最大数は 4 です。However, the maximum number of ExpressRoute connections per ExpressRoute gateway is four.

  • 仮想ネットワークあたりの仮想ネットワーク ピアリング接続の最大数は 500 ですが、ExpressRoute プライベート ピアリング経由で Azure からオンプレミスにアドバタイズできるルートの最大数は 200 です。Although the maximum number of virtual network peering connections per virtual network is 500, the maximum number of routes that can be advertised from Azure to on-premises via ExpressRoute private peering is 200.

  • VPN ゲートウェイの最大集約スループットは 10 Gbps です。A VPN gateway's maximum aggregated throughput is 10 Gbps. 最大で 30 個のサイト間トンネルまたはネットワーク間トンネルがサポートされます。It supports up to 30 site-to-site or network-to-network tunnels.

設計上の推奨事項:Design recommendations:

  • 次のシナリオでは、Virtual WAN 以外のテクノロジを使用するハブ アンド スポーク ネットワーク トポロジに基づくネットワーク設計を検討します。Consider a network design based in the hub-and-spoke network topology with non-Virtual WAN technologies for the following scenarios:

    • Azure のデプロイでのトラフィックの境界は、Azure リージョン内にある。The traffic boundary in an Azure deployment is within an Azure region.

    • ネットワーク アーキテクチャは複数の Azure リージョンにまたがり、リージョンをまたぐランディング ゾーンに対する仮想ネットワーク間の推移的な接続は必要ない。A network architecture spans multiple Azure regions, and there's no need for transitive connectivity between virtual networks for landing zones across regions.

    • ネットワーク アーキテクチャは複数の Azure リージョンにまたがり、グローバル VNet ピアリングを使用して、Azure リージョン間で仮想ネットワークを接続できる。A network architecture spans multiple Azure regions, and global VNet peering can be used to connect virtual networks across Azure regions.

    • VPN 接続と ExpressRoute 接続の間の推移的な接続は必要ない。There's no need for transitive connectivity between VPN and ExpressRoute connections.

    • メインのクロスプレミス接続チャネルが ExpressRoute であり、VPN ゲートウェイあたりの VPN 接続の数が 30 未満である。The main cross-premises connectivity channel is ExpressRoute, and the number of VPN connections is less than 30 per VPN gateway.

    • 集中型 NVA ときめ細かいルーティングに依存している。There's a dependency on centralized NVAs and granular routing.

  • リージョン デプロイの場合は、主にハブ アンド スポーク トポロジが使用されます。For regional deployments, primarily use the hub-and-spoke topology. ExpressRoute 経由のクロスプレミス接続、ブランチ接続用の VPN、NVA と UDR を介したスポーク間接続、NVA によるインターネット送信保護には、中央ハブ仮想ネットワークに対して仮想ネットワーク ピアリングで接続する、ランディング ゾーン仮想ネットワークを使用します。Use landing-zone virtual networks that connect with virtual network peering to a central-hub virtual network for cross-premises connectivity via ExpressRoute, VPN for branch connectivity, spoke-to-spoke connectivity via NVAs and UDRs, and internet-outbound protection via NVA. 次の図はこのワークフローを示したものです。The following figure shows this topology. これにより、適切なトラフィック制御によって、セグメント化と検査のためのほとんどの要件を満たすことができます。This allows for appropriate traffic control to meet most requirements for segmentation and inspection.

    ハブ アンド スポーク ネットワーク トポロジを示す図。

    図 5:ハブ アンド スポーク ネットワーク トポロジ。Figure 5: Hub-and-spoke network topology.

  • 次のいずれかの条件に該当する場合は、複数の ExpressRoute 回線で接続された複数の仮想ネットワークのトポロジを使用します。Use the topology of multiple virtual networks connected with multiple ExpressRoute circuits when one of these conditions is true:

    • 高いレベルの分離が必要である。You need a high level of isolation.

    • 特定の事業単位用に専用の ExpressRoute 帯域幅が必要である。You need dedicated ExpressRoute bandwidth for specific business units.

    • ExpressRoute ゲートウェイあたりの最大接続数 (最大 4 つ) に達した。You've reached the maximum number of connections per ExpressRoute gateway (up to four).

    次の図はこのワークフローを示したものです。The following figure shows this topology.

    複数の ExpressRoute 回線で接続された複数の仮想ネットワークを示す図。

    図 6:複数の ExpressRoute 回線で接続された複数の仮想ネットワーク。Figure 6: Multiple virtual networks connected with multiple ExpressRoute circuits.

  • ExpressRoute ゲートウェイ、VPN ゲートウェイ (必要な場合)、Azure Firewall、またはパートナーの NVA (必要な場合) が含まれる最小限の共有サービスのセットを、中央ハブの仮想ネットワークにデプロイします。Deploy a set of minimal shared services, including ExpressRoute gateways, VPN gateways (as required), and Azure Firewall or partner NVAs (as required) in the central-hub virtual network. 必要に応じて、Active Directory ドメイン コントローラーと DNS サーバーもデプロイします。If necessary, also deploy Active Directory domain controllers and DNS servers.

  • East/West または South/North のトラフィックの保護とフィルター処理のための Azure Firewall またはパートナーの NVA を、中央ハブの仮想ネットワークにデプロイします。Deploy Azure Firewall or partner NVAs for east/west or south/north traffic protection and filtering, in the central-hub virtual network.

  • パートナーのネットワーク テクノロジまたは NVA として展開するときは、パートナー ベンダーのガイダンスに従って次のことを確認します。When you're deploying partner networking technologies or NVAs, follow the partner vendor's guidance to ensure that:

    • ベンダーによってデプロイがサポートされる。The vendor supports deployment.

    • 高可用性と最大パフォーマンスのためのガイダンスが設計されている。The guidance is designed for high availability and maximal performance.

    • Azure ネットワークと競合する構成がない。There are no conflicting configurations with Azure networking.

  • 中央ハブ仮想ネットワークの共有サービスとして、Azure Application Gateway などの L7 受信 NVA をデプロイしないでください。Don't deploy L7 inbound NVAs such as Azure Application Gateway as a shared service in the central-hub virtual network. 代わりに、それらは、それぞれのランディング ゾーンにアプリと一緒にデプロイします。Instead, deploy them together with the app in their respective landing zones.

  • ブランチの拠点を本社に接続するには、既存のネットワーク (MPLS および SD-WAN) を使用します。Use your existing network, MPLS and SD-WAN, for connecting branch locations with corporate headquarters. ExpressRoute ゲートウェイと VPN ゲートウェイの間では Azure の推移はサポートされていません。Transit in Azure between ExpressRoute and VPN gateways isn't supported.

  • Azure リージョンをまたぐ複数のハブ アンド スポーク トポロジがあるネットワーク アーキテクチャでは、リージョン間で通信する必要があるランディング ゾーンの数が少ない場合は、グローバル仮想ネットワーク ピアリングを使用してランディング ゾーンの仮想ネットワークを接続します。For network architectures with multiple hub-and-spoke topologies across Azure regions, use global virtual network peering to connect landing-zone virtual networks when a small number of landing zones need to communicate across regions. このアプローチにより、VM SKU で許可されるような、グローバル仮想ネットワーク ピアリングによる高ネットワーク帯域幅などのメリットが提供されます。This approach offers benefits like high network bandwidth with global virtual network peering, as allowed by the VM SKU. ただし、トラフィックの検査やフィルター処理が必要な場合は、中央の NVA はバイパスされます。But it will bypass the central NVA, in case traffic inspection or filtering is required. これは、グローバル仮想ネットワーク ピアリングに対する制限の対象にもなります。This would also be subject to limitations on global virtual network peering.

  • お客様が 2 つの Azure リージョンにハブ アンド スポーク ネットワーク アーキテクチャをデプロイし、リージョンをまたぐすべてのランディング ゾーン間にトランジット接続が必要な場合は、ExpressRoute とデュアル回線を使用して、Azure リージョンをまたぐランディング ゾーン仮想ネットワークにトランジット接続を提供します。When you deploy a hub-and-spoke network architecture in two Azure regions and transit connectivity between all landing zones across regions is required, use ExpressRoute with dual circuits to provide transit connectivity for landing-zone virtual networks across Azure regions. このシナリオでは、ランディング ゾーンは、リージョン内ではローカル ハブ仮想ネットワーク内の NVA 経由で、リージョン間では ExpressRoute 回線を経由して推移できます。In this scenario, landing zones can transit within a region via NVA in local-hub virtual network and across regions via ExpressRoute circuit. トラフィックは MSEE ルーターで折り返す必要があります。Traffic must hairpin at the MSEE routers. 次の図ではこの設計を示します。The following figure shows this design.

    ランディング ゾーンの接続の設計を示す図。

    図 7:ランディング ゾーンの接続の設計。Figure 7: Landing zone connectivity design.

  • お客様の組織が、2 つを超える Azure リージョン間でのハブ アンド スポーク ネットワーク アーキテクチャを必要としており、Azure リージョンをまたぐランディング ゾーン仮想ネットワーク間でグローバルなトランジット接続が必要な場合。When your organization requires hub-and-spoke network architectures across more than two Azure regions and global transit connectivity between landing zones, virtual networks across Azure regions are required. グローバル仮想ネットワーク ピアリングで中央ハブ仮想ネットワークを相互に接続し、UDR と NVA を使用してグローバル トランジット ルーティングを有効にすることで、このアーキテクチャを実装できます。You can implement this architecture by interconnecting central-hub virtual networks with global virtual network peering and using UDRs and NVAs to enable global transit routing. 複雑度と管理オーバーヘッドが高いため、Virtual WAN を使用したグローバル トランジット ネットワーク アーキテクチャを評価することをお勧めします。Because the complexity and management overhead are high, we recommend evaluating a global transit network architecture with Virtual WAN.

  • Azure 上のネットワークのエンドツーエンドの状態を監視するには、Azure Monitor for Networks (プレビュー) を使用します。Use Azure Monitor for Networks (Preview) to monitor the end-to-end state of your networks on Azure.

  • 中央ハブ仮想ネットワークあたり 200 個より多くのピアリング接続を作成しないでください。Don't create more than 200 peering connections per central-hub virtual network. 仮想ネットワークでは最大 500 個のピアリング接続がサポートされていますが、プライベート ピアリングを使用する ExpressRoute では、Azure からオンプレミスへのアドバタイズに対してサポートされるプレフィックスが最大 200 個です。Although virtual networks support up to 500 peering connections, ExpressRoute with private peering only supports advertising up to 200 prefixes from Azure to on-premises.

Azure への接続性Connectivity to Azure

このセクションでは、ネットワーク トポロジを拡張し、オンプレミスの場所から Azure に接続するために推奨されるモデルを検討します。This section expands on the network topology to consider recommended models for connecting on-premises locations to Azure.

設計上の考慮事項:Design considerations:

  • Azure ExpressRoute は、オンプレミスの場所から Azure のサービスとしてのインフラストラクチャ (IaaS) およびサービスとしてのプラットフォーム (PaaS) 機能への専用プライベート接続を提供します。Azure ExpressRoute provides dedicated private connectivity to Azure infrastructure as a service (IaaS) and platform as a service (PaaS) functionality from on-premises locations.

  • Private Link を使用して、プライベート ピアリングによる ExpressRoute 経由で PaaS サービスへの接続を確立できます。You can use Private Link to establish connectivity to PaaS services over ExpressRoute with private peering.

  • 複数の仮想ネットワークが同じ ExpressRoute 回線に接続されている場合、それらは同じルーティング ドメインの一部になり、帯域幅はすべての仮想ネットワークで共有されます。When multiple virtual networks are connected to the same ExpressRoute circuit, they'll become part of the same routing domain, and all virtual networks will share the bandwidth.

  • ExpressRoute Global Reach (使用可能な場合) を使用すると、お客様は、ExpressRoute 回線を通してオンプレミスの場所をまとめて接続し、Microsoft のバックボーン ネットワーク経由でトラフィックを転送することができます。You can use ExpressRoute Global Reach, where available, to connect on-premises locations together through ExpressRoute circuits to transit traffic over the Microsoft backbone network.

  • ExpressRoute Global Reach は、多くの ExpressRoute ピアリングの場所で利用できます。ExpressRoute Global Reach is available in many ExpressRoute peering locations.

  • ExpressRoute Direct では、ExpressRoute Direct のポート容量 (10 Gbps または 100 Gbps) まで、追加コストなしで複数の ExpressRoute 回線を作成することができます。ExpressRoute Direct allows creation of multiple ExpressRoute circuits at no additional cost, up to the ExpressRoute Direct port capacity (10 Gbps or 100 Gbps). また、Microsoft の ExpressRoute ルーターに直接接続することもできます。It also allows you to connect directly to Microsoft's ExpressRoute routers. 100 Gbps SKU の場合、最小の回線帯域幅は 5 Gbps です。For the 100-Gbps SKU, the minimum circuit bandwidth is 5 Gbps. 10 Gbps SKU の場合、最小の回線帯域幅は 1 Gbps です。For the 10-Gbps SKU, the minimum circuit bandwidth is 1 Gbps.

設計上の推奨事項:Design recommendations:

  • オンプレミス ネットワークを Azure に接続するためのプライマリ接続チャネルとして、ExpressRoute を使用します。Use ExpressRoute as the primary connectivity channel for connecting an on-premises network to Azure. VPN をバックアップ接続のソースとして使用して、接続の回復性を高めることができます。You can use VPNs as a source of backup connectivity to enhance connectivity resiliency.

  • オンプレミスの場所を Azure の仮想ネットワークに接続するときは、異なるピアリングの場所からのデュアル ExpressRoute 回線を使用します。Use dual ExpressRoute circuits from different peering locations when you're connecting an on-premises location to virtual networks in Azure. このようにセットアップすると、オンプレミスと Azure の間に単一障害点がなくなり、Azure への冗長なパスが確保されます。This setup will ensure redundant paths to Azure by removing single points of failure between on-premises and Azure.

  • 複数の ExpressRoute 回線を使用すると、BGP のローカル設定と AS PATH プリペンドにより ExpressRoute のルーティングが最適化されますWhen you use multiple ExpressRoute circuits, optimize ExpressRoute routing via BGP local preference and AS PATH prepending.

  • 帯域幅とパフォーマンスの要件に基づいて、ExpressRoute と VPN ゲートウェイに適切な SKU を使用していることを確認します。Ensure that you're using the right SKU for the ExpressRoute/VPN gateways based on bandwidth and performance requirements.

  • サポートされている Azure リージョンに、ゾーン冗長 ExpressRoute ゲートウェイをデプロイします。Deploy a zone-redundant ExpressRoute gateway in the supported Azure regions.

  • 10 Gbps より高い帯域幅または専用の 10/100 Gbps ポートを必要とするシナリオでは、ExpressRoute Direct を使用します。For scenarios that require bandwidth higher than 10 Gbps or dedicated 10/100-Gbps ports, use ExpressRoute Direct.

  • 待機時間を短くする必要がある場合、またはオンプレミスから Azure へのスループットを 10 Gbps より大きくする必要がある場合は、FastPath を有効にして、データ パスから ExpressRoute ゲートウェイをバイパスします。When low latency is required, or throughput from on-premises to Azure must be greater than 10 Gbps, enable FastPath to bypass the ExpressRoute gateway from the data path.

  • ブランチまたはリモートの場所を Azure に接続するには、VPN ゲートウェイを使用します。Use VPN gateways to connect branches or remote locations to Azure. 回復力を高めるには、ゾーン冗長ゲートウェイをデプロイします (使用可能な場合)。For higher resilience, deploy zone-redundant gateways (where available).

  • ExpressRoute 経由で Azure に接続されている大規模なオフィス、地域本社、またはデータセンターを接続するには、ExpressRoute Global Reach を使用します。Use ExpressRoute Global Reach to connect large offices, regional headquarters, or datacenters connected to Azure via ExpressRoute.

  • トラフィックの分離または専用の帯域幅が必要な場合は (運用環境と非運用環境を分離する場合など)、異なる ExpressRoute 回線を使用します。When traffic isolation or dedicated bandwidth is required, such as for separating production and nonproduction environments, use different ExpressRoute circuits. ルーティング ドメインを分離し、迷惑な隣人のリスクを軽減するのに役立ちます。It will help you ensure isolated routing domains and alleviate noisy-neighbor risks.

  • Network Performance Monitor を使用して ExpressRoute 回線を先行して監視します。Proactively monitor ExpressRoute circuits by using Network Performance Monitor.

  • 単一のピアリングの場所からは、ExpressRoute 回線を明示的に使用しないでください。Don't explicitly use ExpressRoute circuits from a single peering location. このようにすると、単一障害点が作成され、組織がピアリングの場所の停止による影響を受けやすくなります。This creates a single point of failure and makes your organization susceptible to peering location outages.

  • 迷惑な隣人のリスクを回避するため、分離または専用の帯域幅を必要とする複数の環境を、同じ ExpressRoute 回線を使用して接続しないでください。Don't use the same ExpressRoute circuit to connect multiple environments that require isolation or dedicated bandwidth, to avoid noisy-neighbor risks.

Azure PaaS サービスへの接続Connectivity to Azure PaaS services

これまでの接続セクションを基にして、このセクションでは、Azure PaaS サービスを使用するための推奨される接続方法について説明します。Building on the previous connectivity sections, this section explores recommended connectivity approaches for using Azure PaaS services.

設計上の考慮事項:Design considerations:

  • Azure PaaS サービスは通常、パブリック エンドポイントを介してアクセスされます。Azure PaaS services are typically accessed over public endpoints. ただし、Azure プラットフォームには、そのようなエンドポイントをセキュリティで保護する機能や、完全にプライベートにする機能が用意されています。However, the Azure platform provides capabilities to secure such endpoints or even make them entirely private:

    • 仮想ネットワーク インジェクションでは、サポートされるサービスに対する専用のプライベート デプロイが提供されます。Virtual network injection provides dedicated private deployments for supported services. ただし、管理プレーンのトラフィックは、パブリック IP アドレスを通して流れます。But management plane traffic flows through public IP addresses.

    • Private Link では、Azure PaaS インスタンスに対するプライベート IP アドレスを使用した専用アクセス、または Azure Load Balancer Standard の内側にあるカスタム サービスへの専用アクセスが提供されます。Private Link provides dedicated access by using private IP addresses to Azure PaaS instances or custom services behind Azure Load Balancer Standard.

    • 仮想ネットワーク サービス エンドポイントでは、選択されたサブネットから選択された PaaS サービスへのサービス レベルのアクセスが提供されます。Virtual network service endpoints provide service-level access from selected subnets to selected PaaS services.

  • エンタープライズは多くの場合、PaaS サービスに対するパブリック エンドポイントに関する問題があり、適切に軽減する必要があります。Enterprises often have concerns about public endpoints for PaaS services that must be appropriately mitigated.

  • サポートされているサービスの場合、Private Link により、サービス エンドポイントに関するデータの窃盗の問題は解決されます。For supported services, Private Link addresses data exfiltration concerns associated with service endpoints. 代わりの方法として、NVA による送信フィルターを使用して、データの窃盗を緩和するための手順を提供できます。As an alternative, you can use outbound filtering via NVAs to provide steps to mitigate data exfiltration.

設計上の推奨事項:Design recommendations:

  • サポートされている Azure サービスに対する仮想ネットワーク インジェクションを使用して、仮想ネットワーク内からそれらを使用できるようにします。Use virtual network injection for supported Azure services to make them available from within your virtual network.

  • 仮想ネットワークに挿入された Azure PaaS サービスでは、パブリック IP アドレスを使用して管理プレーンの操作がまだ実行されます。Azure PaaS services that have been injected into a virtual network still perform management plane operations by using public IP addresses. UDR と NSG を使用して、この通信が仮想ネットワーク内にロックダウンされるようにします。Ensure that this communication is locked down within the virtual network by using UDRs and NSGs.

  • 使用可能な場合は、Private Link を共有 Azure PaaS サービスに対して使用します。Use Private Link, where available, for shared Azure PaaS services. Private Link は、一部のサービスについては一般提供されており、多くのサービスではパブリック プレビュー段階です。Private Link is generally available for several services and is in public preview for numerous ones.

  • ExpressRoute プライベート ピアリングを介して、オンプレミスから Azure PaaS サービスにアクセスします。Access Azure PaaS services from on-premises via ExpressRoute private peering. 専用の Azure サービスに対する仮想ネットワーク インジェクション、または使用可能な共有 Azure サービスに対する Azure Private Link を使用します。Use either virtual network injection for dedicated Azure services or Azure Private Link for available shared Azure services. 仮想ネットワーク インジェクションまたは Private Link を使用できない場合にオンプレミスから Azure PaaS サービスにアクセスするには、Microsoft ピアリングで ExpressRoute を使用します。To access Azure PaaS services from on-premises when virtual network injection or Private Link isn't available, use ExpressRoute with Microsoft peering. この方法により、パブリック インターネット経由での推移を回避できます。This method avoids transiting over the public internet.

  • 仮想ネットワーク内から Azure PaaS サービスへのアクセスをセキュリティで保護するには、仮想ネットワーク サービス エンドポイントを使用しますが、Private Link を使用できず、データ流出の問題が存在しない場合に限ります。Use virtual network service endpoints to secure access to Azure PaaS services from within your virtual network, but only when Private Link isn't available and there are no data exfiltration concerns. サービス エンドポイントでのデータ窃盗に関する問題に対処するには、NVA のフィルター処理を使用するか、Azure Storage に対する仮想ネットワーク サービス エンドポイント ポリシーを使用します。To address data exfiltration concerns with service endpoints, use NVA filtering or use virtual network service endpoint policies for Azure Storage.

  • すべてのサブネットにおいて既定で仮想ネットワーク サービス エンドポイントを有効にしないでください。Don't enable virtual network service endpoints by default on all subnets.

  • NVA フィルター処理を使用している場合を除き、データ窃盗の問題が存在する場合は、仮想ネットワーク サービス エンドポイントを使用しないでください。Don't use virtual network service endpoints when there are data exfiltration concerns, unless you use NVA filtering.

  • Azure から Azure リソースへの通信を可能にするために強制トンネリングを実装することは推奨されません。We don't recommend that you implement forced tunneling to enable communication from Azure to Azure resources.

受信と送信のインターネット接続を計画するPlan for inbound and outbound internet connectivity

このセクションでは、パブリック インターネットに対する受信接続と送信接続に対して推奨される接続モデルについて説明します。This section describes recommended connectivity models for inbound and outbound connectivity to and from the public internet.

設計上の考慮事項:Design considerations:

  • Azure Firewall、Azure Application Gateway 上の Azure Web アプリケーション ファイアウォール (WAF)、Azure Front Door Service などの Azure ネイティブ ネットワーク セキュリティ サービスは、フル マネージド サービスです。Azure-native network security services such as Azure Firewall, Azure Web Application Firewall (WAF) on Azure Application Gateway, and Azure Front Door Service are fully managed services. そのため、大規模な場合は複雑になる可能性のある、インフラストラクチャのデプロイに関連する運用コストと管理コストが発生することはありません。So you don't incur the operational and management costs associated with infrastructure deployments, which can become complex at scale.

  • 組織が NVA の使用を望む場合や、ネイティブ サービスでは組織に固有の要件が満たされない場合、エンタープライズ規模のアーキテクチャは、パートナーの NVA と完全に互換性があります。The enterprise-scale architecture is fully compatible with partner NVAs, if your organization prefers to use NVAs or for situations where native services don't satisfy your organization's specific requirements.

設計上の推奨事項:Design recommendations:

  • 次のものを管理するには Azure Firewall を使用します。Use Azure Firewall to govern:

    • インターネットへの Azure 送信トラフィック。Azure outbound traffic to the internet.

    • HTTP/S ではない受信接続。Non-HTTP/S inbound connections.

    • East/West トラフィックのフィルター処理 (組織で必要な場合)。East/west traffic filtering (if your organization requires it).

  • Virtual WAN ハブ間またはハブ仮想ネットワーク内に Azure Firewall をデプロイして管理するには、Firewall Manager と Virtual WAN を使用します。Use Firewall Manager with Virtual WAN to deploy and manage Azure firewalls across Virtual WAN hubs or in hub virtual networks. Firewall Manager は、現在、Virtual WAN と通常の仮想ネットワークの両方について GA です。Firewall Manager is now in GA for both Virtual WAN and regular virtual networks.

  • グローバル ネットワーク環境全体でセキュリティ体制を管理するには、グローバル Azure Firewall ポリシーを作成して、すべての Azure Firewall インスタンスに割り当てます。Create a global Azure Firewall policy to govern security posture across the global network environment and assign it to all Azure Firewall instances. ロールベースのアクセス制御を使用してローカル セキュリティ チームに増分ファイアウォール ポリシーをデリゲートすることにより、特定のリージョンの要件を満たすきめ細かいポリシーを設定できます。Allow for granular policies to meet requirements of specific regions by delegating incremental firewall policies to local security teams via role-based access control.

  • 組織のご希望に応じて、サポートされているパートナーの SaaS セキュリティ プロバイダーを Firewall Manager 内で構成し、そのようなソリューションを使用して送信接続を保護できます。Configure supported partner SaaS security providers within Firewall Manager if your organization wants to use such solutions to help protect outbound connections.

  • インターネットからの受信 HTTP/S トラフィックを保護するには、ランディング ゾーンの仮想ネットワーク内で WAF を使用します。Use WAF within a landing-zone virtual network for protecting inbound HTTP/S traffic from the internet.

  • Azure リージョン間でランディング ゾーンへの受信 HTTP/S 接続に対するグローバルな保護を提供するには、Azure Front Door Service と WAF ポリシーを使用します。Use Azure Front Door Service and WAF policies to provide global protection across Azure regions for inbound HTTP/S connections to a landing zone.

  • Azure Front Door Service と Azure Application Gateway を使用して HTTP/S アプリを保護する場合は、Azure Front Door Service で WAF ポリシーを使用します。When you're using Azure Front Door Service and Azure Application Gateway to help protect HTTP/S apps, use WAF policies in Azure Front Door Service. Azure Application Gateway をロックダウンして、Azure Front Door Service からのトラフィックのみを受信するようにします。Lock down Azure Application Gateway to receive traffic only from Azure Front Door Service.

  • East/West または South/North のトラフィックの保護とフィルター処理のために、パートナーの NVA が必要な場合:If partner NVAs are required for east/west or south/north traffic protection and filtering:

    • Virtual WAN ネットワーク トポロジの場合は、別の仮想ネットワーク (NVA 仮想ネットワークなど) に NVA をデプロイします。For Virtual WAN network topologies, deploy the NVAs to a separate virtual network (for example, NVA virtual network). それを、リージョンの Virtual WAN ハブと、NVA にアクセスする必要があるランディング ゾーンに接続します。Then connect it to the regional Virtual WAN hub and to the landing zones that require access to NVAs. こちらの記事でプロセスについて説明されています。This article describes the process.
    • Virtual WAN 以外のネットワーク トポロジの場合は、パートナーの NVA を中央ハブの仮想ネットワークにデプロイします。For non-Virtual WAN network topologies, deploy the partner NVAs in the central-hub virtual network.
  • 受信 HTTP/S 接続にパートナーの NVA が必要な場合は、ランディング ゾーンの仮想ネットワーク内に、保護してインターネットに公開するアプリと共に、これらをデプロイします。If partner NVAs are required for inbound HTTP/S connections, deploy them within a landing-zone virtual network and together with the apps that they're protecting and exposing to the internet.

  • 仮想ネットワーク内でホストされているすべてのパブリック エンドポイントを保護するには、Azure DDoS Protection Standard 保護プランを使用します。Use Azure DDoS Protection Standard protection plans to help protect all public endpoints hosted within your virtual networks.

  • オンプレミスの境界ネットワークの概念とアーキテクチャを Azure に複製しないでください。Don't replicate on-premises perimeter network concepts and architectures into Azure. 同様のセキュリティ機能を Azure で利用できますが、実装とアーキテクチャをクラウドに適合させる必要があります。Similar security capabilities are available in Azure, but the implementation and architecture must be adapted to the cloud.

アプリの配信を計画するPlan for app delivery

このセクションでは、内部および外部に公開されるアプリを、安全で拡張性と可用性の高い方法で配信するための主な推奨事項について説明します。This section explores key recommendations to deliver internal-facing and external-facing apps in a secure, highly scalable, and highly available way.

設計上の考慮事項:Design considerations:

  • Azure Load Balancer (内部およびパブリック) では、リージョン レベルでのアプリの配信に対して高可用性が提供されます。Azure Load Balancer (internal and public) provides high availability for app delivery at a regional level.

  • Azure Application Gateway を使用すると、リージョン レベルで HTTP/S アプリを安全に配信できます。Azure Application Gateway allows the secure delivery of HTTP/S apps at a regional level.

  • Azure Front Door Service を使用すると、Azure リージョン間で高可用性の HTTP/S アプリを安全に配信できます。Azure Front Door Service allows the secure delivery of highly available HTTP/S apps across Azure regions.

  • Azure Traffic Manager を使用すると、グローバル アプリを配信できます。Azure Traffic Manager allows the delivery of global apps.

設計上の推奨事項:Design recommendations:

  • 内部に公開されるアプリと外部に公開されるアプリの両方について、ランディング ゾーン内でアプリの配信を実行します。Perform app delivery within landing zones for both internal-facing and external-facing apps.

  • HTTP/S アプリのセキュリティ保護された配信を行うには、Application Gateway v2 を使用し、WAF の保護とポリシーを有効にします。For secure delivery of HTTP/S apps, use Application Gateway v2 and ensure that WAF protection and policies are enabled.

  • HTTP/S アプリのセキュリティに Application Gateway v2 を使用できない場合は、パートナーの NVA を使用します。Use a partner NVA if you can't use Application Gateway v2 for the security of HTTP/S apps.

  • 受信 HTTP/S 接続に使用される Azure Application Gateway v2 またはパートナーの NVA は、セキュリティ保護対象のアプリと共に、ランディング ゾーンの仮想ネットワーク内にデプロイします。Deploy Azure Application Gateway v2 or partner NVAs used for inbound HTTP/S connections within the landing-zone virtual network and with the apps that they're securing.

  • ランディング ゾーン内のすべてのパブリック IP アドレスに対し、DDoS Standard 保護プランを使用します。Use a DDoS standard protection plan for all public IP addresses in a landing zone.

  • 複数の Azure リージョンにまたがるグローバル HTTP/S アプリの配信と保護には、Azure Front Door Service と WAF ポリシーを使用します。Use Azure Front Door Service with WAF policies to deliver and help protect global HTTP/S apps that span Azure regions.

  • Azure Front Door Service と Application Gateway を使用して HTTP/S アプリを保護する場合は、Azure Front Door Service で WAF ポリシーを使用します。When you're using Azure Front Door Service and Application Gateway to help protect HTTP/S apps, use WAF policies in Azure Front Door Service. Application Gateway をロックダウンして、Azure Front Door Service からのトラフィックのみを受信するようにします。Lock down Application Gateway to receive traffic only from Azure Front Door Service.

  • HTTP/S 以外のプロトコルにまたがるグローバル アプリを配信するには、Traffic Manager を使用します。Use Traffic Manager to deliver global apps that span protocols other than HTTP/S.

ランディング ゾーンのネットワーク セグメント化を計画するPlan for landing zone network segmentation

このセクションでは、ネットワークのゼロ トラスト実装を促進するために、ランディング ゾーン内で高度にセキュリティ保護された内部ネットワーク セグメント化を提供する場合の、主な推奨事項について説明します。This section explores key recommendations to deliver highly secure internal network segmentation within a landing zone to drive a network zero-trust implementation.

設計上の考慮事項:Design considerations:

  • ゼロ トラスト モデルでは、違反状態が想定され、各要求が制御されていないネットワークから送信されたかのように検証されます。The zero-trust model assumes a breached state and verifies each request as though it originates from an uncontrolled network.

  • 高度なゼロ トラスト ネットワークの実装では、完全に分散されたイングレスおよびエグレス クラウド マイクロ境界と、より深いマイクロ セグメント化が採用されています。An advanced zero-trust network implementation employs fully distributed ingress/egress cloud micro-perimeters and deeper micro-segmentation.

  • ネットワーク セキュリティ グループでは、Azure サービス タグを使用して、Azure PaaS サービスへの接続を容易にすることができます。Network security groups can use Azure service tags to facilitate connectivity to Azure PaaS services.

  • アプリのセキュリティ グループでは、仮想ネットワークをまたがって保護が提供されることはありません。App security groups don't span or provide protection across virtual networks.

  • NSG フロー ログは、Azure Resource Manager テンプレートを使用してサポートされるようになりました。NSG flow logs are now supported through Azure Resource Manager templates.

設計上の推奨事項:Design recommendations:

  • サブネットの作成をランディング ゾーンの所有者にデリゲートします。Delegate subnet creation to the landing zone owner. これにより、サブネットをまたいでワークロードをセグメント化する方法を定義できます (たとえば、1 つの大きいサブネット、多層アプリ、ネットワークに挿入されたアプリなど)。This will enable them to define how to segment workloads across subnets (for example, a single large subnet, multitier app, or network-injected app). プラットフォーム チームは、Azure Policy を使用して、特定の規則 (インターネットからの受信 SSH または RDP を拒否する、ランディング ゾーンをまたぐトラフィックを許可またはブロックする、など) が設定された NSG を、拒否のみのポリシーを持つサブネットと常に関連付けることができます。The platform team can use Azure Policy to ensure that an NSG with specific rules (such as deny inbound SSH or RDP from internet, or allow/block traffic across landing zones) is always associated with subnets that have deny-only policies.

  • サブネット間のトラフィックおよびプラットフォームを横断する East/West トラフィック (ランディング ゾーン間のトラフィック) を保護するには、NSG を使用します。Use NSGs to help protect traffic across subnets, as well as east/west traffic across the platform (traffic between landing zones).

  • アプリ チームは、サブネット レベルの NSG でアプリ セキュリティ グループを使用して、ランディング ゾーン内の多層 VM を保護する必要があります。The app team should use app security groups at the subnet-level NSGs to help protect multitier VMs within the landing zone.

  • ランディング ゾーン内のマイクロセグメント トラフィックには NSG とアプリ セキュリティ グループを使用し、中央の NVA を使用してトラフィック フローをフィルター処理しないようにします。Use NSGs and app security groups to micro-segment traffic within the landing zone and avoid using a central NVA to filter traffic flows.

  • NSG フロー ログを有効にし、それらを Traffic Analytics にフィードして、内部および外部のトラフィック フローに関する分析情報を取得します。Enable NSG flow logs and feed them into Traffic Analytics to gain insights into internal and external traffic flows.

  • ランディング ゾーン間の接続を選択的に許可するには、NSG を使用します。Use NSGs to selectively allow connectivity between landing zones.

  • Virtual WAN トポロジでは、お客様の組織がランディング ゾーン間を流れるトラフィックに対するフィルター処理とログの機能を必要とする場合、Azure Firewall を介してランディング ゾーン間のトラフィックをルーティングします。For Virtual WAN topologies, route traffic across landing zones via Azure Firewall if your organization requires filtering and logging capabilities for traffic flowing across landing zones.

ネットワーク暗号化の要件を定義するDefine network encryption requirements

このセクションでは、オンプレミスと Azure の間、および Azure リージョン間で、ネットワーク暗号化を実現するための主な推奨事項について説明します。This section explores key recommendations to achieve network encryption between on-premises and Azure as well as across Azure regions.

設計上の考慮事項:Design considerations:

  • コストと使用可能な帯域幅は、エンドポイント間の暗号化トンネルの長さに反比例します。Cost and available bandwidth are inversely proportional to the length of the encryption tunnel between endpoints.

  • VPN を使用して Azure に接続する場合、インターネット上のトラフィックは IPsec トンネルによって暗号化されます。When you're using a VPN to connect to Azure, traffic is encrypted over the internet via IPsec tunnels.

  • プライベート ピアリングで ExpressRoute を使用する場合、現在は、トラフィックは暗号化されません。When you're using ExpressRoute with private peering, traffic isn't currently encrypted.

  • Media Access Control Security (MACsec) 暗号化を ExpressRoute Direct に適用して、ネットワーク暗号化を実現できます。You can apply media access control security (MACsec) encryption to ExpressRoute Direct to achieve network encryption.

  • 現在、Azure ではグローバル仮想ネットワーク ピアリングに対するネイティブ暗号化は提供されていません。Azure doesn't currently offer native encryption over global virtual network peering. Azure リージョン間の暗号化が必要な場合は、グローバル仮想ネットワーク ピアリングではなく、VPN ゲートウェイを使用して仮想ネットワークを接続することができます。If you need encryption between Azure regions, it's possible to connect virtual networks by using VPN gateways rather than global virtual network peering.

設計上の推奨事項:Design recommendations:

暗号化のフローを示す図。

図 8:暗号化のフロー。Figure 8: Encryption flows.

  • VPN ゲートウェイを使用してオンプレミスから Azure への VPN 接続を確立すると、トラフィックは IPsec トンネルを通してプロトコル レベルで暗号化されます。When you're establishing VPN connections from on-premises to Azure by using VPN gateways, traffic is encrypted at a protocol level through IPsec tunnels. 上の図では、フロー A でこの暗号化が示されています。The preceding diagram shows this encryption in flow A.

  • ExpressRoute Direct を使用するときは、組織のルーターと MSEE の間のレイヤー 2 レベルでトラフィックを暗号化するために、MACsec を構成します。When you're using ExpressRoute Direct, configure MACsec in order to encrypt traffic at the layer-two level between your organization's routers and MSEE. 図では、フロー B でこの暗号化が示されています。The diagram shows this encryption in flow B.

  • MACsec がオプションではない (たとえば、ExpressRoute Direct を使用していない) Virtual WAN のシナリオでは、Virtual WAN VPN ゲートウェイを使用して、ExpressRoute プライベート ピアリング経由で IPsec トンネルを確立します。For Virtual WAN scenarios where MACsec isn't an option (for example, not using ExpressRoute Direct), use a Virtual WAN VPN gateway to establish IPsec tunnels over ExpressRoute private peering. 図では、フロー C でこの暗号化が示されています。The diagram shows this encryption in flow C.

  • Virtual WAN 以外のシナリオで、MACsec がオプションではない場合 (たとえば、ExpressRoute Direct を使用していない場合)、オプションは以下のものだけです。For non-Virtual WAN scenarios, and where MACsec isn't an option (for example, not using ExpressRoute Direct), the only options are:

    • パートナーの NVA を使用して、ExpressRoute プライベート ピアリング経由で IPsec トンネルを確立します。Use partner NVAs to establish IPsec tunnels over ExpressRoute private peering.
    • Microsoft ピアリングを使用して ExpressRoute 経由で VPN トンネルを確立します。Establish a VPN tunnel over ExpressRoute with Microsoft peering.
  • Azure リージョン間のトラフィックを暗号化する必要がある場合は、VPN ゲートウェイを使用してリージョン間で仮想ネットワークを接続します。If traffic between Azure regions must be encrypted, use VPN gateways to connect virtual networks across regions.

  • Azure のネイティブ ソリューション (図のフロー BC で示されているもの) で要件が満たされない場合は、Azure でパートナーの NVA を使用して、ExpressRoute プライベート ピアリング経由でトラフィックを暗号化します。If native Azure solutions (as shown in flows B and C in the diagram) don't meet your requirements, use partner NVAs in Azure to encrypt traffic over ExpressRoute private peering.

トラフィックの検査を計画するPlan for traffic inspection

多くの業界では、組織は、詳細な検査と分析のために、Azure のトラフィックがネットワーク パケット コレクターにミラー化されることを望みます。In many industries, organizations require that traffic in Azure is mirrored to a network packet collector for deep inspection and analysis. この要件では、通常、受信と送信のインターネット トラフィックに焦点が当てられています。This requirement typically focuses on inbound and outbound internet traffic. このセクションでは、Azure Virtual Network 内のトラフィックをミラーリングまたはタップするときの主な考慮事項と推奨される方法について説明します。This section explores key considerations and recommended approaches for mirroring or tapping traffic within Azure Virtual Network.

設計上の考慮事項:Design considerations:

設計上の推奨事項:Design recommendations:

Azure 仮想ネットワーク TAP の代わりの手段としては、次のオプションを評価してください。As an alternative to Azure Virtual Network TAP, evaluate the following options:

  • キャプチャ ウィンドウは制限されていますが、Network Watcher パケットを使用してキャプチャします。Use Network Watcher packets to capture despite the limited capture window.

  • 最新バージョンの NSG フロー ログで、必要な詳細レベルが提供されるかどうかを評価します。Evaluate if the latest version of NSG flow logs provides the level of detail that you need.

  • ディープ パケット インスペクションが必要なシナリオには、パートナー ソリューションを使用します。Use partner solutions for scenarios that require deep packet inspection.

  • トラフィックをミラー化するためのカスタム ソリューションを開発しないでください。Don't develop a custom solution to mirror traffic. このアプローチは小規模なシナリオでは許容されるかもしれませんが、複雑さとサポートの問題が発生する可能性があるため、大規模に使用することは推奨されません。Although this approach might be acceptable for small-scale scenarios, we don't encourage it at scale because of complexity and the supportability issues that might arise.