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

[アーティクル]
12/15/2023

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

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

Azure ランディングゾーンアクセラレータとは何ですか?

Azure ランディングゾーンアクセラレータは、Azure portal ベースのデプロイエクスペリエンスです。これにより、Azure ランディングゾーンの概念アーキテクチャに基づいた厳密な実装がデプロイされます。

Azure ランディングゾーンにお勧めのアクセラレータと実装はどれですか?

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

お勧めのプラットフォームとアプリケーションのランディングゾーンについて詳しくは、「Azure ランディングゾーンをデプロイする」のガイダンスをご覧ください。

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

ヒント

アクセラレータと実装一覧への追加を要求するには、ALZ リポジトリで GitHub issue を登録します。

Azure ランディングゾーンの概念アーキテクチャとは何ですか?

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

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

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

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

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

ポリシー主導のガバナンスとは、Azure Policy を使用して、Azure テナント全体で共通の繰り返される運用タスクに必要な時間を短縮することを意味します。 Append、Deny、DeployIfNotExists、Modify などの多くの Azure Policy の効果を使用して、(ポリシー定義で定義されている) 非準拠リソースの作成または更新を制限するか、リソースをデプロイするか、リソースの作成または更新要求の設定を変更して準拠させることにより、非準拠を防止します。 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 ランディングゾーンでのアプリケーション開発環境の管理」を参照してください。

Azure ランディングゾーンアクセラレータのデプロイ中に Azureリージョンを指定するように求められるのはなぜですか? また、それらは何に使用されるのですか?

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

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

[Network topology and connectivity] (ネットワークトポロジと接続) タブでネットワークトポロジをデプロイする場合は、ネットワークリソースのデプロイ先の Azure リージョンを選ぶ必要があります。このリージョンは、[デプロイの場所] タブで選択されたリージョンと異なっていてもかまいません。

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

Azure ランディングゾーンアーキテクチャを使用する場合、より多くの Azure リージョンを有効にするにはどうすればよいですか。

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

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

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

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

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

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

ヒント

サブスクリプションの民主化の設計原則に関する YouTube ビデオ「Azure ランディングゾーン - Azure でサブスクリプションはいくつ使用する必要があるか?」をご覧ください。

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

Enterprise Agreement (EA) を結んでいて、1 つの EA アカウント所有者アカウント (課金アカウント) に 5,000 を超えるサブスクリプションを作成する予定である (削除されたサブスクリプションを含む)。
Microsoft 顧客契約 (MCA) または Microsoft Partner Agreement (MPA) を結んでいて、5,000 を超えるアクティブなサブスクリプションを持つ予定である
従量課金制のお客様である
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 の委任をすべて削除します。
サブスクリプションから非表示のリソースをすべて削除します。

ヒント

サブスクリプションスコープを対象にして Get-AzResource または az resource list -o table を使用すると、再割り当て前に削除する非表示または残りのリソースを見つけるのに役立ちます。

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

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

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

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

Note

Microsoft Cloud for Sovereignty は、主権のニーズを持つ政府機関向けです。ソブリンランディングゾーンアーキテクチャの採用の検討は、Microsoft Cloud for Sovereignty 機能が必要かどうかを慎重に検討した後にのみ行う必要があります。

ソブリンランディングゾーンの詳細については、「Azure ランディングゾーンの主権に関する考慮事項」を参照してください。

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

Azure ランディング ゾーン アクセラレータとは何ですか?

Azure ランディング ゾーンにお勧めのアクセラレータと実装はどれですか?

Azure ランディング ゾーンの概念アーキテクチャとは何ですか?

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