その2からかなり時間が空いていますが今回はオートスケールについてとなります。

オートスケールを使用する意味

そもそもWVDを使用する要件のうちの一つに使用コストを下げたい、というものがあります。
ただしWVDはAzure上の仮想マシンとなりますのでマシン起動している限り費用が発生、
起動したままだと地味に物理構成より費用がかかる場合もあります。

なのでユーザ接続が少ない時間には仮想マシンの起動台数を抑え、
使用していない端末の起動を減らして費用を抑えるということを実現するため
オートスケールを使用します。
※WVDのオートスケールはWVD用の仮想マシン自体は作成しておく必要があります。
　そのため、WVD用仮想マシンのランニング費用は抑えられますが、ディスクの費用についてはWVD用仮想マシン作成台数に比例します。

オートスケールを利用する条件

オートスケールを使用する方式はスクリプト、またはAutomationアカウントを使用する方法の2種類が
あります。
ですがどちらの方式を取る場合に関しましても、

「WVDのホストプールとWVDの仮想マシンが同じテナントにある」

ことが条件となります。
サービスプリンシパルを使用して認証を行う関係上、テナントを跨ぐと権限がつけられないということが
原因となりますので構築時はお気をつけください。

それ以外の条件は以下となります。
●Automation使用時
　・AzureADへアクセスできる権限があること（アカウント作成時のみ）
　・動作させるアカウントにsubscription管理者の権限があること

●スクリプト使用時
　・動作させるAzureADへアクセスできる権限があること
　・動作させるアカウントにsubscription管理者の権限があること
　・スクリプトを実行するためのマシン（物理 or AzureVM）があること

オートスケールの設定方法

こちらにつきましては記事が長くなりますので一旦割愛させていただきます。
スクリプトに関しましてはGitHubに、Automationに関しましては
マイクロソフトに記載がありますのでそちらを参考に設定することをお勧めします。

GitHub（スクリプト）：
https://github.com/Azure/RDS-Templates
Microsoft（Automation）：
https://docs.microsoft.com/ja-jp/azure/virtual-desktop/set-up-scaling-script

オートスケールの動作について

オートスケールの動作は基本的に。

・オフピーク時にはx台起動
・ユーザセッションが増えた場合は端末を追加で起動

この動作が基本となっています。
ただしこの情報だけでは

・何をトリガーにして追加起動するのか
・コアタイムとオフピークでの違いは何があるのか
・そもそもスクリプトとAutomationの違いはなにがあるのか

ここらへんがわからなかったので調べてみた結果、以下のようです。

Automationでの動作
　使用機能
　　　Automationアカウント
　　　Logic Apps
　セッション分散条件
　　　Set-RdsHostPoolで設定した値をそのまま踏襲
　ジョブの動作

		制限
		1CPU当たりxセッション	1マシン当たりxセッション
オフピーク	拡張条件	拡張なし(*1)	セッション空き-1
	縮退条件	特になし(*1)(*2)	全ユーザセッション切断(*3)(*4)
コアタイム	拡張条件	セッション制限値(*5)	拡張なし
	縮退条件	縮退なし	縮退なし

スクリプトでの動作
　使用機能
　　　AzurePowerShell（要実行用マシン）
　セッション分散条件
　　　Config.jsonに記載した動作
　　　　　※オフピーク/コアタイムで分散方式（BreadthFirst/DepthFirst）の変更が可能
　ジョブの動作

		制限
		1CPU当たりxセッション	1マシン当たりxセッション
オフピーク	拡張条件	拡張なし	拡張なし
	縮退条件	特になし(*2)	特になし(*2)
コアタイム	拡張条件	セッション制限値(*5)	拡張なし
	縮退条件	縮退なし	縮退なし

*1.マシン当たりの設定が優先される
*2.ジョブ実行で縮退
*3.2回めのジョブ実行時
*4.ジョブ実行時、変数に異常値が代入され、以後の処理停止
*5.CPU当たりの設定が優先される

出来ることと出来ないことのまとめ

結果Automationとスクリプトにて、それぞれでしか行えない処理としては以下となります。

Automationでの動作
　・オフピーク時にセッション制限での拡張処理が可能
　　ただし縮退処理時に変数に異常値が入り、その後の処理が動作しなくなる。
　　※スクリプト書き換えで対応できるかもしれませんが当方はそこまで調べていません。

スクリプトでの動作
　・オフピーク/コアタイムでのマシン接続分散方式（BreadthFirst/DepthFirst）の変更が可能
　・両方で同じ分散方式は取れない

　上記結果により、ユーザ数でのセッション制限を行う場合はスクリプト
　行わない場合はAutomationの方式がいいと考えます。

なおセッション制限を行う場合、オフピーク時には接続ユーザ数が固定、
コアタイム時にもCPU当たりのセッション数とユーザ数の制限値を同じにした場合は
追加接続ができるようになるまで時間がかかるため、その制限値については
要件やユーザの接続傾向などを確認しながら設定を行う必要があるでしょう。

費用面としてはFSLogix用のファイルサーバ or ADConnect用のサーバを
Azure上に立てる場合を除き、Automationのほうが安くなります。
（1ヶ月のアクション実行回数が約3000回のため）