BEMAロゴ

エンジニアの
成長を支援する
技術メディア

【Bicep】3年半越しのGA!Azure Deployment stacksのwhat-ifで本番事故を防ぐ7つの検証パターン

リンクをコピー
リンクをコピーしました
Xでシェアするfacebookでシェアする

はじめに

Deployment stacks には長い間、大きな弱点がありました。それは、差分確認(what-if)のコマンドがなかったことです。
通常のデプロイの what-if しか選択肢がなく、Deployment stacks とはコード削除時の挙動が違うため、差分の出力を読み替えるか推測するしかありませんでした。

この欠陥のせいで、Deployment stacks の採用を見送ったり、Bicep 自体を諦めて Terraform など別の IaC を選んだ方もいらっしゃるのではないでしょうか。

そんな中、2026年8月にDeployment stacksの what-if がついにGA(正式リリース)されました!
https://github.com/Azure/deployment-stacks/issues/80Open in new tab

2023年1月に GitHub Issue が立てられてから、3年半越しでの GA です。

この機能によって「Bicep を選択しない理由」が減ったので、Azure ネイティブで今後構築または移行を考えている方の IaC として「Bicep を使いましょう!」となる確率は高くなったかなと思います。

https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/deployment-stacks-what-if?tabs=azure-cli#retrieve-and-delete-stored-resultsOpen in new tab

なぜこの機能が必要だったのか

Deployment stacks は、複数のリソースを1つの単位としてまとめて管理できる仕組みです。便利な反面、本番で使うときに一番怖いのが actionOnUnmanage の設定でした。

テンプレートからリソースの定義を消すと、そのリソースはスタックの管理対象から外れます。このとき何が起きるかは actionOnUnmanage 次第で、detachAll なら Azure 上には残りますが、deleteResourcesdeleteAll を指定していると実リソースごと削除されます

つまり「Bicep ファイルから数行消して az stack group create を実行する」という日常的な操作が、状況次第で本番リソースの削除に直結します。これが Deployment stacks の運用上の最大のハードルでした。

今回 GA した what-if は、まさにここを埋める機能です。適用前に、どのリソースにどういった変更が入るかを確認できます。

差分の内容で利用される種別と記号は以下のとおりです。

変更種別

記号

意味

Create

+

リソースが存在せず、新規作成される

Modify

~

リソースは存在し、一部のプロパティが変更される

NoChange

=

リソースは存在し、変更されない

Delete

-

actionOnUnmanage が削除系のとき。スタックから外れ、リソースも削除される

Detach

v

actionOnUnmanage が detach のとき。スタックの管理から外れるが、Azure 上には残る

Unsupported

!

what-if の評価がサポートされていないリソース

なぜ、デタッチが vなのか気になりますが、わかりやすいですね。

通常のデプロイの what-if との決定的な違い

ここが非常に重要な点で、az deployment group what-if を使ったことがある人ほど戸惑うと思います。

通常のデプロイでは、what-if はただの操作です。実行すると予測結果が返ってくるだけで、何も保存されません。

一方、Deployment stacks の what-if はその結果をリソースとして作成します。Microsoft.Resources/deploymentStacksWhatIfResults という型の独立したリソースで、名前は自分で付けられます。

リソースの ID は次の形になります。

/subscriptions/{subscription-id}/resourceGroups/{resource-group-name}/providers/Microsoft.Resources/deploymentStacksWhatIfResults/{what-if-result-name}

リソースなので、もちろんポータル上からも deploymentStacksWhatIfResults リソースは確認できます。

ポータル上の deploymentStacksWhatIfResults リソース

what-if の結果リソースには保持期間に注意点がありますが、この点については後述します。

検証環境

ここからは、実際に触りながら検証していきます。
コストをかけずに各パターンを試すため、最小構成にしました。

リソース

役割

ストレージアカウント

Modify とプロパティ差分の確認用。SKU とタグを変更する

NSG(A)

追加・削除の繰り返し用。Create / Detach / Delete の確認

NSG(B)

Azure CLI で作成。notManaged => managed の確認用

以下二つのファイルを作成してください。

main.bicep

param location string = resourceGroup().location
param storageSku string
param includeNsgA bool
param saTagEnv string

