翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
デスクトップビューまたはアプリケーションビューの選択
アプリケーションビューとデスクトップビューのどちらを選択しても、パフォーマンスやコストには影響しません。AppStream 2.0 フリート 1 つにつき、一度にアクセスできるビューは 1 つだけです。ストリームビューオプションは変更できます。ストリームビューを変更するにはフリートの再起動が必要なため、この変更はピーク以外の営業時間帯に計画してください。
ストリームビューのベストプラクティスは 1 つではありません。ストリームビューオプションの影響は、次のようにまとめられています。
-
管理者向けの使用状況レポート機能によるアプリケーション使用状況の詳細レポート
-
エンドユーザー向けの全体的なエクスペリエンスとワークフロー (例えば、全画面表示のデスクトップはユースケースのニーズに対応しているのか、それともアプリケーションを見るだけで十分なのか、など)。
デスクトップビュー
ユーザーのワークフローがすべてセッションで実行されるユースケースでは、デスクトップビューではすべてのアプリケーションを 1 つの環境に集中させることができるため、ユーザーエクスペリエンスが簡素化されます。デスクトップビューを使用すると、オペレーティングシステム (OS) との統合を必要とするアプリケーションを 3 ~ 5 個以上でプロイしても、より一貫したユーザーエクスペリエンスを実現できます。デスクトップビューは、2 つの異なる環境を管理する場合に効果的です。例えば、ユーザーは本番環境と本番前のデスクトップ環境の両方に同時にアクセスして、レイアウト、構成、およびアプリケーションアクセスの変更を検証できます。
AppStream 2.0 使用状況レポートは、デスクトップビューの毎日のアプリケーションレポートを作成します。生成されるアプリケーションの出力は単に「デスクトップ」で、AppStream 2.0 セッションに直接マッピングされます。詳細については、このドキュメントの「ユーザー使用状況のモニタリング」セクションを参照してください。
アプリケーション専用ビュー
アプリケーション専用ビューは、AppStream 2.0 スタックが断続的に必要とされるいくつかのアプリケーションを提供することを目的としている場合にも効果的です。キオスク環境では、安全にロックダウンされたアプリケーションのデリバリーがアプリケーションビューを通じて配信されます。アプリケーションビューでは、AppStream 2.0 はデフォルトの Windows シェルをカスタムシェルに置き換えます。このカスタムシェルは実行中のアプリケーションのみを表示し、OS のアタックサーフェス領域を最小限に抑えます。
AppStream 2.0 を使用して既存の組織のデスクトップ環境を強化するユースケースでは、アプリケーション専用ビューが推奨されます。AppStream 2.0 Windows Client をネイティブアプリケーションモードでデプロイし、キーボードショートカットをフルに使用できるようにすることでユーザーの混乱を最小限に抑えます。
AppStream 2.0 使用状況レポートは、アプリケーションビューの毎日のアプリケーションレポートを作成します。アプリケーションと実行の使用状況をより詳細に報告するには、オペレーティングシステムレベルで報告するサードパーティのソリューションを検討してください。Microsoft AppLocker をレポートモードで使用するか、または Liquidware の Stratusphere UX
AWS Identity and Access Management ロールの設定
ワークロードで AppStream 2.0 のエンドユーザーがセッション内から他の AWS サービスにアクセスする必要がある場合、AWS Identity and Access Management(IAM) ロールを使用してアクセスを委任するのがベストプラクティスです。IAM ロールは、フリートレベルでの割り当てを通じてエンドユーザーのセッションに直接アタッチできます。AppStream 2.0 で IAM ロールを使用する際のその他のベストプラクティスについては、管理者ガイドのこのセクションを参照してください。
静的認証情報の使用
ワークロードによっては、IAM アクセスキーをアタッチされたロールから継承するのではなく、静的な入力が必要になる場合があります。これらの認証情報を受け取るには 2 つの方法があります。1 つ目の方法は、アクセスキーを AWS サービス内に保存し、そのサービスから特定の値を取得するための明示的な IAM アクセスをエンドユーザーに付与します。アクセスキーの保存メカニズムの 2 つの例では、AWS Secrets Manager または AWS SSM パラメータストアを使用します。2 つ目の方法は、AppStream 2.0 認証情報プロバイダーを使用して、アタッチされたロールのアクセスキーにアクセスすることです。これを行うには、認証情報プロバイダーを呼び出し、アクセスキーとシークレットキーの出力を解析します。PowerShell 内でこのアクションを実行する方法の例を以下に示します。
$CMD = 'C:\Program Files\Amazon\Photon\PhotonRoleCredentialProvider\PhotonRoleCredentialProvider.exe' $role = 'Machine' $output = & $CMD --role=$role $parsed = $output | ConvertFrom-Json $access_key = $parsed.AccessKeyId $secret_key = $parsed.SecretAccessKey $session_token = $parsed.SessionToken
AppStream 2.0 S3 バケットの保護
AppStream 2.0 ワークロードにホームフォルダまたはアプリケーション永続化が設定されている場合は、永続データが保存されている Amazon S3 バケットを不正アクセスや誤った削除から保護するのがベストプラクティスです。最初の保護レイヤーは、バケットが誤って削除されないように Amazon S3 バケットポリシーを追加することです。2 つ目の保護レイヤーは、最小権限の原則に沿ったバケットポリシーを追加することです。この原則に従うには、必要な関係者にのみバケットアクセスを許可する必要があります。