仮想データセンター:ネットワーク パースペクティブThe virtual datacenter: A network perspective

オンプレミスから移行されたアプリケーションは、最小限のアプリケーション変更であっても、Azure のコスト効率の高い安全なインフラストラクチャのメリットを得られます。Applications migrated from on-premises will benefit from Azure's secure cost-efficient infrastructure, even with minimal application changes. それでも、企業は機敏性を向上させたり、Azure の機能を活用できるように、アーキテクチャを適合させる必要があります。Even so, enterprises should adapt their architectures to improve agility and take advantage of Azure's capabilities.

Microsoft Azure では、ハイパースケールのサービスとインフラストラクチャ、エンタープライズ レベルの機能と信頼性が提供されています。Microsoft Azure delivers hyperscale services and infrastructure with enterprise-grade capabilities and reliability. これらのサービスとインフラストラクチャには、ハイブリッド接続に関する多数の選択肢が用意されているため、インターネットまたはプライベート ネットワーク接続経由でアクセスすることができます。These services and infrastructure offer many choices in hybrid connectivity, so customers can choose to access them over the internet or a private network connection. また、Microsoft のパートナーも、Azure で実行するために最適化されたセキュリティ サービスと仮想アプライアンスを用意して、強化された機能を提供できます。Microsoft partners can also provide enhanced capabilities by offering security services and virtual appliances that are optimized to run in Azure.

Azure を使用すると、インフラストラクチャをクラウドにシームレスに拡張し、多層アーキテクチャを構築できます。Customers can use Azure to seamlessly extend their infrastructure into the cloud and build multitier architectures.

仮想データセンターとはWhat is a virtual datacenter?

クラウドは、パブリック向けアプリケーションをホストするためのプラットフォームとして開始されました。The cloud began as a platform for hosting public-facing applications. 企業はクラウドの価値を認め、社内の基幹業務アプリケーションの移行を始めました。Enterprises recognized the value of the cloud and began migrating internal line-of-business applications. これらのアプリケーションによってセキュリティ、信頼性、パフォーマンス、およびコストに関する考慮事項が増え、クラウド サービスの提供時に柔軟性がさらに必要とされました。These applications brought additional security, reliability, performance, and cost considerations that required additional flexibility when delivering cloud services. 新しいインフラストラクチャとネットワーク サービスがこの柔軟性を実現するように設計され、エラスティック スケールやディザスター リカバリーなどの考慮事項に対する新機能が提供されました。New infrastructure and networking services were designed to provide this flexibility, and new features provided for elastic scale, disaster recovery, and other considerations.

当初、クラウド ソリューションは、パブリック領域で単一の比較的独立したアプリケーションをホストするように設計されました。Cloud solutions were initially designed to host single, relatively isolated applications in the public spectrum. この方法は、数年間はうまくいっていました。This approach worked well for a few years. その後、クラウド ソリューションの利点が明らかになるにつれて、複数の大規模なワークロードがクラウドでホストされました。As the benefits of cloud solutions became clear, multiple large-scale workloads were hosted on the cloud. クラウド サービスのライフサイクル全体を通じて、1 つ以上のリージョンでのデプロイのセキュリティ、信頼性、パフォーマンス、コストの問題に対処することが不可欠になりました。Addressing security, reliability, performance, and cost concerns of deployments in one or more regions became vital throughout the lifecycle of the cloud service.

以下のクラウド配置ダイアグラムの例は、セキュリティ ギャップが赤枠で強調表示されています。In the example cloud deployment diagram below, the red box highlights a security gap. 黄色の枠は、ワークロード間でネットワーク仮想アプライアンスを最適化する機会を示しています。The yellow box shows an opportunity to optimize network virtual appliances across workloads.

00

仮想データセンターは、エンタープライズ ワークロードに必要なスケールの実現に役立ちます。Virtual datacenters help achieve the scale required for enterprise workloads. このスケールは、パブリック クラウドで大規模なアプリケーションを実行するときに発生する課題に対処する必要があります。This scale must address the challenges introduced when running large-scale applications in the public cloud.

仮想データセンター (VDC) の実装には、クラウド内のアプリケーション ワークロード以上のものが含まれます。A virtual datacenter (VDC) implementation includes more than the application workloads in the cloud. また、ネットワーク、セキュリティ、管理、およびその他のインフラストラクチャ (DNS や Active Directory サービスなど) も提供されます。It also provides the network, security, management, and other infrastructure such as DNS and Active Directory services. 企業が Azure に追加のワークロードを移行するときは、これらのワークロードをサポートするインフラストラクチャとオブジェクトを検討してください。As enterprises migrate additional workloads to Azure, consider the infrastructure and objects that support these workloads. リソースを慎重に構成することで、データ フロー、セキュリティ モデル、コンプライアンスに関する個別の課題を抱えた、別々に管理される数百の "ワークロード アイランド" の増殖を防ぐことができます。Carefully structuring your resources helps avoid proliferation of hundreds of separately managed "workload islands" with independent data flows, security models, and compliance challenges.

仮想データセンターの概念により、独立していながら関連するエンティティの集まりを実装するための推奨事項と概要設計が提供されます。The virtual datacenter concept provides recommendations and high-level designs for implementing a collection of separate but related entities. これらのエンティティには、多くの場合、共通のサポート関数、機能、およびインフラストラクチャがあります。These entities often have common supporting functions, features, and infrastructure. ワークロードを仮想データセンターと見なすことにより、スケール メリットと、コンポーネントおよびデータ フローの一元化によるセキュリティの最適化によってコスト削減を実現でき、運用、管理、コンプライアンス監査が容易になります。Viewing your workloads as a virtual datacenter helps realize reduced cost from economies of scale, optimized security via component and data flow centralization, and easier operations, management, and compliance audits.

注意

仮想データセンターは、特定の 1 つの Azure サービスではありませんA virtual datacenter is not a specific Azure service. そうではなく、要件を満たすためにさまざまな Azure の機能が組み合わされています。Rather, various Azure features and capabilities are combined to meet your requirements. 仮想データセンターは、クラウドのリソースと機能を最適化するための、ワークロードと Azure の使用方法についての考え方です。A virtual datacenter is a way of thinking about your workloads and Azure usage to optimize your resources and capabilities in the cloud. これは、企業の組織的な役割と責任に配慮しながら Azure で IT サービスを提供するモジュール方式のアプローチを提供します。It provides a modular approach to providing IT services in Azure while respecting the enterprise's organizational roles and responsibilities.

仮想データセンターは、企業が次のシナリオで Azure にワークロードとアプリケーションをデプロイするのに役立ちます。A virtual datacenter helps enterprises deploy workloads and applications in Azure for the following scenarios:

  • 関連する複数のワークロードをホストする。Host multiple related workloads.
  • オンプレミス環境から Azure にワークロードを移行する。Migrate workloads from an on-premises environment to Azure.
  • 複数のワークロード間に、共有または一元化されたセキュリティとアクセスの要件を実装する。Implement shared or centralized security and access requirements across workloads.
  • 大企業向けに DevOps と一元化された IT を適切に組み合わせる。Mix DevOps and centralized IT appropriately for a large enterprise.

仮想データセンターを実装する必要があるお客様Who should implement a virtual datacenter?

Azure の採用を決定したお客様は、すべてのアプリケーションから共通して使用される一連のリソースの効率的な構成を活用できるようになります。Any customer that has decided to adopt Azure can benefit from the efficiency of configuring a set of resources for common use by all applications. サイズによっては、単一のアプリケーションであっても、VDC 実装の構築に使用されるパターンとコンポーネントを利用することでメリットが得られます。Depending on the size, even single applications can benefit from using the patterns and components used to build a VDC implementation.

IT、ネットワーク、セキュリティ、またはコンプライアンスの一元化されたチームや部門が存在する組織もあります。Some organizations have centralized teams or departments for IT, networking, security, or compliance. VDC を実装することで、ポリシー ポイントの適用、責任の分担、基になる共通コンポーネントの一貫性の確保ができます。Implementing a VDC can help enforce policy points, separate responsibilities, and ensure the consistency of the underlying common components. アプリケーション チームは、要件に適した自由度と制御を維持できます。Application teams can retain the freedom and control that is suitable for their requirements.

DevOps アプローチを採用した組織は、VDC の概念を使用して、Azure リソースの承認済みのポケットを提供することもできます。Organizations with a DevOps approach can also use VDC concepts to provide authorized pockets of Azure resources. この方法により、サブスクリプション レベルで、または共通サブスクリプションのリソース グループ内のいずれかで、DevOps グループがそのグループ内で完全な制御を行うことを保証できます。This method can ensure the DevOps groups have total control within that grouping, at either the subscription level or within resource groups in a common subscription. 同時に、ネットワークとセキュリティの境界では、ハブ ネットワークおよび一元管理されたリソース グループ内の一元化されたポリシーによる定義に従ってコンプライアンスが維持されます。At the same time, the network and security boundaries stay compliant as defined by a centralized policy in the hub network and centrally managed resource group.

仮想データセンターの実装に関する考慮事項Considerations for implementing a virtual datacenter

仮想データセンターの設計時には、次の非常に重要な問題を考慮してください。When designing a virtual datacenter, consider these pivotal issues:

ID とディレクトリ サービスIdentity and directory service

ID とディレクトリ サービスは、オンプレミスとクラウドの両方のデータセンターの主要な機能です。Identity and directory services are key capabilities of both on-premises and cloud datacenters. ID は、VDC 実装内のサービスへのアクセスと認可のすべての側面を対象とします。Identity covers all aspects of access and authorization to services within a VDC implementation. 承認されたユーザーおよびプロセスのみが Azure アカウントとリソースにアクセスできるようにするため、Azure は複数の種類の資格情報を認証に使います。これには、アカウントのパスワード、暗号化キー、デジタル署名、証明書が含まれます。To ensure that only authorized users and processes access your Azure resources, Azure uses several types of credentials for authentication, including account passwords, cryptographic keys, digital signatures, and certificates. Azure Multi-Factor Authentication では、お客様が好みの方法を選択できる各種の簡単な確認オプション (電話、テキスト メッセージ、またはモバイル アプリ通知) による強力な認証を使用して、Azure サービスにアクセスするための追加のセキュリティ レイヤーが提供されます。Azure Multi-Factor Authentication provides an additional layer of security for accessing Azure services using strong authentication with a range of easy verification options (phone call, text message, or mobile app notification) that allow customers to choose the method they prefer.

大企業では、VDC 内または VDC 間での個々の ID とその認証、認可、ロール、権限の管理について説明する ID 管理プロセスを定義する必要があります。Any large enterprise needs to define an identity management process that describes the management of individual identities, their authentication, authorization, roles, and privileges within or across their VDC. このプロセスの目的は、コスト、ダウンタイム、および手作業の反復を減らしながら、セキュリティと生産性を向上させることです。The goals of this process should be to increase security and productivity while reducing cost, downtime, and repetitive manual tasks.

企業組織ではさまざまな基幹業務に必要なサービスの組み合わせに対する要求が厳しい場合があり、従業員は異なるプロジェクトに異なるロールで関係することがよくあります。Enterprise organizations may require a demanding mix of services for different lines of business, and employees often have different roles when involved with different projects. VDC では、適切なガバナンスでシステムを実行するために、それぞれ特定のロール定義を使用するさまざまなチーム間の良好な協力が必要です。The VDC requires good cooperation between different teams, each with specific role definitions, to get systems running with good governance. 責任、アクセス、権限のマトリックスは複雑になる可能性があります。The matrix of responsibilities, access, and rights can be complex. VDC の ID 管理は、Azure Active Directory (Azure AD) とロールベースのアクセス制御 (RBAC) を使用して実装されます。Identity management in the VDC is implemented through Azure Active Directory (Azure AD) and role-based access control (RBAC).

ディレクトリ サービスは、日常的な項目とネットワーク リソースを検索、管理、整理するための共有情報インフラストラクチャです。A directory service is a shared information infrastructure that locates, manages, administers, and organizes everyday items and network resources. これらのリソースには、ボリューム、フォルダー、ファイル、プリンター、ユーザー、グループ、デバイス、その他のオブジェクトが含まれます。These resources can include volumes, folders, files, printers, users, groups, devices, and other objects. ネットワーク上の各リソースは、ディレクトリ サーバーによってオブジェクトと見なされます。Each resource on the network is considered an object by the directory server. リソースに関する情報は、そのリソースまたはオブジェクトに関連付けられた属性のコレクションとして格納されます。Information about a resource is stored as a collection of attributes associated with that resource or object.

すべての Microsoft オンライン ビジネス サービスは、サインオンや他の ID のニーズに対応するために、Azure Active Directory (Azure AD) に依存しています。All Microsoft online business services rely on Azure Active Directory (Azure AD) for sign-on and other identity needs. Azure Active Directory は、統合的で可用性の高い ID とアクセス管理のクラウド ソリューションであり、コアのディレクトリ サービス、高度な ID ガバナンス、およびアプリケーション アクセス管理を組み合わせたものです。Azure Active Directory is a comprehensive, highly available identity and access management cloud solution that combines core directory services, advanced identity governance, and application access management. Azure AD をオンプレミスの Active Directory と統合することで、クラウドベースのアプリケーションとローカルでホストされているオンプレミス アプリケーションのシングル サインオンを有効にすることができます。Azure AD can integrate with on-premises Active Directory to enable single sign-on for all cloud-based and locally hosted on-premises applications. オンプレミスの Active Directory のユーザー属性は、Azure AD に自動的に同期できます。The user attributes of on-premises Active Directory can be automatically synchronized to Azure AD.

