Azure ランディング ゾーンに関する独立系ソフトウェア ベンダー (ISV) の考慮事項

多くの組織では、Azure ランディング ゾーンの概念アーキテクチャは、クラウド導入の取り組みの目的地を表しています。 ランディング ゾーンは、複数のサブスクリプションを使用して Azure 環境を構築する方法を表します。 各ランディング ゾーンは、スケール、セキュリティ、ガバナンス、ネットワーク、ID を考慮し、多くのお客様から得られたフィードバックと教訓に基づいています。

Azure でソリューションを構築および運用する独立系ソフトウェア ベンダー (ISV) は、Azure 環境を構築する際に次のリソースを参照する必要があります。

• Azure ランディング ゾーン: Azure 環境全体に関するガイダンスを提供します。
• Azure Well-Architected フレームワーク: すべてのワークロードに適用できるアーキテクチャに関するガイダンスを提供します。
• Azure でのマルチテナント ソリューションの設計: Azure 上の マルチテナント ソリューションの具体的なアーキテクチャに関するガイダンスを提供します。

Azure ランディング ゾーンを使用すると、Azure 環境全体の方向性を選ぶことができます。 ただし、ISV、SaaS プロバイダー、またはスタートアップでは、具体的な実装のニーズがより標準的な顧客シナリオとは異なる場合があります。 以下に、実装シナリオの例をいくつか紹介します。

• 顧客がその独自のサブスクリプションにデプロイするソフトウェアを構築します。
• 独自の "コントロール プレーン" があり、自動化スクリプトまたはソフトウェアを使用して、SaaS ソリューションの Azure リソースをデプロイおよび構成します。
• 小規模な ISV またはスタートアップが、可能な限り低いコストで始めることを望んでいて、当初は Azure Firewall や Azure DDoS Protection などのサービスを使用しないと考えています。
• 大規模な SaaS ISV が、スケーリングを目的に SaaS アプリケーションを複数のサブスクリプションに分割することを計画しています。 また、サブスクリプションを、開発、テスト、ステージング、運用の各環境に対応するようにグループ化することも考えています。
• 組織の運用モデルでは、企業 IT チームと SaaS 製品チームの役割を分けています。 組織の企業 IT チームは Microsoft Office 365 や Microsoft Teams などのリソースを管理し、SaaS 製品チームは SaaS 製品 (その中央プラットフォームや ID コンポーネントを含む) の構築と運用を担当するといったことが考えられます。

ISV デプロイ モデル

ISV ソリューションは、多くの場合、3 つのデプロイ モデル (純粋な SaaS、顧客デプロイ、デュアルデプロイ SaaS) のいずれかに適合します。 このセクションでは、Azure ランディング ゾーンに関する各モデルのさまざまな考慮事項について説明します。

純粋な SaaS

純粋な SaaS モデルでは、ソフトウェアは完全に Azure サブスクリプションのみにデプロイされます。 エンド カスタマーは、その独自の Azure サブスクリプションにデプロイせずにソフトウェアを使用します。 次の図では、ユーザーは ISV によって提供された純粋な SaaS アプリケーションを使用しています。

純粋な SaaS ソフトウェアの例としては、サービスとしてのメール、サービスとしての Kafka、サービスとしてのクラウド データ ウェアハウス、さらに Azure Marketplaceの SaaS 一覧にある多くのものがあります。

小規模な SaaS ISV であれば、リソースをすぐにデプロイするために複数の Azure サブスクリプションを使用することは必要ないと考えられます。 ただし、拡大していくにつれ、1 つのサブスクリプション内でスケーリングする能力が、Azure のサブスクリプション制限に影響される可能性があります。 「エンタープライズ規模のランディング ゾーン設計原則」 (特にサブスクリプションの民主化) を検討し、マルチテナントのアーキテクチャ アプローチを理解することで、将来の成長について計画してください。

純粋な SaaS ソリューションを構築する ISV では、次の質問について検討する必要があります。

• SaaS ソリューションを構成するすべての Azure リソースを 1 つの Azure サブスクリプションに含めるか、それとも複数の Azure サブスクリプションにパーティション分割するか?
• 各顧客をそれぞれ独自の専用 Azure サブスクリプションでホストするか、それとも 1 つ以上の共有サブスクリプション内にリソースを作成できるか?
• ソリューションのすべてのレベルにデプロイ スタンプ (スケール ユニット) パターンを適用するにはどうすればよいか?
• マルチテナント ソリューションで Azure リソース組織を使用して、スケーリングの課題や Azure サブスクリプションの制限に直面しないようにするにはどうすればよいか?

