セッションスクリプトを使用して AppStream 2.0 ユーザーのストリーミングエクスペリエンスを管理する - Amazon AppStream 2.0
ストリーミングセッションの開始前にスクリプトを実行するストリーミングセッションの終了後にスクリプトを実行するセッションスクリプトを作成および指定するセッションスクリプト設定ファイルWindows PowerShell ファイルの使用セッションスクリプト出力のログ記録セッションスクリプトでストレージコネクタを使用するセッションスクリプトログに対して Amazon S3 バケットストレージを有効にするマルチセッションフリートでセッションスクリプトを使用する

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

セッションスクリプトを使用して AppStream 2.0 ユーザーのストリーミングエクスペリエンスを管理する

AppStream 2.0 には、インスタンスセッションスクリプトが用意されています。ユーザーのストリーミングセッションで特定のイベントが発生したときに、これらのスクリプトを使用して独自のカスタムスクリプトを実行できます。例えば、ユーザーのストリーミングセッションが開始される前に、カスタムスクリプトを使用して AppStream 2.0 環境を準備できます。ユーザーがストリーミングセッションを完了した後に、カスタムスクリプトを使用してストリーミングインスタンスをクリーンアップすることもできます。

セッションスクリプトは AppStream 2.0 イメージ内で指定されます。これらのスクリプトはユーザーコンテキストまたはシステムコンテキスト内で実行されます。セッションスクリプトが情報、エラー、またはデバッグメッセージの書き込みに標準出力を使用する場合は、オプションで、それらを Amazon Web Services アカウント内の Amazon S3 バケットに保存することができます。

ストリーミングセッションの開始前にスクリプトを実行する

ユーザーのアプリケーションが起動されてストリーミングセッションが開始されるまでに最大 60 秒間実行されるようにスクリプトを設定できます。これにより、ユーザーがアプリケーションのストリーミングを開始する前に AppStream 2.0 環境をカスタマイズできます。セッションスクリプトが実行されると、読み込みスピナーがユーザーに表示されます。スクリプトが正常に完了するか、最大待機時間が経過すると、ユーザーのストリーミングセッションが開始されます。スクリプトが正常に完了しなかった場合は、エラーメッセージがユーザーに表示されます。ただし、ユーザーはストリーミングセッションの使用を禁止されません。

Windows インスタンスでファイル名を指定するときは、ダブルバックスラッシュを使用する必要があります。例えば、次のようになります。

C:\\Scripts\\Myscript.bat

二重のバックスラッシュを使用しないと、.json ファイル形式が正しくないことを示すエラーが表示されます。

注記

スクリプトは正常に完了したら、値 0 を返します。スクリプトが 0, AppStream 2.0 以外の値を返すと、ユーザーにエラーメッセージが表示されます。

ストリーミングセッションの開始前にスクリプトを実行し、 AppStream 2.0 動的アプリケーションフレームワークが有効になっていない場合、次のプロセスが発生します。

AppStream 2.0 workflow diagram showing connection, application selection, and session launch steps.

  1. ユーザーは、ドメインに参加していない AppStream 2.0 フリートインスタンスに接続します。この接続には、以下のいずれかのアクセス方法を使用します。

    • AppStream 2.0 ユーザープール

    • SAML 2.0

    • AppStream 2.0 API

  2. アプリケーションカタログが AppStream 2.0 ポータルに表示され、ユーザーは起動するアプリケーションを選択します。

  3. 以下のいずれかのプロセスが発生します。

    • ユーザーに対してアプリケーション設定の永続化が有効になっている場合は、ユーザーのカスタマイズ内容と Windows の設定内容を保存しているアプリケーション設定の Virtual Hard Disk (VHD) ファイルがダウンロードされてマウントされます。この場合は、Windows ユーザーのログインが必要です。

      アプリケーション設定の永続化については、AppStream 2.0 ユーザーのアプリケーション設定の永続化を有効にする を参照してください。

    • アプリケーション設定の永続化が有効になっていない場合、Windows ユーザーはすでにログインしています。

  4. セッションスクリプトが起動されます。ユーザーに対して永続的ストレージが有効になっている場合は、ストレージコネクタのマウントも開始されます。永続的ストレージについては、 AppStream 2.0 ユーザーの永続的ストレージを有効にして管理する を参照してください。

    注記

    ストリーミングセッションを開始するためにストレージコネクタのマウントを完了する必要はありません。セッションスクリプトが完了したとき、まだストレージコネクタのマウントが完了していなくても、ストリーミングセッションは開始されます。

    ストレージコネクタのマウント状況のモニタリングについては、セッションスクリプトでストレージコネクタを使用する を参照してください。

  5. セッションスクリプトは完了するかタイムアウトします。

  6. ユーザーのストリーミングセッションが開始されます。

  7. ユーザーが選択したアプリケーションが起動されます。

