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

概要Overview

オンプレミスのアプリケーションを Azure に移行すると、最小限の変更でアプリケーションを移行した場合でも、セキュリティで保護されたコスト効率の高いインフラストラクチャのメリットが組織にもたらされます。Migrating on-premises applications to Azure provides organizations the benefits of a secured and cost-efficient infrastructure, even if the applications are migrated with minimal changes. ただし、クラウド コンピューティングで可能な俊敏性を最大限に活用するには、Azure の機能を利用するように企業のアーキテクチャを進化させる必要があります。However, to make the most of the agility possible with cloud computing, enterprises must evolve their architectures to take advantage of Azure capabilities.

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

お客様は、これらのクラウド サービスにインターネット経由でアクセスするか、プライベート ネットワーク接続を提供する Azure ExpressRoute を使ってアクセスするかを選択できます。Customers can choose to access these cloud services either via the internet or with Azure ExpressRoute, which provides private network connectivity. Microsoft Azure プラットフォームを使用すると、インフラストラクチャをクラウドにシームレスに拡張し、多層アーキテクチャを構築できます。With the Microsoft Azure platform, customers can seamlessly extend their infrastructure into the cloud and build multitier architectures. また、Microsoft のパートナーも、Azure で実行するために最適化されたセキュリティ サービスと仮想アプライアンスにより、強化された機能を提供しています。Microsoft partners also provide enhanced capabilities by offering security services and virtual appliances that are optimized to run in Azure.

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

クラウドは、初期段階では一般に公開されているアプリケーションをホストするためのプラットフォームでした。At its inception, the cloud was essentially a platform for hosting public-facing applications. 企業はクラウドの価値を理解し始め、社内の基幹業務アプリケーションをクラウドに移行し始めました。Enterprises began to understand the value of the cloud and began to move internal line-of-business applications to the cloud. このような種類のアプリケーションによってセキュリティ、信頼性、パフォーマンス、およびコストの考慮事項が増えたため、クラウド サービスの提供方法をさらに柔軟にする必要がありました。These types of applications brought additional security, reliability, performance, and cost considerations that required additional flexibility in the way cloud services were delivered. その結果、このような柔軟性を実現するように設計された新しいインフラストラクチャとネットワーク サービスだけでなく、スケール、ディザスター リカバリーなどの考慮事項に対応する新しい機能への道が開かれました。This paved the way for new infrastructure and networking services designed to provide this flexibility but also new features for scale, disaster recovery, and other considerations.

当初、クラウド ソリューションは、パブリック領域で単一の比較的独立したアプリケーションをホストするように設計されていました。Cloud solutions were first designed to host single, relatively isolated applications in the public spectrum. この方法は、数年間はうまくいっていました。This approach worked well for a few years. その後、クラウド ソリューションの利点が明らかになり、複数の大規模なワークロードがクラウドでホストされるようになりました。Then the benefits of cloud solutions became apparent, and 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.

次のクラウド配置ダイアグラムでは、赤色のボックスでセキュリティ ギャップの例が強調されています。The following cloud deployment diagram shows an example of a security gap, highlighted in the red box. 黄色のボックスは、ワークロード間でネットワーク仮想アプライアンスを最適化するための余地を示しています。The yellow box shows room for optimizing network virtual appliances across workloads.

00

仮想データセンターは、エンタープライズ ワークロードをサポートするためのスケーリングの必要性から生まれた概念であり、パブリック クラウドで大規模なアプリケーションをサポートするときに発生する問題に対処する必要性ともバランスが取られています。A virtual datacenter is a concept born of the necessity for scaling to support enterprise workloads while balancing the need to deal with the problems introduced when supporting large-scale applications in the public cloud.

仮想データセンター実装とは、クラウド内のアプリケーション ワークロードだけでなく、ネットワーク、セキュリティ、管理、インフラストラクチャ (DNS やディレクトリ サービスなど) でもあります。A virtual datacenter implementation does not just represent the application workloads in the cloud, but also the network, security, management, and infrastructure (for example, DNS and Directory Services). Azure に移行する企業のワークロードの増加に伴って、これらのワークロードが配置されるサポート インフラストラクチャおよびオブジェクトについて考えることが重要になります。As more and more of an enterprise's workloads move to Azure, it's important to think about the supporting infrastructure and objects these workloads are placed in. リソースの構成方法について慎重に考えることで、データ フロー、セキュリティ モデル、コンプライアンスに関する課題が異なり個別に管理する必要のある多数の "ワークロード アイランド" が増殖するのを防ぐことができます。Thinking carefully about how resources are structured can avoid the proliferation of hundreds of "workload islands" that must be managed separately with independent data flow, security models, and compliance challenges.

仮想データセンターの概念は、共通のサポート機能とインフラストラクチャを備えた、独立していながら関連性のあるエンティティのコレクションを実装するための一連の推奨事項とベスト プラクティスで構成されています。The virtual datacenter concept is a set of recommendations and best practices for implementing a collection of separate but related entities with common supporting functions, features, and infrastructure. ワークロードを仮想データセンターのレンズを通して見ることで、運用、管理、コンプライアンス監査が容易になるだけでなく、スケールの経済性およびコンポーネントとデータ フローの一元化によるセキュリティの最適化によってコスト削減を実現できます。By viewing your workloads through the lens of a virtual datacenter, you can realize reduced cost due to economies of scale, optimized security through component and data flow centralization, along with easier operations, management, and compliance audits.

注意

仮想データセンターは Azure の独立した製品ではなく、厳しい要件を満たすためのさまざまな機能の組み合わせであることを理解しておくことが重要です。It's important to understand that a virtual datacenter is NOT a discrete Azure product, but the combination of various features and capabilities to meet your exact requirements. 仮想データセンターは、クラウドのリソースと能力を最大限にするための、ワークロードと Azure の使用方法についての考え方です。A virtual datacenter is a way of thinking about your workloads and Azure usage to maximize your resources and abilities in the cloud. これは企業の組織的な役割と責任範囲を考慮しながら Azure での IT サービスを構築するモジュール方式のアプローチです。It's a modular approach to building up IT services in Azure while respecting the enterprise's organizational roles and responsibilities.