resource sa 'Microsoft.Storage/storageAccounts@2023-01-01' = {
  name: 'stwhatif${uniqueString(resourceGroup().id)}'
  location: location
  sku: { name: storageSku }
  kind: 'StorageV2'
  tags: { env: saTagEnv }
}

resource nsgA 'Microsoft.Network/networkSecurityGroups@2023-11-01' = if (includeNsgA) {
  name: 'nsg-whatif-a'
  location: location
  properties: {
    securityRules: [
      {
        name: 'allow-https'
        properties: {
          priority: 100
          direction: 'Inbound'
          access: 'Allow'
          protocol: 'Tcp'
          sourceAddressPrefix: ''
          sourcePortRange: ''
          destinationAddressPrefix: '*'
          destinationPortRange: '443'
        }
      }
    ]
  }
}

main.bicepparam

using './main.bicep'

param storageSku = 'Standard_LRS'
param includeNsgA = false
param saTagEnv = 'demo'

Azure CLI のバージョンは以下のとおりです。

az cli version: 2.89.1
az bicep version: 0.46.1

az stack-whatifAzure CLI 2.89.0(2026年8月4日リリース)で追加されたコマンドです。それ以前のバージョンではエラーになるので、2.89.0 以上にアップデートしてから試してください。
Azure CLI リリースノート:
https://github.com/MicrosoftDocs/azure-docs-cli/blob/main/docs-ref-conceptual/Latest-version/release-notes-azure-cli.mdOpen in new tab

基本コマンド

https://learn.microsoft.com/ja-jp/cli/azure/stack-whatif?view=azure-cli-latestOpen in new tab

リソースグループスコープの場合はこうなります。

az stack-whatif group create \
  --name <what-if-result-name> \
  --resource-group <resource-group-name> \
  --stack-id <deployment-stack-resource-id> \
  --template-file main.bicep \
  --action-on-unmanage deleteAll \
  --deny-settings-mode none \
  --retention-interval PT3H

対象のスタックは --stack-id でリソース ID を指定します。--name は保存される what-if 結果のリソース名です。保持期間は ISO 8601 の期間形式で、PT3H なら3時間です。
ISO 8601 期間形式の参考記事:
https://qiita.com/e99h2121/items/c298fee44ea4e57986c9Open in new tab

なお、サブスクリプションスコープなら az stack-whatif sub、管理グループスコープなら az stack-whatif mg を使います。

使ってみた

今回の検証はリソースグループスコープで行います。

前提:リソースグループの作成

リソースグループは事前に作成しておきます。

#環境変数
RG=<resource-group-name>
LOCATION=japaneast

#リソースグループ作成
az group create --name $RG --location $LOCATION

パターン1:スタックがまだ存在しない状態で実行する


評価対象のスタックは、存在していなくても大丈夫です(ただしIDの書式自体は正しい必要あり)。存在しない場合、what-if はスタック自体を新規リソースとして報告します。つまり初回作成前にプレビューできるということです。

実行コマンド

#環境変数
SUB_ID=<subscription-id>
RG=<resource-group-name>
STACK_NAME=stack-test
STACK_ID=/subscriptions/$SUB_ID/resourceGroups/$RG/providers/Microsoft.Resources/deploymentStacks/$STACK_NAME
STACK_WIF_NAME="${STACK_NAME}-wif-result"

#スタック作成の差分確認
az stack-whatif group create 
  --name $STACK_WIF_NAME 
  --resource-group $RG 
  --stack-id $STACK_ID 
  --action-on-unmanage deleteAll 
  --deny-settings-mode none 
  --retention-interval PT3H 
  --parameters main.bicepparam

実行結果です。

Resource and property changes are indicated with these symbols:
  + Create              ! Unsupported
  ~ Modify              - Delete
  = NoChange            v Detach

Changes to Stack /subscriptions//resourceGroups//providers/Microsoft.Resources/deploymentStacks/stack-
test:
+ DenySettings.Mode: "None"
+ DenySettings.ApplyToChildScopes: "False"

Changes to Managed Resources:

Azure
  + /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Storage/storageAccounts/stwhatifjllhctmmnuk3i [2023-01-01]
    ~ Management Status: "notManaged" => "managed"
    = Deny Status: "none"

出力は 2 段構成です。

  • Changes to Stack: スタック本体の設定変更(今回は DenySettings が新規追加)

  • Changes to Managed Resources:スタック配下のリソースの変更予定

