はじめに
Azure Blueprints を使っていた現場ほど、移行の話になると最初にこう考えがちです。
Blueprints の代わりになる“次の1つの機能”は何か？
私も最初はそう考えていました。
でも実際に現場で詰まったのは、機能選定よりも運用の責任分界でした。
- セキュリティは「逸脱を防ぎたい」
- アプリチームは「中央チーム待ちを減らしたい」
- 運用チームは「何が誰の管理下かを明確にしたい」
- プラットフォームチームは「再現性と標準化を保ちたい」
つまり、Blueprints の代替を考えるときに本当に必要なのは、1機能の置き換えではなく、Policy と IaC をどう分担して運用するかを決めることでした。
この記事では、越境をテーマに、普段あまり接点のなかったチームと一緒に整理して見えてきた、Blueprints の代替としての Policy + IaC の考え方を、運用視点でまとめます。
まず前提：Blueprints をそのまま別の1機能で置き換えようとしない
Blueprints が便利だったのは、複数の要素をひとまとめに扱えたからです。
図1. Blueprints がまとめていたもの
[Blueprints]
├─ Policy Assignments
├─ Role Assignments
├─ ARM Templates
└─ Resource Groups
この“ひとまとめ感”が使いやすさでもあり、移行を難しくしているポイントでもあります。
移行時にやりがちなのが、次のような考え方です。
図2. 最初に考えがちな置き換え
[Blueprints]
↓
[大きな1本の Bicep / Terraform に全部入れる]
でも、これをそのままやると運用で苦しくなります。
- Policy 的なガードレールと
- IaC 的なリソース作成と
- RBAC 的なアクセス設計と
- 運用上の所有・削除の考え方
が、全部1つの塊になってしまうからです。
現場では、ここを分けたほうがむしろ楽になりました。
図3. 実際に分けて考えた責務
[制限・監査・補正するもの]
└─ Azure Policy
[作るもの]
└─ IaC (Bicep / Terraform / Template Specs)
[誰が触れるか]
└─ Azure RBAC
[何を所有し、どう保護・削除するか]
└─ Deployment Stacks（必要な範囲だけ）
きっかけ：置き換え作業のはずが、運用の議論に変わった
ある環境で、これまで新しいサブスクリプションや基盤初期設定に Blueprints を使っていました。
当初は、プラットフォーム側で次のように考えていました。
Blueprints でやっていたことを、Bicep にまとめ直せば終わるだろう。
ところが、実際に越境して話を聞いてみると、論点は全く別でした。
アプリチームの声
- 毎回中央チームに依頼しないと進められないのは困る
- 環境作成はセルフサービスに寄せたい
- でも、何を触ってよくて何を触るとダメなのかは明確にしてほしい
セキュリティチームの声
- 禁止事項は deny で拒否したい
- 例外が口頭やチャットで流れるのが一番困る
- 監査可能な形で残してほしい
運用チームの声
- どのリソースがテンプレートの管理下なのかわからないと削除が怖い
- 手動変更がどこまで許されるのか曖昧だと障害対応後の差分管理が崩れる
- 後から見て「誰の責任で存在しているリソースか」が追えないとつらい
この時点で、私は初めて気づきました。
Blueprints の代替を考える作業は、技術の置き換えではなく、運用モデルの再設計だったのです。
先に結論：Blueprints の代替は「Policy + IaC + 必要に応じて Deployment Stacks」
私たちの現場では、最終的にこう整理すると運用が安定しました。
| 領域 | 役割 | 主な担当 |
|---|---|---|
| Azure Policy | ガードレール、監査、補正、例外管理 | セキュリティ / プラットフォーム |
| IaC | リソース作成、更新、モジュール化、再現性、レビュー | プラットフォーム / SRE / アプリ |
| Azure RBAC | 誰がどこまで操作できるか | プラットフォーム / ID管理 |
| Deployment Stacks | テンプレートが管理するリソースの所有・保護・削除の制御 | プラットフォーム / 運用 |
要するに、Blueprints の代替は1機能ではなく、役割分担そのものでした。
Policy に寄せるもの
Policy は、運用上の感覚で言うと、**「許可・制限・監査・補正を通じて、組織の基準から逸脱しにくくする仕組み」**です。
向いているのは、たとえば次のようなものです。
- 許可リージョンの制限
- 禁止リソース種別の制限
- パブリック公開に関する制限
- 必須タグ
- 診断設定の監査や補正
- セキュリティ基準への準拠確認
図4. Policy が得意なこと
Policy = 「何を許可し、何を制限・拒否するか」を決める
例:
- このリージョン以外は利用不可
- この設定がない場合は非準拠として監査する
- この種類のリソースは deny で拒否する
- このタグがないなら補正する
逆に、Policy だけで全部やろうとすると苦しくなります。
- VNet やサブネットをどう切るか
- 監視基盤をどの名前で作るか
- どの環境に何個のリソースを出すか
- ワークロードごとの構成差分をどう扱うか
このあたりは、“制限する”より“構成を作る”話なので、IaC に寄せたほうが自然です。
現場で効いた運用ルール
- Policy 定義・Initiative・Assignment は Git 管理する
- まずは
audit系で影響を見る - deny 適用の前に非本番で影響確認する
- 例外は Portal の口頭運用ではなく、Exemption とレビューで残す
ここを守るだけで、セキュリティと運用の会話がかなり噛み合うようになりました。
IaC に寄せるもの
IaC は、運用上の感覚で言うと、**「正しい構成を何度でも再現するための仕組み」**です。
向いているのは、たとえば次のようなものです。
- 管理グループ / サブスクリプション / リソース グループの構成
- 共有ネットワークやログ基盤
- 各種リソースの作成
- Role Assignment
- Policy Definition / Initiative / Assignment の配備そのもの
- 環境差分のパラメータ管理
- モジュール化とバージョン管理
図5. IaC が得意なこと
IaC = 「どう作るか」を定義する
例:
- どの管理グループ配下に置くか
- どのサブスクリプションに何を配備するか
- 共有の Log Analytics Workspace をどう作るか
- Role Assignment をどのスコープで付けるか
- ワークロードごとの差分をどこで吸収するか
ここで大きかったのは、RBAC も IaC 側で宣言的に持つようにしたことです。
Blueprints 時代は「権限もまとめて入っている」感覚になりがちでしたが、移行後は次のように整理しました。
- Policy は「どんな状態を許可・制限・拒否するか」
- RBAC は「誰が何を操作できるか」
- IaC は「それらをどのスコープにどう配るか」
この分け方にすると、責任の所在がかなり明確になります。
Template Specs は「社内向けの配布カタログ」として使う
移行の中で意外と便利だったのが Template Specs です。
体感としては、中央チームが承認したテンプレートを、社内向けに配布するためのカタログに近いです。
向いていた使い方
- 共通のネットワークモジュールを配る
- 標準の監視モジュールを配る
- 承認済みのテンプレートをチーム横断で使い回す
- バージョンを明示して配布する
図6. Template Specs の位置づけ
中央チームが作る
↓
承認済みテンプレートとして公開
↓
各チームは「配布された版」を使ってデプロイ
現場では、テンプレートを Git のURLや個人管理ストレージで共有すると、どうしても次の問題が出ます。
- どれが正式版かわからない
- 同じテンプレートのローカルコピーが増える
- いつの版を使っているか見えにくい
この点、Template Specs を使うと、社内配布物としての“型”が作りやすいと感じました。
Deployment Stacks は「所有」と「後片付け」のために使う
Blueprints を使っていた現場では、単にデプロイできることよりも、何が管理対象で、消すときにどう振る舞うかが大きな論点になります。
ここで効いたのが Deployment Stacks でした。
Deployment Stacks を使って整理しやすかったこと
- このテンプレートが管理するリソースはどれか
- テンプレートから外れたときに削除するのか、切り離すのか
- 事故防止のために更新 / 削除をどこまで保護するか
図7. Deployment Stacks が役立つ場面
[テンプレートで管理する共有基盤]
├─ 何を管理対象にするか明確
├─ 手動変更をどこまで許すか明確
├─ 消すときの挙動を明確
└─ 誤削除・誤更新を保護しやすい
特に運用保守チームとの会話では、この話が非常に重要でした。
この共有基盤、テンプレートから消えたら消していいの？
それとも、誰かが手で作ったものとして残すの？
この問いに答えられないまま自動化を進めると、最後は後片付けで揉めます。
現場で意識したこと
-
deleteAllを安易に使わない - まず「このスタックが本当に所有している範囲」を明確にする
- 共有基盤や中央管理のリソースに絞って使う
- アプリチームが高速に変更したい領域には、むやみに中央管理のスタックをかぶせない
つまり、Deployment Stacks は何にでも使うものというより、
所有と保護を明確にしたい範囲にだけ効かせるものでした。
実際に落ち着いた運用モデル
最終的に、私たちの現場では次のような運用に落ち着きました。
図8. 運用モデル全体像
[Tenant / Management Group]
│
├─ Policy / Initiative
│ └─ 組織共通ガードレール
│
├─ Platform IaC
│ ├─ 管理グループ
│ ├─ サブスクリプション
│ ├─ 共有ネットワーク
│ └─ 共有監視基盤
│
├─ Template Specs
│ └─ 社内向け標準モジュール
│
└─ Deployment Stacks
└─ 共有基盤や中央管理対象の所有・保護
さらに、リポジトリも分けました。
図9. リポジトリの分け方
repos/
├─ policy/
│ ├─ definitions/
│ ├─ initiatives/
│ ├─ assignments/
│ └─ exemptions/
│
├─ platform-iac/
│ ├─ management-groups/
│ ├─ subscriptions/
│ ├─ networking/
│ └─ monitoring/
│
└─ workload-iac/
├─ modules/
└─ environments/
この分け方にすると、次のメリットがありました。
- セキュリティレビューの対象が明確
- 例外管理がコードとして残る
- プラットフォーム変更とアプリ変更が混ざりにくい
- どのスコープをどのリポジトリが責任持つか見えやすい
パイプラインも「Policy と IaC を別々に、でも連携して」回す
ここも運用では重要でした。
図10. 変更フロー
Pull Request
↓
レビュー
↓
非本番へ配備
├─ Policy は監査モードで影響確認
└─ IaC はデプロイ後に準拠確認
↓
必要なら修復 / 例外登録
↓
本番へ段階展開
ポイントは、Policy をあとから見るものにしないことです。
IaC でデプロイした後に、
- どの Policy に引っかかったのか
- どのリソースが非準拠か
- 修復で直せるのか
- 例外が必要なのか
を、早い段階で見えるようにすると、
アプリチームとの会話が「拒否する / 拒否しない」ではなく「どう直すか」に変わります。
現場でハマったこと
1. Blueprints を一枚岩のまま再現しようとした
これは最初にやって失敗しました。
- セキュリティの都合
- 運用の都合
- アプリチームの都合
- 権限管理の都合
を全部1つの大きなテンプレートに押し込むと、変更のたびに全員がつらくなります。
2. Policy に「環境構築の責任」まで持たせた
Policy は強力ですが、IaC の代わりにはなりません。
「これを作る」「この順序で作る」「この差分で作る」は IaC 側の責務です。
Policy 側に寄せすぎると、ガードレールが構築ロジック化していきます。
3. 例外がチケットやチャットだけで流れた
現場では本当にこれが危険でした。
- 誰が承認したか
- いつまで例外なのか
- 恒久例外なのか一時例外なのか
が残らないと、あとから説明できなくなります。
4. 削除時の振る舞いを決めずに自動化した
作るときは盛り上がるのですが、運用は最後に必ず消す / 置き換える / 外すが来ます。
このときに、
- 削除するのか
- 切り離すのか
- 手動リソースをどう扱うのか
を決めていないと、運用チームが一番苦しみます。
今の私の判断基準
迷ったときは、今はこの4つで切り分けています。
| 問い | 寄せ先 |
|---|---|
| 組織として制限・拒否したいか | Policy |
| 正しい構成を何度でも再現したいか | IaC |
| 誰が操作できるかを明確にしたいか | Azure RBAC |
| 管理対象・削除・保護を明確にしたいか | Deployment Stacks |
そして、Blueprints からの移行で一番大事だと感じた問いはこれです。
これは「制限・監査・補正するもの」なのか、
「作るもの」なのか、
それとも「所有するもの」なのか。
この3つが分かれると、かなり整理しやすくなります。
まとめ
Blueprints の代替を考えるとき、つい「次の1機能」を探したくなります。
でも、現場で本当に効いたのは次の分け方でした。
- Policy で制限・監査・補正のガードレールを持つ
- IaC で構成を再現する
- RBAC で操作主体を分ける
- Deployment Stacks で必要な範囲だけ所有と保護を明確にする
- Template Specs で標準テンプレートを配る
そして何より、これを一人で決めないことです。
私自身、プラットフォーム側の都合だけで考えていたときは、
「きれいに置き換えること」ばかり見ていました。
でも、越境して、
- アプリチームのスピード感
- セキュリティの監査性
- 運用チームの後片付け
- 中央チームの標準化
を聞いて初めて、運用に乗る形が見えました。
Blueprints の代替は、ツールの話に見えて、実は責任分界の設計です。
だからこそ、技術をまたいで、人をまたいで、越境して考える価値があると思います。
参考
- Understand the lifecycle of a blueprint
- Overview of Azure Blueprints
- Migrate blueprints to deployment stacks
- Create & deploy template specs
- Create and deploy Azure deployment stacks in Bicep
- Overview of Azure Policy
- Design Azure Policy as Code workflows
- Use Bicep to deploy resources to management group
- Platform landing zone implementation options