alz-accelerator

Azure Landing Zones Accelerator スキル

Azure Verified Modules（AVM）を使用する ALZ Accelerator で Azure Landing Zones をデプロイします。このスキルでは、ALZ コアチームが推奨するワークフロー、意思決定フレームワーク、ベストプラクティスを紹介します。

主な概念

AVM（Azure Verified Modules）： ベストプラクティスに従って Azure リソースをデプロイするための、Infrastructure as Code の標準です。AVM には、リソースモジュール（単一のリソース）とパターンモジュール（リソースモジュールで構成される複雑なアーキテクチャパターン）があります。AVM は、Azure Landing Zones のインフラストラクチャをデプロイする唯一の推奨方法です。

ALZ Accelerator： CI/CD パイプライン、バージョン管理、インフラストラクチャ構成を含む Azure Landing Zone のデプロイ全体をブートストラップするツールです。内部では AVM モジュールを使用します。

Deployment Stacks（Bicep）： Bicep アクセラレーターでリソースのライフサイクル管理に使用され、ポリシー割り当てやリソース削除を手動で管理する煩雑さを解消します。

意思決定フレームワーク：Bicep と Terraform の比較

デプロイを進める前に、ユーザーがこの選択をできるように案内してください。

Terraform を選択する場合

• チームに Terraform の専門知識がある
• マルチクラウド戦略（AWS、GCP、Azure）を採用している — IaC 言語を 2 つ学ぶ必要がありません
• Terraform ALZ モジュールのほうが成熟している（2025 年初頭ごろにリリース）うえ、tfvars による完全な構成が可能
• 状態ベースのドリフト検出が必要

Bicep を選択する場合

• Azure のみを使用する組織で、マルチクラウドの予定がない
• チームが ARM テンプレートまたは Azure ネイティブのツールに慣れている
• 管理する状態ファイルが不要（メリットでもデメリットでもあります。運用は簡素になりますが、ドリフトの可視性は低下します）
• Microsoft の ARM／Bicep 製品グループは、Azure のみを使用する組織に Bicep を推奨している
• Bicep ALZ は 2026 年 2 月ごろにリリースされ、AVM の完全サポート、deployment stacks、カスタマイズ可能なモジュールを備えている

中立的な立場

• どちらも AVM モジュールを使用しており、基盤となるリソース定義は同じです
• どちらもアクセラレーターでサポートされ、ブートストラップ時の UX は同じです
• 2026 年には両者の差が急速に縮まっています
• デフォルトの推奨事項： チームが現在持つスキルに合わせて選択してください

アクセラレーターのデプロイワークフロー

前提条件

1. ALZ PowerShell モジュールをインストールします。

   Install-Module -Name ALZ
   

2. 以下を用意します。

   • Azure CLI または認証済みの PowerShell
   • GitHub PAT または Azure DevOps PAT（VCS の選択に応じて）
   • 少なくとも 4 つのプラットフォームサブスクリプション：Management、Connectivity、Identity、Security
   • 状態ストレージと ID 用のブートストラップサブスクリプション

ステップ 1：アクセラレーターを起動する

Deploy-Accelerator

アクセラレーターは、ガイド付きプロンプトを使用して対話形式で実行されます（最新リリース時点では、パラメーターは不要です）。

ステップ 2：ソフトウェアの確認

アクセラレーターは、必要なソフトウェアがインストールされているか確認します。先に進む前に、不足している依存関係を解消してください。

ステップ 3：キャッシュの保存場所を選択する

セットアップ中に一時ファイルを保存する場所を選択します。通常はデフォルトのままで問題ありません。

ステップ 4：IaC 言語を選択する

以下から選択します。

• Terraform — 構成がより成熟しており、すべて tfvars で設定できます
• Bicep — Azure ネイティブで、状態ファイルが不要です。ライフサイクル管理には deployment stacks を使用します

ステップ 5：バージョン管理と CI/CD プラットフォームを選択する

以下から選択します。

• GitHub（デフォルト、推奨）
• Azure DevOps
• ローカルファイルシステム（カスタムのブートストラップ用）

ステップ 6：接続シナリオを選択する

ネットワークトポロジを選択します。

• Hub and Spoke — VNet ピアリングを使用する従来のハブアンドスポーク構成（最も一般的）
• Virtual WAN — Azure Virtual WAN のマネージドハブ
• 上記のマルチリージョン構成

ステップ 7：対話型の構成

アクセラレーターが Azure に問い合わせて既存のリソースを取得し、選択肢を提示します。

1. ブートストラップリージョン — 状態ストレージと ID をデプロイする場所
2. ルート管理グループ — ALZ 階層の親 MG
3. プラットフォームのサブスクリプション：
   • 管理サブスクリプション（Log Analytics、監視）
   • ID サブスクリプション（Active Directory、DNS）
   • 接続サブスクリプション（ハブ VNet、Firewall、VPN/ER ゲートウェイ）
   • セキュリティサブスクリプション（Sentinel、Defender）
4. ブートストラップサブスクリプション — Terraform の状態ストレージとマネージド ID 用

ステップ 8：命名規則

既定値を使用するか、ブートストラップリソースのリソース命名パターンをカスタマイズします。

ステップ 9：ランナーの構成

次のいずれかを選択します。

• セルフホストランナー — プライベートネットワークに推奨
• Microsoft ホステッドランナー — より簡単ですが、パブリックエンドポイントが必要です

セルフホストを選択した場合は、プライベートネットワークを有効にするかどうかを選択します（ストレージアカウントをパブリックにアクセスできないようにします）。