仮想データセンター実装は、企業が次のシナリオでワークロードとアプリケーションを Azure に移行する際に役立ちます。A virtual datacenter implementation can help enterprises get workloads and applications into 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.
  • 大企業向けに Azure DevOps と一元化された IT を適切に組み合わせる。Mix Azure DevOps and centralized IT appropriately for a large enterprise.

仮想データセンターの利点を実現する鍵となるのは、次のような Azure サービスの機能を組み合わせた集中型のハブとスポークのネットワーク トポロジです。The key to unlock the advantages of a virtual datacenter is a centralized hub and spoke network topology with a mix of Azure services and features:

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

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

IT、ネットワーク、セキュリティ、またはコンプライアンスの一元化されたチームまたは部門が組織にある場合、仮想データセンターを実装することで、ポリシー ポイントの適用、職務の分離、基になる共通コンポーネントの統一性の確保を実現しながら、要件に適した最大限の自由と制御をアプリケーション チームに提供することができます。If your organization has centralized teams or departments for IT, networking, security, or compliance, implementing a virtual datacenter can help enforce policy points, segregation of duty, and ensure uniformity of the underlying common components while giving application teams as much freedom and control as is appropriate for your requirements.

また、DevOps を検討している組織では、仮想データセンターの概念を利用して、Azure リソースの承認されたポケットを提供し、そのグループ (サブスクリプションまたは共通サブスクリプション内のリソース グループ) 内での完全な制御を確保することもできます。その一方で、ネットワークとセキュリティの境界は、ハブの VNet とリソース グループの一元的ポリシーによる定義に従って準拠を維持します。Organizations that are looking to DevOps can also use virtual datacenter concepts to provide authorized pockets of Azure resources and ensure they have total control within that group (either subscription or resource group in a common subscription), but the network and security boundaries stay compliant as defined by a centralized policy in a hub VNet and resource group.

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

仮想データセンター実装を設計するときは、考慮すべき非常に重要な問題がいくつかあります。When designing a virtual datacenter implementation, there are several pivotal issues to consider:

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

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

大規模な企業では、仮想データセンター実装内または仮想データセンター実装間での個々の 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 virtual datacenter implementation. このプロセスの目的は、コスト、ダウンタイム、および手作業の反復を減らしながら、セキュリティと生産性を向上させることです。The goals of this process should be to increase security and productivity while decreasing 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. 仮想データセンターでは、適切なガバナンスでシステムを実行するために、それぞれが特定のロール定義を持つさまざまなチーム間の良好な協力が必要です。A virtual datacenter 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. 仮想データセンターの ID 管理は、Azure Active Directory (Azure AD) とロールベースのアクセス制御 (RBAC) を使用して実装されます。Identity management in a virtual datacenter 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-in 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 人のグローバル管理者が、仮想データセンター実装のすべてのアクセス許可を割り当てる必要があるわけではありません。A single global administrator is not required to assign all permissions in a virtual datacenter implementation. 代わりに、特定の各部門、ユーザーのグループ、またはディレクトリ サービス内のサービスが、仮想データセンター実装内の各自のリソースを管理するために必要なアクセス許可を持つことができます。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 virtual datacenter implementation. アクセス許可を構成するにはバランスが必要です。Structuring permissions requires balancing. アクセス許可が多すぎるとパフォーマンス効率が妨げられ、アクセス許可が少なすぎたり緩すぎたりするとセキュリティ リスクが高まります。Too many permissions can impede performance efficiency, and too few or loose permissions can increase security risks. Azure のロールベースのアクセス制御 (RBAC) は、仮想データセンター実装内のリソースに対してきめ細かなアクセス管理を実現することで、この問題への対処を支援します。Azure role-based access control (RBAC) helps to address this problem, by offering fine-grained access management for resources in a virtual datacenter implementation.

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

セキュリティ インフラストラクチャとは、仮想データセンター実装の特定の仮想ネットワーク セグメントにおけるトラフィックの分離を指します。Security infrastructure refers to the segregation of traffic in a virtual datacenter implementation's specific virtual network segment. このインフラストラクチャで、仮想データセンター実装内のイングレスとエグレスを制御する方法を指定します。This infrastructure specifies how ingress and egress is controlled in a virtual datacenter implementation. Azure の基になっているマルチテナント アーキテクチャは、VNet の分離、アクセス制御リスト (ACL)、ロード バランサー、IP フィルター、トラフィック フロー ポリシーを使って、デプロイ間の許可されていない非意図的なトラフィックを防止します。Azure is based on a multitenant architecture that prevents unauthorized and unintentional traffic between deployments by using VNet isolation, access control lists (ACLs), 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 implementation requires connectivity to external networks to offer services to customers, partners, and internal users. この接続の必要性は、インターネットへの接続だけでなく、オンプレミスのネットワークとデータセンターへの接続も指します。This need for connectivity refers not only to the Internet, but also to on-premises networks and datacenters.

Azure Firewall または他の種類のネットワーク仮想アプライアンス (NVA)、ユーザー定義ルートを使用したカスタム ルーティング ポリシー、ネットワーク セキュリティ グループを使用したネットワーク フィルタリングを使って、パブリック インターネットと双方向にアクセスできるサービスを制御できます。Customers control which services have access to and are accessible from the public internet 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 implementation 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 は、セキュリティで保護された暗号化接続 (IPsec/IKE トンネル) によって確立される、オンプレミスのネットワークと仮想データセンター実装間のインターネットを介した相互接続サービスです。An Azure Site-to-Site VPN is an interconnection service over the Internet between on-premises networks and a virtual datacenter implementation, established through secure encrypted connections (IPsec/IKE tunnels). Azure のサイト間接続は、すべての接続がインターネット経由で接続するため、柔軟で、すばやく作成でき、追加調達の必要がありません。Azure Site-to-Site connection is flexible, quick to create, and does not require any further procurement, as all connections connect over the internet.

