Azure ランディング ゾーンに関してよく寄せられる質問 (FAQ)

この記事では、Azure ランディング ゾーンアーキテクチャに関してよく寄せられる質問に回答します。

Azure ランディング ゾーン アーキテクチャの実装に関する FAQ については、エンタープライズ規模の実装に関する FAQ を参照してください。

Azure ランディング ゾーン ポータル アクセラレータとは

Azure ランディング ゾーン ポータル アクセラレータは、Azure portal ベースのデプロイ エクスペリエンスです。 これは、Azure ランディング ゾーンの参照アーキテクチャに基づいて、オピニオンされた実装をデプロイします。

Azure ランディング ゾーンに推奨されるアクセラレータと実装はどれですか?

Microsoft は、Azure ランディング ゾーンの 設計原則 と 設計領域 のガイダンスに従って、プラットフォームとアプリケーション アクセラレータと実装を積極的に開発および維持しています。

推奨されるプラットフォームとアプリケーションのランディング ゾーンの詳細については、「 Azure ランディング ゾーンのデプロイ 」ガイダンスを参照してください。

ニーズに合わせて Azure ランディング ゾーンのデプロイを調整する方法については、「要件を満たすように Azure ランディング ゾーン アーキテクチャを調整する」を参照してください。

Azure ランディング ゾーンの参照アーキテクチャとは

Azure ランディング ゾーン参照アーキテクチャは、スケールと成熟度の決定を表します。 これは、デジタル資産の一部として Azure を採用したお客様から学んだ教訓とフィードバックに基づいています。 この概念アーキテクチャは、組織がランディング ゾーンを設計および実装するための方向を設定するのに役立ちます。

ランディング ゾーンは、Azure ランディング ゾーン アーキテクチャのコンテキストで Azure で何にマップされますか?

Azure ランディング ゾーンの観点からは、ランディング ゾーンは個々の Azure サブスクリプションです。

ポリシー主導のガバナンスとは何を意味し、どのように機能しますか?

ポリシー駆動型のガバナンス は、エンタープライズ規模のアーキテクチャの主要な設計原則の 1 つです。

ポリシー駆動型のガバナンスとは、Azure Policy を使用して、Azure テナント全体で一般的で繰り返される運用タスクに必要な時間を短縮することを意味します。 (ポリシー定義で定義されている) 非準拠リソースの作成または更新を制限するか、リソースをデプロイするか、リソース作成または更新要求の設定を変更して準拠するようにすることで、非準拠を防ぐために、、Append、Deny、DeployIfNotExistsなど、Modifyを使用します。 Audit、Disabled、AuditIfNotExistsなどの一部の効果では、防止やアクションは行われません。非準拠に関する監査と報告のみを行います。

ポリシー主導のガバナンスの例をいくつか次に示します。

• Deny の効果: サブネットがネットワーク セキュリティ グループと関連付けられずに作成または更新されることを防ぎます。

• DeployIfNotExists 効果: 新しいサブスクリプション (ランディング ゾーン) が作成され、Azure ランディング ゾーンのデプロイ内の管理グループに配置されます。 Azure Policy を使用すると、サブスクリプションで Microsoft Defender for Cloud (旧称 Azure Security Center) が有効になります。 また、アクティビティ ログの診断設定を構成して、管理サブスクリプションの Log Analytics ワークスペースにログを送信します。

  新しいサブスクリプションの作成時にコードまたは手動のアクティビティを繰り返す代わりに、 DeployIfNotExists ポリシー定義によって自動的に展開および構成されます。

DeployIfNotExists (DINE) ポリシーを利用できない場合、またはまだ準備ができていない場合はどうしますか?

さまざまなフェーズとオプションについて説明する専用のページがあり、DINE ポリシーを "無効にする" か、3 段階のアプローチを使用して環境内で時間をかけて導入する必要があります。

ポリシー駆動型ガードレールの導入に関するガイダンスを参照してください

Azure Policy を使用してワークロードをデプロイする必要がありますか?

要するに、 いいえ。 Azure Policy を使用して、ワークロードとランディング ゾーンを制御、管理、および維持します。 ワークロード全体とその他のツールをデプロイするようには設計されていません。 Azure portal またはコードとしてのインフラストラクチャオファリング (ARM テンプレート、Bicep、Terraform) を使用して、ワークロードをデプロイおよび管理し、必要な自律性を得ます。