1 人のグローバル管理者が、VDC 実装のすべてのアクセス許可を割り当てる必要があるわけではありません。A single global administrator isn't required to assign all permissions in a VDC implementation. 代わりに、特定の各部門、ユーザーのグループ、またはディレクトリ サービス内のサービスが、VDC 実装内の各自のリソースを管理するために必要なアクセス許可を持つことができます。Instead, each specific department, group of users, or services in the Directory Service can have the permissions required to manage their own resources within a VDC implementation. アクセス許可を構成するにはバランスが必要です。Structuring permissions requires balancing. アクセス許可が多すぎるとパフォーマンス効率が妨げられ、アクセス許可が少なすぎたり緩すぎたりするとセキュリティ リスクが高まります。Too many permissions can impede performance efficiency, and too few or loose permissions can increase security risks. Azure のロールベースのアクセス制御 (RBAC) は、VDC 実装内のリソースに対してきめ細かいアクセス管理を実現することで、この問題への対処を支援します。Azure role-based access control (RBAC) helps to address this problem, by offering fine-grained access management for resources in a VDC implementation.

セキュリティ インフラストラクチャSecurity infrastructure

セキュリティ インフラストラクチャとは、VDC 実装の特定の仮想ネットワーク セグメントにおけるトラフィックの分離を指します。Security infrastructure refers to the segregation of traffic in a VDC implementation's specific virtual network segment. このインフラストラクチャで、VDC 実装内のイングレスとエグレスを制御する方法を指定します。This infrastructure specifies how ingress and egress are controlled in a VDC implementation. Azure の基になっているマルチテナント アーキテクチャは、仮想ネットワークの分離、アクセス制御リスト、ロード バランサー、IP フィルター、トラフィック フロー ポリシーを使って、デプロイ間の許可されていない非意図的なトラフィックを防止します。Azure is based on a multitenant architecture that prevents unauthorized and unintentional traffic between deployments by using virtual network isolation, access control lists, load balancers, IP filters, and traffic flow policies. ネットワーク アドレス変換 (NAT) は、内部ネットワーク トラフィックを外部トラフィックから分離します。Network address translation (NAT) separates internal network traffic from external traffic.

Azure ファブリックは、テナントのワークロードにインフラストラクチャ リソースを割り当て、仮想マシン (VM) との間の通信を管理します。The Azure fabric allocates infrastructure resources to tenant workloads and manages communications to and from virtual machines (VMs). Azure ハイパーバイザーは、VM 間のメモリおよびプロセスの分離を強制し、ネットワーク トラフィックをゲスト OS テナントに安全にルーティングします。The Azure hypervisor enforces memory and process separation between VMs and securely routes network traffic to guest OS tenants.

クラウドへの接続Connectivity to the cloud

仮想データセンターには、顧客、パートナー、または社内ユーザーにサービスを提供するために、外部ネットワークとの接続が必要です。A virtual datacenter requires connectivity to external networks to offer services to customers, partners, or internal users. この接続の必要性は、インターネットへの接続だけでなく、オンプレミスのネットワークとデータセンターへの接続も指します。This need for connectivity refers not only to the Internet, but also to on-premises networks and datacenters.

お客様は、パブリック インターネットと双方向にアクセスできるサービスを管理します。Customers control which services can access and be accessed from the public internet. このアクセスは、Azure Firewall または他の種類のネットワーク仮想アプライアンス (NVA)、ユーザー定義ルートを使用したカスタム ルーティング ポリシー、ネットワーク セキュリティ グループを使用したネットワーク フィルタリングを使って制御されます。This access is controlled by using Azure Firewall or other types of virtual network appliances (NVAs), custom routing policies by using user-defined routes, and network filtering by using network security groups. インターネットに接続するすべてのリソースを、Azure DDoS Protection Standard で保護することもお勧めします。We recommend that all internet-facing resources also be protected by the Azure DDoS Protection Standard.

企業によっては、仮想データセンターをオンプレミスのデータセンターや他のリソースに接続する必要があります。Enterprises may need to connect their virtual datacenter to on-premises datacenters or other resources. この Azure とオンプレミス ネットワーク間の接続は、効果的なアーキテクチャを設計するときに不可欠な要素となります。This connectivity between Azure and on-premises networks is a crucial aspect when designing an effective architecture. この相互接続を作成するには、インターネット経由またはプライベート直接接続の 2 とおりの方法があります。Enterprises have two different ways to create this interconnection: transit over the Internet or via private direct connections.

Azure サイト間 VPN は、オンプレミスのネットワークを Azure の仮想データセンターに接続します。An Azure Site-to-Site VPN connects on-premises networks to your virtual datacenter in Azure. このリンクは、セキュリティで保護された暗号化接続 (IPsec トンネル) を介して確立されます。The link is established through secure encrypted connections (IPsec tunnels). Azure サイト間 VPN 接続は柔軟性があり、迅速に作成でき、通常は追加のハードウェア調達が不要です。Azure Site-to-Site VPN connections are flexible, quick to create, and typically don't require any additional hardware procurement. 業界標準のプロトコルに基づいて、最新のネットワーク デバイスは、インターネットまたは既存の接続パスを介して Azure への VPN 接続を作成できます。Based on industry standard protocols, most current network devices can create VPN connections to Azure over the internet or existing connectivity paths.

ExpressRoute を使用すると、仮想データセンターとオンプレミス ネットワークの間のプライベート接続が可能になります。ExpressRoute enables private connections between your virtual datacenter and any on-premises networks. ExpressRoute 接続はパブリック インターネットを使わず、高いセキュリティ、信頼性、速度 (最大 100 Gbps)、および一貫した待機時間を提供します。ExpressRoute connections don't go over the public Internet, and offer higher security, reliability, and higher speeds (up to 100 Gbps) along with consistent latency. ExpressRoute により、プライベート接続に関連付けられたコンプライアンス規則のベネフィットが得られます。ExpressRoute provides the benefits of compliance rules associated with private connections. ExpressRoute Direct を使用すると、10 Gbps または 100 Gbps で Microsoft ルーターに直接接続することができます。With ExpressRoute Direct, you can connect directly to Microsoft routers at either 10 Gbps or 100 Gbps.

通常、ExpressRoute 接続のデプロイでは、ExpressRoute サービス プロバイダーと連携する必要があります (ExpressRoute Direct は例外です)。Deploying ExpressRoute connections usually involves engaging with an ExpressRoute service provider (ExpressRoute Direct being the exception). 迅速に開始する必要があるお客様の場合は、最初にサイト間 VPN を使用して、仮想データセンターとオンプレミスのリソース間の接続を確立するのが一般的です。For customers that need to start quickly, it's common to initially use Site-to-Site VPN to establish connectivity between a virtual datacenter and on-premises resources. その後、サービス プロバイダーとの物理的な相互接続が完了したら、接続を ExpressRoute 接続に移行します。Once your physical interconnection with your service provider is complete, then migrate connectivity over your ExpressRoute connection.

多くの VPN または ExpressRoute 接続において、Azure Virtual WAN は、Azure を介してブランチ間接続を最適化し、自動化するネットワーク サービスです。For large numbers of VPN or ExpressRoute connections, Azure Virtual WAN is a networking service that provides optimized and automated branch-to-branch connectivity through Azure. Virtual WAN を使用すると、ブランチ デバイスに接続して Azure と通信するように構成できます。Virtual WAN lets you connect to and configure branch devices to communicate with Azure. 接続と構成は、手動で行うことも、Virtual WAN パートナーを通じて推奨プロバイダー デバイスを使用して行うこともできます。Connecting and configuring can be done either manually or by using preferred provider devices through a Virtual WAN partner. 推奨プロバイダー デバイスを使用すると、使いやすさ、接続の簡素化、および構成管理を実現できます。Using preferred provider devices allows ease of use, simplification of connectivity, and configuration management. Azure WAN の組み込みダッシュボードにはすぐに使用できるトラブルシューティング用分析情報が用意されているため、時間を節約でき、大規模なサイト間接続を簡単に表示することができます。The Azure WAN built-in dashboard provides instant troubleshooting insights that can help save you time, and gives you an easy way to view large-scale site-to-site connectivity. また、Virtual WAN は、オプションの Azure Firewall と Firewall Manager を含むセキュリティ サービスを Virtual WAN ハブに提供します。Virtual WAN also provides security services with an optional Azure Firewall and Firewall Manager in your Virtual WAN hub.

クラウド内の接続Connectivity within the cloud

Azure Virtual Network仮想ネットワーク ピアリングは、仮想データ センター内の基本的なネットワーク コンポーネントです。Azure Virtual Networks and virtual network peering are the basic networking components in a virtual datacenter. 仮想ネットワークは、仮想データセンターのリソースの分離境界を保証します。A virtual network guarantees an isolation boundary for virtual datacenter resources. ピアリングを使用すると、同じ Azure リージョン内の異なる仮想ネットワーク間、リージョン間、および異なるサブスクリプション内のネットワーク間でも相互通信ができます。Peering allows intercommunication between different virtual networks within the same Azure region, across regions, and even between networks in different subscriptions. トラフィック フローは、仮想ネットワーク内とその間の両方で、ネットワーク セキュリティ グループ、ファイアウォール ポリシー (Azure Firewall またはネットワーク仮想アプライアンス)、およびカスタムのユーザー定義ルートに対して指定されたセキュリティ規則のセットによって制御できます。Both inside and between virtual networks, traffic flows can be controlled by sets of security rules specified for network security groups, firewall policies (Azure Firewall or network virtual appliances), and custom user-defined routes.

仮想ネットワークは、サービスとしてのプラットフォーム (PaaS) Azure 製品 (Azure StorageAzure SQL、パブリック エンドポイントを持つその他の統合されたパブリック サービスなど) を統合するためのアンカー ポイントでもあります。Virtual networks are also anchor points for integrating platform as a service (PaaS) Azure products like Azure Storage, Azure SQL, and other integrated public services that have public endpoints. サービス エンドポイントAzure Private Link を使用して、パブリック サービスをプライベート ネットワークと統合できます。With service endpoints and Azure Private Link, you can integrate your public services with your private network. パブリック サービスをプライベートにすることもできますが、それでも Azure マネージド PaaS サービスのベネフィットを享受できます。You can even take your public services private, but still enjoy the benefits of Azure-managed PaaS services.

仮想データセンターの概要Virtual datacenter overview

トポロジTopologies

仮想データセンターは、ニーズとスケール要件に基づいて、次のような高レベルのトポロジのいずれかを使用して構築できます。A virtual datacenter can be built using one of these high-level topologies, based on your needs and scale requirements:

"フラット トポロジ" では、すべてのリソースが 1 つの仮想ネットワークにデプロイされます。In a Flat topology, all resources are deployed in a single virtual network. サブネットではフロー制御と分離が許可されます。Subnets allow for flow control and segregation.

1111

"メッシュ トポロジ" では、仮想ネットワーク ピアリングによって、すべての仮想ネットワークが相互に直接接続されます。In a Mesh topology, virtual network peering connects all virtual networks directly to each other.

1212

"ピアリングハブ アンド スポーク トポロジ" は、責任を委任された分散アプリケーションやチームに非常に適しています。A Peering hub and spoke topology is well suited for distributed applications and teams with delegated responsibilities.

1313

"Azure Virtual WAN トポロジ" では、大規模なブランチ オフィス シナリオとグローバル WAN サービスをサポートできます。An Azure Virtual WAN topology can support large-scale branch office scenarios and global WAN services.

1414

ピアリング ハブ アンド スポーク トポロジと Azure Virtual WAN トポロジではいずれも、通信、共有リソース、および一元化されたセキュリティ ポリシーに最適であるハブ アンド スポーク設計が使用されています。The peering hub and spoke topology and the Azure Virtual WAN topology both use a hub and spoke design, which is optimal for communication, shared resources, and centralized security policy. ハブは、仮想ネットワーク ピアリング ハブ (図では Hub Virtual Network と表示) または Virtual WAN ハブ (図では Azure Virtual WAN と表示) を使用して構築されます。Hubs are built using either a virtual network peering hub (labeled as Hub Virtual Network in the diagram) or a Virtual WAN hub (labeled as Azure Virtual WAN in the diagram). Azure Virtual WAN は、大規模なブランチ間と、ブランチから Azure への通信用に設計されています。また、仮想ネットワーク ピアリング ハブですべてのコンポーネントを個別に構築する複雑さを回避する目的もあります。Azure Virtual WAN is designed for large-scale branch-to-branch and branch-to-Azure communications, or for avoiding the complexities of building all the components individually in a virtual networking peering hub. 要件 (ハブ内にネットワーク仮想アプライアンスが必要など) によっては、仮想ネットワーク ピアリング ハブの設計が必要になる場合があります。In some cases, your requirements might mandate a virtual network peering hub design, such as the need for network virtual appliances in the hub.

