Choosing Desktop View or Application View

The determination for choosing an application view or desktop view has no impact on performance or cost. Only one view is accessible at any given time per AppStream 2.0 fleet. You can change the Stream view option. Plan this change during off-peak business hours, as changing the stream view requires a restart of the fleet.

There is no single best practice for stream view. The impact of stream view options is summarized through the following:

Desktop View

For use cases where all the user’s workflow is performed in session, Desktop View simplifies the user experience by keeping all applications focused in one environment. Desktop View can give a more consistent user experience for deployments of more than 3-5 applications that require integration with the operating system (OS). Desktop View is effective when maintaining two separate and distinct environments. For example, a user can have concurrent access to both a production and pre-production desktop environment to validate changes to layout, configuration, and application access.

AppStream 2.0 Usage Reports creates a daily application report for Desktop View. The resulting output for application is simply ‘desktop’, mapping directly to the AppStream 2.0 session. For more information, refer to the Monitoring user usage section of this document.

Applications Only view

The Applications Only view is also effective when the AppStream 2.0 stack is intended to deliver a few applications that are intermittently required. In kiosk environments, a securely locked down delivery of applications is delivered through Application View. With Application View, AppStream 2.0 replaces the default Windows shell with a custom shell. This custom shell presents only running applications, minimizing the attack surface of the OS.

For use cases where AppStream 2.0 is used to augment an existing organization’s desktop environment, the Applications Only view is preferred. Deploy the AppStream 2.0 Windows Client in native application mode to minimize user confusion by allowing full use of keyboard shortcuts.

Amazon 2.0 Usage Reports creates a daily application report for application view. For more granular reporting of application and run use, consider a third-party solution to report at the operating system level. You can use Microsoft AppLocker in reporting mode, or consider solutions that are available in the AWS Marketplace, such as Liquidware’s Stratusphere UX.

AWS Identity and Access Management role configuration

If a workload requires the AppStream 2.0 end users to access other AWS services from within their session, it is a best practice to delegate access through the use of AWS Identity and Access Management (IAM) roles. IAM roles can be directly attached to your end user’s session through the assignment at the fleet level. For additional best practices when using IAM roles with AppStream 2.0, see this section of the administrator guide.

Using static credentials

Some workloads may require static inputs for the IAM access keys opposed to inheriting them from the attached role. There are two methods for receiving these credentials. The first method involves storing the access keys within an AWS service and then giving your end users explicit IAM access to pull that specific value from the service. Two examples of access keys storage mechanisms is using AWS Secrets Manager or AWS SSM Parameter Store. The second method is to use the AppStream 2.0 credential provider to access the attached role’s access keys. This can be done by invoking the credential provider and parsing the output for your access key and secret key. An example of how to perform this action within PowerShell follows.

$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

Protecting your AppStream 2.0 S3 bucket

If your AppStream 2.0 workload is configured with Home Folder and/or Application Persistence, then it is a best practice to protect the Amazon S3 bucket that the persistent data is being stored in from unauthorized access or accidental deletion. The first layer of protection is to add an Amazon S3 bucket policy to prevent accidental deletion of the bucket. The second layer of protection is to add a bucket policy that aligns to the principle of least privilege. Aligning to the principle can be done by only allowing bucket access to the necessary parties.