この記事では、プラットフォームランディングゾーンとアプリケーションランディングゾーンの両方をデプロイするのに役立つオプションについて説明します。 プラットフォーム ランディング ゾーンでは、ワークロードで使用される一元化されたサービスが提供されます。 アプリケーションのランディング ゾーンは、ワークロード自体用にデプロイされた環境です。
重要
プラットフォームランディングゾーンとその接続されたアプリケーションランディングゾーンの定義の詳細については、「 プラットフォームランディングゾーンとアプリケーションランディングゾーン」を参照してください。
プラットフォームランディングゾーンアプローチを選択する
次のプラットフォーム デプロイ オプションは、Azure のクラウド導入フレームワークで説明されているように 、Azure ランディング ゾーン参照アーキテクチャ をデプロイして運用するためのオピニオンアプローチを提供します。 結果のアーキテクチャはカスタマイズによって異なる可能性があるため、この記事に記載されているすべてのデプロイ オプションで同じとは言えない場合があります。 プラットフォームのデプロイ オプションの違いは、さまざまなテクノロジ、アプローチ、カスタマイズの使用に基づいています。
標準の展開オプション
標準的なデプロイ オプションは、一般的なエンタープライズ Azure の使用状況に対処します。
| Azure プラットフォーム ランディング ゾーンのデプロイ オプション | 説明 | Azure パブリック クラウド | 米国政府や 21Vianet などの Azure ソブリン クラウド |
|---|---|---|---|
| Azure portal のデプロイ | Azure ランディング ゾーン参照アーキテクチャ の完全な実装と、管理グループやポリシーを含む主要なコンポーネントの構成を提供する Azure portal ベースのデプロイ。 | サポートされています | サポートされていません。 Azure portal を使用して個々のリソースをデプロイできます。 ただし、このアプローチでは、リソース間で統一されたガイド付きエクスペリエンスは提供されません。 |
| Bicep のデプロイ | Azure 検証済みモジュールを使用し、Bicep を使用してプラットフォーム ランディング ゾーンをデプロイするカスタマイズ可能な方法を提供するコードとしてのインフラストラクチャ (IaC) デプロイ。 | サポートされています | サポートされていません。 Bicep コードを開始点として使用して、Azure プラットフォーム ランディング ゾーンのベスト プラクティスに従うカスタム実装を構築できます。 コードに必要なカスタマイズの詳細については、「 Azure ソブリン クラウドデプロイ 」セクションを参照してください。 |
| Terraform のデプロイ | Azure 検証済みモジュールを使用し、Terraform を使用してプラットフォーム ランディング ゾーンをデプロイするためのカスタマイズ可能な方法を提供する IaC デプロイ。 | サポートされています | サポートされていません。 Terraform コードを出発点として、Azure プラットフォーム ランディング ゾーンのベスト プラクティスに従ったカスタム実装を構築できます。 コードに必要なカスタマイズの詳細については、「 Azure ソブリン クラウドデプロイ 」セクションを参照してください。 |
また、Azure ランディング ゾーンの実装オプションを確認して、組織に最適なデプロイ オプションを選択することもできます。
Azure 主権クラウドの展開
Azure portal、Bicep、Terraform のデプロイ オプションは、Azure パブリック、グローバル、商用のクラウド オファリングでサポートされています。 米国政府機関向け Azure Infrastructure Services や 21Vianet が運用する Azure など、他の Azure クラウドにデプロイする必要がある場合、プラットフォーム チームはデプロイ資産に手動で構成変更を加える必要があります。 これらの変更に対応するために変更できるのは、Bicep デプロイ オプションと Terraform デプロイ オプションのみです。 次のクラウド固有の制限事項と構成要件を考慮してください。
Azure Policy の定義、イニシアチブ、割り当て: すべてのクラウドですべての Azure ポリシーを使用できるわけではないため、デプロイの前にサポートされていないポリシーを削除する必要があります。
一部のリソースの API バージョン: 特定の API バージョンが一部のクラウドに存在しない可能性があるため、デプロイの前にリソース API のバージョンを調整する必要があります。
リソースの可用性: 一部のリソースは、一部のクラウドに存在しない可能性があります。 たとえば、Azure DDoS Protection プランは、中国の Azure では使用できません。 デプロイする前に、これらのリソースを削除する必要があります。
Azure ランディング ゾーン アーキテクチャは有効であり、すべての Azure クラウドでサポートされています。 ただし、そのアーキテクチャのデプロイは、すべてのクラウドで動作する自動化されたソリューションでは提供されません。 これらのクラウドの自動デプロイ サポートが必要な場合は、 この機能を要求します。
バリアントと特殊化
標準プラットフォームのデプロイ オプションは、すべての業界とサイズのほとんどの組織の要件を満たしています。 その他のシナリオについては、プラットフォーム ランディング ゾーンをすばやくデプロイするのに役立つ、次のカスタマイズされたアーキテクチャとデプロイ オプションを参照してください。
次のオプションは、 標準のデプロイ オプションではなく、使用できる特殊なプラットフォーム ランディング ゾーンの実装を提供します。
| プラットフォームランディングゾーンバリアント | 説明 |
|---|---|
| ソブリン ランディング ゾーン | ソブリン ランディング ゾーンは、主権に重点を置く厳格な規制、コンプライアンス、データ所在地の要件を持つ組織専用に設計された、Azure ランディング ゾーン参照アーキテクチャの特殊な実装です。 これには、これらのニーズを満たすのに役立つカスタマイズされた構成とポリシーが含まれますが、Azure ランディング ゾーンの主要な設計原則と設計領域に準拠しています。 |
パートナーの実装
Azure Accelerate などのパートナー プログラムは、組織のニーズを満たすプラットフォーム ランディング ゾーンの設計と実装に役立ちます。 これらの実装は、クラウド導入戦略、組織のトポロジ、目標に固有の Azure ランディング ゾーン参照アーキテクチャ と設計構成から始まります。
ポリシー管理のコードとしてのエンタープライズ ポリシー
コードとしてのエンタープライズ ポリシー (EPAC) は、組織の Azure 資産全体で Azure Policy をデプロイ、管理、運用するための別の方法です。 標準のプラットフォーム オプションの代わりに EPAC を使用して、Azure ランディング ゾーン環境でポリシーを管理できます。 統合アプローチの詳細については、「 EPAC と Azure ランディング ゾーンの統合」を参照してください。
EPAC は、より高度な開発運用 (DevOps) と IaC のお客様に最適ですが、あらゆる規模の組織が EPAC を評価した後で使用できます。 詳細については、「 EPAC を使用するユーザー」を参照してください。
注
長期的に使用する方法を決定する前に、2 つのアプローチのライフサイクルと柔軟性を比較します。 まず、 既定の実装でネイティブ ポリシー管理を評価します。 その実装がガバナンス ニーズを満たしていない場合は、EPAC を使用して、実用最小限の製品 (MVP) または概念実証を実行します。 オプションを比較し、結果を検証し、アプローチを実装する前に選択を確認します。これは、ポリシー ガバナンスの方法を確立した後で簡単に変更できないためです。
Azure ランディング ゾーンを運用する
プラットフォーム ランディング ゾーンをデプロイしたら、それを運用して維持する必要があります。 詳細については、「Azure ランディング ゾーンを最新のに保つ」を参照してください。
Azure ガバナンス ビジュアライザー
Azure ガバナンス ビジュアライザー は、データをコンテキスト化し、高度なレポートを提供することで、技術的な Azure ガバナンス実装の包括的な概要を取得するのに役立ちます。
サブスクリプション サービス
プラットフォーム ランディング ゾーンとガバナンス戦略を作成したら、ワークロード所有者のサブスクリプションを作成して運用化する方法に一貫したアプローチを確立します。 サブスクリプションの民主化 は、管理とスケールの単位としてサブスクリプションを使用する Azure ランディング ゾーンの設計原則です。 このアプローチにより、アプリケーションの移行と新しいアプリケーション開発が高速化します。
サブスクリプションの自販 は、ワークロード チームがサブスクリプションを要求し、プラットフォーム チームがそれらのサブスクリプションをデプロイおよび管理するためにプラットフォーム チームが使用するプロセスを標準化します。 これにより、アプリケーション チームは一貫した管理された方法で Azure を使用できるため、チームがすべての要件を確実に満たすことができます。
多くの場合、組織には、テナントに自販できるさまざまなスタイルのサブスクリプションがあり、一般に 製品ラインと呼ばれます。 詳細については、「 共通のサブスクリプションの販売製品ラインを確立する」を参照してください。
開始するには、 サブスクリプションの自動販売機の実装に関するガイダンスに従ってください。 次に、実装のニーズに合わせて柔軟性を提供する次の IaC モジュールを確認します。
| デプロイ オプション | 説明 |
|---|---|
| Bicep サブスクリプション サービス | サブスクリプションの自動販売機 Bicep モジュールは、個々のアプリケーション ランディング ゾーンのデプロイを調整します。 |
| Terraform サブスクリプション サービス | このアプローチでは、Terraform を使用して、個々のアプリケーション ランディング ゾーンのデプロイを調整します。 |
すべてのデプロイ オプションを使用してアプリケーション ランディング ゾーンを手動でデプロイできますが、自動化されたプロセスの一部として最も効果的です。
アプリケーションランディングゾーンのアーキテクチャ
アプリケーション ランディング ゾーンは、1 つ以上のサブスクリプション内の指定された領域です。具体的には、特定のワークロードに対してアプリケーション チームが管理するリソースの承認済み宛先として設定されます。 ワークロードでは、プラットフォーム ランディング ゾーン内のサービスを利用したり、それらの一元化されたリソースから分離された状態を維持したりできます。 アプリケーション ランディング ゾーンは、一元管理されたアプリケーション、アプリケーション チームが所有する分散ワークロード、複数のビジネス ユニットのアプリケーションをホストできる Azure Kubernetes Service (AKS) などの一元管理ホスティング プラットフォームに使用します。 異常な状況でアプリケーション ランディング ゾーン サブスクリプションが制約されない限り、通常は、ライフ サイクルや重要度の分類など、単一のワークロードまたは論理アプリケーション境界からのリソースのみが含まれます。
ワークロード チームは、プラットフォーム チームが確立する正式なプロセスを通じてワークロードの要件を伝達します。 プラットフォーム チームは通常、必要なすべてのガバナンスに登録されている空のサブスクリプションをデプロイします。 その後、ワークロード アーキテクトは、そのアプリケーション ランディング ゾーンの制約内で動作し、ファイアウォールやクロスプレミス ルーティングなどの共有プラットフォーム機能を利用するソリューションを設計します (実用的な場合)。
アーキテクトは、アプリケーションランディングゾーン専用に設計されていない参照アーキテクチャを適応させることができます。 ただし、Microsoft Learn には、アプリケーション ランディング ゾーンのコンテキストに特に対処するワークロード チーム向けのアプリケーションとデータ プラットフォームのガイダンスもあります。 組織のワークロードの種類と特性を予測できるように、プラットフォーム チームにこのガイダンスを認識させます。
| アプリケーション ランディング ゾーンのアーキテクチャ | 説明 |
|---|---|
| App Service Environment の | 参照実装を使用したマルチテナントと App Service Environment の両方のユース ケースで実証済みの推奨事項と考慮事項。 |
| Azure API Management | 参照実装の一部として内部 API Management インスタンスをデプロイする方法に関する実証済みの推奨事項と考慮事項。 このシナリオでは、Azure Application Gateway を使用してセキュリティで保護されたイングレス制御を提供し、バックエンドとして Azure Functions を使用します。 |
| ハイブリッドとマルチクラウドのシナリオに Azure Arc を | Azure Arc で有効になっているサーバー、Kubernetes、Azure SQL Managed Instance のガイダンス。 |
| Azure Container Apps | 戦略的な設計パスの概要を示し、Container Apps をデプロイするためのターゲット技術状態を定義するガイダンス。 専用のワークロード チームが、このプラットフォームを所有し、運用しています。 |
| Azureデータファクトリー | アプリケーションランディングゾーン内で medallion lakehouse をホストする方法に関するガイダンス。 |
| Microsoft Foundry チャット ワークロード | 一般的な Foundry チャット アーキテクチャ をアプリケーション ランディング ゾーン内に統合し、共有サービス、ガバナンス、およびコスト効率のために一元化されたプラットフォーム ランディング ゾーン リソースを使用する方法に関するガイダンス。 インフラストラクチャとエージェントのデプロイと管理に関するガイダンスをワークロード チームに提供します。 |
| AKS | アプリケーション ランディング ゾーン内で実行される AKS デプロイの戦略的な設計パスとターゲット技術状態を表すガイダンスと関連する IaC テンプレート。 |
| Azure Red Hat OpenShift | Azure と Red Hat の両方のリソースを含む最適な Azure Red Hat OpenShift デプロイを表す Terraform テンプレートのオープンソース コレクション。 |
| Azure Virtual Desktop | Azure Virtual Desktop デプロイを設計するときに参照する Azure Resource Manager、Bicep、Terraform テンプレート。 これらのテンプレートには、ホスト プール、ネットワーク、ストレージ、監視の作成が含まれます。 |
| Azure Virtual Machines | Virtual Machines ベースライン アーキテクチャからアプリケーション ランディング ゾーンにガイダンスを拡張するアーキテクチャ。 サブスクリプションのセットアップ、パッチのコンプライアンス、およびその他の組織のガバナンスに関する懸念事項に関するガイダンスを提供します。 |
| Azure VMware Solution | AZURE VMware Solution デプロイの設計に使用できる ARM テンプレート、Bicep テンプレート、Terraform テンプレート。 これらのデプロイには、Azure VMware Solution プライベート クラウド、ジャンプ ボックス、ネットワーク、監視が含まれます。 |
| Azure 上の Citrix | 多くの設計領域を含む Azure エンタープライズ規模のランディング ゾーンにおける Citrix Cloud のクラウド導入フレームワークの設計ガイドライン。 |
| Azure での Red Hat Enterprise Linux (RHEL) | Azure で RHEL ベースのワークロードを設計するために使用できるアーキテクチャ ガイダンスと参照実装に関する推奨事項のオープンソース コレクション。 |
| ハイ パフォーマンス コンピューティング (HPC) ワークロード | Terraform、Ansible、Packer などのツールを使用した Azure のエンド ツー エンドの HPC クラスター ソリューション。 ID の実装、ジャンプ ボックス アクセス、自動スケールなど、Azure ランディング ゾーンのベスト プラクティスに対処します。 |
| ミッションクリティカルなワークロード | ミッション クリティカルなワークロードを設計して、アプリケーション ランディング ゾーン内で実行する方法について説明します。 |
| SAP ワークロード | Azure ランディング ゾーンのベスト プラクティスに沿った SAP ワークロードのガイダンスと推奨事項を提供します。 コンピューティング、ネットワーク、ストレージ、監視、SAP システム ビルドなどのインフラストラクチャ コンポーネントを作成する方法に関する推奨事項を提供します。 |
ワークロードは、多くの場合、さまざまなテクノロジと分類で構成されます。 ワークロード内のすべてのテクノロジに関連する参照資料を確認します。 たとえば、Azure OpenAI チャットと API Management のガイダンスは、生成 AI シナリオが API ゲートウェイからメリットを得られるかどうかを確認するのに役立ちます。