ハブとスポークの両方のトポロジにおいて、ハブは異なるゾーン (インターネット、オンプレミス、スポーク) 間のトラフィックをすべて制御および検査する中央ネットワーク ゾーンです。In both of the hub and spoke topologies, the hub is the central network zone that controls and inspects all traffic between different zones: internet, on-premises, and the spokes. ハブ アンド スポーク トポロジは、IT 部門によるセキュリティ ポリシーの一元的な適用に役立ちます。The hub and spoke topology helps the IT department centrally enforce security policies. また、構成の誤りや露出の可能性も低減されます。It also reduces the potential for misconfiguration and exposure.

多くの場合、ハブには、スポークによって消費される共通のサービス コンポーネントが含まれます。The hub often contains the common service components consumed by the spokes. 共通の中央サービスの例を次に示します。The following examples are common central services:

  • 信頼されていないネットワークからアクセスするサード パーティがスポーク内のワークロードにアクセスする前のユーザー認証に必要な Windows Active Directory インフラストラクチャ。The Windows Active Directory infrastructure, required for user authentication of third parties that access from untrusted networks before they get access to the workloads in the spoke. これには、関連する Active Directory フェデレーション サービス (AD FS) が含まれます。It includes the related Active Directory Federation Services (AD FS).
  • オンプレミスおよびインターネット上のリソースにアクセスするための、スポーク内のワークロードの名前付けを解決する分散ネーム システム (DNS) サービス (Azure DNS が使用されていない場合)。A Distributed Name System (DNS) service to resolve naming for the workload in the spokes, to access resources on-premises and on the internet if Azure DNS isn't used.
  • ワークロードにシングル サインオンを実装するための公開キー基盤 (PKI)。A public key infrastructure (PKI), to implement single sign-on on workloads.
  • スポーク ネットワーク ゾーンとインターネット間の TCP/UDP トラフィックのフロー制御。Flow control of TCP and UDP traffic between the spoke network zones and the internet.
  • スポークとオンプレミス間のフロー制御。Flow control between the spokes and on-premises.
  • (必要に応じて) スポーク間のフロー制御。If needed, flow control between one spoke and another.

仮想データセンターでは、複数のスポーク間で共有ハブ インフラストラクチャを使用することで、全体的なコストを削減します。A virtual datacenter reduces overall cost by using the shared hub infrastructure between multiple spokes.

各スポークのロールは、異なる種類のワークロードをホストできます。The role of each spoke can be to host different types of workloads. スポークは、同じワークロードの反復可能なデプロイのためのモジュール方式のアプローチも提供します。The spokes also provide a modular approach for repeatable deployments of the same workloads. 例として、開発/テスト、ユーザー受け入れテスト、運用前環境、運用環境があります。Examples include dev/test, user acceptance testing, preproduction, and production. スポークでは、組織内のさまざまなグループを分離して有効にすることもできます。The spokes can also segregate and enable different groups within your organization. 例として DevOps グループがあります。An example is DevOps groups. スポーク内には、基本的なワークロードや、階層間のトラフィック制御を伴う複雑な多層ワークロードをデプロイできます。Inside a spoke, it's possible to deploy a basic workload or complex multitier workloads with traffic control between the tiers.

サブスクリプションの制限と複数のハブSubscription limits and multiple hubs

重要

Azure デプロイのサイズに基づき、複数ハブの戦略が必要になる場合があります。Based on the size of your Azure deployments, a multiple hub strategy may be needed. ハブ アンド スポークの戦略を設計するときに、"このリージョンで別のハブ仮想ネットワークを使用するためにこの設計でスケーリング可能か"、また"複数のリージョンに対応するためにこの設計でスケーリング可能か" を確認してください。When designing your hub and spoke strategy, ask "can this design scale to use another hub virtual network in this region?", also, "can this design scale to accommodate multiple regions?" スケーリングする設計の計画を立てたが必要にならない方が、計画しないでそれが必要になるよりもはるかにましです。It's far better to plan for a design that scales and not need it, than to fail to plan and need it.

セカンダリ (またはそれ以上) のハブにスケーリングするタイミングは、通常、スケールに固有の制限に基づく、多種多様な要因に依存します。When to scale to a secondary (or more) hub will depend on myriad factors, usually based on inherent limits on scale. スケールの設計時には、サブスクリプション、仮想ネットワーク、および仮想マシンの制限を必ず確認してください。Be sure to review the subscription, virtual network, and virtual machine limits when designing for scale.

Azure では、種類に関係なく、すべてのコンポーネントが Azure サブスクリプションにデプロイされます。In Azure, every component, whatever the type, is deployed in an Azure subscription. 異なる Azure サブスクリプションに Azure コンポーネントを分離することで、差別化されたレベルのアクセスと承認の設定など、さまざまな業種の要件を満たすことができます。The isolation of Azure components in different Azure subscriptions can satisfy the requirements of different lines of business, such as setting up differentiated levels of access and authorization.

1 つの VDC 実装で多数のスポークにスケールアップできますが、他の IT システムと同様に、プラットフォームの制限があります。A single VDC implementation can scale up to large number of spokes, although, as with every IT system, there are platform limits. ハブのデプロイは特定の Azure サブスクリプションにバインドされており、これには制約と制限があります (仮想ネットワーク ピアリングの最大数など)。The hub deployment is bound to a specific Azure subscription, which has restrictions and limits (for example, a maximum number of virtual network peerings. 詳細については、「Azure サブスクリプションとサービスの制限、クォータ、制約」をご覧ください。For details, see Azure subscription and service limits, quotas, and constraints). 制限が問題になる可能性がある場合は、単一のハブとスポークからハブとスポークのクラスターにモデルを拡張することによって、アーキテクチャをさらに拡張できます。In cases where limits may be an issue, the architecture can scale up further by extending the model from a single hub-spokes to a cluster of hub and spokes. 1 つ以上の Azure リージョン内の複数のハブを、仮想ネットワーク ピアリング、ExpressRoute、Virtual WAN、またはサイト間 VPN を使用して接続できます。Multiple hubs in one or more Azure regions can be connected using virtual network peering, ExpressRoute, Virtual WAN, or site-to-site VPN.

22

複数のハブを導入すると、システムのコストと管理作業が増加します。The introduction of multiple hubs increases the cost and management effort of the system. それが妥当なのは、スケーラビリティ、システムの制限、冗長性、エンドユーザーのパフォーマンスのためのリージョン レプリケーション、またはディザスター リカバリーに起因する場合のみです。It is only justified due to scalability, system limits, redundancy, regional replication for end-user performance, or disaster recovery. 複数のハブが必要なシナリオでは、運用を容易にするため、すべてのハブで同じサービスのセットを提供する必要があります。In scenarios requiring multiple hubs, all the hubs should strive to offer the same set of services for operational ease.

スポーク間の相互接続Interconnection between spokes

1 つのスポーク (フラット ネットワーク設計) 内に、複雑な多層ワークロードを実装できます。Inside a single spoke, or a flat network design, it's possible to implement complex multitier workloads. 多階層の構成は、同じ仮想ネットワーク内のサブネット (階層またはアプリケーションごとに 1 つ) を使用して実装できます。Multitier configurations can be implemented using subnets, one for every tier or application, in the same virtual network. トラフィック制御とフィルター処理は、ネットワーク セキュリティ グループとユーザー定義ルートを使用して行われます。Traffic control and filtering are done using network security groups and user-defined routes.

アーキテクトは、複数の仮想ネットワークに多層ワークロードをデプロイできます。An architect might want to deploy a multitier workload across multiple virtual networks. 仮想ネットワーク ピアリングにより、スポークは同じハブまたは異なるハブの他のスポークに接続できます。With virtual network peering, spokes can connect to other spokes in the same hub or different hubs. このシナリオの一般的な例は、アプリケーション処理サーバーが 1 つのスポーク (仮想ネットワーク) にあるケースです。A typical example of this scenario is the case where application processing servers are in one spoke, or virtual network. データベースは別のスポーク (仮想ネットワーク) にデプロイされています。The database deploys in a different spoke, or virtual network. この場合、仮想ネットワーク ピアリングでスポークを相互接続することは簡単です。そうすることによって、ハブの通過を容易に回避できます。In this case, it's easy to interconnect the spokes with virtual network peering and, by doing that, avoid transiting through the hub. ハブをバイパスすることで、ハブにしか存在しない重要なセキュリティ ポイントや監査ポイントがバイパスされることがないように、アーキテクチャとセキュリティを慎重に見直す必要があります。A careful architecture and security review should be done to ensure that bypassing the hub doesn't bypass important security or auditing points that might exist only in the hub.

33

スポークは、ハブとして機能するスポークに相互接続することもできます。Spokes can also be interconnected to a spoke that acts as a hub. この方法では 2 レベルの階層が作成され、上位レベル (レベル 0) のスポークが、階層の下位レベル (レベル 1) のスポークのハブになります。This approach creates a two-level hierarchy: the spoke in the higher level (level 0) becomes the hub of lower spokes (level 1) of the hierarchy. VDC 実装のスポークは、トラフィックがオンプレミス ネットワークまたはパブリック インターネットのいずれかで送信先に到達できるように、中央のハブにトラフィックを転送する必要があります。The spokes of a VDC implementation are required to forward the traffic to the central hub so that the traffic can transit to its destination in either the on-premises network or the public internet. 2 レベルのハブのアーキテクチャでは複雑なルーティングが導入され、シンプルなハブ スポーク関係のメリットが失われます。An architecture with two levels of hubs introduces complex routing that removes the benefits of a simple hub-spoke relationship.

Azure では複雑なトポロジを構成できますが、VDC の概念の中核となる原則の 1 つは再現性と単純さです。Although Azure allows complex topologies, one of the core principles of the VDC concept is repeatability and simplicity. 管理作業を最小限に抑えるために、単純なハブ スポーク設計が、推奨される VDC 参照アーキテクチャです。To minimize management effort, the simple hub-spoke design is the VDC reference architecture that we recommend.

コンポーネントComponents

仮想データセンターは、4 種類の基本的なコンポーネントで構成されています。インフラストラクチャ境界ネットワークワークロード、および監視です。The virtual datacenter is made up of four basic component types: Infrastructure, Perimeter Networks, Workloads, and Monitoring.

各コンポーネントの種類は、さまざまな Azure の機能とリソースで構成されます。Each component type consists of various Azure features and resources. VDC 実装は、複数のコンポーネントの種類のインスタンスと、同じコンポーネントの種類の複数のバリエーションで構成されます。Your VDC implementation is made up of instances of multiple components types and multiple variations of the same component type. たとえば、異なるアプリケーションを表す多数の異なる論理的に分離されたワークロード インスタンスを使用できます。For instance, you may have many different, logically separated workload instances that represent different applications. これらのさまざまなコンポーネントの種類とインスタンスを使って、最終的に VDC を構築します。You use these different component types and instances to ultimately build the VDC.

44

VDC の上記のおおまかな概念アーキテクチャでは、ハブ スポーク トポロジのさまざまなゾーンで使用されるさまざまなコンポーネントの種類が示されています。The preceding high-level conceptual architecture of the VDC shows different component types used in different zones of the hub-spokes topology. 図では、アーキテクチャのさまざまな部分にインフラストラクチャ コンポーネントが示されています。The diagram shows infrastructure components in various parts of the architecture.

一般的には、アクセス権と特権をグループ ベースにすることをお勧めします。As good practice in general, access rights and privileges should be group-based. 個々のユーザーではなくグループを処理すれば、チーム間に一貫した管理方法を用意することでアクセス ポリシーの保守が容易になります。さらに、構成エラーを最小限に抑えることにも役立ちます。Dealing with groups rather than individual users eases maintenance of access policies, by providing a consistent way to manage it across teams, and aids in minimizing configuration errors. 適切なグループに対するユーザーの割り当てや削除を行うことで、特定のユーザーの権限を最新に保つことができます。Assigning and removing users to and from appropriate groups helps keeping the privileges of a specific user up to date.

各ロール グループの名前には、一意のプレフィックスが必要です。Each role group should have a unique prefix on their names. このプレフィックスにより、グループとワークロードの関連付けを識別しやすくなります。This prefix makes it easy to identify which group is associated with which workload. たとえば、認証サービスをホストしているワークロードでは、グループに AuthServiceNetOpsAuthServiceSecOpsAuthServiceDevOpsAuthServiceInfraOps という名前を付けます。For example, a workload hosting an authentication service might have groups named AuthServiceNetOps, AuthServiceSecOps, AuthServiceDevOps, and AuthServiceInfraOps. 一元化されたロール (特定のサービスに関係しないロール) には、Corp というプレフィックスを付けます (例: CorpNetOps)。Centralized roles, or roles not related to a specific service, might be prefaced with Corp. An example is CorpNetOps.

