Azure Blueprints

解決する課題

• 新しいサブスクリプションを払い出すたびに、リソースグループ・ポリシー・RBAC・共通リソースを手作業で揃えるのが手間で漏れも起きる
• 組織標準の構成（ランディングゾーン）を、準拠した状態で繰り返し再現したい
• テンプレート展開だけでは、展開後にだれかが構成を変えても気づけない（ドリフトを止めたい）
• 「だれが・どのバージョンの標準環境を・どこへ適用したか」を、追跡可能な形で管理したい
• ポリシー割り当てやロール割り当てまで含めて、環境のガバナンスを最初からセットで配りたい

主要概念と用語

• ブループリント定義（Blueprint Definition）: 払い出したい環境の設計図。後述の「アーティファクト」をまとめた入れ物で、管理グループまたはサブスクリプションに保存する
• アーティファクト（Artifact）: 定義に含める部品。主に ARM テンプレート（リソース展開）、ポリシー割り当て、ロール割り当て（RBAC）、リソースグループ の4種類がある
• 発行（Publish）とバージョン: 定義を編集したらバージョンを付けて発行する。割り当てには発行済みの特定バージョンを指定するため、標準環境の版管理ができる
• 割り当て（Assignment）: 発行済みブループリントをサブスクリプションへ適用する操作。割り当て時にパラメータ（場所、命名など）を渡す
• ロック（Locking / Blueprint Locks）: 割り当てによって作られたリソースを保護するモード。読み取り専用や削除禁止にして、展開後の改変・削除を防ぐ
• マネージド ID: 割り当て時に使う ID。システム割り当てかユーザー割り当てを指定し、この ID の権限でアーティファクトを展開する
• アーティファクトの順序付け（依存関係）: リソースグループを先に作ってからその中へテンプレートを展開するなど、部品間の順序を定義に持たせられる

仕様・制限・クォータ

• アーティファクトとして扱えるのは主に ARM テンプレート / ポリシー割り当て / ロール割り当て / リソースグループ の4種類。Bicep を使う場合はコンパイル後の ARM テンプレートとして含める
• 定義の保存先は管理グループまたはサブスクリプション。管理グループに保存すると配下の複数サブスクリプションへ割り当てられる
• 割り当てのスコープはサブスクリプション単位で、1つの割り当ては1つのサブスクリプションに対して適用される
• 定義内のアーティファクト数や、保存できる定義数などには上限がある。具体値は変動するため公式ドキュメントを確認すること
• ロックは割り当てによって展開されたリソースに効く。所有者でもロック中のリソースの削除・変更は基本的に拒否される（ロック解除は割り当ての更新で行う）
• 新規利用は非推奨（廃止予定）として告知されており、後継として Template Specs と Deployment Stacks の利用が案内されている

内部の仕組み

ブループリントは Azure Resource Manager（ARM）上のオブジェクトとして動作します。割り当てを作成すると、定義に含まれたアーティファクトが順序付けに従って展開され、割り当てリソースが作成済みリソースとの関連を保持します。

• 割り当てが展開の主体: 割り当て時に指定したマネージド ID の権限で、リソースグループ作成・テンプレート展開・ポリシー割り当て・ロール割り当てが順に実行される
• 順序付け（依存関係）: リソースグループを先に作り、その中へテンプレートを展開する、といった依存関係を定義側に持たせて整合性を保つ
• ロックの適用: ロックモードが有効な割り当てでは、作成されたリソースに削除・変更を防ぐガードがかかる。これは ARM の制御パスで効く
• バージョンの固定: 割り当ては発行済みの特定バージョンを指す。標準を更新したい場合は新バージョンを発行し、割り当てを新版へ更新する

定義そのものは JSON で表現され、アーティファクトの種類・パラメータ・依存関係を記述します。割り当ても JSON で、対象サブスクリプション・パラメータ・ロックモード・使用 ID を持ちます。

設計パターン / ベストプラクティス