ステップ 10：認証

次の情報を入力します。

• 個人用アクセストークン — GitHub PAT または Azure DevOps PAT（環境変数として保存され、構成ファイルには保存されません）
• GitHub/ADO 組織名
• 適用承認者 — plan-to-apply ステージを承認するユーザー名

ステップ 11：確認して IDE で開く

アクセラレーターによって構成ファイルが生成され、VS Code で開かれます。次の項目を確認して更新します。

1. プラットフォームランディングゾーンの構成：
   • プライマリおよびセカンダリのデプロイリージョン（例：UK South、UK West）
   • Defender のメールセキュリティ連絡先
2. 機密値はプレーンテキストファイルではなく、現在のターミナルセッションの環境変数として保存されます。

ステップ 12：ブートストラップのデプロイ

構成が完了していることを確認します。アクセラレーターによって、次の項目がブートストラップされます。

• 状態ストレージ（Terraform）またはデプロイスタック（Bicep）
• CI/CD 用のマネージド ID
• パイプラインを含む GitHub リポジトリ/Azure DevOps プロジェクト
• ブランチポリシーと承認

デプロイ後

アクセラレーターの完了後：

1. CI/CD パイプラインが選択した VCS に作成されます
2. Plan/What-If ステージが PR で自動実行されます
3. Apply/Deploy ステージには、構成された承認者による承認が必要です
4. 以降の変更は構成ファイルを通じて行い、パイプライン経由でプッシュします

AVM モジュールアーキテクチャ

ALZ のデプロイでは、次の主要な AVM パターンモジュールを使用します。

モジュール	用途
管理グループ	階層：テナントルート → プラットフォーム（Mgmt、Conn、Identity）→ ランディングゾーン（Corp、Online）
管理	Log Analytics ワークスペース、Automation Account、監視
接続（ハブスポーク）	ハブ VNet、Azure Firewall、VPN/ER ゲートウェイ、DNS
接続（vWAN）	Virtual WAN、Virtual Hubs、ルーティング
ID	DNS ゾーン、ドメインコントローラーのネットワーク
ポリシー	Azure Policy の割り当て、カスタムポリシー定義

これらのモジュールは単独で使用する（自分で組み合わせる）ことも、アクセラレーター経由で使用する（推奨方法）こともできます。

ルール

1. 常に AVM モジュールを使用する — AVM モジュールがある場合、azurerm/azapi のリソースを直接使って ALZ リソースをデプロイしないでください。
2. アクセラレーターを使用する — 特別な理由がない限り、モジュールを手動で組み合わせないでください。アクセラレーターがブートストラップ、CI/CD、構成を処理します。
3. チームのスキルに合わせる — Bicep を使うチームに Terraform を押し付けたり、その逆をしたりしないでください。
4. 本番環境ではプライベートネットワークを使用する — 本番環境へのデプロイには、プライベートネットワークを使用するセルフホスト型ランナーを使用してください。
5. PAT を設定ファイルに保存しない — アクセラレーターは機密値に環境変数を使用します。このパターンを維持してください。
6. プラットフォームサブスクリプションは最低 4 つ必要 — 管理、接続、ID、セキュリティを統合しないでください。
7. 適用前に計画する — デプロイを承認する前に、必ず plan／what-if の出力を確認してください。
8. モジュールの編集ではなく設定でカスタマイズする — Terraform では、すべてのカスタマイズを tfvars で行います。Bicep ではモジュールを直接編集できますが、可能な場合は設定を使う方法を優先してください。

トラブルシューティング

問題	解決方法
デプロイスタックのバグ（Bicep）	既知の制限事項です。what-if は完全にはサポートされていません。ALZ GitHub のイシューを確認してください
ポリシー割り当ての競合	カスタムポリシーとデフォルトポリシーを分離した構成を使用してください（Bicep 2026 リリース）
状態ファイルの管理（Terraform）	状態は自動的にブートストラップされます。バックエンド構成を手動で変更しないでください
古い ALZ バージョンからのアップグレードの難しさ	新しい Bicep リリースでは、カスタマイズがアップストリームモジュールから分離されています

リソース

• 質問フォーム：aka.ms/alz/quests
• ALZ ドキュメント：aka.ms/alz
• AVM レジストリ：aka.ms/avm
• ALZ アクセラレーターのドキュメント：aka.ms/alz/accelerator

---

注意事項

• Bicep の what-if はベストエフォートです — ネストされたデプロイでは、リソースが存在していても「Create」と表示されることがあります。what-if だけを信頼せず、ARM のデプロイ出力を信頼してください。
• AVM モジュールのバージョンはデプロイ時に固定されます — 古い version: パラメーターを指定すると、ローカルで修正したバグが残る数か月前のリリースが取得されます。
• 管理グループ ID はグローバルです — 名前が競合すると、他のデプロイの途中であるデプロイの中盤に 409 が返されます。
• デフォルトのポリシー割り当てには監査効果が含まれます。非本番環境ではアクティビティログが大量に発生するため、明示的に無効にしないと、ノイズに重要なシグナルが埋もれます。
• サブスクリプションのクォータは検証時ではなく作成時に確認されます — what-if は成功しても、5 分後に作成がクォータエラーで失敗することがあります。
• Bicep のテンプレートスペックと生の .bicep の違い：テンプレートスペックは ARM でバージョン管理されますが、生の .bicep のデプロイでは、そのバージョン管理が完全にスキップされます。