多くの組織では、次のグループのバリエーションを使って、ロールが大きく分類されています。Many organizations use a variation of the following groups to provide a major breakdown of roles:

  • 中央 IT チーム (Corp) は、インフラストラクチャ コンポーネントを制御するための所有者権限を持ちます。The central IT team, Corp, has the ownership rights to control infrastructure components. コンポーネントの例として、ネットワークとセキュリティがあります。Examples are networking and security. このグループには、サブスクリプションの共同作業者のロールとスポークのネットワーク共同作成者権限が必要であり、ハブを制御できる必要があります。The group needs to have the role of contributor on the subscription, control of the hub, and network contributor rights in the spokes. 多くの場合、大規模な組織では、これらの管理責任を複数のチームが分担します。Large organizations frequently split up these management responsibilities between multiple teams. たとえば、ネットワーク運用 (CorpNetOps) グループはネットワークだけを担当し、セキュリティ運用 (CorpSecOps) グループはファイアウォールとセキュリティ ポリシーを担当します。Examples are a network operations CorpNetOps group with exclusive focus on networking and a security operations CorpSecOps group responsible for the firewall and security policy. この場合、カスタム ロールの割り当て用に 2 つの異なるグループを作成する必要があります。In this specific case, two different groups need to be created for assignment of these custom roles.
  • 開発/テスト グループ (AppDevOps) は、アプリまたはサービス ワークロードをデプロイする役割を担います。The dev/test group, AppDevOps, has the responsibility to deploy app or service workloads. このグループには、IaaS デプロイの仮想マシン共同作成者のロール、または 1 つ以上の PaaS 共同作成者のロールが割り当てられます。This group takes the role of virtual machine contributor for IaaS deployments or one or more PaaS contributor's roles. 詳細については、「Azure リソースの組み込みロール」を参照してください。For more information, see Built-in roles for Azure resources. 場合によっては、開発とテスト チームは、ハブまたは特定のスポーク内のセキュリティ ポリシー (ネットワーク セキュリティ グループ) とルーティング ポリシー (ユーザー定義ルート) を表示できる必要があります。Optionally, the dev/test team might need visibility on security policies (network security groups) and routing policies (user-defined routes) inside the hub or a specific spoke. その場合、このグループには、ワークロードの共同作成者のロールに加え、ネットワーク閲覧者のロールも必要になります。In addition to the role of contributor for workloads, this group would also need the role of network reader.
  • 運用とメンテナンス グループ (CorpInfraOps または AppInfraOps) は、運用環境のワークロードを管理する役割を担います。The operation and maintenance group, CorpInfraOps or AppInfraOps, has the responsibility of managing workloads in production. このグループは、運用サブスクリプションのワークロードのサブスクリプション共同作成者である必要があります。This group needs to be a subscription contributor on workloads in any production subscriptions. 一部の組織では、運用環境のサブスクリプション共同作成者のロールと中央ハブ サブスクリプションを持つ、追加のエスカレーション サポート チーム グループが必要かどうかを評価することもあります。Some organizations might also evaluate if they need an additional escalation support team group with the role of subscription contributor in production and the central hub subscription. この追加のグループは、運用環境における潜在的な構成の問題を修正します。The additional group fixes potential configuration issues in the production environment.

VDC は、ハブを管理する中央 IT チーム用に作成されたグループがワークロード レベルで対応するグループを持つように設計されています。The VDC is designed so that groups created for the central IT team, managing the hub, have corresponding groups at the workload level. ハブ リソースを管理するだけでなく、中央 IT チームはサブスクリプションでの外部アクセスと最上位レベルのアクセス許可を制御できます。In addition to managing hub resources only, the central IT team can control external access and top-level permissions on the subscription. また、ワークロード グループは、それぞれの仮想ネットワークのリソースとアクセス許可を中央 IT チームから独立して制御することもできます。Workload groups can also control resources and permissions of their virtual network independently from the central IT team.

仮想データセンターは、さまざまな基幹業務にわたって複数のプロジェクトを安全にホストできるように、パーティション分割されています。The virtual datacenter is partitioned to securely host multiple projects across different lines of business. すべてのプロジェクトでさまざまな分離環境 (開発、UAT、運用) が必要になります。All projects require different isolated environments (dev, UAT, and production). これらの環境ごとに Azure サブスクリプションを分けると、自然な分離を実現できます。Separate Azure subscriptions for each of these environments can provide natural isolation.

55

上記の図は、組織のプロジェクト、ユーザー、グループ間の関係と、Azure のコンポーネントがデプロイされている環境を示しています。The preceding diagram shows the relationship between an organization's projects, users, and groups and the environments where the Azure components are deployed.

通常、IT の環境 (または階層) は、複数のアプリケーションがデプロイされて実行されるシステムです。Typically in IT, an environment (or tier) is a system in which multiple applications are deployed and executed. 大規模な企業では、開発環境 (変更が行われてテストされる場所) と運用環境 (エンドユーザーが使うもの) が使われます。Large enterprises use a development environment (where changes are made and tested) and a production environment (what end-users use). これらの環境は分離され、多くの場合、その間に複数のステージング環境があり、段階的にデプロイ (ロールアウト)、テスト、および問題が発生した場合のロールバックを行うことができます。Those environments are separated, often with several staging environments in between them to allow phased deployment (rollout), testing, and rollback if problems arise. デプロイ アーキテクチャは大きく異なりますが、通常、開発 (DEV) で始まって運用 (PROD) で終わる基本的なプロセスは同じです。Deployment architectures vary significantly, but usually the basic process of starting at development (DEV) and ending at production (PROD) is still followed.

この種の多層環境の一般的なアーキテクチャは、開発およびテスト用の DevOps、ステージング用の UAT、運用環境で構成されます。A common architecture for these types of multitier environments consists of DevOps for development and testing, UAT for staging, and production environments. 組織では、1 つまたは複数の Azure AD テナントを使用して、これらの環境に対するアクセスと権限を定義できます。Organizations can use single or multiple Azure AD tenants to define access and rights to these environments. 前の図では、DevOps および UAT 用と運用専用の 2 つ異なる Azure AD テナントが使われている場合が示されています。The previous diagram shows a case where two different Azure AD tenants are used: one for DevOps and UAT, and the other exclusively for production.

異なる Azure AD テナントが存在すると、必然的に環境間が分離されます。The presence of different Azure AD tenants enforces the separation between environments. プロジェクトの DevOps または運用環境のロールやアクセス許可を変更するために別の Azure AD テナントにアクセスするには、同じユーザー グループ (中央 IT チームなど) が、異なる URI を使用して認証する必要があります。The same group of users, such as the central IT team, need to authenticate by using a different URI to access a different Azure AD tenant to modify the roles or permissions of either the DevOps or production environments of a project. 環境にアクセスするときに、環境ごとに異なるユーザー認証が存在すると、人的エラーが原因で発生する可能性のある停止や他の問題が減少します。The presence of different user authentications to access different environments reduces possible outages and other issues caused by human errors.

コンポーネントの種類:インフラストラクチャComponent type: Infrastructure

このコンポーネントの種類には、ほとんどのサポート インフラストラクチャが存在します。This component type is where most of the supporting infrastructure resides. また、一元化された IT、セキュリティ、コンプライアンスのチームが時間の大半を費やす部分でもあります。It's also where your centralized IT, security, and compliance teams spend most of their time.

66

インフラストラクチャ コンポーネントは、VDC 実装のさまざまなコンポーネントに相互接続を提供し、ハブとスポークの両方に存在します。Infrastructure components provide an interconnection for the different components of a VDC implementation, and are present in both the hub and the spokes. インフラストラクチャ コンポーネントの管理と保守の責任は、通常、中央 IT チームまたはセキュリティ チームに割り当てられます。The responsibility for managing and maintaining the infrastructure components is typically assigned to the central IT team or security team.

IT インフラストラクチャ チームの主要なタスクの 1 つは、企業全体にわたって一貫した IP アドレス スキーマを保証することです。One of the primary tasks of the IT infrastructure team is to guarantee the consistency of IP address schemas across the enterprise. VDC 実装に割り当てられたプライベート IP アドレス空間は、一貫性があり、オンプレミスのネットワークで割り当てられたプライベート IP アドレスと重複していない必要があります。The private IP address space assigned to a VDC implementation must be consistent and NOT overlapping with private IP addresses assigned on your on-premises networks.

オンプレミスのエッジ ルーター上または Azure 環境内の NAT は、IP アドレスの競合を回避できますが、インフラストラクチャ コンポーネントが複雑になります。While NAT on the on-premises edge routers or in Azure environments can avoid IP address conflicts, it adds complications to your infrastructure components. 管理の簡単さが VDC の主な目標の 1 つなので、NAT を使って IP の問題を処理することは有効なソリューションではあるものの、推奨されるソリューションではありません。Simplicity of management is one of the key goals of the VDC, so using NAT to handle IP concerns, while a valid solution, is not a recommended solution.