顧客デプロイ

顧客デプロイ モデルでは、エンド カスタマーがソフトウェアを購入して独自の Azure サブスクリプションにデプロイします。 デプロイは、Azure Marketplace から開始する場合も、手順に従って提供されたスクリプトを使用して手動で行う場合もあります。

次の図では、ISV はソフトウェア パッケージまたは Azure Marketplace カタログ製品を提供し、ユーザーはそのリソースを他のワークロードと共に独自の Azure サブスクリプションにデプロイします。

図の "顧客の他のワークロード" の要素は、顧客自身のワークロードまたは顧客が Azure サブスクリプション内にデプロイした別の ISV 製品を表します。 顧客は、多くの場合、さまざまな ISV の複数の製品を Azure サブスクリプションにデプロイします。 これらの個々の製品を組み合わせてソリューションを作成します。 たとえば、顧客がデプロイするデータベース製品、ネットワーク仮想アプライアンス、Web アプリケーションが、それぞれ異なる ISV のものであることが考えられます。

顧客デプロイの ISV 製品の例としては、Azure Marketplace 内の多くの仮想マシン イメージ (ネットワークやストレージの仮想アプライアンスなど) と Azure アプリケーションなどがあります。

一部の顧客デプロイのソリューションでは、組織が、Azure Lighthouse または Azure Managed Applications を使用して、エンド カスタマーの Azure サブスクリプション内にデプロイされたソリューションの管理を行い、更新プログラムを提供する場合があります。 ISV、ソリューション インテグレーター (SI)、マネージド サービス プロバイダー (MSP) はすべて、特定のニーズを満たす際にこの戦略を使用できます。

顧客デプロイの ISV ソリューションは、Azure ランディング ゾーンの観点では標準のアプリケーション ワークロードと見なされます。 Azure の顧客が採用している Azure ランディング ゾーンの設計原則に対応するように製品を設計する際には、Azure ランディング ゾーンのガイダンスを確認してください。

既存の顧客のワークロードを Azure に移行する際には、Azure ランディング ゾーンの概念を的確に理解しておくことが特に重要です。

顧客デプロイのソリューションを構築する ISV では、次の質問について検討する必要があります。

• 顧客がソリューションをその独自の専用サブスクリプションにデプロイするか、それとも関連するワークロードを含む既存のサブスクリプションにデプロイするか?
• 既存のワークロード (Azure の内部と外部) とソリューションの間で、顧客がどのようにネットワーク接続を確立するか?
• ソリューションが、Microsoft Entra ID の認証メカニズムをサポートするか、それとも LDAP や Kerberos などの他のプロトコルを必要とするか?
• Azure Policy 違反 (ソリューション テンプレートと顧客の Azure ポリシーの間の競合が原因のものなど) を削減または排除するにはどうしたらよいか?

Azure Policy 違反を引き起こす可能性のある顧客の Azure ポリシーには、"All subnets must have a network security group (すべてのサブネットにはネットワーク セキュリティ グループが必要です)" や "No public IP addresses can be attached to network interfaces in the Corp landing zone (企業のランディング ゾーンのネットワーク インターフェイスにはパブリック IP アドレスをアタッチできなません)" などの例が含まれます。 デプロイを計画する際は、これらの競合の原因となるポリシーの可能性を念頭に置いてください。

デュアル デプロイ SaaS

一部の SaaS ソリューションは、顧客の Azure サブスクリプションにデプロイされたリソースと対話したり、それを使用したりします。 このデプロイ モデルは、"デュアル デプロイ SaaS" または "SaaS ハイブリッド" と呼ばれることがあります。 次の図では、ISV は、エンド カスタマーの Azure サブスクリプションにデプロイされたリソースと対話するホスト型 SaaS ソリューションを提供しています。

"デュアル デプロイ SaaS" の実際の例として、Microsoft Power BI があります。これは、顧客の Azure サブスクリプション内の仮想マシンにデプロイされた Power BI オンプレミス データ ゲートウェイを必要に応じて使用できる SaaS サービスです。

"デュアル デプロイ SaaS" シナリオのその他の例を次に示します。

• 組織は、Virtual Desktop Manager (各顧客の Azure サブスクリプションで Azure Virtual Desktop リソースを制御するための SaaS コンソール インターフェイスを提供する製品) を構築します。
• 組織は、データ分析用の SaaS コンソールを提供し、各顧客の Azure サブスクリプションでコンピューティング ノード仮想マシンを動的に作成および削除します。