Terraform (aztfmod) のクラウド導入フレームワークランディング ゾーンとは

クラウド導入フレームワークランディング ゾーン オープン ソース プロジェクト (OSS) ( aztfmod とも呼ばれます) は、Azure ランディング ゾーン コア チームと Azure GitHub 組織の外部で所有および管理されているコミュニティ主導のプロジェクトです。 組織がこの OSS プロジェクトを使用することを選択した場合は、GitHub を通じたコミュニティの取り組みによって行われるので、利用可能なサポートを考慮する必要があります。

ランディング ゾーンに既にリソースがあり、そのスコープに含まれる Azure Policy 定義を後で割り当てる場合はどうでしょうか。

次のドキュメント セクションを確認します。

• 既存の Azure 環境を Azure ランディング ゾーン参照アーキテクチャに移行する - "ポリシー" セクション
• クイック スタート: ポリシー割り当てを作成して準拠していないリソースを識別する - 「準拠していないリソースを識別する」セクション

専用または個別の AI ランディング ゾーンが必要ですか?

いいえ。別の AI ランディング ゾーンは必要ありません。 代わりに、既存の Azure ランディング ゾーン アーキテクチャを使用して AI ワークロードをデプロイできます。 Azure ランディング ゾーンでの AI のガイダンスと説明を参照してください。

Azure ランディング ゾーン アーキテクチャで "開発/テスト/運用" ワークロード ランディング ゾーンを処理する方法

詳細については、「Azure ランディング ゾーンでのアプリケーション開発環境の管理」を参照してください。

Azure ランディング ゾーン参照アーキテクチャのデプロイ時に Azure リージョンを指定するように求められるのはなぜですか。

Azure ランディング ゾーン参照アーキテクチャ ポータル ベースのエクスペリエンスを使用して Azure ランディング ゾーン アーキテクチャをデプロイする場合は、デプロイ先の Azure リージョンを選択します。 最初のタブ [ デプロイの場所] によって、デプロイ データの格納場所が決まります。 詳細については、「 ARM テンプレートを使用したテナントのデプロイ」を参照してください。 ランディング ゾーンの一部はグローバルにデプロイされますが、デプロイ メタデータはリージョン メタデータ ストアで追跡されます。 デプロイに関するメタデータは、[デプロイの 場所 ] タブで選択したリージョンに格納されます。

[ デプロイの場所 ] タブのリージョン セレクターは、必要に応じて Log Analytics ワークスペースなど、リージョン固有のリソースを格納する必要がある Azure リージョンを選択するためにも使用されます。

[ネットワーク トポロジ と接続 ] タブでネットワーク トポロジをデプロイする場合は、ネットワーク リソースをデプロイする Azure リージョンを選択する必要があります。 このリージョンは、[ デプロイの場所 ] タブで選択したリージョンとは異なる場合があります。

ランディング ゾーン リソースが使用するリージョンの詳細については、「 ランディング ゾーンリージョン」を参照してください。

Azure ランディング ゾーン アーキテクチャを使用する場合、より多くの Azure リージョンを有効にする方法

ランディング ゾーンに新しいリージョンを追加する方法、またはランディング ゾーン リソースを別のリージョンに移動する方法については、「 ランディング ゾーンリージョン」を参照してください。

毎回新しい Azure サブスクリプションを作成する必要がありますか、それとも Azure サブスクリプションを再利用する必要がありますか?

サブスクリプションの再利用とは

サブスクリプションの再利用は、既存のサブスクリプションを新しい所有者に再発行するプロセスです。 サブスクリプションを既知のクリーンな状態にリセットし、新しい所有者に再割り当てするプロセスが必要です。

サブスクリプションの再利用を検討する必要がある理由

一般に、お客様は サブスクリプション民主化設計原則を採用することをお勧めします。 ただし、サブスクリプションの再利用が不可能または推奨されない特定の状況があります。

次のいずれかの状況を満たす場合は、サブスクリプションの再利用を検討する必要があります。