インフラストラクチャ コンポーネントは次の機能を備えています。Infrastructure components have the following functionality:

  • ID とディレクトリ サービスIdentity and directory services. Azure のすべてのリソース種類へのアクセスは、ディレクトリ サービスに格納された ID によって制御されます。Access to every resource type in Azure is controlled by an identity stored in a directory service. ディレクトリ サービスは、ユーザーのリストだけでなく、特定の Azure サブスクリプション内のリソースへのアクセス権も格納しています。The directory service stores not only the list of users, but also the access rights to resources in a specific Azure subscription. これらのサービスは、クラウドのみに存在することも、Active Directory に格納されたオンプレミスの ID と同期することもできます。These services can exist cloud-only, or they can be synchronized with on-premises identity stored in Active Directory.
  • Virtual NetworkVirtual Network. Virtual Network は、VDC の主要コンポーネントの 1 つであり、Azure プラットフォーム上にトラフィックの分離境界を作成できるようにします。Virtual networks are one of main components of the VDC, and enable you to create a traffic isolation boundary on the Azure platform. 仮想ネットワークは、1 つまたは複数の仮想ネットワーク セグメントで構成され、それぞれが特定の IP ネットワーク プレフィックス (サブネット、IPv4 またはデュアルスタック IPv4/IPv6 のいずれか) を持ちます。A virtual network is composed of a single or multiple virtual network segments, each with a specific IP network prefix (a subnet, either IPv4 or dual stack IPv4/IPv6). 仮想ネットワークにより、IaaS 仮想マシンと PaaS サービスがプライベート通信を確立できる内部境界領域が定義されます。The virtual network defines an internal perimeter area where IaaS virtual machines and PaaS services can establish private communications. ある仮想ネットワーク内のVM (および PaaS サービス) と異なる仮想ネットワーク内の VM (および PaaS サービス) は、両方の仮想ネットワークが同じお客様によって同じサブスクリプションの下で作成された場合でも、直接通信することはできません。VMs (and PaaS services) in one virtual network can't communicate directly to VMs (and PaaS services) in a different virtual network, even if both virtual networks are created by the same customer, under the same subscription. 分離は、顧客の VM と通信が仮想ネットワーク内でプライベートであることを保証する重要な特性です。Isolation is a critical property that ensures customer VMs and communication remains private within a virtual network. ネットワーク間接続が必要な場合、以下の機能でそれをどのように実現できるかについて説明します。Where cross-network connectivity is desired, the following features describe how that can be accomplished.
  • 仮想ネットワーク ピアリングVirtual network peering. VDC のインフラストラクチャの作成に使用される基本的な機能は、仮想ネットワーク ピアリングです。これは、Azure データ センター ネットワーク経由、またはリージョンをまたがる Azure の世界規模のバックボーンを使用して、同じリージョンの 2 つの仮想ネットワークを接続します。The fundamental feature used to create the infrastructure of a VDC is virtual network peering, which connects two virtual networks in the same region, either through the Azure datacenter network or using the Azure worldwide backbone across regions.
  • Virtual Network サービス エンドポイントVirtual Network service endpoints. サービス エンドポイントにより、PaaS 空間を含めるように、仮想ネットワークのプライベート アドレス空間が拡張されます。Service endpoints extend your virtual network private address space to include your PaaS space. さらに、このエンドポイントでは、仮想ネットワークの ID が直接接続を介して Azure サービスまで拡張されます。The endpoints also extend the identity of your virtual network to the Azure services over a direct connection. エンドポイントを使用することで、重要な Azure サービス リソースへのアクセスを仮想ネットワークのみに限定することができます。Endpoints allow you to secure your critical Azure service resources to only your virtual networks.
  • Private LinkPrivate Link. Azure Private Link を使用すると、仮想ネットワーク内のプライベート エンドポイント経由で Azure PaaS サービス (Azure StorageAzure Cosmos DBAzure SQL Database など) と Azure でホストされている顧客/パートナー サービスにアクセスできます。Azure Private Link enables you to access Azure PaaS Services (for example, Azure Storage, Azure Cosmos DB, and Azure SQL Database) and Azure hosted customer/partner services over a Private Endpoint in your virtual network. 仮想ネットワークとサービスの間のトラフィックは、Microsoft のバックボーン ネットワークを経由して、パブリック インターネットからの公開を排除します。Traffic between your virtual network and the service traverses over the Microsoft backbone network, eliminating exposure from the public Internet. また、独自のPrivate Link サービスを仮想ネットワークに作成し、そのサービスを顧客に非公開で配信することもできます。You can also create your own Private Link Service in your virtual network and deliver it privately to your customers. Azure Private Link を使用した設定と消費のエクスペリエンスは、Azure PaaS サービス、顧客所有サービス、共有パートナー サービス間で一貫しています。The setup and consumption experience using Azure Private Link is consistent across Azure PaaS, customer-owned, and shared partner services.
  • ユーザー定義ルートUser-defined routes. 仮想ネットワーク内のトラフィックは、システム ルーティング テーブルに基づいて既定でルーティングされます。Traffic in a virtual network is routed by default based on the system routing table. ユーザー定義ルートはカスタム ルーティング テーブルであり、ネットワーク管理者はそれを 1 つ以上のサブネットに関連付けることで、システム ルーティング テーブルの動作をオーバーライドし、仮想ネットワーク内の通信パスを定義することができます。A user-defined route is a custom routing table that network administrators can associate to one or more subnets to override the behavior of the system routing table and define a communication path within a virtual network. ユーザー定義ルートが存在すると、スポークからのエグレス トラフィックが特定のカスタム VM を通過するか、ネットワーク仮想アプライアンスとロード バランサーがハブとスポークの両方に存在することが保証されます。The presence of user-defined routes guarantees that egress traffic from the spoke transit through specific custom VMs or network virtual appliances and load balancers present in both the hub and the spokes.
  • ネットワーク セキュリティ グループNetwork security groups. ネットワーク セキュリティ グループは、IP 送信元、IP 送信先、プロトコル、IP 送信元ポート、IP 送信先ポート (レイヤー 4 の 5 タプルとも呼ばれます) 上のトラフィック フィルターとして機能するセキュリティ規則のリストです。A network security group is a list of security rules that act as traffic filtering on IP sources, IP destinations, protocols, IP source ports, and IP destination ports (also called a Layer 4 five-tuple). ネットワーク セキュリティ グループは、サブネット、Azure VM に関連付けられた仮想 NIC のどちらか一方または両方に適用できます。The network security group can be applied to a subnet, a Virtual NIC associated with an Azure VM, or both. ネットワーク セキュリティ グループは、ハブとスポークに正しいフロー制御を実装するうえで不可欠です。The network security groups are essential to implement a correct flow control in the hub and in the spokes. ネットワーク セキュリティ グループによって提供されるセキュリティのレベルは、どのポートをどのような目的で開くのかによって決まります。The level of security afforded by the network security group is a function of which ports you open, and for what purpose. お客様は、iptables や Windows ファイアウォールなどのホストベースのファイアウォールを使用して、VM ごとの追加フィルターを適用する必要があります。Customers should apply additional per-VM filters with host-based firewalls such as iptables or the Windows Firewall.
  • DNSDNS. DNS は、仮想データセンター内のリソースの名前解決を提供します。DNS provides name resolution for resources in a virtual datacenter. Azure は、パブリックプライベートの両方の名前解決用に DNS サービスを提供します。Azure provides DNS services for both public and private name resolution. プライベート ゾーンは、仮想ネットワーク内での名前解決と仮想ネットワーク間での名前解決を両方提供します。Private zones provide name resolution both within a virtual network and across virtual networks. プライベート ゾーンは、同じリージョンの複数の仮想ネットワークをまたぐだけでなく、複数のリージョンおよびサブスクリプションをまたぐことができます。You can have private zones not only span across virtual networks in the same region, but also across regions and subscriptions. パブリック解決の場合、Azure DNS は、DNS ドメインのホスティング サービスであり、Microsoft Azure インフラストラクチャを使用した名前解決を提供します。For public resolution, Azure DNS provides a hosting service for DNS domains, providing name resolution using Microsoft Azure infrastructure. Azure でドメインをホストすることで、その他の Azure サービスと同じ資格情報、API、ツール、課金情報を使用して DNS レコードを管理できます。By hosting your domains in Azure, you can manage your DNS records using the same credentials, APIs, tools, and billing as your other Azure services.
  • 管理グループサブスクリプション、およびリソース グループの管理。Management group, subscription, and resource group management. サブスクリプションでは、Azure にリソースの複数のグループを作成する自然な境界が定義されています。A subscription defines a natural boundary to create multiple groups of resources in Azure. この分離は、関数、ロールの分離、または課金用です。This separation can be for function, role segregation, or billing. サブスクリプションのリソースは、リソース グループと呼ばれる論理コンテナーにまとめられています。Resources in a subscription are assembled together in logical containers known as resource groups. リソース グループは、仮想データセンターのリソースを整理するための論理グループを表します。The resource group represents a logical group to organize the resources in a virtual datacenter. 組織に多数のサブスクリプションがある場合は、これらのサブスクリプションのアクセス、ポリシー、およびコンプライアンスを効率的に管理する方法が必要になることがあります。If your organization has many subscriptions, you may need a way to efficiently manage access, policies, and compliance for those subscriptions. Azure 管理グループの範囲は、サブスクリプションを上回ります。Azure management groups provide a level of scope above subscriptions. 管理グループと呼ばれるコンテナーにサブスクリプションを整理して、管理グループにガバナンス条件を適用します。You organize subscriptions into containers known as management groups and apply your governance conditions to the management groups. 管理グループ内のすべてのサブスクリプションは、管理グループに適用された条件を自動的に継承します。All subscriptions within a management group automatically inherit the conditions applied to the management group. 階層ビューでこれら 3 つの機能を表示するには、クラウド導入フレームワークのリソースの整理に関する記事を参照してください。To see these three features in a hierarchy view, see Organizing your resources in the Cloud Adoption Framework.
  • ロールベースのアクセス制御 (RBAC)Role-based access control (RBAC). RBAC により、特定の Azure リソースにアクセスするための組織のロールと権限をマップでき、ユーザーをアクションの特定のサブセットのみに制限できます。RBAC can map organizational roles and rights to access specific Azure resources, allowing you to restrict users to only a certain subset of actions. Azure Active Directory をオンプレミスの Active Directory と同期している場合は、オンプレミスで使用しているものと同じ Active Directory グループを Azure で使用できます。If you're synchronizing Azure Active Directory with an on-premises Active Directory, you can use the same Active Directory groups in Azure that you use on-premises. RBAC では、関連するスコープ内のユーザー、グループ、アプリケーションに適切なロールを割り当てることで、アクセス権を付与できます。With RBAC, you can grant access by assigning the appropriate role to users, groups, and applications within the relevant scope. ロール割り当てのスコープには、Azure サブスクリプション、リソース グループ、または単独のリソースを指定できます。The scope of a role assignment can be an Azure subscription, a resource group, or a single resource. RBAC では、アクセス許可を継承できます。RBAC allows inheritance of permissions. 親スコープでロールが割り当てられると、その親に含まれる子へのアクセス権も付与されます。A role assigned at a parent scope also grants access to the children contained within it. RBAC を使って、職務を分離し、職務に必要なアクセス許可のみをユーザーに付与することができます。Using RBAC, you can segregate duties and grant only the amount of access to users that they need to perform their jobs. たとえば、ある従業員がサブスクリプションで仮想マシンを管理できる一方で、他の従業員が同じサブスクリプション内で SQL Server データベースを管理できます。For example, one employee can manage virtual machines in a subscription, while another can manage SQL Server databases in the same subscription.

コンポーネントの種類:境界ネットワークComponent Type: Perimeter Networks

境界ネットワーク (DMZ ネットワークとも呼ばれます) のコンポーネントは、インターネット接続と共に、オンプレミスまたは物理データセンターのネットワークを接続します。Components of a perimeter network (sometimes called a DMZ network) connect your on-premises or physical datacenter networks, along with any internet connectivity. 境界には通常、ネットワークやセキュリティのチームの多大な時間投資が必要です。The perimeter typically requires a significant time investment from your network and security teams.

受信パケットは、スポーク内のバックエンド サーバーおよびサービスに到達する前に、ハブのセキュリティ アプライアンスを通過する必要があります。Incoming packets should flow through the security appliances in the hub before reaching the back-end servers and services in the spokes. 例として、ファイアウォール、IDS、IPS があります。Examples include the firewall, IDS, and IPS. ワークロードからインターネットへのパケットも、ネットワークから送信される前に、境界ネットワーク内のセキュリティ アプライアンスを通過する必要があります。Before they leave the network, internet-bound packets from the workloads should also flow through the security appliances in the perimeter network. このフローにより、ポリシーの適用、検査、監査ができるようになります。This flow enables policy enforcement, inspection, and auditing.

境界ネットワーク コンポーネントには次のものが含まれます。Perimeter network components include:

通常、中央 IT チームとセキュリティ チームは、境界ネットワークの要件の定義と運用を担当します。Usually, the central IT team and security teams have responsibility for requirement definition and operation of the perimeter networks.

77

上の図では、インターネットとオンプレミス ネットワークにアクセスする 2 つの境界の適用が示されており、どちらも DMZ ハブに存在します。The preceding diagram shows the enforcement of two perimeters with access to the internet and an on-premises network, both resident in the DMZ hub. DMZ ハブでは、Web アプリケーション ファイアウォール (WAF) または Azure Firewall の複数のファームを使って、多数の業種をサポートするようにインターネットへの境界ネットワークをスケールアップできます。In the DMZ hub, the perimeter network to internet can scale up to support many lines of business, using multiple farms of Web Application Firewalls (WAFs) or Azure Firewalls. このハブは、必要に応じて VPN または ExpressRoute 経由でのオンプレミスの接続も許可します。The hub also allows for on-premises connectivity via VPN or ExpressRoute as needed.

注意

上の図の "DMZ ハブ" で、仮想ネットワーク、ユーザー定義ルート、ネットワーク セキュリティ グループ、VPN ゲートウェイ、ExpressRoute ゲートウェイ、Azure ロードバランサー、Azure Firewall、Firewall Manager、DDOS などの多くの機能をまとめて Azure Virtual WAN ハブにバンドルできます。In the preceding diagram, in the "DMZ Hub", many of the following features can be bundled together in an Azure Virtual WAN hub (such as virtual networks, user-defined routes, network security groups, VPN gateways, ExpressRoute gateways, Azure load balancers, Azure Firewalls, Firewall Manager, and DDOS). Azure Virtual WAN ハブを使用すると、ハブ仮想ネットワーク、ひいては VDC をはるかに簡単に作成できます。これは、ユーザーが Azure Virtual WAN ハブをデプロイするときに、複雑なエンジニアリングのほとんどが Azure によって処理されるためです。Using Azure Virtual WAN hubs can make the creation of the hub virtual network, and thus the VDC, much easier, since most of the engineering complexity is handled for you by Azure when you deploy an Azure Virtual WAN hub.

仮想ネットワークVirtual networks. 通常、ハブは複数のサブネットを含む仮想ネットワーク上に構築され、Azure Firewall、NVA、WAF、Azure Application Gateway インスタンスを介してインターネットとの間でやり取りされるトラフィックをフィルター処理および検査するさまざまな種類のサービスをホストします。The hub is typically built on a virtual network with multiple subnets to host the different types of services that filter and inspect traffic to or from the internet via Azure Firewall, NVAs, WAF, and Azure Application Gateway instances.

ユーザー定義ルート ユーザー定義ルートを使うと、ファイアウォール、IDS/IPS、その他の仮想アプライアンスをデプロイし、これらのセキュリティ アプライアンスを介してネットワーク トラフィックをルーティングすることで、セキュリティ境界ポリシーを適用、監査、検査することができます。User-defined routes Using user-defined routes, customers can deploy firewalls, IDS/IPS, and other virtual appliances, and route network traffic through these security appliances for security boundary policy enforcement, auditing, and inspection. ユーザー定義ルートはハブとスポークのどちらにでも作成でき、VDC 実装で使用される特定のカスタム VM、ネットワーク仮想アプライアンス、ロード バランサーをトラフィックが通過することを保証します。User-defined routes can be created in both the hub and the spokes to guarantee that traffic transits through the specific custom VMs, Network Virtual Appliances, and load balancers used by a VDC implementation. スポーク内に存在する仮想マシンから生成されたトラフィックが正しい仮想アプライアンスに転送されることを保証するには、次ホップとして内部ロード バランサーのフロントエンド IP アドレスを設定することで、スポークのサブネットにユーザー定義ルートを設定する必要があります。To guarantee that traffic generated from virtual machines residing in the spoke transits to the correct virtual appliances, a user-defined route needs to be set in the subnets of the spoke by setting the front-end IP address of the internal load balancer as the next hop. 内部ロード バランサーは、内部トラフィックを仮想アプライアンス (ロード バランサーのバックエンド プール) に分散させます。The internal load balancer distributes the internal traffic to the virtual appliances (load balancer back-end pool).