多くの VPN 接続において、Azure Virtual WAN は、Azure を介してブランチ間接続を最適化し、自動化するネットワーク サービスです。For large numbers of VPN 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 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.

Azure の接続サービスである ExpressRoute を使用すると、仮想データセンター実装とすべてのオンプレミス ネットワーク間のプライベート接続が可能になります。ExpressRoute is an Azure connectivity service that enables private connections between a virtual datacenter implementation and any on-premises networks. ExpressRoute 接続はパブリック インターネットを使わず、高いセキュリティ、信頼性、速度 (最大 10 Gbps)、および一貫した待機時間を提供します。ExpressRoute connections do not go over the public Internet, and offer higher security, reliability, and higher speeds (up to 10 Gbps) along with consistent latency. ExpressRoute のお客様はプライベート接続に関連付けられたコンプライアンス ルールの利点が得られるので、ExpressRoute は仮想データセンター実装に適しています。ExpressRoute is useful for virtual datacenter implementations, as ExpressRoute customers can get the benefits of compliance rules associated with private connections. より広い帯域幅が必要なお客様の場合、ExpressRoute Direct を使用すると、100 Gbps で Microsoft ルーターに直接接続することができます。With ExpressRoute Direct, you can connect directly to Microsoft routers at 100 Gbps for customers with larger bandwidth needs.

通常、ExpressRoute 接続のデプロイでは、ExpressRoute サービス プロバイダーと連携する必要があります。Deploying ExpressRoute connections usually involves engaging with an ExpressRoute service provider. 短時間で使い始める必要がある顧客の場合は、通常、最初にサイト間 VPN を使って仮想データセンター実装とオンプレミスのリソース間の接続を確立した後、サービス プロバイダーとの物理相互接続の完了時に ExpressRoute 接続に移行します。For customers that need to start quickly, it is common to initially use Site-to-Site VPN to establish connectivity between a virtual datacenter implementation and on-premises resources, and then migrate to ExpressRoute connection when your physical interconnection with your service provider is complete.

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

VNetVNet ピアリングは、仮想データセンター実装内の基本的なネットワーク接続サービスです。VNets and VNet peering are the basic networking connectivity services inside a virtual datacenter implementation. VNet は仮想データセンター リソースの分離の自然な境界を保証し、VNet ピアリングは同じ Azure リージョン内またはリージョンをまたがる異なる VNet 間の相互通信を可能にします。A VNet guarantees a natural boundary of isolation for virtual datacenter resources, and VNet peering allows intercommunication between different VNets within the same Azure region or even across regions. VNet 内および VNet 間のトラフィック制御では、アクセス制御リスト (ネットワーク セキュリティ グループ)、ネットワーク仮想アプライアンス、およびカスタム ルーティング テーブル (ユーザー定義ルート) によって指定されたセキュリティ ルールのセットを一致させる必要があります。Traffic control inside a VNet and between VNets needs to match a set of security rules specified through access control lists (network security groups), network virtual appliances, and custom routing tables (user-defined routes).

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

トポロジTopology

ハブとスポークは、仮想データセンター実装のネットワーク トポロジを設計するためのモデルです。Hub and spoke is a model for designing the network topology for a virtual datacenter implementation.

11

示されているように、Azure では 2 種類のハブ アンド スポークの設計を使用できます。As shown, two types of hub and spoke design can be used in Azure. 通信、共有リソース、一元的セキュリティ ポリシーに対するものと (図の VNet Hub)、ブランチとブランチの間またはブランチと Azure の間の大規模な通信に対する仮想 WAN タイプ (図の Virtual WAN) です。For communication, shared resources, and centralized security policy (VNet Hub in the diagram), or a Virtual WAN type (Virtual WAN in the diagram) for large-scale branch-to-branch and branch-to-Azure communications.

ハブは、異なるゾーン (インターネット、オンプレミス、スポーク) 間のイングレスまたはエグレス トラフィックを制御および検査する中央ネットワーク ゾーンです。A hub is the central network zone that controls and inspects ingress or egress traffic between different zones: internet, on-premises, and the spokes. ハブとスポークのトポロジでは、IT 部門は一元化された場所でセキュリティ ポリシーを効率的に適用できます。The hub and spoke topology gives the IT department an effective way to enforce security policies in a central location. また、構成の誤りや露出の可能性も低減されます。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 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.

仮想データセンターでは、複数のスポーク間で共有ハブ インフラストラクチャを使用することで、全体的なコストを削減します。The 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 are dev and test, user acceptance testing, preproduction, and production. スポークでは、組織内のさまざまなグループを分離して有効にすることもできます。The spokes can also segregate and enable different groups within your organization. 例として Azure DevOps グループがあります。An example is Azure 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 では、種類に関係なくすべてのコンポーネントが、Azure サブスクリプションにデプロイされます。In Azure, every component, whatever the type, is deployed in an Azure Subscription. 異なる Azure サブスクリプションに Azure コンポーネントを分離することで、差別化されたレベルのアクセスと承認の設定など、異なる LOB の要件を満たすことができます。The isolation of Azure components in different Azure subscriptions can satisfy the requirements of different LOBs, such as setting up differentiated levels of access and authorization.

1 つの仮想データセンター実装で多数のスポークにスケールアップできますが、他の IT システムと同様に、プラットフォームの制限があります。A single virtual datacenter implementation can scale up to large number of spokes, although, as with every IT system, there are platform limits. ハブのデプロイは特定の Azure サブスクリプションにバインドされ、サブスクリプションには制限事項と上限があります (たとえば、VNet ピアリングの最大数、詳しくは「Azure サブスクリプションとサービスの制限、クォータ、制約」を参照)。The hub deployment is bound to a specific Azure subscription, which has restrictions and limits (for example, a maximum number of VNet peerings; see Azure subscription and service limits, quotas, and constraints for details). 制限が問題になる可能性がある場合は、単一のハブとスポークからハブとスポークのクラスターにモデルを拡張することによって、アーキテクチャをさらに拡張できます。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 リージョン内の複数のハブを、VNet ピアリング、ExpressRoute、Virtual WAN、サイト間 VPN を使って相互に接続できます。Multiple hubs in one or more Azure regions can be interconnected using VNet 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 would only be justified by scalability, system limits or redundancy and 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, it is possible to implement complex multitier workloads. 多階層の構成は、同じ VNet 内のサブネット (すべての階層に対して 1 つ) を使い、ネットワーク セキュリティ グループを使ってフローをフィルター処理することによって、実装できます。Multitier configurations can be implemented using subnets (one for every tier) in the same VNet and filtering the flows using network security groups.