+は新規作成、その下の ~ Management Status: "notManaged" => "managed" は「スタックの管理対象に取り込まれる」ことを表す差分で、通常の what-if にはない Deployment stacks 特有の表示です。
なお、今回は初回なので全て貼り付けていますが長いので、以降は Azure 行以下のみ抜粋します。

出力結果を確認したら、スタックとリソースをデプロイします。

az stack group create \
  --name $STACK_NAME \
  --resource-group $RG \
  --deny-settings-mode none \
  --action-on-unmanage deleteAll \
  --parameters main.bicepparam

パターン2:リソースを追加する

main.bicepparam の includeNsgAtrue にして、NSG A をスタックに追加します。

param includeNsgA = true

パターン1で実行した az stack-whatif group create から一部変更して what-if を実行します。

  • --name のサフィックスに -nsga を追加

az stack-whatif group create \
  --name "${STACK_WIF_NAME}-nsga" \
  ...

実行すると、差分として NSG が一つ作成される(加えて、スタックの管理対象となった)ことがわかります。

Azure
  + /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Network/networkSecurityGroups/nsg-whatif-a [2023-11-01]
    ~ Management Status: "notManaged" => "managed"
    = Deny Status: "none"
  = /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Storage/storageAccounts/stwhatifjllhctmmnuk3i [2023-01-01]
    = Management Status: "managed"
    = Deny Status: "none"

差分を確認できたら、NSG A を az stack group create でデプロイしてください。

パターン3:プロパティを変更する

main.bicepparam の storageSkuStandard_GRS に変更し、saTagEnvtest に差し替えます。

param storageSku = 'Standard_GRS'
param saTagEnv = 'test'

パターン1で実行した az stack-whatif group create から一部変更して what-if を実行します。

  • --name のサフィックスに -st-grs を追加してください

az stack-whatif group create \
  --name "${STACK_WIF_NAME}-st-grs" \
  ...

パターン2で作成した NSG A は = となっており差分がないことがわかります。
今回変更したストレージアカウントには、変更したパラメータの内容が
~ と変更として出力されています。

Azure
  = /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Network/networkSecurityGroups/nsg-whatif-a [2023-11-01]
    = Management Status: "managed"
    = Deny Status: "none"
  ~ /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Storage/storageAccounts/stwhatifjllhctmmnuk3i [2023-01-01]
    = Management Status: "managed"
    = Deny Status: "none"
    ~ sku.name: "Standard_LRS" => "Standard_GRS"
    ~ tags.env: "demo" => "test"

差分を確認できたら、az stack group create でデプロイしてください。

パターン4:管理外のリソースをテンプレートに含める

Azure CLI で作成した NSG B をテンプレートに追記します。既存リソースをスタックの管理下に取り込むケースです。

NSG B を Azure CLI で作成します。

az network nsg create -g $RG -n nsg-whatif-b --location japaneast

main.bicep の末尾に以下を追記します。

resource nsgB 'Microsoft.Network/networkSecurityGroups@2023-11-01' = {
  name: 'nsg-whatif-b'
  location: location
}

パターン1で実行した az stack-whatif group create から一部変更して what-if を実行します。

  • --name のサフィックスに -nsgb を追加してください

az stack-whatif group create \
  --name "${STACK_WIF_NAME}-nsgb" \
  ...

nsg-whatif-bnotManaged(管理外)から managed(管理)になっていることがわかります。
また、パターン2で NSG A を作成した時は、
+(追加)判定だったのに対して、今回 main.bicep に追加した NSG B のリソース自体は既存リソースのため差分なしとなっているのがわかります。

Azure
  = /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Network/networkSecurityGroups/nsg-whatif-a [2023-11-01]
    = Management Status: "managed"
    = Deny Status: "none"
  = /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Network/networkSecurityGroups/nsg-whatif-b [2023-11-01]
    ~ Management Status: "notManaged" => "managed"
    = Deny Status: "none"
  = /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Storage/storageAccounts/stwhatifjllhctmmnuk3i [2023-01-01]
    = Management Status: "managed"
    = Deny Status: "none"

差分を確認できたら、az stack group create でデプロイしてください。

パターン5:テンプレートから消す × actionOnUnmanage