Azure Firewall は、Azure Virtual Network リソースを保護するマネージド ネットワーク セキュリティ サービスです。Azure Firewall is a managed network security service that protects your Azure Virtual Network resources. これは、高可用性とクラウドのスケーラビリティを備えた、ステートフルなマネージド ファイアウォールです。It's a stateful managed firewall with high availability and cloud scalability. サブスクリプションと仮想ネットワークをまたいでアプリケーションとネットワークの接続ポリシーを一元的に作成、適用、記録できます。You can centrally create, enforce, and log application and network connectivity policies across subscriptions and virtual networks. Azure Firewall では、仮想ネットワーク リソースに静的パブリック IP アドレスが使用されます。Azure Firewall uses a static public IP address for your virtual network resources. これにより、仮想ネットワークから送信されるトラフィックを外部のファイアウォールで識別できます。It allows outside firewalls to identify traffic that originates from your virtual network. サービスはログ記録と分析を行うために Azure Monitor と完全に統合されます。The service is fully integrated with Azure Monitor for logging and analytics.

Azure Virtual WAN トポロジを使用する場合は、Azure Firewall Manager が、クラウドベースのセキュリティ境界に対して集約型セキュリティ ポリシーとルート管理を提供するセキュリティ管理サービスです。If you use the Azure Virtual WAN topology, the Azure Firewall Manager is a security management service that provides central security policy and route management for cloud-based security perimeters. これは、ハブおよびスポークの各アーキテクチャを簡単に作成できる Microsoft の管理対象リソースである Azure Virtual WAN ハブと連携して動作します。It works with Azure Virtual WAN hub, a Microsoft-managed resource that lets you easily create hub and spoke architectures. セキュリティおよびルーティングのポリシーがそのようなハブに関連付けられている場合は、セキュリティ保護付き仮想ハブと呼ばれます。When security and routing policies are associated with such a hub, it's referred to as a secured virtual hub.

ネットワーク仮想アプライアンスNetwork virtual appliances. ハブでは、インターネットにアクセスする境界ネットワークは、通常、Azure Firewall インスタンスあるいはファイアウォールまたは Web アプリケーション ファイアウォール (WAF) のファームによって管理されます。In the hub, the perimeter network with access to the internet is normally managed through an Azure Firewall instance or a farm of firewalls or web application firewall (WAF).

さまざまな業種で一般的に多くの Web アプリケーションが使用され、これらは種々の脆弱性や悪用の可能性に悩まされる傾向があります。Different lines of business commonly use many web applications, which tend to suffer from various vulnerabilities and potential exploits. Web アプリケーション ファイアウォールは、Web アプリケーション (HTTP/HTTPS) に対する攻撃を汎用ファイアウォールよりも詳細に検出するために使用される特殊な種類の製品です。Web application firewalls are a special type of product used to detect attacks against web applications, HTTP/HTTPS, in more depth than a generic firewall. 従来のファイアウォール テクノロジと比較すると、WAF は脅威から内部 Web サーバーを保護するための特定の機能セットを備えています。Compared with tradition firewall technology, WAFs have a set of specific features to protect internal web servers from threats.

Azure Firewall または NVA ファイアウォールはいずれも共通管理プレーンを使用し、一連のセキュリティ規則により、スポークでホストされているワークロードを保護し、オンプレミスのネットワークへのアクセスを制御します。An Azure Firewall or NVA firewall both use a common administration plane, with a set of security rules to protect the workloads hosted in the spokes, and control access to on-premises networks. Azure Firewall にはスケーラビリティが組み込まれているのに対し、NVA ファイアウォールはロード バランサーの背後で手動でスケーリングすることができます。The Azure Firewall has scalability built in, whereas NVA firewalls can be manually scaled behind a load balancer. 一般に、ファイアウォール ファームは WAF ほど特化したソフトウェアではありませんが、エグレスおよびイングレスのあらゆる種類のトラフィックをフィルター処理して検査する、より広範なアプリケーション スコープを備えています。Generally, a firewall farm has less specialized software compared with a WAF, but has a broader application scope to filter and inspect any type of traffic in egress and ingress. NVA アプローチを使用している場合は、Azure Marketplace で入手してデプロイできます。If an NVA approach is used, they can be found and deployed from Azure Marketplace.

インターネットから送信されるトラフィックには、Azure Firewall インスタンスまたは NVA の特定のセットを使用することをお勧めします。We recommend that you use one set of Azure Firewall instances, or NVAs, for traffic originating on the internet. オンプレミスから送信されるトラフィックには、別のセットを使用します。Use another for traffic originating on-premises. 両方にファイアウォールの同じセットを使用すると、2 つのネットワーク トラフィック セットの間にセキュリティ境界が提供されないため、セキュリティ リスクになります。Using only one set of firewalls for both is a security risk as it provides no security perimeter between the two sets of network traffic. 個別のファイアウォール レイヤーを使用すると、セキュリティ規則のチェックの複雑さが軽減され、規則と受信ネットワーク要求の対応が明確になります。Using separate firewall layers reduces the complexity of checking security rules and makes it clear which rules correspond to which incoming network request.

Azure Load Balancer が提供する高可用性レイヤー 4 (TCP、UDP) サービスは、負荷分散セットで定義されているサービス インスタンス間に受信トラフィックを分散できます。Azure Load Balancer offers a high availability Layer 4 (TCP/UDP) service, which can distribute incoming traffic among service instances defined in a load-balanced set. フロントエンド エンドポイント (パブリック IP エンドポイントまたはプライベート IP エンドポイント) からロード バランサーに送信されたトラフィックは、アドレス変換をして、またはしないで、バックエンド IP アドレス プール (ネットワーク仮想アプライアンスや仮想マシンなど) のセットに再配信できます。Traffic sent to the load balancer from front-end endpoints (public IP endpoints or private IP endpoints) can be redistributed with or without address translation to a set of back-end IP address pool (such as network virtual appliances or virtual machines).

Azure Load Balancer を使用すると、さまざまなサーバー インスタンスの正常性をプローブすることもでき、インスタンスがプローブへの応答に失敗した場合、異常なインスタンスへのトラフィック送信がロード バランサーによって停止されます。Azure Load Balancer can probe the health of the various server instances as well, and when an instance fails to respond to a probe, the load balancer stops sending traffic to the unhealthy instance. 仮想データセンターでは、外部ロード バランサーがハブとスポークにデプロイされています。In a virtual datacenter, an external load balancer is deployed to the hub and the spokes. ハブでは、ファイアウォール インスタンス間でトラフィックを効率的にルーティングするためにロード バランサーが使用され、スポークでは、アプリケーション トラフィックを管理するためにロード バランサーが使用されます。In the hub, the load balancer is used to efficiently route traffic across firewall instances, and in the spokes, load balancers are used to manage application traffic.

Azure Front Door (AFD) は、Microsoft による高可用性かつスケーラブルな Web アプリケーション アクセラレーション プラットフォーム、グローバル HTTP ロード バランサー、アプリケーション保護、コンテンツ配信ネットワークです。Azure Front Door (AFD) is Microsoft's highly available and scalable Web Application Acceleration Platform, Global HTTP Load Balancer, Application Protection, and Content Delivery Network. AFD は、Microsoft のグローバル ネットワークのエッジの 100 を超える箇所で動作し、動的 Web アプリケーションと静的コンテンツを構築、操作、スケールアウトできるようにします。Running in more than 100 locations at the edge of Microsoft's Global Network, AFD enables you to build, operate, and scale out your dynamic web application and static content. AFD を使用すれば、世界レベルのエンドユーザー パフォーマンス、統一されたリージョン/スタンプのメンテナンス自動化、BCDR の自動化、統一されたクライアント/ユーザー情報、キャッシュ、サービスの分析情報がアプリケーションに提供されます。AFD provides your application with world-class end-user performance, unified regional/stamp maintenance automation, BCDR automation, unified client/user information, caching, and service insights. プラットフォームでは以下が提供されます。The platform offers: - パフォーマンス、信頼性、およびサービス レベル アグリーメント (SLA) のサポート。Performance, reliability, and support service-level agreements (SLAs). - コンプライアンス認定。Compliance certifications. - Azure によって開発、運用、およびネイティブでのサポートが行われる監査可能なセキュリティ プラクティス。Auditable security practices that are developed, operated, and natively supported by Azure. Azure Front Door には、一般的な脆弱性や悪用から Web アプリケーションを保護する Web アプリケーション ファイアウォール (WAF) も用意されています。Azure Front Door also provides a web application firewall (WAF), which protects web applications from common vulnerabilities and exploits.

Azure Application Gateway は専用の仮想アプライアンスであり、マネージド アプリケーション配信コントローラーが提供されます。Azure Application Gateway is a dedicated virtual appliance providing a managed application delivery controller. これは、レイヤー 7 のさまざまな負荷分散機能をお客様のアプリケーションに提供します。It offers various Layer 7 load-balancing capabilities for your application. これにより、CPU を集中的に使用する SSL 終了をアプリケーション ゲートウェイにオフロードし、Web ファームのパフォーマンスを最適化できます。It allows you to optimize web farm performance by offloading CPU-intensive SSL termination to the application gateway. また、着信トラフィックのラウンド ロビン分散、Cookie ベースのセッション アフィニティ、URL パス ベースのルーティング、単一のアプリケーション ゲートウェイの背後で複数の Web サイトをホストする機能など、その他のレイヤー 7 ルーティング機能も用意されています。It also provides other Layer 7 routing capabilities, such as round-robin distribution of incoming traffic, cookie-based session affinity, URL-path-based routing, and the ability to host multiple websites behind a single application gateway. アプリケーション ゲートウェイの WAF SKU の一部として、Web アプリケーション ファイアウォール (WAF) も提供されます。A web application firewall (WAF) is also provided as part of the application gateway WAF SKU. この SKU は、一般的な Web の脆弱性や悪用から Web アプリケーションを保護します。This SKU provides protection to web applications from common web vulnerabilities and exploits. Application Gateway は、インターネット接続ゲートウェイ、または内部的にのみ使用されるゲートウェイのいずれかとして構成できるほか、この両方を組み合わせて使用することも可能です。Application Gateway can be configured as internet facing gateway, internal only gateway, or a combination of both.

パブリック IPPublic IPs. Azure の一部の機能を使用して、インターネットからリソースにアクセスできるように、サービス エンドポイントをパブリック IP アドレスに関連付けることができます。With some Azure features, you can associate service endpoints to a public IP address so that your resource is accessible from the internet. このエンドポイントでは、NAT を使用して、Azure の仮想ネットワーク上の内部アドレスとポートにトラフィックをルーティングします。This endpoint uses NAT to route traffic to the internal address and port on the virtual network in Azure. これは、外部トラフィックが仮想ネットワークに到達するための主な経路です。This path is the primary way for external traffic to pass into the virtual network. パブリック IP アドレスを構成することで、仮想ネットワークに渡されるトラフィックと、そのトラフィックが仮想ネットワークのどこでどのように変換されるのかを決定することができます。You can configure public IP addresses to determine which traffic is passed in and how and where it's translated onto the virtual network.

Azure DDoS Protection Standard は、Basic サービス レベルに加えて、特に Azure Virtual Network リソースに対してチューニングされた追加の軽減機能を提供します。Azure DDoS Protection Standard provides additional mitigation capabilities over the Basic service tier that are tuned specifically to Azure Virtual Network resources. DDoS Protection Standard の有効化は簡単であり、アプリケーションの変更は不要です。DDoS Protection Standard is simple to enable and requires no application changes. 保護ポリシーは、専用のトラフィック監視および機械学習アルゴリズムによってチューニングされます。Protection policies are tuned through dedicated traffic monitoring and machine learning algorithms. ポリシーは、仮想ネットワークにデプロイされたリソースに関連付けられているパブリック IP アドレスに適用されます。Policies are applied to public IP addresses associated to resources deployed in virtual networks. 例として、Azure Load Balancer、Azure Application Gateway、および Azure Service Fabric のインスタンスがあります。Examples include Azure Load Balancer, Azure Application Gateway, and Azure Service Fabric instances. 攻撃中および履歴の表示のために、Azure Monitor ビューからシステム生成ログをほぼリアルタイムで使用できます。Near real-time, system-generated logs are available through Azure Monitor views during an attack and for history. アプリケーション レイヤー保護は、Azure Application Gateway Web アプリケーション ファイアウォールによって追加できます。Application layer protection can be added through the Azure Application Gateway web application firewall. IPv4 と IPv6 の Azure パブリック IP アドレスに対して保護が提供されます。Protection is provided for IPv4 and IPv6 Azure public IP addresses.

ハブ アンド スポーク トポロジでは、仮想ネットワーク ピアリングとユーザー定義ルートを使用して、トラフィックを適切にルーティングします。The hub and spoke topology uses virtual network peering and user-defined routes to route traffic properly.

88

この図では、ユーザー定義ルートによって、トラフィックが、ExpressRoute ゲートウェイ経由でオンプレミスに渡される前に、スポークからファイアウォールに確実に送信されます (ファイアウォール ポリシーによってこのフローが許可されている場合)。In the diagram, the user-defined route ensures that traffic flows from the spoke to the firewall before passing to on-premises through the ExpressRoute gateway (if the firewall policy allows that flow).