アーキテクトは、複数の仮想ネットワークに多層ワークロードをデプロイできます。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 thereby avoid transiting through the hub. ハブをバイパスすることで、ハブにしか存在しない重要なセキュリティ ポイントや監査ポイントがバイパスされることがないように、アーキテクチャとセキュリティを慎重に見直す必要があります。A careful architecture and security review should be performed 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. 仮想データセンター実装のスポークは、トラフィックがオンプレミス ネットワークまたはパブリック インターネットのいずれかで送信先に到達できるように、中央のハブにトラフィックを転送する必要があります。The spokes of a virtual datacenter 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 では複雑なトポロジを構成できますが、仮想データセンターの概念の中核となる原則の 1 つは再現性と単純さです。Although Azure allows complex topologies, one of the core principles of the virtual datacenter concept is repeatability and simplicity. 管理作業を最小限に抑えるために、単純なハブ スポーク設計が、推奨される仮想データセンター参照アーキテクチャです。To minimize management effort, the simple hub-spoke design is the virtual datacenter reference architecture that we recommend.

コンポーネントComponents

仮想データセンターは、4 種類の基本的なコンポーネントで構成されています。インフラストラクチャ境界ネットワークワークロード、および監視です。A 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. 仮想データセンター実装は、複数のコンポーネントの種類のインスタンスと、同じコンポーネントの種類の複数のバリエーションで構成されます。Your virtual datacenter 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. これらのさまざまなコンポーネントの種類とインスタンスを使って、最終的に仮想データセンターを構築します。You use these different component types and instances to ultimately build a virtual datacenter.

44

仮想データセンターの上記のおおまかな概念アーキテクチャでは、ハブ スポーク トポロジのさまざまなゾーンで使用されるさまざまなコンポーネントの種類が示されています。The preceding high-level conceptual architecture of a virtual datacenter 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 group, 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 リソースの組み込みロール」をご覧ください。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.

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

仮想データセンターは、さまざまな基幹業務の複数のプロジェクトを安全にホストできるようにパーティション分割されています。A virtual datacenter is partitioned to securely host multiple projects across different lines of business. すべてのプロジェクトには、異なる分離環境 (開発、UAT、運用) が必要です。All projects require different isolated environments (Dev, UAT, production). これらの環境ごとに Azure サブスクリプションを分けると、自然な分離が提供されます。Separate Azure subscriptions for each of these environments 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.

この種の多層環境の一般的なアーキテクチャは、開発およびテスト用の Azure DevOps、ステージング用の UAT、運用環境で構成されます。A common architecture for these types of multitier environments consists of Azure 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. 前の図は、Azure DevOps および UAT 用と運用専用の 2 つの異なる Azure AD テナントが使用されているケースを示しています。The previous diagram shows a case where two different Azure AD tenants are used: one for Azure DevOps and UAT, and the other exclusively for production.

異なる Azure AD テナントが存在すると、必然的に環境間が分離されます。The presence of different Azure AD tenants enforces the separation between environments. 同じユーザー グループ (中央 IT など) が、プロジェクトの Azure DevOps または運用環境のロールやアクセス許可を変更するために Azure AD テナントにアクセスするときは、テナントごとに異なる URI を使用して認証する必要があります。The same group of users, such as the central IT, needs to authenticate by using a different URI to access a different Azure AD tenant to modify the roles or permissions of either the Azure 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

インフラストラクチャ コンポーネントは、仮想データセンター実装のさまざまなコンポーネントに相互接続を提供し、ハブとスポークの両方に存在します。Infrastructure components provide an interconnection for the different components of a virtual datacenter 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 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. 仮想データセンター実装に割り当てられたプライベート IP アドレス空間は、一貫性があり、オンプレミスのネットワークで割り当てられたプライベート IP アドレスと重複していない必要があります。The private IP address space assigned to a virtual datacenter 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. 管理の簡単さが仮想データセンターの主な目標の 1 つなので、NAT を使って IP の問題を処理することは推奨されるソリューションではありません。Simplicity of management is one of the key goals of the virtual datacenter, so using NAT to handle IP concerns 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 は、仮想データセンターの主要コンポーネントの 1 つであり、Azure プラットフォーム上にトラフィックの分離境界を作成できるようにします。Virtual Networks are one of main components of the virtual datacenter, and enable you to create a traffic isolation boundary on the Azure platform. Virtual Network は、1 つまたは複数の仮想ネットワーク セグメントで構成され、それぞれが特定の IP ネットワーク プレフィックス (サブネット) を持ちます。A Virtual Network is composed of a single or multiple virtual network segments, each with a specific IP network prefix (a subnet). Virtual Network では、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 cannot 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.
  • ユーザー定義ルート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 overwrite 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 送信先ポート上のトラフィック フィルターとして機能するセキュリティ規則のリストです。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. ネットワーク セキュリティ グループは、サブネットと、Azure VM に関連付けられた仮想 NIC カードの、どちらか一方または両方に適用できます。The network security group can be applied to a subnet, a Virtual NIC card 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. 仮想データセンター実装の VNet 内のリソースの名前解決は、DNS によって提供されます。The name resolution of resources in the VNets of a virtual datacenter implementation is provided through DNS. 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.
  • サブスクリプションリソース グループ管理Subscription and Resource Group Management. サブスクリプションでは、Azure にリソースの複数のグループを作成する自然な境界が定義されています。A subscription defines a natural boundary to create multiple groups of resources in Azure. サブスクリプションのリソースは、リソース グループと呼ばれる論理コンテナーにまとめられています。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 of a virtual datacenter implementation.
  • RBACRBAC. RBAC を使うと、組織のロールと特定の Azure リソースにアクセスするための権限をマップすることができ、ユーザーをアクションの特定のサブセットのみに制限することができます。Through RBAC, it is possible to map organizational role along with rights to access specific Azure resources, allowing you to restrict users to only a certain subset of actions. 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. たとえば、RBAC を使って、ある従業員にはサブスクリプションで仮想マシンを管理できるようにし、他の従業員にも同じサブスクリプション内で SQL DB を管理できるようにします。For example, use RBAC to let one employee manage virtual machines in a subscription, while another can manage SQL DBs within the same subscription.
  • VNet ピアリングVNet Peering. 仮想データセンターのインフラストラクチャの作成に使用される基本的な機能は、VNet ピアリングです。これは、Azure データ センターのネットワークを介して、あるいはリージョンをまたがる Azure の世界規模のバックボーンを使用して、同じリージョンの 2 つの仮想ネットワーク (VNet) を接続するメカニズムです。The fundamental feature used to create the infrastructure of a virtual datacenter is VNet peering, a mechanism that connects two virtual networks (VNets) in the same region through the Azure datacenter network, or using the Azure world-wide backbone across regions.

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