デュアル デプロイ ISV は、Azure ランディング ゾーンを参照して 2 つの分野でのガイダンスを確認する必要があります。つまり、SaaS サービスをホストする独自の Azure 環境を構築すること、および顧客の Azure サブスクリプション内のデプロイと顧客のランディング ゾーンとの間で適切に対話できるようにすることです。

デュアル デプロイ SaaS ソリューションを構築する ISV では、次の質問について検討する必要があります。

• 純粋な SaaS および顧客デプロイの両方のソリューションを構築するための考慮事項をすべて確認したか?
• ソリューションのどのコンポーネントを Azure サブスクリプションでホストし、どのコンポーネントを顧客デプロイにするか?
• 顧客の Azure サブスクリプションにデプロイされたリソースを安全にプロビジョニングおよび操作するにはどうすればよいか?

Azure ランディング ゾーンの設計の原則と実装

Azure のランディング ゾーン設計原則では、Log Analytics、Azure Monitor、Azure Firewall などの Azure ネイティブ プラットフォームの機能に合わせることをお勧めしています。 ランディング ゾーンのガイダンスでは、具体的な Azure ランディング ゾーン実装オプションも示しています。

ISV として、独自のランディング ゾーン環境を実装することを決定する場合があります。 独自の自動化を使用して複数のサブスクリプション全体に Azure リソースをデプロイすることが必要になる場合があります。 または、ログ、監視、その他のプラットフォームレベル サービスに既に使用しているツールをそのまま使用する場合もあります。

独自のランディング ゾーン環境を実装する場合は、参照用に Azure ランディング ゾーンのガイダンスとサンプル実装を使用し、使用する手法を実績ある Azure ランディング ゾーンの設計に合わせることをお勧めします。

Microsoft Entra テナント

各 Azure ランディング ゾーンとその管理グループ階層は、そのルートを 1 つの Microsoft Entra テナントとしています。 つまり、最初に決定する必要があることは、Azure リソースを管理するための ID のソースとして、どの Microsoft Entra テナントを使用するかということです。 Microsoft Entra ID の ID には、ユーザー、グループ、サービス プリンシパルが含まれます。

Azure ランディング ゾーンと Microsoft Entra テナントのガイダンスでは、Microsoft Entra テナントを 1 つだけ使用することを強くお勧めしています。これはほとんどの状況に適した手法です。 ただし、SaaS ISV として、2 つのテナントを使用する理由が生じる場合があります。

一部の SaaS ISV では、1 つのチームが企業のリソースを管理し、別のチームが SaaS ソリューションを運用しています。 この分離は、運用上の理由から、または規制要件に準拠するために行われます。 企業の IT チームは SaaS 関連のサブスクリプションとリソースを管理することが許可されないため、Microsoft Entra テナントの管理者にはなれない可能性があります。 このシナリオが該当する場合は、2 つの別個の Microsoft Entra テナント (Office 365 などの企業の IT リソース用 に 1 つのテナント、SaaS ソリューションを構成する Azure リソース用に 1 つのテナント) を使用することを検討してください。

各 Microsoft Entra テナントには、独自のドメイン名が必要です。 組織で 2 つのテナントを使用している場合は、次の図に示すように、企業のMicrosoft Entra テナントには contoso.com、SaaS Microsoft Entra テナントには contoso-saas-ops.com といった名前を選ぶことができます。

運用前と運用の環境に、別々の Microsoft Entra テナントを使用することは避けてください。 別個の Azure サブスクリプションを使用する contoso-saas-ops-preprod.com と contoso-saas-ops-prod.com などの 2 つのテナントを作成するのではなく、1 つの Microsoft Entra テナントを作成してください。 管理グループと Azure RBAC を使用して、この 1 つのテナントのもとでサブスクリプションとリソースへのアクセスを制御できます。

複数の Microsoft Entra テナントを使用する場合の詳細については、「Azure ランディング ゾーンと複数の Microsoft Entra テナント」および「マルチ テナントでのリソースの分離」を参照してください。

管理グループ

「Azure ランディング ゾーンの概念アーキテクチャ」では、特定の管理グループ階層の使用をお勧めしています。 ただし、ISV には他の組織とは異なる要件がある場合があります。 このセクションでは、ランディング ゾーンの概念アーキテクチャでお勧めするものとは異なる手法を採用するために、ISV 組織で選ばれているいくつかの方法について説明します。