コンポーネントの種類:監視Component type: Monitoring

監視コンポーネントは、他のすべての種類のコンポーネントからの可視性とアラートを提供します。Monitoring components provide visibility and alerting from all the other component types. すべてのチームは、アクセスできるコンポーネントとサービスに対する監視にアクセスできる必要があります。All teams should have access to monitoring for the components and services they have access to. 一元的なヘルプ デスクまたは運用チームは、これらのコンポーネントによって提供されるデータへの統合アクセスが必要です。If you have a centralized help desk or operations teams, they require integrated access to the data provided by these components.

Azure では、Azure がホストするリソースの動作を追跡するために、さまざまな種類のログ サービスと監視サービスが提供されています。Azure offers different types of logging and monitoring services to track the behavior of Azure-hosted resources. Azure でのワークロードのガバナンスと制御は、ログ データの収集だけでなく、報告された特定のイベントに基づいてアクションをトリガーする機能にも基づいています。Governance and control of workloads in Azure is based not just on collecting log data but also on the ability to trigger actions based on specific reported events.

Azure MonitorAzure Monitor. Azure には、監視領域において特定の役割やタスクを個別に実行するサービスが複数用意されています。Azure includes multiple services that individually perform a specific role or task in the monitoring space. これらのサービスを組み合わせることにより、アプリケーションやそれらを支える Azure リソースからシステム生成ログを収集、分析し、それに対処するための包括的なソリューションが提供されます。Together, these services deliver a comprehensive solution for collecting, analyzing, and acting on system-generated logs from your applications and the Azure resources that support them. また、オンプレミスの重要なリソースを監視して、ハイブリッド監視環境を構築することもできます。They can also work to monitor critical on-premises resources in order to provide a hybrid monitoring environment. アプリケーションの包括的な監視戦略を策定するための最初のステップは、利用可能なツールとデータの把握です。Understanding the tools and data that are available is the first step in developing a complete monitoring strategy for your applications.

Azure Monitor には、次の 2 つの基本的な種類のログがあります。There are two fundamental types of logs in Azure Monitor:

  • メトリックは、特定の時点におけるシステムの何らかの側面を表す数値です。Metrics are numerical values that describe some aspect of a system at a particular point in time. メトリックは軽量であり、リアルタイムに近いシナリオをサポートできます。They are lightweight and capable of supporting near real-time scenarios. Azure Monitor が収集した多くの Azure リソースのデータは、Azure portal の [Overview](概要) ページで参照できます。For many Azure resources, you'll see data collected by Azure Monitor right in their Overview page in the Azure portal. たとえば、任意の仮想マシンを見てみると、パフォーマンス メトリックが表示されたいくつかのグラフが表示されます。As an example, look at any virtual machine and you'll see several charts displaying performance metrics. いずれかのグラフを選択すると、データが Azure portal のメトリック エクスプローラーで開かれ、複数のメトリックの値を時系列にグラフ化できます。Select any of the graphs to open the data in metrics explorer in the Azure portal, which allows you to chart the values of multiple metrics over time. グラフは、対話形式で表示したり、ダッシュボードにピン留めして他の視覚化と一緒に表示したりできます。You can view the charts interactively or pin them to a dashboard to view them with other visualizations.

  • ログには、種類ごとに異なるプロパティ セットを持つレコードに編成されたさまざまな種類のデータが含まれます。Logs contain different kinds of data organized into records with different sets of properties for each type. イベントとトレースは、パフォーマンス データと共にログとして格納されます。これらはすべて分析のために組み合わせることができます。Events and traces are stored as logs along with performance data, which can all be combined for analysis. Azure Monitor で収集したログ データは、収集データをすばやく取得、統合、分析するクエリを使用して分析できます。Log data collected by Azure Monitor can be analyzed with queries to quickly retrieve, consolidate, and analyze collected data. ログは Log Analytics に格納され、そこからクエリが実行されます。Logs are stored and queried from Log Analytics. Azure portal で Log Analytics を使用してクエリを作成してテストした後、これらのツールを使用してデータを直接分析するか、クエリを保存して視覚化またはアラート ルールで利用できます。You can create and test queries using Log Analytics in the Azure portal and then either directly analyze the data using these tools or save queries for use with visualizations or alert rules.

99

Azure Monitor はさまざまなソースからデータを収集できます。Azure Monitor can collect data from a variety of sources. ご自分のアプリケーション、オペレーティング システム、およびそれが依存するサービスから、Azure プラットフォーム自体に至るまで、アプリケーションのさまざまな階層のデータ監視を検討することができます。You can think of monitoring data for your applications in tiers ranging from your application, any operating system, and the services it relies on, down to the Azure platform itself. Azure Monitor は、以下のそれぞれの層からデータを収集します。Azure Monitor collects data from each of the following tiers:

  • アプリケーション監視データ: プラットフォームを問わず、記述したコードのパフォーマンスと機能に関するデータ。Application monitoring data: Data about the performance and functionality of the code you have written, regardless of its platform.
  • ゲスト OS 監視データ: アプリケーションが実行されているオペレーティング システムに関するデータ。Guest OS monitoring data: Data about the operating system on which your application is running. この OS は Azure、別のクラウド、またはオンプレミスで実行できます。This OS could be running in Azure, another cloud, or on-premises.
  • Azure リソース監視データ: Azure リソースの操作に関するデータ。Azure resource monitoring data: Data about the operation of an Azure resource.
  • Azure サブスクリプション監視データ: Azure サブスクリプションの操作および管理に関するデータと、Azure 自体の正常性および操作に関するデータ。Azure subscription monitoring data: Data about the operation and management of an Azure subscription, as well as data about the health and operation of Azure itself.
  • Azure テナントの監視データ: Azure Active Directory など、テナント レベルの Azure サービスの操作に関するデータ。Azure tenant monitoring data: Data about the operation of tenant-level Azure services, such as Azure Active Directory.
  • カスタム ソース: オンプレミスのソースから送信されたログも含めることができます。Custom sources: Logs sent from on-premises sources can be included as well. たとえば、オンプレミスのサーバー イベントや、ネットワーク デバイスの syslog 出力などです。Examples include on-premises server events or network device syslog output.

データの監視が役立つのは、コンピューティング環境の運用の可視性が高まる場合のみです。Monitoring data is only useful if it can increase your visibility into the operation of your computing environment. Azure Monitor には、アプリケーションやそれが依存するリソースに対する貴重な洞察を提供するいくつかの機能やツールが含まれています。Azure Monitor includes several features and tools that provide valuable insights into your applications and other resources that they depend on. Application Insights やコンテナーに対する Azure Monitor などの監視ソリューションと機能では、アプリケーションや特定の Azure サービスのさまざまな側面に対する詳細な分析情報が提供されます。Monitoring solutions and features such as Application Insights and Azure Monitor for containers provide deep insights into different aspects of your application and specific Azure services.

Azure Monitor の監視ソリューションは、特定のアプリケーションまたはサービスに関する分析情報を提供するロジックのパッケージ化されたセットです。Monitoring solutions in Azure Monitor are packaged sets of logic that provide insights for a particular application or service. それには、アプリケーションまたはサービスの監視データを収集するためのロジック、そのデータを分析するためのクエリ、視覚化のためのビューが含まれています。They include logic for collecting monitoring data for the application or service, queries to analyze that data, and views for visualization. 各種の Azure サービスおよびその他のアプリケーションの監視を実現するために、複数の監視ソリューションが Microsoft とパートナーから入手できます。Monitoring solutions are available from Microsoft and partners to provide monitoring for various Azure services and other applications.

収集したこの豊富なデータをすべて使用して、手動クエリだけでは十分ではない環境で発生するイベントに対してプロアクティブな対策を取ることが重要です。With all of this rich data collected, it's important to take proactive action on events happening in your environment where manual queries alone won't suffice. Azure Monitor のアラートは、重大な状態を事前に通知し、場合によっては是正措置を試行します。Alerts in Azure Monitor proactively notify you of critical conditions and potentially attempt to take corrective action. メトリックに基づくアラート ルールは、数値に基づくほぼリアルタイムのアラートを提供します。一方、ログに基づくルールを使うと、複数のソースのデータにまたがる複雑なロジックを実現できます。Alert rules based on metrics provide near real-time alerting based on numeric values, while rules based on logs allow for complex logic across data from multiple sources. Azure Monitor のアラート ルールは、複数のルール間で共有できる、受信者およびアクションの一意なセットを含むアクション グループを使用します。Alert rules in Azure Monitor use action groups, which contain unique sets of recipients and actions that can be shared across multiple rules. アクション グループによって、要件に基づいて、Webhook を使用してアラートから外部アクションを起動したり、ITSM ツールと統合したりするようなアクションを実行できます。Based on your requirements, action groups can perform such actions as using webhooks that cause alerts to start external actions or to integrate with your ITSM tools.

Azure Monitor では、カスタム ダッシュボードを作成することもできます。Azure Monitor also allows the creation of custom dashboards. Azure ダッシュボードを使用すると、メトリックとログの両方を含むさまざまな種類のデータを組み合わせて Azure portal の 1 つのウィンドウにまとめることができます。Azure dashboards allow you to combine different kinds of data, including both metrics and logs, into a single pane in the Azure portal. ダッシュボードは、他の Azure ユーザーと共有することもできます。You can optionally share the dashboard with other Azure users. Azure Monitor のすべての要素は、任意のログ クエリやメトリック グラフの出力と合わせて、Azure ダッシュ ボードに追加できます。Elements throughout Azure Monitor can be added to an Azure dashboard in addition to the output of any log query or metrics chart. たとえば、メトリックのグラフ、アクティビティ ログの表、Application Insights の使用状況グラフ、ログ クエリ結果を示すタイルを組み合わせて 1 つのダッシュボードを作成できます。For example, you could create a dashboard that combines tiles that show a graph of metrics, a table of activity logs, a usage chart from Application Insights, and the output of a log query.

最後に、Azure Monitor データは Power BI のネイティブ ソースです。Finally, Azure Monitor data is a native source for Power BI. Power BI は、さまざまなデータ ソースにわたって対話的な視覚化を提供するビジネス分析サービスであり、組織内外の他のユーザーがデータを使用できるようにする効果的な手段です。Power BI is a business analytics service that provides interactive visualizations across a variety of data sources and is an effective means of making data available to others within and outside your organization. Azure Monitor からログ データを自動的にインポートするように Power BI を構成すると、それらの追加の視覚化も利用できます。You can configure Power BI to automatically import log data from Azure Monitor to take advantage of these additional visualizations.

Azure Network Watcher は、Azure の仮想ネットワーク内のリソースの監視、診断、メトリックの表示、ログの有効化/無効化を行うツールを提供します。Azure Network Watcher provides tools to monitor, diagnose, and view metrics and enable or disable logs for resources in a virtual network in Azure. これは、次のような機能を提供する多面的なサービスです。It's a multifaceted service that allows the following functionalities and more:

  • 仮想マシンとエンドポイント間の通信を監視する。Monitor communication between a virtual machine and an endpoint.
  • 仮想ネットワーク内のリソースとそれらの関係を表示する。View resources in a virtual network and their relationships.
  • VM との間で発生するネットワーク トラフィック フィルターの問題を診断する。Diagnose network traffic filtering problems to or from a VM.
  • VM からのネットワーク ルーティングの問題を診断する。Diagnose network routing problems from a VM.
  • VM からの送信接続を診断する。Diagnose outbound connections from a VM.
  • VM との間のパケットをキャプチャする。Capture packets to and from a VM.
  • 仮想ネットワーク ゲートウェイと接続に関する問題を診断する。Diagnose problems with an virtual network gateway and connections.
  • Azure リージョンとインターネット サービス プロバイダー間の相対待ち時間を確認する。Determine relative latencies between Azure regions and internet service providers.
  • ネットワーク インターフェイスのセキュリティ規則を表示する。View security rules for a network interface.
  • ネットワーク メトリックを表示する。View network metrics.
  • ネットワーク セキュリティ グループとの間のトラフィックを分析する。Analyze traffic to or from a network security group.
  • ネットワーク リソースの診断ログを表示する。View diagnostic logs for network resources.

コンポーネントの種類:ワークロードComponent type: Workloads

ワークロード コンポーネントは、実際のアプリケーションとサービスが存在する場所です。Workload components are where your actual applications and services reside. これは、アプリケーション開発チームが時間の大半を費やす部分です。It's where your application development teams spend most of their time.

ワークロードの可能性は無限です。The workload possibilities are endless. 次に示すのは可能なワークロードの種類のほんの一部です。The following are just a few of the possible workload types:

内部アプリケーション: 基幹業務アプリケーションは、企業の業務に不可欠です。Internal applications: Line-of-business applications are critical to enterprise operations. これらのアプリケーションには、一般的な特性がいくつかあります。These applications have some common characteristics:

  • 対話型: データを入力すると、結果またはレポートが返されます。Interactive: Data is entered, and results or reports are returned.
  • データドリブン: データベースや他のストレージに頻繁にアクセスするデータ集約型です。Data-driven: Data intensive with frequent access to databases or other storage.
  • 統合型: 組織の内外の他のシステムとの統合を提供します。Integrated: Offer integration with other systems within or outside the organization.