AppStream 2.0 動的アプリケーションフレームワークの詳細については、「」を参照してくださいAppStream 2.0 動的アプリケーションフレームワークを使用して動的アプリケーションプロバイダーを構築する。

ストリーミングセッションの開始前にスクリプトを実行し、 AppStream 2.0 動的アプリケーションフレームワークが有効になっている場合、次のプロセスが発生します。

AppStream 2.0 workflow from user login to application launch, including SAML authentication and session scripts.

  1. ユーザーは組織の SAML 2.0 アプリケーションポータルにアクセスし、 AppStream 2.0 スタックを選択します。

  2. ドメインに参加している AppStream 2.0 フリートインスタンスに接続します。

  3. ユーザーに対してアプリケーション設定の永続化が有効になっている場合は、ユーザーのカスタマイズ内容と Windows の設定内容を保存しているアプリケーション設定の VHD ファイルがダウンロードされてマウントされます。

  4. Windows ユーザーのログオンが発生します。

  5. アプリケーションカタログが AppStream 2.0 ポータルに表示され、ユーザーは起動するアプリケーションを選択します。

  6. セッションスクリプトが起動されます。ユーザーに対して永続的ストレージが有効になっている場合は、ストレージコネクタのマウントも開始されます。

    注記

    ストリーミングセッションを開始するためにストレージコネクタのマウントを完了する必要はありません。セッションスクリプトが完了したとき、まだストレージコネクタのマウントが完了していなくても、ストリーミングセッションは開始されます。

    ストレージコネクタのマウント状況のモニタリングについては、セッションスクリプトでストレージコネクタを使用する を参照してください。

  7. セッションスクリプトは完了するかタイムアウトします。

  8. ユーザーのストリーミングセッションが開始されます。

  9. ユーザーが選択したアプリケーションが起動されます。

ストリーミングセッションの終了後にスクリプトを実行する

ユーザーのストリーミングセッションの終了後にスクリプトを実行するように設定することもできます。例えば、ユーザーが AppStream 2.0 ツールバーからセッション終了を選択した場合や、セッションに許容される最大時間に達したときにスクリプトを実行できます。これらのセッションスクリプトを使用して、ストリーミングインスタンスが終了する前に AppStream 2.0 環境をクリーンアップすることもできます。たとえば、スクリプトを使用してファイルロックを解除したり、ログファイルをアップロードしたりできます。ストリーミングセッションの終了後にスクリプトを実行すると、以下のプロセスが発生します。

Flowchart showing AppStream 2.0 session termination process with scripts and storage actions.

  1. ユーザーの AppStream 2.0 ストリーミングセッションが終了します。

  2. セッション終了スクリプトが起動されます。

  3. セッション終了スクリプトが完了またはタイムアウトします。

  4. Windows ユーザーのログアウトが発生します。

  5. 以下のうち該当する一方が実行されるか、両方が同時に実行されます。

    • ユーザーに対してアプリケーション設定の永続化が有効になっている場合、ユーザーのカスタマイズ内容と Windows 設定内容を保存しているアプリケーション設定の VHD ファイルがマウント解除され、アカウントの Amazon S3 バケットにアップロードされます。

    • ユーザーに対して永続的ストレージが有効になっている場合、ストレージコネクタは最後の同期を完了し、マウント解除されます。

  6. フリートインスタンスは削除されます。

セッションスクリプトを作成および指定する

常時オン、オンデマンド、および Elastic フリートのセッションスクリプトを設定および指定できます。

常時オンおよびオンデマンドフリートのセッションスクリプトを設定および指定するには

  1. https://console.aws.amazon.com/appstream2 で AppStream 2.0 コンソールを開きます。

  2. ナビゲーションペインで、[Images (イメージ)]、[Image Builder (イメージビルダー)] の順に選択します。

  3. [実行中] 状態のイメージビルダーを選択してから、[接続] を選択します。

  4. プロンプトが表示されたら、[管理者] を選択します。

  5. C:\AppStream\SessionScripts に移動し、config.json 設定ファイルを開きます。

    セッションスクリプトパラメータについては、セッションスクリプト設定ファイル を参照してください。

  6. 変更が終了したら、config.json ファイルを保存して閉じます。

  7. Image Builder デスクトップから、Image Assistant を開きます。

  8. (オプション) イメージに含める他のアプリケーションを指定します。

  9. Image Assistant で、必要な手順に従って、イメージの作成を完了します。

    セッションスクリプトの設定の検証でエラーになる場合 (.json ファイルの形式が正しくない場合など)、[Disconnect and create image (イメージの接続解除と作成)] を選択してイメージを作成すると、通知されます。

    注記

    Linux ベースの Image Builder 向けのセッションスクリプト設定ファイルを見つけるには、/opt/appstream/SessionScripts/config.json に移動します。

