サブスクリプションに関する考慮事項と推奨事項

サブスクリプションは、Azure 内での管理、課金、スケールの単位です。 大規模な Azure 導入を計画するときに、重要な役割を果たします。 この記事は、次のような重要な要素に基づいて、サブスクリプション要件を把握し、ターゲット サブスクリプションを設計する場合に役立ちます。

• 環境の種類
• 所有権とガバナンス モデル
• 組織構成
• アプリケーション ポートフォリオ

ヒント

このトピックについては、Azure ランディング ゾーン - Azure で使用する必要があるサブスクリプションの数に関する最近の YouTube ビデオで説明しました。

注意

「Azure portal での課金アカウントとスコープ」に記載されているとおり、サブスクリプションの制限について検討する必要があります。 このガイダンスは主に、Enterprise Agreement、Microsoft 顧客契約 (Enterprise)、または Microsoft Partner Agreements (CSP) をお使いになるお客様を対象としています。

サブスクリプションに関する考慮事項

次のセクションでは、Azure のサブスクリプションの計画および作成に役立つ考慮事項について説明します。

組織とガバナンスの設計に関する考慮事項

• サブスクリプションは、Azure Policy を割り当てるための境界として機能します。

  • たとえば、ペイメント カード業界 (PCI) のワークロードなどのセキュリティ保護されたワークロードでは、通常、コンプライアンスを実現するために別のポリシーが必要になります。 管理グループを使用して PCI コンプライアンスを必要とするワークロードを照合する代わりに、、サブスクリプションで同じ分離を実現できます。少数のサブスクリプションが含まれる管理グループを多数作成する必要はありません。

    • 同じワークロード アーキタイプの多数のサブスクリプションをグループ化する必要がある場合は、管理グループの下に作成します。

• サブスクリプションはスケール ユニットとして機能します。これにより、コンポーネントのワークロードをプラットフォームのサブスクリプション制限内でスケーリングできます。 ワークロードを設計する際は、サブスクリプションのリソース制限を考慮してください。

• サブスクリプションによって、ガバナンスと分離のための管理境界が提供され、問題が明確に分離されます。

• 必要に応じて、管理 (監視)、接続、ID 用に個別のプラットフォーム サブスクリプションを作成します。

  • Azure Monitor Log Analytics ワークスペースや Azure Automation Runbook などのグローバル管理機能をサポートするために、専用の管理サブスクリプションをプラットフォーム管理グループ内に確立します。
    • 必要に応じて、Windows Server Active Directory ドメイン コントローラーをホストするために、専用の ID サブスクリプションをプラットフォーム管理グループ内に確立します。
    • Azure Virtual WAN ハブ、プライベート ドメイン ネーム システム (DNS)、ExpressRoute 回線、その他のネットワーク リソースをホストするために、専用の接続サブスクリプションをプラットフォーム管理グループ内に確立します。 専用のサブスクリプションによって、すべての基盤ネットワーク リソースが一緒に請求され、他のワークロードから分離されることが保証されます。
    • ビジネス ニーズや優先度に合わせて民主化された管理のユニットとして、サブスクリプションを使用します。

• 手動プロセスを使用して、Microsoft Entra テナントを Enterprise Agreement 加入契約サブスクリプションのみに制限します。 手動プロセスを使用することにより、ルート管理グループのスコープでの Microsoft Developer Network サブスクリプションの作成が防止されます。

  • サポートについては、Azure サポート チケットを送信してください。

• Azure 課金プラン間のサブスクリプションの移転については、「Azure サブスクリプションと予約の譲渡ハブ」を参照してください。

クォータと容量の設計上の考慮事項

Azure リージョンに含まれるリソースの数には制限がある場合があります。 そのため、多数のリソースを含む Azure の導入の場合、使用可能な容量と SKU を追跡する必要があります。

• ワークロードに必要な各サービスについて、Azure プラットフォームでの制限とクォータを考慮します。

• 選択した Azure リージョンで必要な SKU を利用できるかどうかを検討します。 たとえば、新しい機能は特定のリージョンでしか使用できない場合があります。 VM など、特定のリソースに対する特定の SKU の可用性は、リージョンによって異なる場合があります。

• サブスクリプションのクォータは容量の保証ではなく、リージョンごとに適用されることを考慮します。

  • 仮想マシンの容量予約については、「オンデマンド容量予約」を参照してください。

• 「毎回新しい Azure サブスクリプションを作成する必要がありますか、それとも Azure サブスクリプションを再利用する必要がありますか?」 - Azure ランディング ゾーンに関する FAQ のガイダンスに従って未使用または使用停止のサブスクリプションを再利用することを検討してください。