顧客向け Web サイト (インターネット接続または社内向け): ほとんどのインターネットアプリケーションは Web サイトです。Customer-facing web sites (internet-facing or internally facing): Most internet applications are web sites. Azure では、IaaS 仮想マシンまたは Azure Web Apps サイト (PaaS) のいずれかを使用して、Web サイトを実行できます。Azure can run a web site via either an IaaS virtual machine or an Azure Web Apps site (PaaS). Azure Web Apps は仮想ネットワークと統合して、スポーク ネットワーク ゾーンに Web アプリをデプロイします。Azure Web Apps integrates with virtual networks to deploy web apps in a spoke network zone. プライベート仮想ネットワークからは、インターネット経由でルーティングできないプライベート アドレスを介してリソースにアクセスできるので、社内向け Web サイトでパブリック インターネット エンドポイントを公開する必要はありません。Internally facing web sites don't need to expose a public internet endpoint because the resources are accessible via private non-internet routable addresses from the private virtual network.

ビッグ データ分析: データをより大規模にスケールアップする必要がある場合、リレーショナル データベースは、データの極端な負荷や非構造化の性質により、適切に動作しない可能性があります。Big data analytics: When data needs to scale up to larger volumes, relational databases may not perform well under the extreme load or unstructured nature of the data. Azure HDInsight は、全範囲に対応した、クラウドでのオープンソースの企業向けマネージド分析サービスです。Azure HDInsight is a managed, full-spectrum, open-source analytics service in the cloud for enterprises. Hadoop、Apache Spark、Apache Hive、LLAP、Apache Kafka、Apache Storm、R などのオープンソース フレームワークを使用できます。HDInsight では、場所ベースの仮想ネットワークへのデプロイがサポートされており、仮想データセンターのスポーク内のクラスターにデプロイできます。You can use open-source frameworks such as Hadoop, Apache Spark, Apache Hive, LLAP, Apache Kafka, Apache Storm, and R. HDInsight supports deploying into a location-based virtual network, can be deployed to a cluster in a spoke of the virtual datacenter.

イベントとメッセージング: Azure Event Hubs は、ビッグ データのストリーミング プラットフォームとなるイベント インジェスト サービスです。Events and Messaging: Azure Event Hubs is a big data streaming platform and event ingestion service. 1 秒間に何百万ものイベントを受信して処理することができます。It can receive and process millions of events per second. 待機時間が短く、保持時間を構成できるため、大量のデータを Azure に取り込み、複数のアプリケーションから読み取ることができます。It provides low latency and configurable time retention, enabling you to ingest massive amounts of data into Azure and read it from multiple applications. 1 つのストリームで、リアルタイムとバッチ ベースの両方のパイプラインをサポートできます。A single stream can support both real-time and batch-based pipelines.

Azure Service Bus により、アプリケーションとサービス間に信頼性の高いクラウド メッセージング サービスを実装できます。You can implement a highly reliable cloud messaging service between applications and services through Azure Service Bus. クライアントとサーバー間の非同期のブローカー メッセージング、構造化された先入れ先出し (FIFO) メッセージング、パブリッシュとサブスクライブの機能が提供されます。It offers asynchronous brokered messaging between client and server, structured first-in-first-out (FIFO) messaging, and publishes and subscribe capabilities.

"10"10

これらの例は、Azure で作成できるワークロードの種類のほんの一部を示しているにすぎません — 基本的な Web および SQL アプリから、最新の IoT、ビッグ データ、機械学習、AI などあらゆるものに対応します。These examples barely scratch the surface of the types of workloads you can create in Azure—everything from a basic Web and SQL app to the latest in IoT, big data, machine learning, AI, and so much more.

高可用性: 複数の仮想データセンターHighly availability: multiple virtual datacenters

ここまで、この記事では、単一の VDC の設計に注目し、回復性に寄与する基本的なコンポーネントとアーキテクチャについて説明してきました。So far, this article has focused on the design of a single VDC, describing the basic components and architectures that contribute to resiliency. Azure には、Azure Load Balancer、NVA、可用性ゾーン、可用性セット、スケール セット、および運用サービスに確実な SLA レベルを組み込みのに役立つその他の機能があります。Azure features such as Azure load balancer, NVAs, availability zones, availability sets, scale sets, and other capabilities that help you include solid SLA levels into your production services.

ただし、仮想データセンターは一般的に単一のリージョン内に実装されるため、そのリージョン全体に影響を与える停止に対して脆弱な場合があります。However, because a virtual datacenter is typically implemented within a single region, it might be vulnerable to outages that affect the entire region. 高可用性を求めるお客様は、異なるリージョンにデプロイされた 2 つ以上の VDC 実装に同じプロジェクトをデプロイして、サービスを保護する必要があります。Customers that require high availability must protect the services through deployments of the same project in two or more VDC implementations deployed to different regions.

SLA の懸念事項に加えて、いくつかの一般的なシナリオでは、複数の仮想データセンターを実行するとメリットがあります。In addition to SLA concerns, several common scenarios benefit from running multiple virtual datacenters:

  • エンド ユーザーまたはパートナーのリージョンへの配置またはグローバルな配置。Regional or global presence of your end users or partners.
  • ディザスター リカバリーの要件。Disaster recovery requirements.
  • 負荷やパフォーマンスのためにデータセンター間でトラフィックを転送するメカニズム。A mechanism to divert traffic between datacenters for load or performance.

リージョンへの配置/グローバルな配置Regional/global presence

Azure データセンターは世界中の多数のリージョンに存在します。Azure datacenters exist in many regions worldwide. 複数の Azure データセンターを選択する場合、地理的な距離と待機時間という関連する 2 つの要因を考慮してください。When selecting multiple Azure datacenters, consider two related factors: geographical distances and latency. ユーザー エクスペリエンスを最適化するには、各仮想データセンター間の距離と、各仮想データセンターからエンド ユーザーへの距離を評価します。To optimize user experience, evaluate the distance between each virtual datacenter as well as the distance from each virtual datacenter to the end users.

仮想データセンターをホストする Azure リージョンは、組織が運営されている法的管轄の規制要件に準拠している必要があります。An Azure region that hosts your virtual datacenter must conform with regulatory requirements of any legal jurisdiction under which your organization operates.

障害復旧Disaster recovery

ディザスター リカバリー計画の設計は、ワークロードの種類と、さまざまな VDC 実装間でワークロードの状態を同期する機能によって変わります。The design of a disaster recovery plan depends on the types of workloads and the ability to synchronize state of those workloads between different VDC implementations. ほとんどのお客様は高速フェールオーバー メカニズムを望み、この要件により、複数の VDC 実装で実行されているデプロイ間でアプリケーション データの同期が必要となる場合があります。Ideally, most customers desire a fast fail-over mechanism, and this requirement may need application data synchronization between deployments running in multiple VDC implementations. ただし、ディザスター リカバリー計画を設計する場合は、ほとんどのアプリケーションがこのようなデータの同期によって発生する可能性がある待機時間の影響を受けやすい点を考慮することが重要です。However, when designing disaster recovery plans, it's important to consider that most applications are sensitive to the latency that can be caused by this data synchronization.

異なる VDC 実装内のアプリケーションの同期とハートビート監視には、ネットワークを介した通信が必要です。Synchronization and heartbeat monitoring of applications in different VDC implementations requires them to communicate over the network. 異なるリージョンの複数の VDC 実装は、次の方法で接続できます。Multiple VDC implementations in different regions can be connected through:

  • 同じ Virtual WAN 内のリージョンにわたって各 Azure Virtual WAN ハブに組み込まれているハブ間通信。Hub-to-hub communication built into Azure Virtual WAN hubs across regions in the same Virtual WAN.
  • リージョンをまたいでハブを接続する仮想ネットワーク ピアリング。Virtual network peering to connect hubs across regions.
  • ExpressRoute のプライベート ピアリング (各 VDC 実装内のハブが同じ ExpressRoute 回線に接続されている場合)。ExpressRoute private peering, when the hubs in each VDC implementation are connected to the same ExpressRoute circuit.
  • 企業バックボーン経由で接続されている複数の ExpressRoute 回線と、ExpressRoute 回線に接続された複数の VDC 実装。Multiple ExpressRoute circuits connected via your corporate backbone, and your multiple VDC implementations connected to the ExpressRoute circuits.
  • 各 Azure リージョン内の VDC 実装のハブ ゾーン間のサイト間 VPN 接続。Site-to-site VPN connections between the hub zone of your VDC implementations in each Azure region.

通常、Virtual WAN ハブ、仮想ネットワーク ピアリング、または ExpressRoute の接続がネットワーク接続に適しています。これは、Microsoft バックボーンを通過するときの帯域幅と、一貫性のある待機時間のレベルが高いためです。Typically, Virtual WAN hubs, virtual network peering, or ExpressRoute connections are preferred for network connectivity, due to the higher bandwidth and consistent latency levels when passing through the Microsoft backbone.

ネットワーク認定テストを実行して、これらの接続の待機時間と帯域幅を検証し、その結果に基づいて同期または非同期のデータ レプリケーションが適切かどうかを判断します。Run network qualification tests to verify the latency and bandwidth of these connections, and decide whether synchronous or asynchronous data replication is appropriate based on the result. また、最適な目標復旧時間 (RTO) の観点からこれらの結果を比較検討することも重要です。It's also important to weigh these results in view of the optimal recovery time objective (RTO).

ディザスター リカバリー: あるリージョンから別のリージョンへのトラフィックの転送Disaster recovery: diverting traffic from one region to another

Azure Traffic ManagerAzure Front Door の両方で、さまざまな VDC 実装内のリッスン エンドポイントのサービス正常性が定期的にチェックされ、これらのエンドポイントに障害が発生した場合は、次に最も近い VDC に自動的にルーティングされます。Both Azure Traffic Manager and Azure Front Door periodically check the service health of listening endpoints in different VDC implementations and, if those endpoints fail, route automatically to the next closest VDC. Traffic Manager は、リアルタイムのユーザー測定と DNS を使用して、ユーザーを最も近いもの (または、障害時は次に最も近いもの) にルーティングします。Traffic Manager uses real-time user measurements and DNS to route users to the closest (or next closest during failure). Azure Front Door は、100 個を超える Microsoft バックボーン エッジ サイトのリバース プロキシであり、エニーキャストを使用して最も近いリッスン エンドポイントにユーザーをルーティングします。Azure Front Door is a reverse proxy at over 100 Microsoft backbone edge sites, using anycast to route users to the closest listening endpoint.

まとめSummary

データ センター移行への仮想データ センターのアプローチにより、Azure リソースの使用を最適化し、コストを削減し、システムのガバナンスを簡素化するスケーラブルなアーキテクチャが作成されます。A virtual datacenter approach to datacenter migration creates a scalable architecture that optimizes Azure resource use, lowers costs, and simplifies system governance. 仮想データセンターは通常、(仮想ネットワーク ピアリングまたは Virtual WAN ハブのいずれかを使用する) ハブおよびスポークのネットワーク トポロジに基づきます。The virtual datacenter is typical based on hub and spoke network topologies (using either virtual network peering or Virtual WAN hubs). ハブで提供される一般的な共有サービスと、特定のアプリケーションおよびワークロードがスポークにデプロイされます。Common shared services provided in the hub, and specific applications and workloads are deployed in the spokes. また、仮想データセンターは、さまざまな部門 (中央 IT、DevOps、運用とメンテナンスなど) すべてが協力すると同時に各部門の役割を果たすという、会社の役割の構造にも対応しています。The virtual datacenter also matches the structure of company roles, where different departments such as Central IT, DevOps, and Operations and Maintenance all work together while performing their specific roles. 仮想データセンターは、Azure への既存のオンプレミスのワークロードの移行をサポートしていますが、クラウドネイティブのデプロイにも多くの利点をもらたします。The virtual datacenter supports migrating existing on-premises workloads to Azure, but also provides many advantages to cloud-native deployments.

ReferencesReferences

このドキュメントで説明した Azure の機能の詳細をご覧ください。Learn more about the Azure capabilities discussed in this document.

次のステップNext steps

  • ハブ アンド スポーク トポロジの中核となるテクノロジである仮想ネットワーク ピアリングの詳細について確認します。Learn more about virtual network peering, the core technology of hub and spoke topologies.
  • ロールベースのアクセス制御を使用するために Azure Active Directory を実装します。Implement Azure Active Directory to use role-based access control.
  • 組織の構造、要件、ポリシーに適合するロールベースのアクセス制御を使用して、サブスクリプションおよびリソースの管理モデルを開発します。Develop a subscription and resource management model using role-based access control that fits the structure, requirements, and policies of your organization. 最も重要なアクティビティは計画です。The most important activity is planning. 再編成、合併、新しい製品ライン、およびその他の考慮事項が初期モデルに与える影響を分析し、将来のニーズと成長に合わせて調整できるようにします。Analyze how reorganizations, mergers, new product lines, and other considerations will affect your initial models to ensure you can scale to meet future needs and growth.