Elastic フリートのセッションスクリプトを設定および指定するには

  1. セッションスクリプトと config.json ファイルを含む zip ファイルを作成します。スクリプトファイルは、次の場所にコピーされます。config.json には、これらの場所を使用する必要があります。

    • Windows の場合は C:\AppStream\SessionScripts\SessionScript を使用します。

    • Linux の場合は /opt/appstream/SessionScripts/SessionScript を使用します。

    注記

    セッションスクリプトファイルを実行するには、.zip ファイルに、含まれているフォルダではなくセッションスクリプトと config.json ファイルのみが含まれていることを確認します。詳細については、「セッションスクリプト設定ファイル」を参照してください。

  2. ZIP ファイルを、アカウントの Amazon S3 バケットにアップロードします。

    注記

    VPC は Amazon S3 バケットに対するアクセス権を提供する必要があります。詳細については、「 AppStream 2.0 機能での Amazon S3 VPC エンドポイントの使用」を参照してください。

    同じ に S3 バケットと AppStream 2.0 フリートが必要です AWS リージョン。

    Amazon S3 バケット内のセッションスクリプトオブジェクトで S3:GetObject アクションを実行するための IAM 許可が必要です。Amazon S3 バケットでのセッションスクリプトの保存に関する詳細については、「S3 バケットにアプリケーションアイコン、セットアップスクリプト、セッションスクリプト、および VHD を保存する」を参照してください。

  3. https://console.aws.amazon.com/appstream2 で AppStream 2.0 コンソールを開きます。

  4. ナビゲーションペインの [Fleets] を選択します。

  5. 更新する Elastic フリートを選択し、[View Details] (詳細を表示) を選択します。

  6. [Session scripts settings] (セッションスクリプトの設定) タブで、[編集] を選択します。

  7. [Session scripts object in S3] (S3 のセッションスクリプトオブジェクト) で、セットアップスクリプトオブジェクトを表す S3 URI を入力するか、[Browse S3] (S3 を参照する) を選択して S3 バケットに移動し、セットアップスクリプトオブジェクトを見つけます。

  8. 変更が完了したら、[Save Changes] (変更を保存) を選択します。

  9. この時点で、セッションスクリプトは起動されたすべてのフリートインスタンスで使用できます。

    注記

    新しい Elastic フリートを作成するときに、セッションスクリプトを設定することもできます。

セッションスクリプト設定ファイル

Windows インスタンスでセッションスクリプト設定ファイルを見つけるには、C:\AppStreamSessionScripts\config.json に移動します。Linux インスタンスで、/opt/appstream/SessionScripts/config.json に移動します。ファイル形式は次のとおりです。

注記

設定ファイルは .json 形式です。このファイルに入力したテキストが有効な .json 形式であることを確認します。

{
  "SessionStart": {
    "executables": [
      {
        "context": "system",
        "filename": "",
        "arguments": "",
        "s3LogEnabled": true
      },
      {
        "context": "user",
        "filename": "",
        "arguments": "",
        "s3LogEnabled": true
      }
    ],
    "waitingTime": 30
  },
  "SessionTermination": {
    "executables": [
      {
        "context": "system",
        "filename": "",
        "arguments": "",
        "s3LogEnabled": true
      },
      {
        "context": "user",
        "filename": "",
        "arguments": "",
        "s3LogEnabled": true
      }
    ],
    "waitingTime": 30
  }
}

セッションスクリプト設定ファイルでは、以下のパラメータを使用できます。

SessionStart/SessionTermination

オブジェクトの名前に基づいて該当するセッションイベントで実行するセッションスクリプト。

型: 文字列

必須: いいえ

使用できる値: SessionStart、SessionTermination

WaitingTime

セッションスクリプトの最大期間 (秒単位)。

タイプ: 整数

必須: いいえ

制約: 最大期間は 60 秒です。セッションスクリプトは、この期間内に完了しない場合、停止されます。スクリプトを引き続き実行する必要がある場合は、別のプロセスとして起動してください。

Executables

実行するセッションスクリプトの詳細。

型: 文字列

必須: はい

制約: セッションイベントごとに実行できるスクリプトの最大数は 2 です (1 つはユーザーコンテキスト用、もう 1 つはシステムコンテキスト用)。