この記事の本題です。同じ「テンプレートから削除」でも、スタックの actionOnUnmanage 設定によって結果が変わります。

main.bicepparam の includeNsgAfalse にして、NSG A が削除されるようにします。

param includeNsgA = false

パターン1で実行した az stack-whatif group create から一部変更して what-if を実行します。

  • --name のサフィックスに -check-action を追加してください

  • --action-on-unmanage は実行時に各オプションに変更してください

az stack-whatif group create \
  --name "${STACK_WIF_NAME}-check-action" \
  ...
  --action-on-unmanage <適宜変更> \
  ...

detachAll の場合
NSG A が
v(デタッチ)になっています。

Azure
  v /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Network/networkSecurityGroups/nsg-whatif-a
    ~ Management Status: "managed" => "notManaged"
    = Deny Status: "none"
  = /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Network/networkSecurityGroups/nsg-whatif-b [2023-11-01]
    = Management Status: "managed"
    = Deny Status: "none"
  = /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Storage/storageAccounts/stwhatifjllhctmmnuk3i [2023-01-01]
    = Management Status: "managed"
    = Deny Status: "none"

deleteResources の場合
NSG A が -(削除)になっています。

Azure
  - /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Network/networkSecurityGroups/nsg-whatif-a
    ~ Management Status: "managed" => "notManaged"
    = Deny Status: "none"
  = /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Network/networkSecurityGroups/nsg-whatif-b [2023-11-01]
    = Management Status: "managed"
    = Deny Status: "none"
  = /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Storage/storageAccounts/stwhatifjllhctmmnuk3i [2023-01-01]
    = Management Status: "managed"
    = Deny Status: "none"

Deleting - Resources Marked for Deletion 1 total:

Azure
  - /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Network/networkSecurityGroups/nsg-whatif-a

なお、actionOnUnmanage には deleteAll があります。ただ、リソースグループスコープのスタックでは deleteAlldeleteResources の結果に差が出ません。
deleteAll はスタックが管理するリソースグループも削除対象にできます(違いを確認するにはサブスクリプションスコープが必要)。今回は検証環境を軽くするため、リソースグループで割り切りました。

NSG A はまだ使いますので、includeNsgA=true に戻して消さずに残しておいてください。

パターン6:ポータルから手で変更した場合(ドリフト)

テンプレートは触らず、Azure 側を手で変更した状態で what-if を実行します。実運用で一番ありがちなケースです。

以下のような変更をポータル上で施します。

  • NSG A にセキュリティルールを1本追加:配列プロパティの差分がどう表示されるか

  • NSG B を削除:Create として復活扱いになるか

  • ストレージアカウントにタグを追加:- tags.xxx として削除差分で出るか

パターン1で実行した az stack-whatif group create から一部変更して what-if を実行します。

  • --name のサフィックスに -check-drift を追加してください

az stack-whatif group create \
  --name "${STACK_WIF_NAME}-check-drift" \
  ...

実行結果です。

Azure
  ~ /subscriptions//resourceGroups//providers/Microsoft.Network/networkSecurityGroups/nsg-whatif-a [2023-11-01]
    = Management Status: "managed"
    = Deny Status: "none"
    ~ properties.securityRules:
      - 1:
          {
            "name": "allow-ssh",
            "properties": {
              "access": "Allow",
              "destinationAddressPrefix": "",
              "destinationPortRange": "22",
              "direction": "Inbound",
              "priority": 110,
              "protocol": "TCP",
              "sourceAddressPrefix": "",
              "sourcePortRange": "*"
            }
          }
  + /subscriptions/<subscription-id>/resourceGroups/<resource-group-
name>/providers/Microsoft.Network/networkSecurityGroups/nsg-whatif-b [2023-11-01]
    = Management Status: "managed"
    = Deny Status: "none"
   ~ /subscriptions/<subscription-id>/resourceGroups/<resource-group-
name>/providers/Microsoft.Storage/storageAccounts/stwhatifjllhctmmnuk3i [2023-01-01]
    = Management Status: "managed"
    = Deny Status: "none"
    - tags.manage: "bicep"

実行結果から、ポータル上の変更が以下のようにテンプレートの内容に戻されることがわかります。

  • NSG A にセキュリティルールを1本追加 → 追加したセキュリティルール削除

  • NSG B を削除 → Create として復活

  • ストレージアカウントにタグを追加 → - tags.manage: "bicep" として削除