• Enterprise Agreement (EA) があり、削除されたサブスクリプションを含む、1 つの EA アカウント所有者アカウント (課金アカウント) に 5,000 を超えるサブスクリプションを作成する予定です。
• Microsoft 顧客契約 (MCA) または Microsoft Partner Agreement MPA があり、5,000 を超えるアクティブなサブスクリプションを持つ予定です。 サブスクリプションの制限の詳細については、 Azure portal の課金アカウントとスコープに関するページを参照してください。
• 従量課金制のお客様である。
• Microsoft Azure スポンサー プランを使用します。
• 以下をよく作成する。
  1. 一時的な実験室またはサンドボックス環境
  2. 顧客デモ/試用版アクセス用の独立系ソフトウェア ベンダー (ISV) を含む、概念実証 (POC) または実用最小限の製品 (MVP) のデモ環境
  3. MSP/トレーナーの学習環境などのトレーニング環境

サブスクリプションを再利用する方法

上記のシナリオまたは考慮事項のいずれかに一致する場合は、既存の使用停止または未使用のサブスクリプションを再利用し、新しい所有者と目的に再割り当てすることを検討する必要があります。

古いサブスクリプションをクリーンアップする

最初に、再利用のために古いサブスクリプションをクリーンアップする必要があります。 再利用する準備が整う前に、サブスクリプションに対して次のアクションを実行する必要があります。

• リソース グループと包含リソースを削除します。
• サブスクリプション スコープで、ロールの割り当てを削除します (Privileged Identity Management (PIM) ロールの割り当てを含みます)。
• サブスクリプション スコープで、カスタム ロールベースのアクセス制御 (RBAC) 定義を削除します。
• サブスクリプション スコープでポリシー定義、イニシアティブ、割り当て、および除外を削除します。
• サブスクリプション スコープでデプロイを削除します。
• サブスクリプション スコープでタグを削除します。
• サブスクリプション スコープでリソース ロックを削除します。
• サブスクリプション スコープで Microsoft Cost Management の予算を削除します。
• 組織の要件でこれらのログが有料レベルに設定されている必要がない限り、Microsoft Defender for Cloud プランを Free レベルにリセットします。 通常は、Azure Policy を使用してこれらの要件を適用します。
• サブスクリプションがアクティブな間、組織の要件でこれらのログの転送が義務付けられている場合を除き、Log Analytics ワークスペース、Event Hubs、ストレージ アカウント、またはその他のサポートされている宛先に転送するサブスクリプション アクティビティ ログ (診断設定) を削除します。
• サブスクリプション スコープで Azure Lighthouse の委任を解除します。
• サブスクリプションから非表示のリソースを削除します。

サブスクリプションを再割り当てする

サブスクリプションをクリーンアップした後で、サブスクリプションを再割り当てできます。 再割り当てプロセスの一部として実行する一般的なアクティビティを次に示します。

• サブスクリプションに新しいタグを追加し、それらの値を設定します。
• 新しい所有者のサブスクリプション スコープで、新しいロールの割り当てや、Privileged Identity Management (PIM) ロールの割り当てを追加します。 通常、これらの割り当ては、個人ではなく Microsoft Entra グループに対して行われます。
• ガバナンス要件に基づいて、サブスクリプションを目的の管理グループに配置します。
• 新しい Microsoft Cost Management 予算を作成し、しきい値が満たされたときに新しい所有者にアラートを設定します。
• Microsoft Defender for Cloud プランを目的のレベルに設定します。 この設定は、正しい管理グループに配置された後、Azure Policy を使用して適用する必要があります。
• Log Analytics ワークスペース、Event Hubs、ストレージ アカウント、またはその他のサポートされている宛先に転送するサブスクリプション アクティビティ ログ (診断設定) を構成します。 この設定は、正しい管理グループに配置された後、Azure Policy を使用して適用する必要があります。

ソブリン ランディング ゾーンとは何ですか。また、Azure ランディング ゾーン アーキテクチャとどのように関連していますか?

ソブリン ランディング ゾーンは、高度な主権制御を必要とする公共部門のお客様を対象とした Microsoft ソブリン クラウドのコンポーネントです。 Azure ランディング ゾーン参照アーキテクチャのカスタマイズされたバージョンとして、ソブリン ランディング ゾーンは、サービス所在地、カスタマー マネージド キー、Azure Private Link、コンフィデンシャル コンピューティングなどの Azure 機能を調整します。 この調整により、ソブリン ランディング ゾーンは、データとワークロードが既定で脅威からの暗号化と保護を提供するクラウド アーキテクチャを作成します。

ソブリンランディングゾーンの詳細については、「 ソブリンランディングゾーン(SLZ)」を参照してください。