テナントの移転制限による設計上の考慮事項

すべての Azure サブスクリプションは、Azure サブスクリプションの ID プロバイダー (IdP) として機能する 1 つの Microsoft Entra テナントにリンクされています。 Microsoft Entra テナントは、ユーザー、サービス、およびデバイスを認証するために使用されます。

Azure サブスクリプションにリンクされている Microsoft Entra テナントは、必要なアクセス許可を持つユーザーによって変更できます。 このプロセスについては、次の記事で詳しく説明します。

• Microsoft Entra テナントに Azure サブスクリプションを関連付ける、または追加する
• Azure サブスクリプションを別の Microsoft Entra ディレクトリに移転する

Note

Azure クラウド ソリューション プロバイダー (CSP) サブスクリプションの場合、別の Microsoft Entra テナントへの移転はサポートされていません。

Azure ランディング ゾーンでは、ユーザーが組織のMicrosoft Entra テナントにサブスクリプションを移転できないようにするための要件を設定できます。 「Azure サブスクリプションのポリシーを管理する」のプロセスを確認してください。

除外対象ユーザーの一覧を提供して、サブスクリプション ポリシーを構成します。 除外対象ユーザーは、ポリシーで設定された制限をバイパスできます。

重要

除外対象ユーザーの一覧は Azure Policy ではありません。

• Visual Studio/MSDN Azure サブスクリプションを持つユーザーに、Microsoft Entra テナントとの間でのサブスクリプションの移転を許可する必要があるかどうかを検討します。

• テナントの移転設定は、Microsoft Entra の全体管理者ロールが割り当てられているユーザーのみが構成できます。 これらのユーザーには、ポリシーを変更するために昇格したアクセス権が必要です。

  • 個々のユーザー アカウントは、Microsoft Entra グループではなく、除外対象ユーザーとしてのみ指定できます。

• Azure へのアクセス権を持つすべてのユーザーは、Microsoft Entra テナント用に定義されたポリシーを表示できます。

  • ユーザーは除外対象ユーザーの一覧を表示できません。

  • ユーザーは、Microsoft Entra テナント内のグローバル管理者を表示できます。

• Microsoft Entra テナントに移転された Azure サブスクリプションは、そのテナントの既定の管理グループに配置されます。

• 組織が承認した場合、アプリケーション チームは、Microsoft Entra テナントとの間で Azure サブスクリプションを移転することを許可するプロセスを定義できます。

コスト管理の設計の確立に関する考慮事項

コストの透明性は、すべての大規模なエンタープライズ組織が直面する重要な管理上の課題です。 この記事のこのセクションでは、大規模な Azure 環境全体でコストの透明性を実現する主な側面について説明します。

• 高密度を実現するために、Azure App Service Environment や Azure Kubernetes Service などのチャージバック モデルの共有が必要になる場合があります。 共有されたサービスとしてのプラットフォーム (PaaS) リソースは、チャージバック モデルによる影響を受ける可能性があります。

• コストを最適化するには、非運用ワークロードのシャットダウン スケジュールを使用します。

• Azure Advisor を使用して、コストを最適化するための推奨事項を確認します。

• 組織全体のコスト分布を改善するために、チャージ バック モデルを確立します。

• 組織の環境へのデプロイが許可されていないリソースのデプロイを防止するポリシーを実装します。

• コストとワークロードに適したリソースのサイズを確認する定期的なスケジュールと頻度を確立します。

サブスクリプションに関する推奨事項

次のセクションでは、Azure のサブスクリプションの計画および作成に役立つ推奨事項について説明します。

組織とガバナンスに関する推奨事項

• ビジネス ニーズや優先度に合わせて調整された管理のユニットとして、サブスクリプションを扱います。

• サブスクリプションの所有者に各自のロールと責任を認識させます。

  • Microsoft Entra Privileged Identity Management のアクセス レビューを四半期ごとまたは年 1 回行い、ユーザーが組織内を移動することで特権が大幅に増えていないことを確認します。
  • 予算の支出とリソースを完全に所有します。
  • ポリシーのコンプライアンスを保証し、必要に応じて修復します。

