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

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

• 環境タイプ
• 所有権とガバナンス モデル
• 組織構造
• アプリケーション ポートフォリオ
• 地域

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

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

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

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

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

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

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

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

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

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

  • 必要に応じて、Windows Server Active Directory ドメイン コントローラーをホストするために、専用の ID サブスクリプションをプラットフォーム管理グループ内に確立します。

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

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

• 手動プロセスを使用して、Microsoft Entra テナントを Enterprise Agreement 加入契約サブスクリプションのみに制限します。 手動プロセスを使用する場合、ルート管理グループのスコープでの Microsoft Developer Network (MSDN) サブスクリプションを作成できません。

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

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

複数リージョンに関する考慮事項

• スケーリングまたは geo ディザスター リカバリーの単一ワークロード レベル、またはグローバル レベル (異なるリージョンの異なるワークロード) でマルチリージョン アプローチを採用できます。

• 単一サブスクリプションには、要件とアーキテクチャに応じて、異なるリージョンのリソースを含めることができます。

• geo ディザスター リカバリー コンテキストでは、プライマリ リージョンとセカンダリ リージョンのリソースが論理的に同じワークロードの一部であるため、同じサブスクリプションを使用してそれらのリソースを含めることができます。

• 同じワークロードに対して異なる環境を異なるリージョンにデプロイして、コストとリソースの可用性を最適化できます。

• 複数のリージョンのリソースを含むサブスクリプションでは、リソース グループを使用して、リージョン別にリソースを整理して含めることができます。

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

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

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

• 選択した Azure リージョンで必要な SKU を利用できるかどうかを検討します。 たとえば、新しい機能は特定のリージョンでしか使用できない場合があります。 仮想マシン (VM) のような特定のリソースに対する特定の SKU の可用性は、あるリージョンから別のリージョンに変わることができます。

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

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

• 未使用または使用停止のサブスクリプションを再利用することを検討してください。 詳細については、「Azure サブスクリプションの作成または再利用」を参照してください。

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

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

任意のユーザーが必要なアクセス許可を持つ場合、Azure サブスクリプションにリンクされている Microsoft Entra テナントを変更できます。 詳細については、以下を参照してください:

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

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

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

• 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 (AKS) などの配賦モデルの共有が必要になる場合があります。 配賦モデルは、共有されたサービスとしてのプラットフォーム (PaaS) リソースに影響を与える可能性があります。

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

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

• 組織全体のコスト分布を改善するために、配賦モデルを確立します。

• 未承認のリソースを組織の環境に展開できないようにポリシーを実装します。

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

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

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

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

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

• サブスクリプションの所有者に各自のロールと責任について知らせます。

  • Microsoft Entra Privileged Identity Management (PIM) のアクセス レビューを四半期ごとまたは年 1 回行い、ユーザーが組織内を移動する際に権限が大幅に増えていないことを確認します。

  • 予算の支出とリソースを完全に所有します。

  • ポリシーのコンプライアンスを保証し、必要に応じて修復します。

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

  • スケールの制限:サブスクリプションはコンポーネントのワークロードのスケール ユニットとして機能し、プラットフォーム サブスクリプションの制限内でスケーリングします。 ハイパフォーマンス コンピューティング、IoT、SAP などの大規模で特殊なワークロードでは、これらの制限に達するのを回避するための個別のサブスクリプションを使用する必要があります。

  • 管理境界: サブスクリプションにより、ガバナンスと分離のための管理境界が提供されるので、問題を明確に分離することができます。 開発環境、テスト環境、運用環境などのさまざまな環境は、多くの場合、管理の観点から除去されます。

  • ポリシー境界: サブスクリプションは、Azure Policy の割り当ての境界として機能します。 たとえば、PCI ワークロードなどのセキュリティ保護されたワークロードでは、通常、コンプライアンスを実現するために別のポリシーが必要になります。 別のサブスクリプションを使用する場合、他のオーバーヘッドは考慮されません。 開発環境には、運用環境よりも緩やかなポリシー要件があります。

  • ターゲット ネットワーク トポロジ: 仮想ネットワークは、サブスクリプション間で共有することはできませんが、仮想ネットワーク ピアリングや ExpressRoute などのさまざまなテクノロジを使用して接続することができます。 新しいサブスクリプションが必要かどうかを判断するときには、相互通信が必要なワークロードを検討してください。

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

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

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

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

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

  詳細については、「開発/テスト/運用ワークロード のランディング ゾーンの処理」を参照してください。

複数リージョンに関する推奨事項

• データ主権やクォータ制限を超えてスケーリングする場合など、リージョン固有のガバナンスと管理の要件がある場合にのみ、リージョンごとに追加のサブスクリプションを作成します。

• 複数のリージョンにまたがる geo ディザスター リカバリー環境でスケーリングが問題でない場合は、プライマリ リージョンリソースとセカンダリ リージョン リソースに同じサブスクリプションを使用します。 一部の Azure サービスは、採用する事業継続とディザスター リカバリー (BCDR) の戦略とツールに応じて、同じサブスクリプションを使用する必要があります。 デプロイが個別に管理されている、またはライフサイクルが異なるアクティブ・アクティブなシナリオでは、異なるサブスクリプションを使用することをお勧めします。

• リソース グループを作成するリージョンと、含まれているリソースのリージョンは、回復性と信頼性に影響を与えないように一致している必要があります。

• 単一のリソース グループには、別のリージョンに存在するリソースが含まれていてはいけません。 この方法では、リソース管理と可用性に関する問題が発生する可能性があります。

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

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

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

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

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

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

自動化に関する推奨事項

• 要求ワークフローを使用してアプリケーション チームのためにサブスクリプションの作成を自動化する、サブスクリプション サービス プロセスを構築します。 詳細については、「サブスクリプション サービス」を参照してください。

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

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

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

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

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

  • Azure プラットフォーム運用 チームのメンバーを含めます。

  • 除外対象ユーザーの一覧に緊急用アカウントを含めます。

次のステップ

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