• 管理グループに定義を置いて複数サブスクリプションへ展開する。組織標準のランディングゾーンを一箇所で管理し、各サブスクリプションへ割り当てる
• 発行バージョンで標準を版管理する。標準を変えたら新バージョンを発行し、影響を見ながら割り当てを段階的に更新する
• ガードレールはポリシー、保護はロックで二重化する。許可リージョンや必須タグはポリシーアーティファクトで強制し、土台リソースはロックで改変・削除から守る
• パラメータで再利用可能にする。場所・命名・サイズなどは割り当て時に渡し、定義本体は使い回す
• 新規はあえて後継へ寄せる。これから作る標準化は Template Specs と Deployment Stacks を優先し、ブループリントは既存資産の維持にとどめる
• Infrastructure as Code で履歴を残す。定義・割り当てをコードとして版管理し、レビューと再現性を確保する

運用・監視

• アクティビティログで割り当ての作成・更新・削除を監査し、どの版をどこへ適用したかを追跡する
• 割り当ての状態を確認し、アーティファクト展開の成否（特にマネージド ID の権限不足による失敗）を点検する
• ロックの整合を点検する。意図せぬロックで正当な運用変更が止まっていないか、逆に外すべきでないロックが解除されていないかを確認する
• 準拠の継続評価はポリシー側で行う。ブループリントは「配る」役割、配った後の準拠状況の可視化は Azure Policy のダッシュボードと組み合わせる
• 後継への移行計画を運用に織り込む。非推奨の告知を踏まえ、既存割り当ての棚卸しと移行先の検討を定期的に進める

コスト

Azure Blueprints の定義・発行・割り当て自体は、基本的に追加料金のかからないガバナンス機能です。実際の費用は、割り当てによって展開される各リソース（仮想ネットワーク、ストレージ、ログ送信先など）の通常料金として発生します。コストはブループリント機能そのものより、アーティファクトとして配るリソースで決まると考えるとよいでしょう。標準化によって過剰な構成を抑えられれば、無駄なコストを未然に防ぐ側面もあります。

セキュリティ

• ガバナンスを最初からセットで配る。ポリシー割り当てとロール割り当てをアーティファクトに含め、準拠した状態で環境を払い出す
• ロックで土台を保護する。展開後の改変・削除を防ぎ、設定ドリフトや誤操作による破壊を抑える
• マネージド ID は最小権限で。割り当ての ID には、アーティファクト展開に必要な範囲だけのロールを与え、広すぎる権限を避ける
• 管理グループ保存でガードレールを統一し、サブスクリプション間の標準逸脱を防ぐ
• 版とパラメータを履歴で追えるようにし、なぜその構成を配ったかを監査できるようにする

関連サービス・比較

Azure Blueprints は「準拠した環境を束ねて配る」役割で、土台のテンプレート配布を担う Template Specs と、割り当て単位の管理とドリフト保護を担う Deployment Stacks に役割が引き継がれつつあります。AWS では StackSets と Service Catalog にまたがる立ち位置です。

ハンズオン / CLI例

# ブループリント拡張機能を有効化（初回のみ）
az extension add --name blueprint

# サブスクリプション スコープにブループリント定義を作成
az blueprint create \
  --name landing-zone \
  --subscription "<SUBSCRIPTION_ID>" \
  --description "標準ランディングゾーン"

# 定義を発行してバージョンを付ける
az blueprint publish \
  --blueprint-name landing-zone \
  --subscription "<SUBSCRIPTION_ID>" \
  --version "1.0"

# 発行済みバージョンをサブスクリプションへ割り当て（削除禁止ロックで保護）
az blueprint assignment create \
  --name landing-zone-assign \
  --subscription "<SUBSCRIPTION_ID>" \
  --location japaneast \
  --blueprint-version "/subscriptions/<SUBSCRIPTION_ID>/providers/Microsoft.Blueprint/blueprints/landing-zone/versions/1.0" \
  --locks-mode AllResourcesDoNotDelete \
  --identity-type SystemAssigned

# 割り当ての状態を確認
az blueprint assignment show \
  --name landing-zone-assign \
  --subscription "<SUBSCRIPTION_ID>" -o jsonc