• 新しいサブスクリプションの要件を特定するときは、次の原則を参照してください。

  • スケールの制限: サブスクリプションは、コンポーネントのワークロードがプラットフォームのサブスクリプション制限内でスケーリングされるときのスケール ユニットとして機能します。 ハイパフォーマンス コンピューティング、IoT、SAP などの大規模で特殊なワークロードでは、これらの制限に達するのを回避するための個別のサブスクリプションを使用する必要があります。
  • 管理の境界: サブスクリプションでは、ガバナンスと分離のための管理境界が提供され、問題を明確に分離できます。 開発、テスト、運用などのさまざまな環境は、多くの場合、管理の観点から除去されます。
  • ポリシー境界: サブスクリプションは、Azure Policy の割り当ての境界として機能します。 たとえば、PCI などのセキュリティ保護されたワークロードでは、通常、コンプライアンスを実現するために別のポリシーが必要になります。 別のサブスクリプションを使用する場合、他のオーバーヘッドは考慮されません。 開発環境には、運用環境よりも緩やかなポリシー要件があります。
  • ターゲット ネットワーク トポロジ: 仮想ネットワークは、サブスクリプション間で共有することはできませんが、仮想ネットワーク ピアリングや Azure ExpressRoute などのさまざまなテクノロジを使用して接続することができます。 新しいサブスクリプションが必要かどうかを判断するときには、相互通信が必要なワークロードを検討してください。

• 管理グループの構造およびポリシー要件に合わせて、管理グループにサブスクリプションをグループ化します。 サブスクリプションをグループ化することで、ポリシーと Azure ロール割り当てのセットが同じサブスクリプションはすべて、1 つの管理グループから取得されるようになります。

• Azure Monitor Log Analytics ワークスペースや Azure Automation Runbook などのグローバル管理機能をサポートするために、専用の管理サブスクリプションを Platform 管理グループ内に確立します。

• 必要に応じて、Platform 管理グループで専用の ID サブスクリプションを設定して、Windows Server Active Directory ドメイン コントローラーをホストします。

• Platform 管理グループで専用の接続サブスクリプションを設定し、Azure Virtual WAN ハブ、プライベート ドメイン ネーム システム (DNS)、ExpressRoute 回線、その他のネットワーク リソースをホストします。 専用のサブスクリプションによって、すべての基盤ネットワーク リソースが一緒に請求され、他のワークロードから分離されることが保証されます。

• 厳格なサブスクリプション モデルは避けてください。 代わりに、一連の柔軟な条件を使用して、組織全体でサブスクリプションをグループ化します。 この柔軟性により、組織の構造とワークロードの構成が変化したときに、既存のサブスクリプションの固定したセットを使用するのではなく、新しいサブスクリプション グループを作成できることが保証されます。 1 つのサイズがすべてのサブスクリプションに適合することはありません。ある部署に対して機能するものが、別の部署に対しては機能しない場合があります。 アプリケーションによっては、同じランディング ゾーンのサブスクリプション内で共存する場合もあれば、独自のサブスクリプションを必要とする場合もあります。

  • 詳しくは、Azure ランディング ゾーン アーキテクチャで "開発/テスト/運用" ワークロード ランディング ゾーンを処理する方法に関するページを参照してください。

クォータと容量に関する推奨事項

• サブスクリプションをスケール ユニットとして使用し、必要に応じてリソースとサブスクリプションをスケールアウトします。 これにより、スケールアウトに必要なリソースをワークロードで使用できるようになり、Azure プラットフォームでのサブスクリプションの制限に達することがなくなります。

• 一部のリージョンの容量を管理するために、容量予約を使用します。 これにより、特定のリージョンで大量のリソースが必要になったときに、ワークロードに必要な容量を確保できます。

• 使用済みの容量レベルを監視するためのカスタム ビューを備えたダッシュボードを設定し、容量が重大レベル (CPU 使用率が 90%) に近づいた場合のアラートを設定します。

• サブスクリプションのプロビジョニングで、サブスクリプションで使用可能な合計 VM コア数などに対するクォータ増量のサポート リクエストを送ります。 ワークロードが既定の制限を超える前に、クォータ制限が設定されるようにします。

• 必要なサービスと機能が、選択したデプロイ リージョンで利用可能であることを確認します。

自動化に関する推奨事項

• 「サブスクリプションの自動販売」で説明されているように、要求ワークフローを使用してアプリケーション チームのためにサブスクリプションの作成を自動化する、サブスクリプションの自動販売プロセスを構築します。

テナントの移転制限に関する推奨事項

• 次の設定を構成して、ユーザーが Microsoft Entra テナントとの間で Azure サブスクリプションを移転できないようにします。

  • Microsoft Entra ディレクトリから移転するサブスクリプションを Permit no one に設定します。

  • Microsoft Entra ディレクトリに移転するサブスクリプションを Permit no one に設定します。

• 除外対象ユーザーの制限付き一覧を構成します。

  • Azure PlatformOps (プラットフォーム運用) チームのメンバーを含めます。
  • 除外対象ユーザーの一覧に緊急用アカウントを含めます。

次の手順

ポリシー主導のガードレールの採用