差分を確認できたら、az stack group create でデプロイしてください。

パターン7:denySettings との組み合わせ

-deny-settings-modedenyDelete(削除防止)にしたスタックに対して what-if を実行します。出力には Deny Status という行があるので、deny 設定の変更も差分として表示されます。

パターン1で実行した az stack-whatif group create から一部変更して what-if を実行します。

  • --name のサフィックスに -deny-delete を追加してください

  • --deny-settings-modedenyDelete に変更

az stack-whatif group create \
  --name "${STACK_WIF_NAME}-deny-delete" \
  ...
  --deny-settings-mode denyDelete \
  ...

Deny Statusnone から denyDelete になっています。
これで、ポータルや Azure CLI からの削除ができなくなるリソースが事前に把握しやすくなります。

Azure
  = /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Network/networkSecurityGroups/nsg-whatif-a [2023-11-01]
    = Management Status: "managed"
    ~ Deny Status: "none" => "denyDelete"
  = /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Network/networkSecurityGroups/nsg-whatif-b [2023-11-01]
    = Management Status: "managed"
    ~ Deny Status: "none" => "denyDelete"
  = /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Storage/storageAccounts/stwhatifjllhctmmnuk3i [2023-01-01]
    = Management Status: "managed"
    ~ Deny Status: "none" => "denyDelete"

以上で、「使ってみた」の章は終了です。

ある程度 Deployment stacks の what-if の挙動について理解できました。
他にもたくさんオプションがありますのでご自身で触ってみてください。

ノイズ削減と、その前提条件

通常の what-if は「変えていないのに差分として出る」ノイズが多いことで知られています。

リソースプロバイダーがデプロイ後に値を追加したり正規化したりするため、実質的には何も変わっていなくてもテンプレートとの差が出てしまうからです。

Deployment stacks の what-if は、ここにノイズ削減の仕組みが入っています。

スタックをデプロイまたは更新したとき、Azure はその時点でスタックの what-if を評価し、結果を ベースライン として保持します。後から what-if を実行すると、ベースラインと現在の評価の間で変わっていないプロパティはノイズとして結果から除去されます。残るのは、テンプレートが実際に持ち込む変更に近いものになります。

ここで注意したいのが、ベースラインはスタックのデプロイ時に記録されるという点です。そのため、ノイズ削減が適用されるのは、この機能が使えるようになった後に作成または更新されたスタックだけです。GA 後にデプロイも更新もしていないスタックでは、what-if 結果にノイズが残ります。

「GA したから既存のスタックで試したのにノイズだらけだった」となりやすいので、覚えておくとよさそうです。

ハマりどころ

結果リソースの保持期間は PT3H 以下にする

保持期間を PT3H より長く設定した結果は自動削除されません。不要になったら自分で削除する必要があります。

# 一覧
az stack-whatif group list --resource-group $RG

# 単一取得
az stack-whatif group show --name $STACK_WIF_NAME --resource-group $RG

# 削除
az stack-whatif group delete --name $STACK_WIF_NAME --resource-group $RG

今回、パターンごとに stack-whatif の --name オプションを毎回変えて実行してきました。
その結果、以下のように7パターン分のリソースが溜まっていることがわかります。

$ az stack-whatif group list --resource-group $RG 
  --query "[].{Name:name}" -o table

Name
----------------------------------
stack-test-wif-result
stack-test-wif-result-nsga
stack-test-wif-result-st-grs
stack-test-wif-result-nsgb
stack-test-wif-result-check-action
stack-test-wif-result-check-drift
stack-test-wif-result-deny-delete

このように、what-if 結果は作成したスコープに存在するリソースなので、検証で何度も実行していると気づいたら結果リソースだらけになります。

保存済み結果は -with-property-changes を付けないと切り捨てられる

保存済みの what-if 結果を az stack-whatif group show で取得するとき、既定ではリソース単位の差分しか返りません。

パターン3 で見た sku.nametags.env などのプロパティ差分は表示されないので、必ず --with-property-changes true(別名 --wpc true)を付けてください。

既定(プロパティ差分は出ない)

az stack-whatif group show \
  --name "${STACK_WIF_NAME}-st-grs" \
  --resource-group $RG
