Azureデプロイスタック（Deployment Stack）のパブリックプレビュー開始

# 概要
7/22 (土)にパブリックプレビューになったAzureデプロイスタック（Deployment Stack）を試してみました。
 - MSブログ
[ARM Deployment Stacks now Public Preview!](https://techcommunity.microsoft.com/t5/azure-governance-and-management/arm-deployment-stacks-now-public-preview/ba-p/3871180)

これまでAzureのIaC（Bicep、ARMテンプレート等）では、デプロイしたリソースの状態を管理することはできなかったため、AWSのCloudFormation等に比べて使いきりの印象が強かったものの、この機能で状態の管理ができるようになると考えられます。

実際の使い勝手を確認するため基本機能を試してみます。
なお、デプロイスタックは管理グループ、サブスクリプション、リソースグループのいずれかをスコープとしてデプロイできますが、一番利用ケースが多そうなリソースグループで検証しています。

# デプロイ
- デプロイするリソースの定義はあくまでARMテンプレートやBicepテンプレートファイルとして用意する必要があります。
- テンプレートファイルのデプロイをおこなう際に使用するコマンドがデプロイスタック用のコマンドになります。
- 現状Azureポータルからの操作は限定的です。
- リソース追加は特に違和感なくデプロイと同様に可能です。

以下気になったポイントです。
## デプロイスタックで確認できるリソースの単位
- Bicepテンプレートファイルでリソースを定義する際にサブネットやNSGのルールのように親リソースありきのリソースは親リソース内の定義に記載することも、親リソースの外に記載することもできます。
デプロイスタックでのリソースの単位は定義したリソースに対応しているようで、仮想ネットワークを構築する際に一部のサブネットは仮想ネットワーク内で定義し、一部は別で定義というようなケースだと同じサブネットのリソースでもデプロイスタックにおけるリソース管理の扱いが異なってしまうようです。コーディング時のルールである程度はカバーできると思いますが注意点です。
  - **個別に定義したGatewaySubnetとNSGルール（rule1）が別リソースとして表示**
  ![ds_deploy_01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/481267/5a4f8577-6a2f-5189-0100-3c361ff5fe1a.png)



# リソース削除
- 削除についてはAzureリソース自体の削除とデプロイスタックからのリソース削除（デタッチ）を分けて考える必要があります。
- デプロイスタックでリソースを削除した際の挙動は、デプロイスタックにおける設定でデタッチするだけ、もしくはリソース自体削除を設定できます。
- デフォルトはデタッチでデプロイスタックのデプロイ時や更新時のパラメータ指定でリソース削除（リソースグループ削除）を設定可能です。

以下気になったポイントです。
## デタッチ・削除したリソースの表示
- デタッチ・削除したリソースもデプロイスタック内で確認できるのは嬉しい。
- ただし、デタッチ・削除したリソースについては次回のデプロイスタック更新でデプロイスタック内での確認も不可能になる（完全に見えなくなる）。
  - **デタッチ・削除直後のリソース表示**
  ![ds_deploy_02.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/481267/e54e2d74-75ec-b70c-9452-ff6813040fd2.png)

  - **デタッチ・削除後のデプロイスタック更新後**
  ![ds_deploy_03.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/481267/0916ff5c-e0a9-a377-1535-15f2832e9a9d.png)

# ドリフトの検出
- デプロイスタックでデプロイしたリソースをデプロイスタックを利用せずに削除してみると、デプロイスタックにはリソース削除が反映されずドリフトは検出されませんでした。
- ただし、この点はRBAC（Azureロール）の拒否の割り当てを使うことで、そもそもデプロイスタック外からの削除・更新を拒否する運用を想定していると思われます。

# RBAC（Azureロール）の拒否の割り当て
- これまではBlueprints（プレビュー中）でのみ割り当て可能だった拒否の割り当てをデプロイスタック単位で設定可能です。
- 前述の通りこの機能を使ってデプロイスタックの管理リソースをデプロイスタック外からの変更から保護することができます。
- 拒否の割り当ては基本的にすべてのセキュリティプリンシパル（ユーザー、グループ、サービスプリンシパル）に適用されますが、拒否の割り当てから除外するアクションとセキュリティプリンシパルを定義可能です（後述）。

以下気になったポイントです。
## 拒否の割り当てからの除外
- Blueprintsでは除外可能なセキュリティプリンシパルは最大5つまでに制限されていましたが、デプロイスタックでは6つ以上の除外指定も可能でした。Blueprintsで除外を設計する際にはセキュリティグループを除外するように設計することで6つ以上のセキュリティプリンシパルを除外する対応が必要でしたが、この点は不要なようです（最大数は未確認）。
- デプロイスタックで除外したセキュリティプリンシパルを確認するとセキュリティグループとサービスプリンシパルが表示されませんでした。恐らく現段階での不具合と思われますが、除外しているセキュリティプリンシパルすべてを確認するには、拒否の割り当てを設定したリソースのIAMを確認する必要があります。
  - **デプロイスタックの拒否の割り当て除外画面**
  2行目と5行目に空白行あり。
  ![ds_exclueded_01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/481267/e5d0ac74-9f72-78c9-ac83-7b5d0669a8ab.png)
  - **リソースのIAMにおける拒否の割り当て画面**
  上図の2行目と5行目に対応するプリンシパルも表示される。
  ![ds_exclueded_02.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/481267/4ed874ec-689e-ff26-0cce-adf97799c496.png)

# まとめ
パブリックプレビューが開始されたAzureデプロイスタックを試しました。
Azureポータルからの操作は限定的ですが、IaCでデプロイした環境をポータルから確認し、拒否の割り当てを組み合わせることでIaC外からの変更を防ぐことができます。
GAまでにさらに使い勝手が上がることを期待したいところです。

また、現在既知の不具合もありますので、こちらのMSのドキュメントを参照して使用しましょう。
- MSドキュメント
[Bicepのドキュメント(デプロイスタック)](https://learn.microsoft.com/ja-jp/azure/azure-resource-manager/bicep/deployment-stacks?tabs=azure-powershell)