Context

セッションスクリプトを実行するコンテキスト。

型: 文字列

必須: はい

使用できる値: user、system

Filename

実行するセッションスクリプトへの完全パス。このパラメータを指定しない場合、セッションスクリプトは実行されません。

型: 文字列

必須: いいえ

制約: ファイル名と完全パスの最大長は 1,000 文字です。

使用できる値： .bat、.exe、 .sh

注記

Windows PowerShell ファイルを使用することもできます。詳細については、「Windows PowerShell ファイルの使用」を参照してください。

引数

セッションスクリプトまたは実行可能ファイルの引数。

型: 文字列

必須: いいえ

長さの制限: 最大長は 1,000 文字です。

S3LogEnabled

このパラメータの値が True に設定されていると、セッションスクリプトによって作成されたログを保存するための S3 バケットが Amazon Web Services アカウント内に作成されます。デフォルトでは、この値は True に設定されます。詳細については、このトピックの後半の「セッションスクリプト出力のログ記録」セクションを参照してください。

タイプ: ブール

必須: いいえ

使用できる値: True、False

Windows PowerShell ファイルの使用

Windows PowerShell ファイルを使用するには、 filenameパラメータで PowerShell ファイルへのフルパスを指定します。

"filename": 
"C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe",

次に、arguments パラメータにセッションスクリプトを指定します。

"arguments": "-File \"C:\\path\\to\\session\\script.ps1\"",

最後に、 PowerShell 実行ポリシーで PowerShell ファイルの実行が許可されていることを確認します。

セッションスクリプト出力のログ記録

設定ファイルでこのオプションを有効にすると、 AppStream 2.0 は標準出力に書き込まれたセッションスクリプトからの出力を自動的にキャプチャします。この出力はアカウントの Amazon S3 バケットにアップロードされます。トラブルシューティングやデバッグの目的でログファイルを確認できます。

注記

ログファイルは、セッションスクリプトが値を返したときか、WaitingTime に設定された時間を経過したときの、どちらか早いほうでアップロードされます。

セッションスクリプトでストレージコネクタを使用する

AppStream 2.0 ストレージコネクタを有効にすると、セッション開始スクリプトの実行時にマウントが開始されます。スクリプトがマウントされているストレージコネクタに依存している場合は、コネクタが利用可能になるまで待機できます。 AppStream 2.0 は Windows インスタンスの Windows レジストリ内のストレージコネクタのマウントステータスを次のキーで維持します。

HKEY_LOCAL_MACHINE\SOFTWARE\AmazonAppStream\\Storage\<provided user name>\<Storage connector>

レジストリキーの値は以下のとおりです。

  • 提供されたユーザー名 — アクセスモードで提供されたユーザー ID。アクセスモードと各モードの値は以下のとおりです。

    • ユーザープール — ユーザーの E メールアドレス。

    • ストリーミング URL — ユーザー ID。

    • SAML — NameID。ユーザー名にスラッシュ (ドメインユーザーの SAM などAccountName) が含まれている場合、スラッシュは「-」文字に置き換えられます。

  • ストレージコネクタ — ユーザーに対して有効になっている永続的ストレージオプションに対応するコネクタ。ストレージコネクタの値は以下のとおりです。

    • HomeFolder

    • GoogleDrive

    • OneDrive

各ストレージコネクタレジストリキーには DWORD MountStatus 値が含まれています。次の表に、 の可能な値を示しますMountStatus。

注記

これらのレジストリキーを表示するには、イメージに Microsoft .NET Framework バージョン 4.7.2 以降がインストールされている必要があります。

値 説明
0

ストレージコネクタはこのユーザーに対して有効になっていない
1

ストレージコネクタのマウントが進行中
2

ストレージコネクタのマウントに成功した
3

ストレージコネクタのマウントに失敗した
4

ストレージコネクタのマウントは有効ですが、まだマウントされていません

Linux インスタンスでは、ファイル ~/.config//-status の appstream_home_folder_mount_status appstream-home-folderappstream-home-folder-mountの値を調べることで、ホームフォルダのマウントステータスを確認できます。

値 説明
True

ホームフォルダが正常にマウントされています
False ホームフォルダがまだマウントされていません

セッションスクリプトログに対して Amazon S3 バケットストレージを有効にする

セッションスクリプト設定で Amazon S3 ログ記録を有効にすると、 AppStream はセッションスクリプトからの標準出力をキャプチャします。出力は、Amazon Web Services アカウント内の S3 バケットに定期的にアップロードされます。 AppStream 2.0 は、各 AWS リージョンについて、アカウントとリージョンに固有のバケットをアカウントに作成します。