Azure
  = /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Network/networkSecurityGroups/nsg-whatif-a
    = Management Status: "managed"
    = Deny Status: "none"
  ~ /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Storage/storageAccounts/stwhatif7et6h4m5up5ze
    = Management Status: "managed"
    = Deny Status: "none"

-with-property-changes true を付ける(プロパティ差分も出る)

az stack-whatif group show \
  --name "${STACK_WIF_NAME}-st-grs" \
  --resource-group $RG \
  --with-property-changes true
Azure
  = /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Network/networkSecurityGroups/nsg-whatif-a [2023-11-01]
    = Management Status: "managed"
    = Deny Status: "none"
  ~ /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Storage/storageAccounts/stwhatif7et6h4m5up5ze [2023-01-01]
    = Management Status: "managed"
    = Deny Status: "none"
    ~ sku.name: "Standard_LRS" => "Standard_GRS"
    ~ tags.env: "demo" => "test"

保存済み結果リソースから出る警告

what-if 結果を保存した後に、対象のスタックで az stack group createを実行すると、show で取得したときに以下の警告が付きます。

WARNING: [DeploymentStackWhatIfDiagnostic_StaleWhatIf]
  Message: The corresponding deployment stack has been deleted or updated since the what-if operation was run. For accurate what-if predictions, please re-run the deployment stack what-if.

意味は「保存された予測はもう最新のスタック状態と一致しないかもしれないので、正確な差分が必要なら再度 what-if を打ち直してね」というものです。あくまで注意喚起で、show 自体は成功します。

この記事のように「what-if → 適用 → 次のパターンの what-if → 適用 …」を繰り返す運用では、過去のパターンの結果を後から show すると軒並みこの警告が付くので、そういうものだと思っておくとよさそうです。

what-if の結果は「保証」ではない

リソースの種類やプロパティによっては、変更種別が Unsupported!)と表示されて評価がスキップされたり、リソースプロバイダーの実装次第で差分が正確に取れないケースがあります。

what-if が「差分ゼロ」と出ていても、actionOnUnmanagedeleteResources / deleteAll の場合は特に、内容を目視で確認してから適用するのが安全です。

クリーンアップ

最後に、スタックとリソースグループを削除しておきます!
遠足は帰るまでが、検証はクリーンアップまでが完了定義です。

# リソースグループごと削除
az group delete --name $RG

# スタックとその管理下のリソースを削除する場合
az stack group delete \
  --name $STACK_NAME \
  --resource-group $RG \
  --action-on-unmanage deleteAll

ここで注意したいのが、パターン7 で denyDelete を実際に適用したスタックが残っていたとしても、リソースグループごと削除可能という点です。
これは既知の問題としても挙げられています。もし、リソースグループを削除防止に割り当てしたい場合は、サブスクリプションスコープにしてテンプレートにリソースグループを含める必要があります。

Deployment stacks の既知の問題:
https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/deployment-stacks-known-issuesOpen in new tab

まとめ

やっと出た差分確認機能ですが、まとめると以下のような注意点があります。

  • 通常のデプロイの what-if と違い、結果は Microsoft.Resources/deploymentStacksWhatIfResults という独立した Azure リソースとして保存される

  • az stack-whatif group show には --with-property-changes true をつけないとプロパティの差分が出ない。

  • what-if 結果にはノイズ削減が入っている。ただしベースラインはスタックのデプロイ時に記録されるため、しばらく更新していないスタックではノイズが残る。

  • 保持期間を PT3H より長くすると自動削除されないので、消し忘れに注意。

GA になったばかりで、まだ成熟途中といった感じです。

しかし、Bicep は非常に扱いやすく、Azure の IaC として最初の入り口で利用するにはもってこいです。そのリソース管理をより柔軟にできる Deployment stacks を、今後は有力な選択肢として入れてみてはいかがでしょうか。

この記事が役に立ったと思ったら、
ぜひ「いいね」とシェアをお願いします!

��リンクをコピー
リンクをコピーしました
Xでシェアするfacebookでシェアする

この記事を書いた人

蒔苗 純平
蒔苗 純平
2025年新卒として株式会社メンバーズへ入社。現在、エンジニアとしてクラウド保守の業務に従事しつつDevOpsやSREについて勉強中です。
詳しく見る
ページトップへ戻る