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