本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
在多工作階段機群上使用工作階段指令碼時，還有其他要求和考量，以確保最佳效能和安全性。
要求
在單一工作階段機群上，對於指定的執行個體，SessionStart 和 SessionTermination 掛鉤保證只會執行一次。這是因為 1：1 會將工作階段映射到執行個體。使用多工作階段機群時，會有一個工作階段到執行個體的 N：M 映射，其中每個工作階段都會執行自己的 SessionStart 和 SessionTermination hook。這表示 SessionStart 和 SessionTermination 掛鉤可在指定的執行個體上執行多次，並以許多不同的順序執行。為了獲得最佳體驗，在多工作階段機群上使用時，工作階段指令碼應該符合以下條件：
-
指令碼具有等冪性。
當動作已執行時，指令碼應處理相同執行個體上的多個執行，並具有正常的處理。
-
指令碼是獨立的。
因為指令碼會執行每個工作階段，如果一個工作階段正在執行 SessionTermination，而另一個工作階段正在執行 SessionStart，則不應互相干擾，或與其他工作階段的體驗相干。
-
指令碼具有效能。
在多工作階段執行個體上，可以同時佈建多個工作階段。這表示工作階段指令碼可以有多個並行執行。指令碼應該有效率、不會耗用過多的資源，也不會影響其他使用者在執行個體上的體驗或工作階段的穩定性。
許多這些需求都可以透過將工作階段指令碼邏輯專注於執行指令碼的特定使用者工作階段來滿足。
安全考量
AppStream 2.0 映像不應設定為允許任何使用者寫入工作階段指令碼檔案。這為惡意使用者引入了關鍵的攻擊向量，他們可以在其中修改指令碼檔案。這些檔案接著可以做為 SYSTEM 或其他使用者執行，視您的組態而定。
重要
您有責任確保您的 AppStream 2.0 映像設定安全。這對於多工作階段執行個體特別重要，其中多個使用者使用相同的執行個體。如果影像未安全設定，則該執行個體的所有使用者都會有安全風險。
對於您的映像和工作階段指令碼檔案，應該如下：
-
使用者沒有修改工作階段指令碼檔案的許可。
-
使用者沒有修改工作階段指令碼 config.json 的許可。映像上的預設行為限制對管理員的存取。
工作階段指令碼可執行檔應存放在安全的位置，在執行時間可安全地進行修改。
如果服務偵測到工作階段指令碼可執行檔已修改，則該執行個體上該掛鉤的任何後續執行將會失敗，並將日誌檔案上傳到 Amazon S3 （如果已啟用 Amazon S3 記錄），而且您會看到下列訊息：
工作階段指令碼未執行，因為執行個體佈建後已修改可執行檔。基於安全考量，已略過執行。
如果您的使用案例需要在執行時間修改工作階段指令碼可執行檔 （例如，如果您指向執行時間自動更新程序修改的 EXE 檔案），則上述檢查將會失敗。在此情況下，請使用指令碼將執行重新導向至修改後的可執行檔。當服務執行安全性檢查時，讓指令碼在執行時間保持不變。
如果您的工作階段指令碼檔案過大 （超過 100 MB)，這可能會導致執行個體和工作階段佈建延遲，而安全檢查需要額外時間 （取決於執行個體類型和可用資源）。如果您的使用案例需要大型工作階段指令碼，請考慮使用較小的指令碼來重新導向執行。這將改善執行個體和工作階段佈建體驗。
請注意，服務只會檢查工作階段指令碼 config.json 中定義的可執行檔，而這只是備用/最佳工作量機制。您有責任確保工作階段指令碼可執行檔中的所有程式碼路徑都是安全的，且無法由最終使用者修改。