最上位の管理グループ

管理グループ階層は、Azure で作成されたテナント ルート グループ管理グループの下で入れ子になっています。 テナント ルート グループは直接使用しません。

プラットフォームと共有サービス (ログ、ネットワーク、ID、セキュリティなど) を管理する一元化された企業 IT チームを持つ標準的な組織は、通常、Azure で作成されたテナント ルート グループの下に最上位の管理グループを 1 つ作成し、その下に残りの管理グループをデプロイします。 この最上位の管理グループは、通常、組織自体 (Contoso など) の名前にちなんで命名されます。

SaaS ISV には、SaaS 製品が 1 つある場合、または複数の SaaS 製品や基幹業務がある場合があります。 一般に、すべての製品で同じMicrosoft Entra テナントを使用して Azure リソースを管理する (「Microsoft Entra テナント」セクションの説明のとおり) 必要がありますが、任意で複数の管理グループ階層をデプロイすることもあります。

製品が互いにどの程度独立性を持っているかを検討し、ご自身に次のように質問してください。

• 製品がすべて、DevOps、ID、セキュリティ、接続、ログに同じプラットフォームを使用しているか?
• これらの共有サービスが 1 つの中央チームによって運用されているか?

両方の質問に対して "はい" と答えた場合は、テナント ルート グループの下に最上位の SaaS 製品管理グループを 1 つ作成します。

そうではなく、"いいえ" と答えていて、各 SaaS 製品が別々のプラットフォーム チームによって管理および運用されている場合は、製品ごとに別の最上位の管理グループ (たとえば、SaaS Product-01 と SaaS Product-02 の 2 つの最上位の管理グループ) を作成することを検討してください。

この管理手法は、エンタープライズ規模のランディング ゾーンのテスト手法に似ています。 ただし、この手法の場合、テナント ルート グループの下に Contoso と Contoso-Canary を作成するのではなく、この例の会社では、その下に製品固有の Contoso-SaaS-Product-01、Contoso-SaaS-Product-02、Contoso-SaaS-Product-03 という最上位の管理グループを作成します。 次の図は、このシナリオを説明したものです。

プラットフォーム管理グループ

Azure ランディング ゾーンのリソース組織階層では、プラットフォーム管理グループに、ランディング ゾーン サブスクリプションのワークロードで使用されるコンポーネントと共有サービスをホストする、すべての Azure サブスクリプションが含まれています。 プラットフォームと共有サービスのサブスクリプションにデプロイされるコンポーネントの例としては、一元化されたログ インフラストラクチャ (Log Analytics ワークスペースなど)、DevOps、セキュリティ、自動化ツール、中央ネットワーク リソース (ハブ VNet や DDos Protection プランなど)、ISV のコントロール プレーン サービスなどがあります。

プラットフォーム管理グループは、多くの場合、ID、管理、接続という子グループにパーティション分割され、企業のお客様がロールとポリシーを簡単に分離できるようにします。

組織内に、ID、ネットワーク、管理など、すべての共有プラットフォーム コンポーネントを管理する 1 つのチームが存在する場合があります。 その場合、その管理を複数のチームに分ける予定がなければ、1 つのプラットフォーム管理グループを使用することを検討してください。

代わりに、一元化されたプラットフォームのさまざまな部分を管理する個別のチームを設ける場合、プラットフォーム管理グループの下の管理グループ階層に追加のレベルをデプロイする必要があります。 これにより、一元化されたプラットフォームの部分ごとにそれぞれ別のポリシーを割り当てることができます。

次の図は、プラットフォーム管理グループで可能な 2 つの実装を示しています。 オプション A は、より包括的なシナリオを示しています。この場合、プラットフォーム管理グループに、管理とDevOps、ID とセキュリティ、接続という 3 つの子管理グループが含まれています。 各子管理グループには、関連するリソースを含むサブスクリプションが含まれています。 オプション B は、よりシンプルなシナリオを示しています。この場合、プラットフォーム管理グループには 1 つのプラットフォーム サブスクリプションが含まれています。

ランディング ゾーン管理グループ

ランディング ゾーン管理グループには、SaaS ソリューションの実際のサブシステムとワークロードをホストする Azure サブスクリプションが含まれています。