境界ネットワーク コンポーネントを使用すると、オンプレミス ネットワークまたは物理データセンター ネットワーク間のネットワーク接続だけでなく、インターネットとの間の双方向の接続も提供できます。Perimeter network components enable network connectivity between your on-premises or physical datacenter networks, along with any connectivity to and from the Internet. このコンポーネントは、ネットワークおよびセキュリティ チームが最も多くの時間を費やす場所でもあります。It's also where your network and security teams likely spend most of their time.

受信パケットは、スポーク内のバックエンド サーバーに到達する前に、ハブのセキュリティ アプライアンスを通過する必要があります。Incoming packets should flow through the security appliances in the hub before reaching the back-end servers in the spokes. セキュリティ アプライアンスの例として、ファイアウォール、IDS、IPS があります。Examples are 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. このフローは、ポリシーの適用、検査、監査を目的としています。The purposes of this flow are policy enforcement, inspection, and auditing.

境界ネットワーク コンポーネントは、次の機能を提供します。Perimeter network components provide the following features:

通常、中央 IT チームとセキュリティ チームは、境界ネットワークの要件の定義と運用を担当します。Usually, the central IT 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 の複数のファームを使って、多数の LOB をサポートするようにインターネットへの境界ネットワークをスケールアップできます。In the DMZ hub, the perimeter network to internet can scale up to support large numbers of LOBs, using multiple farms of Web Application Firewalls (WAFs) or Azure Firewalls. ハブでは、必要に応じて VPN または ExpressRoute 経由で接続することもできます。In hub also allows for connectivity via VPN or ExpressRoute as needed.

仮想ネットワークVirtual networks. 通常、ハブは複数のサブネットを含む仮想ネットワーク上に構築され、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 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. ユーザー定義ルートはハブとスポークのどちらにでも作成でき、仮想データセンター実装で使用される特定のカスタム 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 virtual datacenter 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, cloud-based network security service that protects your Azure Virtual Network resources. 組み込みの高可用性とクラウドの無制限のスケーラビリティを備えた、完全にステートフルなサービスとしてのファイアウォールです。It's a fully stateful firewall as a service with built-in high availability and unrestricted 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.

ネットワーク仮想アプライアンス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).

一般に、さまざまな LOB で多くの Web アプリケーションが使用されます。Different LOBs commonly use many web applications. これらのアプリケーションは、さまざまな脆弱性や潜在的な悪用の影響を受ける傾向があります。These applications 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 the Azure marketplace.

インターネットから送信されるトラフィックとオンプレミスから送信されるトラフィックには、それぞれ異なる Azure Firewall (または NVA) のセットを使用してください。Use one set of Azure Firewalls (or NVAs) for traffic originating on the Internet, and another for traffic originating on-premises. 両方にただ 1 つのファイアウォールのセットを使うと、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 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 アドレス プール (例: ネットワーク仮想アプライアンスまたは VM) のセットに再配信できます。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 (examples are Network Virtual Appliances or VMs).

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 to services in the spokes, 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. このプラットフォームは、パフォーマンス、信頼性、サポートの SLA やコンプライアンス認定資格に加え、Azure でネイティブに開発、運用、サポートされている監査可能なセキュリティ プラクティスを提供します。The platform offers performance, reliability and support SLAs, compliance certifications and auditable security practices developed, operated, and supported natively by Azure.

Application Gateway Microsoft Azure Application Gateway は、アプリケーション配信コントローラー (ADC) をサービスとして提供する専用仮想アプライアンスで、さまざまなレイヤー 7 負荷分散機能をアプリケーションで利用できるようにします。Application Gateway Microsoft Azure Application Gateway is a dedicated virtual appliance providing application delivery controller (ADC) as a service, offering various layer 7 load-balancing capabilities for your application. これにより、CPU を集中的に使用する SSL 終了を Application Gateway にオフロードし、Web ファームの生産性を最適化できます。It allows you to optimize web farm productivity by offloading CPU intensive SSL termination to the application gateway. また、着信トラフィックのラウンド ロビン分散、Cookie ベースのセッション アフィニティ、URL パス ベースのルーティング、単一の Application Gateway の背後で複数の Web サイトをホストする機能など、その他のレイヤー 7 ルーティング機能も用意されています。It also provides other layer 7 routing capabilities including 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 can be accessed from the internet. このエンドポイントでは、ネットワーク アドレス変換 (NAT) を使用して、Azure 仮想ネットワーク上の内部アドレスとポートにトラフィックをルーティングします。This endpoint uses network address translation (NAT) to route traffic to the internal address and port on the Azure virtual network. これは、外部トラフィックが仮想ネットワークに到達するための主な経路です。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 are Azure Load Balancer, Azure Application Gateway, and Azure Service Fabric instances. 攻撃中および履歴の表示のために、Azure Monitor ビューからリアルタイムのテレメトリを使用できます。Real-time telemetry is 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 の Azure パブリック IP アドレスに対して保護が提供されます。Protection is provided for IPv4 Azure public IP addresses.

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

