先日 Azure Blueprints が非推奨になることが発表されました
今回はその後継にあたる デプロイ スタック (Deployment stacks) を試してみます
Blueprints とは
そもそも Azure Blueprints がどんなサービスだったかを振り返ります
Azure を企業で使うときは管理部門からサブスクリプションを発行してあげることがあります
このとき以下の3点を予め管理部門が設定することがあります
- 定番の Azure リソース
- RBAC
- Azure Policy
よく使うならセットにしたら便利やん っていうサービスが Azure Blueprints でした
ついでに バージョン管理で制御もできます
詳細は こちらの動画を見てみてください
※特に削除防止は非常に便利な機能です
最低限知っておきたい Azure ガバナンス サービスの基礎知識 - cafbc11 | 日本マイクロソフト - YouTube
で、はじめに書いた通り Blueprint は非推奨になってしまいます
2026 年 7 月 11 日に、Blueprints (プレビュー) は非推奨になります。 既存のブループリントの定義と割り当てを Template Specs とデプロイ スタックに移行します。
Azure Blueprint の概要 - Azure Blueprints | Microsoft Learn
後継は Template Specs と デプロイ スタックになります
Template Specs は別途シリーズ化を目論んでいる IaC – クラウドを勉強し隊 のところで触れる予定です
今回はデプロイ スタックにだけフォーカスします
デプロイ スタック とは
Azure デプロイ スタックは、Azure リソースのグループをアトミック単位として管理できるようにする Azure リソースの一種です
Bicep でのデプロイ スタックの作成とデプロイ - Azure Resource Manager | Microsoft Learn
と書かれています
Blueprint でカバーしていた内容のうち「定番の Azure リソース」の部分を担ってそうです
また Azure リソースと記載があるので、Bicep ファイルなどのテンプレートとの関係性を担う役割をもつリソースのようです
この関係性を変更できるかどうかも RBAC で制御できそうです
デプロイを計画し、同じスタックに含めるリソース グループを決定するときは、これらのリソースの管理ライフサイクル (作成、更新、削除など) を考慮することが重要です。 たとえば、さまさまなリソース グループ スコープにわたって、さまざまなアプリケーション チーム用にいくつかのテスト VM をプロビジョニングする必要があるとします。 この場合、デプロイ スタックを利用して、これらのテスト環境を作成し、その後のデプロイ スタックの更新を通じてテスト VM 構成を更新できます。 プロジェクトを完了した後、作成されたすべてのリソース (テスト VM など) を削除する必要がある場合があります。 デプロイ スタックを利用して、適切な削除フラグを指定することで、管理対象リソースを簡単に削除できます。 この合理化されたアプローチでは、各種リソース グループ スコープでそれぞれのテスト VM を個別に変更または削除するのではなく、スタック リソースへの 1 回の更新で行われるため、環境のクリーンアップにかかる時間を節約できます。
Azure の場合リソース グループを丸ごと削除ができるので、ライフサイクルをともにするサービスをまとめておくのがおすすめです
これを見ると、デプロイ スタック単位でグループ化されていて、そのグループで削除できる。しかもそれは リソースグループの枠組みを超えられる
ということでしょうか
公開情報のメリットを改めて整理してみます
- リソースの管理を簡略化
- 削除を防止する
- 効率的なリソースの削除
- Azure の IaC (ARM テンプレート、Bicep) との連携
Blueprint は Bicep に対応していなかったので、削除以外の観点でもメリットがありますね
現在はプレビュー中で、既知の問題がいくつか記載されているので注意です
※いずれ解決すると思うので、あえてこのブログには記載しないです
Bicep でのデプロイ スタックの作成とデプロイ - Azure Resource Manager | Microsoft Learn
RBAC と Azure Policy は記載がないので対応していないのかな。。。
何はともあれ触ってみます
ざっくり手順
公開情報に従って触ってみます
Bicep を使用してデプロイ スタックを作成してデプロイする (プレビュー) - Azure Resource Manager | Microsoft Learn
- Bicep ファイルの準備
- デプロイ スタックの作成
- デプロイ スタックの検証
- デプロイ スタックの更新
- デプロイ スタックの削除
1. Bicep ファイルの準備
公開情報のものをコピペしました
Azure_Bicep/Blog/after_blueprint/main.bicep at main · NakayamaKento/Azure_Bicep
2. デプロイ スタックの作成
Bicep ファイルをもとにデプロイ スタックを作成します
|
|
デプロイ スタック部分の実行結果はこれです
|
|
Resources を見るとストレージアカウントと仮想ネットワークの2つがデプロイできていることがわかります
3. デプロイ スタックの検証
先ほどの実行結果は以下のコマンドを実行すると再度表示させることができます
|
|
リソース情報だけを取り出したいときは以下のコマンドを実行します
|
|
実行結果は以下の通りです
|
|
Azure Portal 上の表示も見てみます
デプロイ スタックの作成自体は現在は PowerShell か Azure CLI のみですが、作成後の変更は Azure Portal からでもできそうです


4. デプロイ スタックの更新
元の Bicep ファイルのストレージアカウントの SKU を変更します
変更前 | 変更後 |
---|---|
Standard_LRS | Standard_GRS |
変更を反映させる前のストレージアカウントの SKU を確認しておきます

では、以下のコマンドを実行して更新します
|
|
無事に変更が反映されました

ついでに DenySettingMode を denyDelete に変更したバージョンを実行してみました
|
|
結果としては、ストレージ アカウントや仮想ネットワークの削除はできませんでした
が、サブネットの削除はできました
調べてみると DenySettingsApplyToChildScopes というパラメータがありました
名前の通り入れ子になったリソースにも削除の設定が反映されると記述がありました
改めて、以下を実行してみます
|
|
その結果、サブネットの削除ができなくなっていました
削除拒否の抜け道が 2 種類用意されています
- DenySettingsExcludedAction
- 最大 200 個の操作を設定できます
- DenySettingsExcludedPrincipal
- 最大 5 つのサービスプリンシパルを設定できます
5. デプロイ スタックの削除
最後に削除をしておきたいと思います
ここで少し落とし穴です。以下のコマンドを実行するとデプロイスタックのリソースは削除されますが、リソースは残っています
すなわち、削除拒否の設定などが消えるだけということです
|
|
そのためデプロイスタック経由で作成したリソースを削除する場合は以下のようなコマンドを実行します
DeleteResources の部分は、DeleteAll に変えても OK です
|
|
最後にデプロイ スタックに含まれていないリソース グループも削除してクリーンアップ完了です
|
|
まとめ
Blueprints の後継にあたるデプロイスタックを試しました
RBAC、Azure Policy の設定は含まれていませんが Azure のリソースを効率よく管理できそうです
また、拒否の設定により変更や削除を許さないのは非常に強力だと思いました