これらの S3 バケットを管理するための設定タスクを実行する必要はありません。これらは AppStream 2.0 サービスによって完全に管理されます。各バケットに保存されているログファイルは、転送時には Amazon S3 の SSL エンドポイントを使用して暗号化され、保管時には Amazon S3 管理の暗号化キーを使用して暗号化されます。バケットは、以下にあるような特定の形式で命名されます。

appstream-logs-region-code-account-id-without-hyphens-random-identifier
region-code

これは、セッションスクリプトログに対して Amazon S3 バケットストレージを有効にしてスタックが作成される AWS リージョンコードです。

account-id-without-hyphens

ご自身の Amazon Web Services アカウント ID ランダムな ID は、そのリージョン内のその他バケットとの競合が発生しないことを確実にします。バケット名の最初の部分 appstream-logs は、複数のアカウントやリージョンにまたがる場合でも変更されません。

例えば、アカウント番号 123456789012,2.0 の米国西部 (オレゴン) リージョン (us-west- AppStream 2) のイメージでセッションスクリプトを指定すると、表示された名前でそのリージョンのアカウント内に Amazon S3 バケットが作成されます。適切なアクセス許可を持つ管理者のみが、このバケットを削除できます。

appstream-logs-us-west-2-1234567890123-abcdefg

セッションスクリプトを無効にしても、S3 バケットに保存されているログファイルは削除されません。ログファイルを完全に削除するには、Amazon S3 コンソールまたは API. AppStream 2.0 を使用して、適切なアクセス許可を持つ別の管理者が、バケットの誤った削除を防止するバケットポリシーを追加する必要があります。詳細については、Amazon AppStream 2.0 の Identity and Access Management の「アプリケーション設定の永続化用の IAM ポリシーと Amazon S3 バケット」を参照してください。

セッションスクリプトを有効にすると、開始されるストリーミングセッションごとに固有のフォルダが作成されます。

アカウントの S3 バケットでログファイルが保存されているフォルダへのパスは、以下の構造になります。

bucket-name/stack-name/fleet-name/access-mode/user-id-SHA-256-hash/session-id/SessionScriptsLogs/session-event
bucket-name

セッションスクリプトが保存されている S3 バケットの名前。名前の形式については、このセクションで先ほど説明しました。

stack-name

セッションが発生したスタックの名前。

fleet-name

セッションスクリプトが実行されているフリートの名前。

access-mode

ユーザーの ID メソッド: AppStream 2.0 API custom または CLI の場合は 、SAML federatedの場合は 、ユーザープール内のユーザーuserpoolの場合は 。

user-id-SHA-256-hash

ユーザー固有のフォルダ名。この名前は、ユーザー識別子から生成された小文字の SHA-256 ハッシュ 16 進数文字列を使用して作成されます。

session-id

ユーザーのストリーミングセッションの識別子。ユーザーの各ストリーミングセッションでは一意の ID が生成されます。

session-event

セッションスクリプトログを生成したイベント。イベント値は SessionStart と SessionTermination です。

以下のフォルダ構造の例は、test-stack と test-fleet から始まるストリーミングセッションに当てはまります。セッションではtestuser@mydomain.com、 の ID からのユーザー AWS アカウント ID の API と123456789012、test-stack米国西部 (オレゴン) リージョン (米国西部-2) の設定グループを使用します。

appstream-logs-us-west-2-1234567890123-abcdefg/test-stack/test-fleet/custom/a0bcb1da11f480d9b5b3e90f91243143eac04cfccfbdc777e740fab628a1cd13/05yd1391-4805-3da6-f498-76f5x6746016/SessionScriptsLogs/SessionStart/

このフォルダ構造の例には、ユーザーコンテキストセッション開始スクリプト用の 1 つのログファイルと、必要に応じてシステムコンテキストセッション開始スクリプト用の 1 つのログファイルが含まれています。

マルチセッションフリートでセッションスクリプトを使用する

マルチセッションフリートでセッションスクリプトを使用する場合、最適なパフォーマンスとセキュリティを確保するためのその他の要件と考慮事項があります。

要件

単一セッションフリートでは、特定のインスタンスに対して、 SessionStart および SessionTerminationフックが 1 回のみ実行されることが保証されます。これは、セッションとインスタンス間の 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 で定義されている実行可能ファイルのみをチェックしており、これはフォールバック/ベストエフォートメカニズムにすぎないことに注意してください。セッションスクリプト実行可能ファイル内のすべてのコードパスが安全で、エンドユーザーが変更できないようにするのはお客様の責任です。