監視コンポーネントは、他のすべてのコンポーネントの種類からの可視性とアラートを提供します。Monitoring components provide visibility and alerting from all the other components 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 telemetry from your application 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 application.

Azure の主要なログの種類は次の 2 つです。There are two major types of logs in Azure:

  • Azure アクティビティ ログ (以前の名称は操作ログ) では、Azure サブスクリプションのリソースに対して実行された操作を把握できます。The Azure Activity Log, previously called Operational Logs, provides insight into the operations that were performed on resources in the Azure subscription. これらのログは、サブスクリプションのコントロールプレーン イベントを報告します。These logs report the control-plane events for your subscriptions. すべての Azure リソースで監査ログが生成されます。Every Azure resource produces audit logs.

  • Azure Monitor 診断ログは、リソースによって生成されるログであり、そのリソースの操作に関する豊富なデータを提供します。Azure Monitor diagnostic logs are logs generated by a resource that provides rich, frequent data about the operation of that resource. これらのログの内容は、リソースの種類によって異なります。The content of these logs varies by resource type.

99

ネットワーク セキュリティ グループ、特に次の情報のログを追跡することが重要です。It is important to track the logs for the network security groups, particularly this information:

  • イベント ログ: MAC アドレスに基づいて VM とインスタンス ロールに適用されるネットワーク セキュリティ グループ ルールに関する情報が提供されます。Event logs provide information on what network security group rules are applied to VMs and instance roles based on MAC address.
  • カウンター ログ: トラフィックを拒否または許可するために各ネットワーク セキュリティ グループ ルールが実行された回数を追跡します。Counter logs track how many times each network security groups rule was run to deny or allow traffic.

監査、スタティック分析、またはバックアップのために、すべてのログを Azure ストレージ アカウントに保存できます。All logs can be stored in Azure storage accounts for audit, static analysis, or backup purposes. Azure ストレージ アカウントにログを保存すると、さまざまな種類のフレームワークを使用してこのデータを取得、準備、分析、視覚化し、クラウド リソースの状態と正常性を報告できます。When you store the logs in an Azure storage account, customers can use different types of frameworks to retrieve, prep, analyze, and visualize this data to report the status and health of cloud resources.

大企業では、オンプレミス システムの監視用に標準的なフレームワークを既に利用していると考えられます。Large enterprises should already have acquired a standard framework for monitoring on-premises systems. そのフレームワークを拡張して、クラウド デプロイによって生成されたログを統合できます。They can extend that framework to integrate logs generated by cloud deployments. 組織では、Azure Log Analytics を使用して、すべてのログをクラウドに保持できます。By using Azure Log Analytics, organizations can keep all the logging in the cloud. Log Analytics は、クラウドベースのサービスとして実装されます。Log Analytics is implemented as a cloud-based service. そのため、インフラストラクチャ サービスへの投資を最小限に抑えて、このサービスをすぐに稼働させることができます。So you have it up and running quickly with minimal investment in infrastructure services. Log Analytics は、System Center Operations Manager などの System Center のコンポーネントと統合して、管理のための既存の投資をクラウドに拡張することもできます。Log Analytics also integrates with System Center components like System Center Operations Manager to extend your existing management investments into the cloud.

Log Analytics は、オペレーティング システム、アプリケーション、インフラストラクチャ クラウド コンポーネントによって生成されたログおよびパフォーマンス データを収集、関連付け、検索、操作するための、Azure のサービスです。Log Analytics is a service in Azure that helps collect, correlate, search, and act on log and performance data generated by operating systems, applications, and infrastructure cloud components. 統合された検索およびカスタム ダッシュボードを使って、仮想データセンター実装のすべてのワークロードのすべてのレコードを分析するためのリアルタイムの運用分析情報を提供します。It gives customers real-time operational insights using integrated search and custom dashboards to analyze all the records across all your workloads in your virtual datacenter implementation.

Azure Network Watcher は、Azure 仮想ネットワーク内のリソースの監視、診断、メトリックの表示、ログの有効化/無効化を行うツールを提供します。Azure Network Watcher provides tools to monitor, diagnose, and view metrics and enable or disable logs for resources in an Azure virtual network. これは、次のような機能を提供する多面的なサービスです。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.
  • Azure 仮想ネットワーク ゲートウェイと接続に関する問題を診断する。Diagnose problems with an Azure 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.

Operations Management Suite 内の Network Performance Monitor ソリューションは、ネットワークの詳細情報をエンド ツー エンドで提供できます。The Network Performance Monitor solution inside Operations Management Suite can provide detailed network information end-to-end. この情報には、Azure ネットワークとオンプレミス ネットワークの単一ビューが含まれます。This information includes a single view of your Azure networks and on-premises networks. このソリューションには、ExpressRoute とパブリック サービスの固有のモニターがあります。The solution has specific monitors for ExpressRoute and public services.

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

ワークロード コンポーネントは、実際のアプリケーションとサービスが存在する場所です。Workload components are where your actual applications and services reside. アプリケーション開発チームはここで最も多くの時間を費やします。It's also 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:

内部 LOB アプリケーション: 基幹業務アプリケーションは、企業の現在の経営にとって重要なコンピューター アプリケーションです。Internal LOB applications: Line-of-business applications are computer applications critical to the ongoing operation of an enterprise. LOB アプリケーションには、いくつかの一般的な特性があります。LOB applications have some common characteristics:

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

顧客向け Web サイト (インターネットまたは内部接続): インターネットと対話するほとんどのアプリケーションは Web サイトです。Customer facing web sites (internet or internal facing): Most applications that interact with the Internet are web sites. Azure は、IaaS VM 上または Azure Web Apps サイト (PaaS) から Web サイトを実行する機能を提供します。Azure offers the capability to run a web site on an IaaS VM or from an Azure Web Apps site (PaaS). Azure Web Apps は VNet との統合をサポートし、ネットワーク ゾーンのスポークに Web アプリをデプロイできます。Azure Web Apps support integration with VNets that allow the deployment of the Web Apps in a spoke network zone. プライベートの VNet からは、インターネット経由でルーティングできないプライベート アドレスを介してリソースにアクセスできるので、社内向け Web サイトでパブリック インターネット エンドポイントを公開する必要はありません。Internal 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 VNet.