この管理グループには、1 つ以上の子管理グループが含まれています。 ランディング ゾーンの下の各子管理グループは、ワークロードまたはサブシステムの "アーキタイプ" を表します。これには、すべてのサブスクリプションに一貫して適用する必要があるポリシーとアクセスの要件が含まれます。 複数のアーキタイプを使用する理由には、次のようなものがあります。

• コンプライアンス: SaaS 製品のサブシステムが PCI-DSS に準拠する必要がある場合は、ランディング ゾーンの下に PCI DSS アーキタイプの子管理グループを作成することを検討してください。 PCI-DSS コンプライアンスの適用範囲内のリソースを含むすべての Azure サブスクリプションは、その管理グループ内に配置する必要があります。
• レベル: SaaS ソリューションの "専用" レベルの顧客と "無料" レベルの顧客に対して、それぞれ別のランディング ゾーン アーキタイプを作成することを検討してください。 各子管理グループには、異なる Azure Policy 設定が含まれています。 たとえば、無料レベルのポリシーでは、特定の仮想マシン SKU のみを有効にするようにデプロイを制限し、専用レベルのポリシーでは、リソースを特定のリージョンにデプロイすることを求める、といったことが考えられます。

環境固有の管理グループ

SaaS ISV では、多くの場合、一連のソフトウェア開発ライフサイクル環境をモデル化することで、クラウド環境を整理します。 この場合、通常は最初に "開発" 環境に、次に "テスト" 環境に、その次は "ステージング" 環境に、そして最後に "運用" 環境にデプロイする必要があります。

これらの環境の一般的な違いの 1 つは、各サブスクリプション グループに誰がアクセスできるかといった、Azure RBAC ルールです。 たとえば、DevOps、SaaSOps、開発、テストのチームはすべて、それぞれ異なる環境に対して異なるレベルのアクセス権を持つことが考えられます。

SaaS ISV では、同じサブシステム、アプリケーション、またはワークロードの "シャード" または "パーティション" を表す複数のサブスクリプションをグループ化する必要が生じる場合があります。 場合によっては、アーキタイプ管理グループとはまったく異なる方法で、サブスクリプションのグループにポリシーまたはロールの割り当てを適用する必要があります。 この場合は、アーキタイプ管理グループの下に、各環境に対応する子管理グループを作成することを検討してください。

次の図は、2 つの可能なオプションを示しています。 オプション A が示すシナリオでは、環境ごとにそれぞれ別のサブスクリプションがありますが、環境固有の管理グループはありません。 オプション B では、Regular スタンプ管理グループの下に環境固有の管理グループがある SaaS ISV シナリオを示しています。 各環境固有の管理グループには、複数のサブスクリプションが含まれています。 ISV では、時間の経過と共に、共通したポリシーとロールの割り当てのセットを含み、数が増加しているサブスクリプションを対象に、各環境内で Azure リソースをスケーリングしていきます。

各タブを選択すると、2 つの図が表示されます。

使用停止およびサンドボックスの管理グループ

Azure ランディング ゾーンのリソース組織のガイダンスでは、最上位の管理グループのすぐ下に使用停止とサンドボックスの管理グループを含めることをお勧めしています。

使用停止管理グループは、無効になっていて最終的には削除される Azure サブスクリプションが保持される場所です。 使用されなくなったサブスクリプションをこの管理グループに移動して、そのサブスクリプション内のすべてのリソースが完全に削除されるまで追跡できます。

サンドボックス管理グループには通常、調査の目的に使用されAzure サブスクリプションが含まれ、それらに適用されるポリシーは緩やかであるか、存在しません。 たとえば、個々の開発者に、開発とテスト用の独自のサブスクリプションを提供する場合などがあります。 これらのサブスクリプションをサンドボックス管理グループに配置することで、通常のポリシーとガバナンスをそれらに適用しないようにすることができます。 これにより、開発者の俊敏性が向上し、Azure を簡単に試すことができます。

次の図は、2 つの可能なオプションを示しています。 オプション A には使用停止とサンドボックスの管理グループは含まれていませんが、オプション B には含まれています。

ISV ランディング ゾーンの例

このセクションでは、SaaS ISV の 2 つの Azure ランディング ゾーン構造の例を示します。 各タブを選択して、2 つのランディング ゾーンの例を比較してください。

次の手順

• マルチテナント ソリューションを構築する場合は、Azure でのマルチテナント ソリューションの設計に関する詳細を確認します。
• Azure ランディング ゾーンとは何であるかを確認します。
• 「Azure ランディング ゾーンの設計領域」を確認します。