ビッグ データと分析: データを膨大な量に拡張する必要があるときに、データベースが適切にスケールアップされない場合があります。Big Data and Analytics: When data needs to scale up to a large volume, databases may not scale up properly. Hadoop テクノロジは、多数のノードで分散クエリを並列に実行するシステムを提供します。Hadoop technology offers a system to run distributed queries in parallel on large number of nodes. ユーザーは、データ ワークロードを IaaS VM または PaaS (HDInsight) で実行することを選択できます。Customers have the option to run data workloads in IaaS VMs or PaaS (HDInsight). HDInsight は、場所ベースの VNet へのデプロイをサポートし、仮想データセンターのスポーク内のクラスターにデプロイできます。HDInsight supports deploying into a location-based VNet, can be deployed to a cluster in a spoke of a virtual datacenter.

イベントとメッセージング: Azure Event Hubs は、数百万のイベントを収集、変換、保存する、ハイパースケールのテレメトリ インジェスト サービスです。Events and Messaging: Azure Event Hubs is a hyperscale telemetry ingestion service that collects, transforms, and stores millions of events. 分散型のストリーミング プラットフォームとして、遅延時間が短く、保持時間を設定可能なため、膨大な量のテレメトリを Azure に送信し、複数のアプリケーションからデータを読み込むことができます。As a distributed streaming platform, it offers low latency and configurable time retention, enabling you to ingest massive amounts of telemetry into Azure and read that data from multiple applications. Event Hubs では、1 つのストリームでリアルタイム パイプラインとバッチ ベースのパイプラインの両方をサポートできます。With Event Hubs, 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. Azure Service Bus は、クライアントとサーバー間の非同期のブローカー メッセージング、構造化された先入れ先出し (FIFO) メッセージング、および発行機能とサブスクライブ機能を提供します。It offers asynchronous brokered messaging between client and server, structured first-in-first-out (FIFO) messaging, and publish and subscribe capabilities.

1010

仮想データセンターの可用性を高める: 複数の仮想データセンターMake a virtual datacenter highly available: multiple virtual datacenters

ここまで、この記事では、単一の仮想データセンターの設計に注目し、回復性に寄与する基本的なコンポーネントとアーキテクチャについて説明してきました。So far, this article has focused on the design of a single virtual datacenter, describing the basic components and architecture that contribute to resiliency. Azure には、Azure Load Balancer、NVA、可用性セット、スケール セット、そして運用サービスに確実な SLA レベルを構築できるシステムに寄与する他のメカニズムなどの機能があります。Azure features such as Azure load balancer, NVAs, availability sets, scale sets, along with other mechanisms contribute to a system that enables you to build solid SLA levels into your production services.

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

SLA の問題に加え、複数の仮想データセンター実装をデプロイすることに意味がある一般的なシナリオがいくつかあります。In addition to SLA concerns, there are several common scenarios where deploying multiple virtual datacenter implementations makes sense:

  • リージョンまたはグローバル プレゼンスRegional or global presence.
  • ディザスター リカバリーDisaster recovery.
  • データセンター間でトラフィックを転送するメカニズムA mechanism to divert traffic between datacenters.

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

Azure データセンターは世界中の多数のリージョンに存在します。Azure datacenters are present in numerous regions worldwide. 複数の Azure データセンターを選択するとき、ユーザーは地理的な距離と待機時間という関連する 2 つの要因を考慮する必要があります。When selecting multiple Azure datacenters, customers need to consider two related factors: geographical distances and latency. 最良のユーザー エクスペリエンスを提供するには、各仮想データセンター実装間の地理的な距離と、各仮想データセンター実装とエンド ユーザー間の距離を評価してください。To offer the best user experience, evaluate the geographical distance between each virtual datacenter implementation as well as the distance between each virtual datacenter implementation and the end users.

仮想データセンター実装がホストされているリージョンは、組織が運営されている法的管轄によって定められた規制要件に準拠している必要があります。The region in which virtual datacenter implementations are hosted must conform with regulatory requirements established by any legal jurisdiction under which your organization operates.

障害復旧Disaster recovery

ディザスター リカバリー計画の設計は、ワークロードの種類と、さまざまな仮想データセンター実装間でワークロードの状態を同期する機能によって変わります。The design of a disaster recovery plan depends on the types of workloads and the ability to synchronize state of those workloads between different virtual datacenter implementations. ほとんどのお客様は高速フェールオーバー メカニズムを望んでおり、そのためには、状況に応じて複数の仮想データセンター実装を実行するデプロイ間でアプリケーション データを同期する必要があります。Ideally, most customers desire a fast fail-over mechanism, and this may require application data synchronization between deployments running multiple virtual datacenter 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.

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

  • VNet ピアリング - VNet ピアリングはリージョンをまたいでハブを接続できます。VNet Peering - VNet Peering can connect hubs across regions.
  • ExpressRoute のプライベート ピアリング (各仮想データセンター実装内のハブが同じ ExpressRoute 回線に接続されている場合)。ExpressRoute private peering when the hubs in each virtual datacenter implementation are connected to the same ExpressRoute circuit.
  • 企業バックボーン経由で接続されている複数の ExpressRoute 回線と、ExpressRoute 回線に接続された複数の仮想データセンター実装。Multiple ExpressRoute circuits connected via your corporate backbone and multiple virtual datacenter implementations connected to the ExpressRoute circuits.
  • 各 Azure リージョン内の仮想データセンター実装のハブ ゾーン間のサイト間 VPN 接続。Site-to-Site VPN connections between the hub zone of your virtual datacenter implementations in each Azure region.

Microsoft バックボーン経由の通過では、高い帯域幅と一貫性のある待機時間レベルなので、VNet ピアリングまたは ExpressRoute の接続が通常は好ましい種類のネットワーク接続です。Typically, VNet Peering or ExpressRoute connections are the preferred type of network connectivity due to the higher bandwidth and consistent latency levels when transiting through the Microsoft backbone.

このような接続の待機時間と帯域幅を確認し、その結果に基づいて同期または非同期のデータ レプリケーションが適切かどうかを判断するために、ネットワーク認定テストを実行することをお勧めします。We recommend that customers 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 Manager では、異なる仮想データセンター実装のパブリック エンドポイントのサービス正常性が定期的にチェックされ、対象のエンドポイントに障害が発生した場合は、ドメイン ネーム システム (DNS) を使用してセカンダリ仮想データセンターに自動的にルーティングされます。Azure Traffic Manager periodically checks the service health of public endpoints in different virtual datacenter implementations and, if those endpoints fail, it routes automatically to the secondary virtual datacenter using the Domain Name System (DNS).

DNS が使用されるため、Traffic Manager は Azure パブリック エンドポイントにのみ使用できます。Because it uses DNS, Traffic Manager is only for use with Azure public endpoints. 通常、このサービスは、仮想データセンター実装の正常なインスタンスで Azure VM および Web アプリへのトラフィックを制御または転送するために使用されます。The service is typically used to control or divert traffic to Azure VMs and Web Apps in the healthy instance of a virtual datacenter implementation. Traffic Manager は、Azure リージョン全体で障害が発生した場合でも回復性があり、複数の条件に基づいて、異なる仮想データセンター内のサービス エンドポイントに対するユーザー トラフィックの分散を制御できます。Traffic Manager is resilient even in the face of an entire Azure region failing and can control the distribution of user traffic for service endpoints in different virtual datacenters based on several criteria. たとえば、特定の仮想データセンターのサービスの障害や、クライアントのネットワーク待機時間が最も短い仮想データセンターの選択などです。For example, failure of a service in a specific virtual datacenter implementation, or selecting the virtual datacenter implementation with the lowest network latency.

まとめSummary

仮想データ センターは、クラウド リソースの使用を最大化し、コストを削減し、システムのガバナンスを簡素化するスケーラブルなアーキテクチャを Azure で作成するためのデータ センター移行のアプローチです。A virtual datacenter is an approach to datacenter migration to create a scalable architecture in Azure that maximizes cloud resource use, reduces costs, and simplifies system governance. 仮想データセンター実装の概念はハブとスポークのトポロジに基づいており、ハブで共通の共有サービスを提供し、スポークで特定のアプリケーションおよびワークロードを実行できます。A virtual datacenter is based on a hub and spoke network topology, providing common shared services in the hub and allowing specific applications and workloads in the spokes. また、仮想データセンターは、さまざまな部門 (中央 IT、DevOps、運用保守) すべてが協力すると同時に各部門の役割を果たすという、会社の役割の構造にも対応しています。A 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. 仮想データセンターは、リフトアンドシフト移行の要件を満たしますが、ネイティブなクラウド デプロイにも多くの利点をもたらします。A virtual datacenter satisfies the requirements for a lift and shift migration, but also provides many advantages to native cloud deployments.

参照References

このドキュメントでは以下の機能について説明しました。The following features were discussed in this document. 詳細については、次のリンクを参照してください。Follow the links to learn more.

ネットワーク機能Network Features 負荷分散Load Balancing 接続Connectivity
Azure 仮想ネットワークAzure Virtual Networks
ネットワーク セキュリティ グループNetwork Security Groups
ネットワーク セキュリティ グループのログNetwork Security Group Logs
ユーザー定義ルートUser-Defined Routes
ネットワーク仮想アプライアンスNetwork Virtual Appliances
パブリック IP アドレスPublic IP Addresses
Azure DDoSAzure DDoS
Azure FirewallAzure Firewall
Azure DNSAzure DNS
Azure Front DoorAzure Front Door
Azure Load Balancer (L3)Azure Load Balancer (L3)
Application Gateway (L7)Application Gateway (L7)
[Web アプリケーション ファイアウォール][WAF][Web Application Firewall][WAF]
Azure の Traffic ManagerAzure Traffic Manager
VNET ピアリングVNet Peering
仮想プライベート ネットワークVirtual Private Network
Virtual WANVirtual WAN
ExpressRouteExpressRoute
ExpressRoute DirectExpressRoute Direct
IDIdentity
監視Monitoring
ベスト プラクティスBest Practices
Azure Active DirectoryAzure Active Directory
Multi-Factor AuthenticationMulti-Factor Authentication
ロールベースのアクセス制御Role Base Access Controls
既定の Azure AD ロールDefault Azure AD Roles

Network WatcherNetwork Watcher
Azure MonitorAzure Monitor
アクティビティ ログActivity Logs
診断ログDiagnostic Logs
Microsoft Operations Management SuiteMicrosoft Operations Management Suite
ネットワーク パフォーマンス監視Network Performance Monitor
境界ネットワークのベスト プラクティスPerimeter Networks Best Practices
サブスクリプション管理Subscription Management
リソース グループ管理Resource Group Management
Azure サブスクリプションの制限Azure Subscription Limits

その他の Azure サービスOther Azure Services
Azure Web AppsAzure Web Apps
HDInsight (Hadoop)HDInsight (Hadoop)
Event HubsEvent Hubs
Service BusService Bus

次の手順Next steps

  • 仮想データセンターのハブとスポークの設計の基礎となるテクノロジである VNet ピアリングの詳細を確認しますExplore VNet Peering, the underpinning technology for virtual datacenter hub and spoke designs.
  • Azure AD を実装して RBAC の調査を始めます。Implement Azure AD to get started with RBAC exploration.
  • 組織の構造、要件、ポリシーに対応する、サブスクリプションおよびリソース管理モデルと RBAC モデルを開発します。Develop a Subscription and Resource management model and RBAC model to meet the structure, requirements, and policies of your organization. 最も重要なアクティビティは計画です。The most important activity is planning. 再編成、合併、新しい製品ライン、その他の考慮事項について、できるだけ実用的な計画を立ててください。As much as practical, plan for reorganizations, mergers, new product lines, and other considerations.