

# Security in Amazon WorkSpaces Applications
<a name="security"></a>

Cloud security at AWS is the highest priority. As an AWS customer, you benefit from a data center and network architecture that is built to meet the requirements of the most security-sensitive organizations.

Security is a shared responsibility between AWS and you. The [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/) describes this as security of the cloud and security in the cloud:
+ **Security of the cloud** – AWS is responsible for protecting the infrastructure that runs AWS services in the AWS Cloud. AWS also provides you with services that you can use securely. Third-party auditors regularly test and verify the effectiveness of our security as part of the [AWS Compliance Programs](https://aws.amazon.com/compliance/programs/). For information about the compliance programs that apply to WorkSpaces Applications, see [AWS Services in Scope by Compliance Program](https://aws.amazon.com/compliance/services-in-scope/).
+ **Security in the cloud** – Your responsibility is determined by the AWS service that you use. You are also responsible for other factors including the sensitivity of your data, your company’s requirements, and applicable laws and regulations 

This documentation helps you understand how to apply the shared responsibility model when using WorkSpaces Applications. It shows you how to configure WorkSpaces Applications to meet your security and compliance objectives. You also learn how to use other AWS services that help you to monitor and secure your WorkSpaces Applications resources.

**Topics**
+ [

# Data Protection in Amazon WorkSpaces Applications
](data-protection.md)
+ [

# Identity and Access Management for Amazon WorkSpaces Applications
](controlling-access.md)
+ [

# Logging and Monitoring in Amazon WorkSpaces Applications
](logging-monitoring-alerting.md)
+ [

# Compliance Validation for Amazon WorkSpaces Applications
](compliance-validation.md)
+ [

# Resilience in Amazon WorkSpaces Applications
](disaster-recovery-resiliency.md)
+ [

# Infrastructure Security in Amazon WorkSpaces Applications
](infrastructure-security.md)
+ [

# Security Groups in Amazon WorkSpaces Applications
](managing-network-security-groups.md)
+ [

# Update Management in Amazon WorkSpaces Applications
](update-management.md)
+ [

# Amazon WorkSpaces Applications Cross-Service Confused Deputy Prevention
](confused-deputy.md)
+ [

# Security Best Practices in Amazon WorkSpaces Applications
](security-best-practices.md)

# Data Protection in Amazon WorkSpaces Applications
<a name="data-protection"></a>

The AWS [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/) applies to data protection in Amazon WorkSpaces Applications. As described in this model, AWS is responsible for protecting the global infrastructure that runs all of the AWS Cloud. You are responsible for maintaining control over your content that is hosted on this infrastructure. This content includes the security configuration and management tasks for the AWS services that you use. For more information about data privacy, see the [Data Privacy FAQ](https://aws.amazon.com/compliance/data-privacy-faq). For information about data protection in Europe, see the [AWS Shared Responsibility Model and GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) blog post on the *AWS Security Blog*.

For data protection purposes, we recommend that you protect AWS account credentials and set up individual users with AWS Identity and Access Management (IAM). That way each user is given only the permissions necessary to fulfill their job duties. We also recommend that you secure your data in the following ways:
+ Use multi-factor authentication (MFA) with each account.
+ Use SSL/TLS to communicate with AWS resources. We recommend TLS 1.2.
+ Set up API and user activity logging with AWS CloudTrail.
+ Use AWS encryption solutions, along with all default security controls within AWS services.
+ Use advanced managed security services such as Amazon Macie, which assists in discovering and securing personal data that is stored in Amazon S3.
+ If you require FIPS 140-2 validated cryptographic modules when accessing AWS through a command line interface or an API, use a FIPS endpoint. For more information about the available FIPS endpoints, see [Federal Information Processing Standard (FIPS) 140-2](https://aws.amazon.com/compliance/fips/).

We strongly recommend that you never put confidential or sensitive information, such as your customers' email addresses, into tags or free-form fields such as a **Name** field. This includes when you work with WorkSpaces Applications or other AWS services using the console, API, AWS CLI, or AWS SDKs. Any data that you enter into tags or free-form fields used for names may be used for billing or diagnostic logs. If you provide a URL to an external server, we strongly recommend that you do not include credentials information in the URL to validate your request to that server.

**Topics**
+ [

# Encryption at Rest
](encryption-rest.md)
+ [

# Encryption in Transit
](encryption-transit.md)
+ [

# Administrator Controls
](administrator-controls.md)
+ [

# Application Access
](application-access.md)

# Encryption at Rest
<a name="encryption-rest"></a>

WorkSpaces Applications fleet instances are ephemeral in nature. After a user's streaming session is finished, the underlying instance and its associated Amazon Elastic Block Store (Amazon EBS) volume are terminated. In addition, WorkSpaces Applications periodically recycles unused instances for freshness.

When you enable [application settings persistence](how-it-works-app-settings-persistence.md), [home folders](home-folders-admin.md), [session scripts](enable-S3-bucket-storage-session-script-logs.md), or [usage reports](enable-usage-reports.md) your users, the data that is generated by your users and stored in Amazon Simple Storage Service buckets is encrypted at rest. AWS Key Management Service is a service that combines secure, highly available hardware and software to provide a key management system scaled for the cloud. Amazon S3 uses [AWS Managed CMKs](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-managed-cmk) to encrypt your Amazon S3 object data.

# Encryption in Transit
<a name="encryption-transit"></a>

The following table provides information about how data is encrypted in transit. Where applicable, other data protection methods for WorkSpaces Applications are also listed.


| Data | Network path | How protected | 
| --- | --- | --- | 
|  Web assets This traffic includes assets such as images and JavaScript files.  |  Between WorkSpaces Applications users and WorkSpaces Applications  | Encrypted using TLS 1.2 | 
| Pixel and related streaming traffic | Between WorkSpaces Applications users and WorkSpaces Applications |  Encrypted using 256-bit Advanced Encryption Standard (AES-256) Transported using TLS 1.2  | 
| API traffic | Between WorkSpaces Applications users and WorkSpaces Applications |  Encrypted using TLS 1.2 Requests to create a connection are signed using SigV4  | 
| Application settings and home folder data generated by users Applicable when application settings persistence and home folders are enabled.  | Between WorkSpaces Applications users and Amazon S3 | Encrypted using Amazon S3 SSL endpoints | 
| WorkSpaces Applications-managed traffic |  Between WorkSpaces Applications streaming instances and: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/appstream2/latest/developerguide/encryption-transit.html)  | Encrypted using TLS 1.2 Requests to create a connection are signed using SigV4 where applicable | 

# Administrator Controls
<a name="administrator-controls"></a>

WorkSpaces Applications provides administrative controls that you can use to limit the ways in which users can transfer data between their local computer and an WorkSpaces Applications fleet instance. You can limit or disable the following when you [create or update an WorkSpaces Applications stack](set-up-stacks-fleets-install.md):
+ Clipboard/copy and paste actions
+ File upload and download, including folder and drive redirection
+ Printing

When you create an WorkSpaces Applications image, you can specify which USB devices are available to redirect to WorkSpaces Applications fleet instances from the WorkSpaces Applications client for Windows. The USB devices that you specify will be available for use during users’ WorkSpaces Applications streaming sessions. For more information, see [Qualify USB Devices for Use with Streaming Applications](qualify-usb-devices.md).

# Application Access
<a name="application-access"></a>

By default, WorkSpaces Applications enables the applications that you specify in your image to launch other applications and executable files on the image builder and fleet instance. This ensures that applications with dependencies on other applications (for example, an application that launches the browser to navigate to a product website) function as expected. Make sure that you configure your administrative controls, security groups, and other security software to grant users the minimum permissions required to access resources and transfer data between their local computers and fleet instances.

You can use application control software, such as [Microsoft AppLocker](https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/applocker/applocker-overview), and policies to control which applications and files your users can run. Application control software and policies help you control the executable files, scripts, Windows installer files, dynamic-link libraries, and application packages that your users can run on WorkSpaces Applications image builders and fleet instances.

**Note**  
The WorkSpaces Applications agent software relies on the Windows command prompt and Windows Powershell to provision streaming instances. If you choose to prevent users from launching the Windows command prompt or Windows Powershell, the policies must not apply to the Windows NT AUTHORITY\$1SYSTEM or users in the Administrators group.


| Rule type | Action | Windows user or group | Name/Path | Condition | Description | 
| --- | --- | --- | --- | --- | --- | 
| Executable | Allow | NT AUTHORITY\$1System | \$1 | Path | Required for the WorkSpaces Applications agent software | 
| Executable | Allow | BUILTIN\$1Administrators | \$1 | Path | Required for the WorkSpaces Applications agent software | 
| Executable | Allow | Everyone | %PROGRAMFILES%\$1nodejs\$1\$1 | Path | Required for the WorkSpaces Applications agent software | 
| Executable | Allow | Everyone | %PROGRAMFILES%\$1NICE\$1\$1 | Path | Required for the WorkSpaces Applications agent software | 
| Executable | Allow | Everyone | %PROGRAMFILES%\$1Amazon\$1\$1 | Path | Required for the WorkSpaces Applications agent software | 
| Executable | Allow | Everyone | %PROGRAMFILES%\$1<default-browser>\$1\$1 | Path | Required for the WorkSpaces Applications agent software when persistent storage solutions, such as Google Drive or Microsoft OneDrive for Business, are used. This exception is not required when WorkSpaces Applications home folders are used. | 

# Identity and Access Management for Amazon WorkSpaces Applications
<a name="controlling-access"></a>

Your security credentials identify you to services in AWS and grant you unlimited use of your AWS resources, such as your WorkSpaces Applications resources. You can use features of WorkSpaces Applications and AWS Identity and Access Management (IAM) to allow other users, services, and applications to use your WorkSpaces Applications resources without sharing your security credentials. 

You can use IAM to control how other users use resources in your Amazon Web Services account, and you can use security groups to control access to your WorkSpaces Applications streaming instances. You can allow full use or limited use of your WorkSpaces Applications resources. 

**Topics**
+ [

# Network Access to Your Streaming Instance
](network-access-to-streaming-instances.md)
+ [

# Using AWS Managed Policies and Linked Roles to Manage Administrator Access to WorkSpaces Applications Resources
](controlling-administrator-access-with-policies-roles.md)
+ [

# Using IAM Policies to Manage Administrator Access to Application Auto Scaling
](autoscaling-iam-policy.md)
+ [

# Using IAM Policies to Manage Administrator Access to the Amazon S3 Bucket for Home Folders and Application Settings Persistence
](s3-iam-policy.md)
+ [

# Using an IAM Role to Grant Permissions to Applications and Scripts Running on WorkSpaces Applications Streaming Instances
](using-iam-roles-to-grant-permissions-to-applications-scripts-streaming-instances.md)
+ [

# SELinux on Red Hat Enterprise Linux and Rocky Linux
](selinux.md)
+ [

# Cookie-Based Authentication in Amazon WorkSpaces Applications
](cookie-auth.md)

# Network Access to Your Streaming Instance
<a name="network-access-to-streaming-instances"></a>

A security group acts as a stateful firewall that controls what traffic is allowed to reach your streaming instances. When you launch an WorkSpaces Applications streaming instance, assign it to one or more security groups. Then, add rules to each security group that control traffic for the instance. You can modify the rules for a security group at any time. The new rules are automatically applied to all instances to which the security group is assigned. 

For more information, see [Security Groups in Amazon WorkSpaces Applications](managing-network-security-groups.md).

# Using AWS Managed Policies and Linked Roles to Manage Administrator Access to WorkSpaces Applications Resources
<a name="controlling-administrator-access-with-policies-roles"></a>

By default, IAM users don't have the permissions required to create or modify WorkSpaces Applications resources, or perform tasks by using the WorkSpaces Applications API. This means that these users can't perform these actions in the WorkSpaces Applications console or by using WorkSpaces Applications AWS CLI commands. To allow IAM users to create or modify resources and perform tasks, attach an IAM policy to the IAM users or groups that require those permissions. 

When you attach a policy to a user, group of users, or IAM role, it allows or denies the users permission to perform the specified tasks on the specified resources. 

**Topics**
+ [

# AWS Managed Policies Required to Access WorkSpaces Applications Resources
](managed-policies-required-to-access-appstream-resources.md)
+ [

# Roles Required for WorkSpaces Applications, Application Auto Scaling, and AWS Certificate Manager Private CA
](roles-required-for-appstream.md)
+ [

# Checking for the AmazonAppStreamServiceAccess Service Role and Policies
](controlling-access-checking-for-iam-service-access.md)
+ [

# Checking for the ApplicationAutoScalingForAmazonAppStreamAccess Service Role and Policies
](controlling-access-checking-for-iam-autoscaling.md)
+ [

# Checking for the `AWSServiceRoleForApplicationAutoScaling_AppStreamFleet` Service-Linked Role and Policies
](controlling-access-checking-for-iam-service-linked-role-application-autoscaling-appstream-fleet.md)
+ [

# Checking for the AmazonAppStreamPCAAccess Service Role and Policies
](controlling-access-checking-for-AppStreamPCAAccess.md)

# AWS Managed Policies Required to Access WorkSpaces Applications Resources
<a name="managed-policies-required-to-access-appstream-resources"></a>

To provide full administrative or read-only access to WorkSpaces Applications, you must attach one of the following AWS managed policies to the IAM users or groups that require those permissions. An *AWS managed policy* is a standalone policy that is created and administered by AWS. For more information, see [AWS Managed Policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) in the *IAM User Guide*.

**Note**  
In AWS, IAM roles are used to grant permissions to an AWS service so it can access AWS resources. The policies that are attached to the role determine which AWS resources the service can access and what it can do with those resources. For WorkSpaces Applications, in addition to having the permissions defined in the **AmazonAppStreamFullAccess** policy, you must also have the required roles in your AWS account. For more information, see [Roles Required for WorkSpaces Applications, Application Auto Scaling, and AWS Certificate Manager Private CA](roles-required-for-appstream.md).

**AmazonAppStreamFullAccess**  
This managed policy provides full administrative access to WorkSpaces Applications resources. To manage WorkSpaces Applications resources and perform API actions through the AWS Command Line Interface (AWS CLI), AWS SDK, or AWS Management Console, you must have the permissions defined in this policy.  
If you sign into the WorkSpaces Applications console as an IAM user, you must attach this policy to your AWS account. If you sign in through console federation, you must attach this policy to the IAM role that was used for federation.  
To view the permissions for this policy, see [AmazonAppStreamFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonAppStreamFullAccess.html).

**AmazonAppStreamReadOnlyAccess**  
This identity-based policy grants users read-only permissions to view and monitor WorkSpaces Applications resources and related service configurations. Users can access the WorkSpaces Applications console to view streaming applications, fleet status, usage reports, and associated resources, but cannot make any changes. The policy also includes necessary read permissions for supporting services like IAM, Application Auto Scaling, and CloudWatch to enable comprehensive monitoring and reporting capabilities.  
To view the permissions for this policy, see [AmazonAppStreamReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonAppStreamReadOnlyAccess.html).

The WorkSpaces Applications console uses an additional action that provides functionality that is not available through the AWS CLI or AWS SDK. The **AmazonAppStreamFullAccess** and **AmazonAppStreamReadOnlyAccess** policies both provide permissions for the following action.


| Action | Description | Access Level | 
| --- | --- | --- | 
| DescribeImageBuilders | Grants permission to retrieve a list that describes one or more specified image builders, if the image builder names are provided. Otherwise, all image builders in the account are described. | Read | 

**AmazonAppStreamPCAAccess**  
This managed policy provides full administrative access to AWS Certificate Manager Private CA resources in your AWS account for certificate-based authentication.  
To view the permissions for this policy, see [AmazonAppStreamPCAAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonAppStreamPCAAccess.html).

**AmazonAppStreamServiceAccess**  
This managed policy is the default policy for the WorkSpaces Applications service role.   
This role permissions policy allows WorkSpaces Applications to complete the following actions:  
+ When using subnets in your account for your WorkSpaces Applications fleets, WorkSpaces Applications is able to describe subnets, VPCs, and availability zones, as well as create and manage the lifecycle of all elastic network interfaces associated with the fleet instances in those subnets. This also includes being able to attach Security Groups and IP addresses from those subnets to those elastic network interfaces.
+ When using features such as UPP and HomeFolders, WorkSpaces Applications is able to create and manage Amazon S3 buckets, objects and their lifecyles, policies, and encryption configuration in the account. These buckets include the following naming prefixes:
  + `"arn:aws:s3:::appstream2-36fb080bb8-",`
  + `"arn:aws:s3:::appstream-app-settings-",`
  + `"arn:aws:s3:::appstream-logs-"`
To view the permissions for this policy, see [AmazonAppStreamServiceAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonAppStreamServiceAccess.html).

**ApplicationAutoScalingForAmazonAppStreamAccess**  
This managed policy enables application autoscaling for WorkSpaces Applications.  
To view the permissions for this policy, see [ApplicationAutoScalingForAmazonAppStreamAccess ](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/ApplicationAutoScalingForAmazonAppStreamAccess.html).

**AWSApplicationAutoscalingAppStreamFleetPolicy**  
This managed policy grants permissions for Application Auto Scaling to access WorkSpaces Applications and CloudWatch .  
To view the permissions for this policy, see [AWSApplicationAutoscalingAppStreamFleetPolicy ](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSApplicationAutoscalingAppStreamFleetPolicy.html).

## WorkSpaces Applications updates to AWS managed policies
<a name="security-iam-awsmanpol-updates"></a>



View details about updates to AWS managed policies for WorkSpaces Applications since this service began tracking these changes. For automatic alerts about changes to this page, subscribe to the RSS feed on the [Document History for Amazon WorkSpaces Applications](doc-history.md) page.




| Change | Description | Date | 
| --- | --- | --- | 
|  AmazonAppStreamServiceAccess – Change  |   Added allow permissions for `"ec2:DescribeImages"` to the policy JSON policy document  | November 17, 2025 | 
|  AmazonAppStreamReadOnlyAccess – Change  |   Removed `"appstream:Get*",` from the JSON policy document  | October 22, 2025 | 
|  WorkSpaces Applications started tracking changes  |  WorkSpaces Applications started tracking changes for its AWS managed policies  | October 31, 2022 | 

# Roles Required for WorkSpaces Applications, Application Auto Scaling, and AWS Certificate Manager Private CA
<a name="roles-required-for-appstream"></a>

In AWS, IAM roles are used to grant permissions to an AWS service so it can access AWS resources. The policies that are attached to the role determine which AWS resources the service can access and what it can do with those resources. For WorkSpaces Applications, in addition to having the permissions defined in the **AmazonAppStreamFullAccess** policy, you must also have the following roles in your AWS account.

**Topics**
+ [

## AmazonAppStreamServiceAccess
](#AmazonAppStreamServiceAccess)
+ [

## ApplicationAutoScalingForAmazonAppStreamAccess
](#ApplicationAutoScalingForAmazonAppStreamAccess)
+ [

## AWSServiceRoleForApplicationAutoScaling\$1AppStreamFleet
](#AWSServiceRoleForApplicationAutoScaling_AppStreamFleet)
+ [

## AmazonAppStreamPCAAccess
](#AppStreamPCAAccess)

## AmazonAppStreamServiceAccess
<a name="AmazonAppStreamServiceAccess"></a>

This role is a service role that is created for you automatically when you get started with WorkSpaces Applications in an AWS Region. For more information about services roles, see [Creating a role to delegate permissions to an AWS service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) in the *IAM User Guide*.

While WorkSpaces Applications resources are being created, the WorkSpaces Applications service makes API calls to other AWS services on your behalf by assuming this role. To create fleets, you must have this role in your account. If this role is not in your AWS account and the required IAM permissions and trust relationship policies are not attached, you cannot create WorkSpaces Applications fleets.

For more information, see [Checking for the AmazonAppStreamServiceAccess Service Role and Policies](controlling-access-checking-for-iam-service-access.md) to check whether the **AmazonAppStreamServiceAccess** service role is present and has the correct policies attached. 

**Note**  
This service role can have permissions that are different from the first user that is getting started with WorkSpaces Applications. For details on the permissions of this role see “AmazonAppStreamServiceAccess” in [AWS Managed Policies Required to Access WorkSpaces Applications Resources](managed-policies-required-to-access-appstream-resources.md).

## ApplicationAutoScalingForAmazonAppStreamAccess
<a name="ApplicationAutoScalingForAmazonAppStreamAccess"></a>

This role is a service role that is created for you automatically when you get started with WorkSpaces Applications in an AWS Region. For more information about services roles, see [Creating a role to delegate permissions to an AWS service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) in the *IAM User Guide*.

Automatic scaling is a feature of WorkSpaces Applications fleets. To configure scaling policies, you must have this service role in your AWS account. If this service role is not in your AWS account and the required IAM permissions and trust relationship policies are not attached, you cannot scale WorkSpaces Applications fleets.

For more information, see [Checking for the ApplicationAutoScalingForAmazonAppStreamAccess Service Role and Policies](controlling-access-checking-for-iam-autoscaling.md).

## AWSServiceRoleForApplicationAutoScaling\$1AppStreamFleet
<a name="AWSServiceRoleForApplicationAutoScaling_AppStreamFleet"></a>

This role is a service-linked role that is created for you automatically. For more information, see [Service-linked roles](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-service-linked-roles.html) in the *Application Auto Scaling User Guide*.

Application Auto Scaling uses a service-linked role to perform automatic scaling on your behalf. A *service-linked role* is an IAM role that is linked directly to an AWS service. This role includes all the permissions that the service requires to call other AWS services on your behalf.

For more information, see [Checking for the `AWSServiceRoleForApplicationAutoScaling_AppStreamFleet` Service-Linked Role and Policies](controlling-access-checking-for-iam-service-linked-role-application-autoscaling-appstream-fleet.md).

## AmazonAppStreamPCAAccess
<a name="AppStreamPCAAccess"></a>

This role is a service role that is created for you automatically when you get started with WorkSpaces Applications in an AWS Region. For more information about services roles, see [Creating a role to delegate permissions to an AWS service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) in the *IAM User Guide*.

Certificate-based authentication is a feature of WorkSpaces Applications fleets joined to Microsoft Active Directory domains. To enable and use certificate-based authentication, you must have this service role in your AWS account. If this service role is not in your AWS account and the required IAM permissions and trust relationship policies are not attached, you cannot enable or use certificate-based authentication.

For more information, see [Checking for the AmazonAppStreamPCAAccess Service Role and Policies](controlling-access-checking-for-AppStreamPCAAccess.md).

# Checking for the AmazonAppStreamServiceAccess Service Role and Policies
<a name="controlling-access-checking-for-iam-service-access"></a>

Complete the steps in this section to check whether the **AmazonAppStreamServiceAccess** service role is present and has the correct policies attached. If this role is not in your account and must be created, you or an administrator with the required permissions must perform the steps to get started with WorkSpaces Applications in your Amazon Web Services account.

**To check whether the AmazonAppStreamServiceAccess IAM service role is present**

1. Open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

1. In the navigation pane, choose **Roles**. 

1. In the search box, type **amazonappstreamservice** to narrow the list of roles to select, and then choose **AmazonAppStreamServiceAccess**. If this role is listed, select it to view the role **Summary** page. 

1. On the **Permissions** tab, confirm whether the **AmazonAppStreamServiceAccess** permissions policy is attached.

1. Return to the role **Summary** page.

1. On the **Trust relationships** tab, choose **Show policy document**, and then confirm whether the **AmazonAppStreamServiceAccess** trust relationship policy is attached and follows the correct format. If so, the trust relationship is correctly configured. Choose **Cancel** and close the IAM console. 

## AmazonAppStreamServiceAccess trust relationship policy
<a name="controlling-access-service-access-trust-policy"></a>

The **AmazonAppStreamServiceAccess** trust relationship policy must include the WorkSpaces Applications service as the principal. A *principal* is an entity in AWS that can perform actions and access resources. This policy must also include the `sts:AssumeRole` action. The following policy configuration defines WorkSpaces Applications as a trusted entity.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
      "Service": "appstream.amazonaws.com"
    },
    "Action": "sts:AssumeRole"
    }
  ]
}
```

------

# Checking for the ApplicationAutoScalingForAmazonAppStreamAccess Service Role and Policies
<a name="controlling-access-checking-for-iam-autoscaling"></a>

Complete the steps in this section to check whether the **ApplicationAutoScalingForAmazonAppStreamAccess** service role is present and has the correct policies attached. If this role is not in your account and must be created, you or an administrator with the required permissions must perform the steps to get started with WorkSpaces Applications in your Amazon Web Services account.

**To check whether the ApplicationAutoScalingForAmazonAppStreamAccessIAM service role is present**

1. Open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

1. In the navigation pane, choose **Roles**. 

1. In the search box, type **applicationautoscaling** to narrow the list of roles to select, and then choose **ApplicationAutoScalingForAmazonAppStreamAccess**. If this role is listed, select it to view the role **Summary** page. 

1. On the **Permissions** tab, confirm whether the **ApplicationAutoScalingForAmazonAppStreamAccess** permissions policy is attached. 

1. Return to the role **Summary** page.

1. On the **Trust relationships** tab, choose **Show policy document**, and then confirm whether the **ApplicationAutoScalingForAmazonAppStreamAccess** trust relationship policy is attached and follows the correct format. If so, the trust relationship is correctly configured. Choose **Cancel** and close the IAM console. 

## ApplicationAutoScalingForAmazonAppStreamAccess trust relationship policy
<a name="controlling-access-autoscaling-trust-policy"></a>

The **ApplicationAutoScalingForAmazonAppStreamAccess** trust relationship policy must include the Application Auto Scaling service as the principal. This policy must also include the `sts:AssumeRole` action. The following policy configuration defines Application Auto Scaling as a trusted entity.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "application-autoscaling.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
```

------

# Checking for the `AWSServiceRoleForApplicationAutoScaling_AppStreamFleet` Service-Linked Role and Policies
<a name="controlling-access-checking-for-iam-service-linked-role-application-autoscaling-appstream-fleet"></a>

Complete the steps in this section to check whether the `AWSServiceRoleForApplicationAutoScaling_AppStreamFleet` service-linked role is present and has the correct policies attached. If this role is not in your account and must be created, you or an administrator with the required permissions must perform the steps to get started with WorkSpaces Applications in your Amazon Web Services account.

**To check whether the `AWSServiceRoleForApplicationAutoScaling_AppStreamFleet` IAM service-linked role is present**

1. Open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

1. In the navigation pane, choose **Roles**. 

1. In the search box, type **applicationautoscaling** to narrow the list of roles to select, and then choose `AWSServiceRoleForApplicationAutoScaling_AppStreamFleet`. If this role is listed, select it to view the role **Summary**page. 

1. On the **Permissions** tab, confirm whether the `AWSApplicationAutoscalingAppStreamFleetPolicy` permissions policy is attached.

1. Return to the **Role** summary page.

1. On the **Trust relationships **tab, choose **Show policy document**, and then confirm whether the `AWSServiceRoleForApplicationAutoScaling_AppStreamFleet` trust relationship policy is attached and follows the correct format. If so, the trust relationship is correctly configured. Choose **Cancel** and close the IAM console. 

## AWSServiceRoleForApplicationAutoScaling\$1AppStreamFleet trust relationship policy
<a name="controlling-access-application-autoscaling-appstream-fleet-trust-policy"></a>

The `AWSServiceRoleForApplicationAutoScaling_AppStreamFleet` trust relationship policy must include **appstream.application-autoscaling.amazonaws.com** as the principal. This policy must also include the `sts:AssumeRole` action. The following policy configuration defines **appstream.application-autoscaling.amazonaws.com** as a trusted entity.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "appstream.application-autoscaling.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
```

------

# Checking for the AmazonAppStreamPCAAccess Service Role and Policies
<a name="controlling-access-checking-for-AppStreamPCAAccess"></a>

Complete the steps in this section to check whether the **AmazonAppStreamPCAAccess** service role is present and has the correct policies attached. If this role is not in your account and must be created, you or an administrator with the required permissions must perform the steps to get started with WorkSpaces Applications in your Amazon Web Services account.

**To check whether the AmazonAppStreamPCAAccess IAM service role is present**

1. Open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

1. In the navigation pane, choose **Roles**. 

1. In the search box, type **appstreampca ** to narrow the list of roles to select, and then choose **AmazonAppStreamPCAAccess**. If this role is listed, select it to view the role **Summary**page. 

1. On the **Permissions** tab, confirm whether the **AmazonAppStreamPCAAccess ** permissions policy is attached.

1. Return to the **Role** summary page.

1. On the **Trust relationships **tab, choose **Show policy document**, and then confirm whether the **AmazonAppStreamPCAAccess ** trust relationship policy is attached and follows the correct format. If so, the trust relationship is correctly configured. Choose **Cancel** and close the IAM console. 

## AmazonAppStreamPCAAccess trust relationship policy
<a name="controlling-access-amazonappstreampcaaccess-trust-policy"></a>

The **AmazonAppStreamPCAAccess** trust relationship policy must include prod.euc.ecm.amazonaws.com as the principal. This policy must also include the `sts:AssumeRole` action. The following policy configuration defines ECM as a trusted entity.

**To create the AmazonAppStreamPCAAccess trust relationship policy using the AWS CLI**

1. Create a JSON file named `AmazonAppStreamPCAAccess.json` with the following text.

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Effect": "Allow",
               "Principal": {
                   "Service": [
                       "prod.euc.ecm.amazonaws.com"
                   ]
               },
               "Action": "sts:AssumeRole",
               "Condition": {}
           }
       ]
   }
   ```

------

1. Adjust the `AmazonAppStreamPCAAccess.json` path as needed and run the following AWS CLI commands to create the trust relationship policy and attach the AmazonAppStreamPCAAccess managed policy. For more information about the managed policy, see [AWS Managed Policies Required to Access WorkSpaces Applications Resources](managed-policies-required-to-access-appstream-resources.md).

   ```
   aws iam create-role --path /service-role/ --role-name AmazonAppStreamPCAAccess --assume-role-policy-document file://AmazonAppStreamPCAAccess.json
   ```

   ```
   aws iam attach-role-policy —role-name AmazonAppStreamPCAAccess —policy-arn arn:aws:iam::aws:policy/AmazonAppStreamPCAAccess
   ```

# Using IAM Policies to Manage Administrator Access to Application Auto Scaling
<a name="autoscaling-iam-policy"></a>

Automatic scaling for fleets is made possible by a combination of the WorkSpaces Applications, Amazon CloudWatch, and Application Auto Scaling APIs. WorkSpaces Applications fleets are created with WorkSpaces Applications, alarms are created with CloudWatch, and scaling policies are created with Application Auto Scaling.

In addition to having the permissions defined in the [AmazonAppStreamFullAccess](managed-policies-required-to-access-appstream-resources.md) policy, the IAM user that accesses fleet scaling settings must have the required permissions for the services that support dynamic scaling. IAM users must have permissions to use the actions shown in the following example policy. 

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
          "appstream:*",
          "application-autoscaling:*",
          "cloudwatch:DeleteAlarms",
          "cloudwatch:DescribeAlarmsForMetric",
          "cloudwatch:DisableAlarmActions",
          "cloudwatch:DescribeAlarms",
          "cloudwatch:EnableAlarmActions",
          "cloudwatch:ListMetrics",
          "cloudwatch:PutMetricAlarm",
          "iam:ListRoles"
      ],
      "Resource": "*"
    },
    {
      "Sid": "iamPassRole",
      "Effect": "Allow",
      "Action": [
          "iam:PassRole"
      ],
      "Resource": "*",
      "Condition": {
         "StringEquals": {
             "iam:PassedToService": "application-autoscaling.amazonaws.com"
          }
      }
    }
  ]
}
```

------

You can also create your own IAM policies to set more specific permissions for calls to the Application Auto Scaling API. For more information, see [Authentication and Access Control](https://docs.aws.amazon.com/autoscaling/application/userguide/auth-and-access-control.html) in the *Application Auto Scaling User Guide*.

# Using IAM Policies to Manage Administrator Access to the Amazon S3 Bucket for Home Folders and Application Settings Persistence
<a name="s3-iam-policy"></a>

The following examples show how you can use IAM policies to manage access to the Amazon S3 bucket for home folders and application settings persistence.

**Topics**
+ [

# Deleting the Amazon S3 Bucket for Home Folders and Application Settings Persistence
](s3-iam-policy-delete.md)
+ [

# Restricting Administrator Access to the Amazon S3 Bucket for Home Folders and Application Settings Persistence
](s3-iam-policy-restricted-access.md)

# Deleting the Amazon S3 Bucket for Home Folders and Application Settings Persistence
<a name="s3-iam-policy-delete"></a>

WorkSpaces Applications adds an Amazon S3 bucket policy to the buckets that it creates to prevent them from being accidentally deleted. To delete an S3 bucket, you must first delete the S3 bucket policy. Following are the bucket policies that you must delete for home folders and application settings persistence.

**Home folders policy**

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Sid": "PreventAccidentalDeletionOfBucket",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:DeleteBucket",
      "Resource": "arn:aws:s3:::appstream2-36fb080bb8-region-code-123456789012-without-hyphens"
    }
  ]
}
```

------

**Application settings persistence policy**

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Sid": "PreventAccidentalDeletionOfBucket",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:DeleteBucket",
      "Resource": "arn:aws:s3:::appstream-app-settings-region-code-123456789012-without-hyphens-unique-identifier"
     }
   ]
}
```

------

 For more information, see [Deleting or Emptying a Bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-or-empty-bucket.html) in the *Amazon Simple Storage Service User Guide*.

# Restricting Administrator Access to the Amazon S3 Bucket for Home Folders and Application Settings Persistence
<a name="s3-iam-policy-restricted-access"></a>

By default, administrators who can access the Amazon S3 buckets created by WorkSpaces Applications can view and modify content that is part of users' home folders and persistent application settings. To restrict administrator access to the S3 buckets that contain user files, we recommend applying the S3 bucket access policy based on the following template: 

```
{
  "Sid": "RestrictedAccess",
  "Effect": "Deny",
  "NotPrincipal": 
  {
    "AWS": [
      "arn:aws:iam::account:role/service-role/AmazonAppStreamServiceAccess",
      "arn:aws:sts::account:assumed-role/AmazonAppStreamServiceAccess/PhotonSession",
      "arn:aws:iam::account:user/IAM-user-name"
    ]
  },
    "Action": "s3:*",
    "Resource": "arn:aws:s3:::home-folder-or-application-settings-persistence-s3-bucket-region-account"
  }
 ]
}
```

This policy allows S3 bucket access only to the users specified and to the WorkSpaces Applications service. For every IAM user who should have access, replicate the following line:

```
"arn:aws:iam::account:user/IAM-user-name"
```

In the following example, the policy restricts access to the home folder S3 bucket for anyone other than IAM users marymajor and johnstiles. It also allows access to the WorkSpaces Applications service, in AWS Region US West (Oregon) for account ID 123456789012.

```
{
  "Sid": "RestrictedAccess",
  "Effect": "Deny",
  "NotPrincipal": 
  {
    "AWS": [
      "arn:aws:iam::123456789012:role/service-role/AmazonAppStreamServiceAccess",
      "arn:aws:sts::123456789012:assumed-role/AmazonAppStreamServiceAccess/PhotonSession",
      "arn:aws:iam::123456789012:user/marymajor",
      "arn:aws:iam::123456789012:user/johnstiles"
    ]
  },
    "Action": "s3:*",
    "Resource": "arn:aws:s3:::appstream2-36fb080bb8-us-west-2-123456789012"
  }
 ]
}
```

# Using an IAM Role to Grant Permissions to Applications and Scripts Running on WorkSpaces Applications Streaming Instances
<a name="using-iam-roles-to-grant-permissions-to-applications-scripts-streaming-instances"></a>

Applications and scripts that run on WorkSpaces Applications streaming instances must include AWS credentials in their AWS API requests. You can create an IAM role to manage these credentials. An IAM role specifies a set of permissions that you can use to access AWS resources. This role is not uniquely associated with one person, however. Instead, it can be assumed by anyone that needs it.

You can apply an IAM role to an WorkSpaces Applications streaming instance. When the streaming instance switches to (assumes) the role, the role provides temporary security credentials. Your application or scripts use these credentials to perform API actions and management tasks on the streaming instance. WorkSpaces Applications manages the temporary credential switch for you.

**Topics**
+ [

# Best Practices for Using IAM Roles With WorkSpaces Applications Streaming Instances
](best-practices-for-using-iam-role-with-streaming-instances.md)
+ [

# Configuring an Existing IAM Role to Use With WorkSpaces Applications Streaming Instances
](configuring-existing-iam-role-to-use-with-streaming-instances.md)
+ [

# How to Create an IAM Role to Use With WorkSpaces Applications Streaming Instances
](how-to-create-iam-role-to-use-with-streaming-instances.md)
+ [

# How to Use the IAM Role With WorkSpaces Applications Streaming Instances
](how-to-use-iam-role-with-streaming-instances.md)

# Best Practices for Using IAM Roles With WorkSpaces Applications Streaming Instances
<a name="best-practices-for-using-iam-role-with-streaming-instances"></a>

When you use IAM roles with WorkSpaces Applications streaming instances, we recommend that you follow these practices:
+ Limit the permissions that you grant to AWS API actions and resources.

  Follow least privilege principles when you create and attach IAM policies to the IAM roles associated with WorkSpaces Applications streaming instances. When you use an application or script that requires access to AWS API actions or resources, determine the specific actions and resources that are required. Then, create policies that allow the application or script to perform only those actions. For more information, see [Grant Least Privilege](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) in the *IAM User Guide*.
+ Create an IAM role for each WorkSpaces Applications resource.

  Creating a unique IAM role for each WorkSpaces Applications resource is a practice that follows least privilege principles. Doing so also lets you modify permissions for a resource without affecting other resources.
+ Limit where the credentials can be used.

  IAM policies let you define the conditions under which your IAM role can be used to access a resource. For example, you can include conditions to specify a range of IP addresses that requests can come from. Doing so prevents the credentials from being used outside of your environment. For more information, see [Use Policy Conditions for Extra Security](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#use-policy-conditions) in the *IAM User Guide*.

# Configuring an Existing IAM Role to Use With WorkSpaces Applications Streaming Instances
<a name="configuring-existing-iam-role-to-use-with-streaming-instances"></a>

This topic describes how to configure an existing IAM role so that you can use it with image builders and fleet streaming instances.

**Prerequisites**

The IAM role that you want to use with an WorkSpaces Applications image builder or fleet streaming instance must meet the following prerequisites:
+ The IAM role must be in the same Amazon Web Services account as the WorkSpaces Applications streaming instance.
+ The IAM role cannot be a service role.
+ The trust relationship policy that is attached to the IAM role must include the WorkSpaces Applications service as the principal. A *principal* is an entity in AWS that can perform actions and access resources. The policy must also include the `sts:AssumeRole` action. This policy configuration defines WorkSpaces Applications as a trusted entity.

  
+ If you are applying the IAM role to an image builder, the image builder must run a version of the WorkSpaces Applications agent released on or after September 3, 2019. If you are applying the IAM role to a fleet, the fleet must use an image that uses a version of the agent released on or after the same date. For more information, see [WorkSpaces Applications Agent Release Notes](agent-software-versions.md). 

**To enable the WorkSpaces Applications service principal to assume an existing IAM role**

To perform the following steps, you must sign into the account as an IAM user who has the permissions required to list and update IAM roles. If you don't have the required permissions, ask your Amazon Web Services account administrator either to perform these steps in your account or to grant you the required permissions.

1. Open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

1. In the navigation pane, choose **Roles**. 

1. In the list of roles in your account, choose the name of the role that you want to modify.

1. Choose the **Trust relationships** tab, and then choose **Edit trust relationship**.

1. Under **Policy Document**, verify that the trust relationship policy includes the `sts:AssumeRole` action for the `appstream.amazonaws.com` service principal:

------
#### [ JSON ]

****  

   ```
   {
     "Version":"2012-10-17",		 	 	 
     "Statement": [
       {
         "Effect": "Allow",
         "Principal": {
           "Service": [
             "appstream.amazonaws.com"
           ]
         },
         "Action": "sts:AssumeRole"
       }
     ]
   }
   ```

------

1. When you are finished editing your trust policy, choose **Update Trust Policy** to save your changes. 

1. The IAM role that you selected will display in the WorkSpaces Applications console. This role grants permissions to applications and scripts to perform API actions and management tasks on streaming instances.

# How to Create an IAM Role to Use With WorkSpaces Applications Streaming Instances
<a name="how-to-create-iam-role-to-use-with-streaming-instances"></a>

This topic describes how to create a new IAM role so that you can use it with image builders and fleet streaming instances.

1. Open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

1. In the navigation pane, choose **Roles**, and then choose **Create role**.

1. For **Select type of trusted entity**, choose **AWS service**.

1. From the list of AWS services, choose **WorkSpaces Applications**.

1. Under **Select your use case**, **WorkSpaces Applications — Allows WorkSpaces Applications instances to call AWS services on your behalf** is already selected. Choose **Next: Permissions**.

1. If possible, select the policy to use for the permissions policy or choose **Create policy** to open a new browser tab and create a new policy from scratch. For more information, see step 4 in the procedure [Creating IAM Policies (Console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-start) in the *IAM User Guide*.

   After you create the policy, close that tab and return to your original tab. Select the check box next to the permissions policies that you want WorkSpaces Applications to have.

1. (Optional) Set a permissions boundary. This is an advanced feature that is available for service roles, but not service-linked roles. For more information, see [Permissions Boundaries for IAM Entities ](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) in the *IAM User Guide*.

1. Choose **Next: Tags**. You can optionally attach tags as key-value pairs. For more information, see [Tagging IAM Users and Roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html) in the *IAM User Guide*.

1. Choose **Next: Review**.

1. For **Role name**, type a role name that is unique within your Amazon Web Services account. Because other AWS resources might reference the role, you can't edit the name of the role after it has been created.

1. For **Role description**, keep the default role description or type a new one.

1. Review the role, and then choose **Create role**.

# How to Use the IAM Role With WorkSpaces Applications Streaming Instances
<a name="how-to-use-iam-role-with-streaming-instances"></a>

After you create an IAM role, you can apply it to an image builder or fleet streaming instance when you launch the image builder or create a fleet. You can also apply an IAM role to existing fleets. For information about how to apply IAM role when you launch an image builder, see [Launch an Image Builder to Install and Configure Streaming Applications](tutorial-image-builder-create.md). For information about how to apply IAM role when you create a fleet, see [Create a Fleet in Amazon WorkSpaces Applications](set-up-stacks-fleets-create.md).

When you apply an IAM role to your image builder or fleet streaming instance, WorkSpaces Applications retrieves temporary credentials and creates the **appstream\$1machine\$1role** credential profile on the instance. The temporary credentials are valid for 1 hour, and new credentials retrieved every hour. The previous credentials do not expire, so you can use them for as long as they are valid. You can use the credential profile to call AWS services programmatically by using the AWS Command Line Interface (AWS CLI), AWS Tools for PowerShell, or the AWS SDK with the language of your choice.

When you make the API calls, specify **appstream\$1machine\$1role** as the credential profile. Otherwise, the operation fails due to insufficient permissions.

WorkSpaces Applications assumes the specified role while the streaming instance is provisioned. Because WorkSpaces Applications uses the elastic network interface that is attached to your VPC for AWS API calls, your application or script must wait for the elastic network interface to become available before making AWS API calls. If API calls are made before the elastic network interface is available, the calls fail.

The following examples show how you can use the **appstream\$1machine\$1role** credential profile to describe streaming instances (EC2 instances) and to create the Boto client. Boto is the Amazon Web Services (AWS) SDK for Python. 

**Describe Streaming Instances (EC2 instances) by Using the AWS CLI**

```
aws ec2 describe-instances --region us-east-1 --profile appstream_machine_role
```

**Describe Streaming Instances (EC2 instances) by Using AWS Tools for PowerShell**

You must use AWS Tools for PowerShell version 3.3.563.1 or later, with the Amazon Web Services SDK for .NET version 3.3.103.22 or later. You can download the AWS Tools for Windows installer, which includes AWS Tools for PowerShell and the Amazon Web Services SDK for .NET, from the [AWS Tools for PowerShell](https://aws.amazon.com/powershell/) website.

```
Get-EC2Instance -Region us-east-1 -ProfileName appstream_machine_role
```

**Creating the Boto Client by Using the AWS SDK for Python**

```
session = boto3.Session(profile_name='appstream_machine_role')
```

# SELinux on Red Hat Enterprise Linux and Rocky Linux
<a name="selinux"></a>

By default, Security Enhanced Linux (SELinux) is `enabled` and set to `enforcing` mode for WorkSpaces Applications image builders and streaming instances powered by Red Hat Enterprise Linux and Rocky Linux. In `enforcing` mode, permission denials are enforced. SELinux is a collection of kernel features and utilities to provide a strong, flexible, mandatory access control (MAC) architecture to the major subsystems of the kernel.

SELinux provides an enhanced mechanism to enforce the separation of information based on confidentiality and integrity requirements. This separation of information reduces threats of tampering and bypassing of application security mechanisms. It also confines damage that can be caused by malicious or flawed applications.

SELinux includes a set of sample security policy configuration files that's designed to meet everyday security goals. For more information about SELinux features and functionality, see [What is SELinux](https://www.redhat.com/en/topics/linux/what-is-selinux)?

# Cookie-Based Authentication in Amazon WorkSpaces Applications
<a name="cookie-auth"></a>

WorkSpaces Applications uses browser cookies to authenticate streaming sessions and allow users to reconnect to an active session without re-entering their sign-in credentials every time. Authentication tokens are stored in browser cookies for every authentication scenario. While cookies are necessary for many online services, they can potentially be vulnerable to cookie theft attacks. We strongly recommend that you take proactive measures to prevent cookie theft, such as implementing robust endpoint protection solutions for your users' devices. Furthermore, to mitigate the potential impact in the event of cookie theft, we advise you to consider the following actions:
+ **Enforce single-session limit**: For your WorkSpaces Applications Windows images, create a registry key under `HKEY_USERS\S-1-5-18\Software\GSettings\com\nicesoftware\dcv\session-management` with the name **max-concurrent-clients** set to 1 to only allow one connection at a time. This limits the number of concurrent session to one, and blocks mirroring of active sessions. For more information, see [session-management Parameters](https://docs.aws.amazon.com/dcv/latest/adminguide/config-param-ref.html#session_management).
+ **Enforce session expiry and re-authentication**
  + Reduce the SessionDuration value so that the authentication token expires after the user successfully starts the streaming session. Reusing authentication cookies after the sessionDuration expires requires users to re-authenticate themselves. SessionDuration specifies the maximum amount of time that a federated streaming session for a user can remain active before re-authentication is required. The default value is 60 minutes. For more information, see [Step 5: Create Assertions for the SAML Authentication Response](external-identity-providers-setting-up-saml.md#external-identity-providers-create-assertions).
  + To help maximize security, users should end sessions properly with the toolbar (terminate session), instead of closing the streaming window. Ending the session through the toolbar terminates both the user session and the streaming instance. This requires re-authentication for future access, preventing cookie misuse. If a user closes the streaming window without ending the session, the session and instance remains active for a configurable disconnect timeout period (in minutes). The disconnect timeout must be a number between 1 and 5760, with a default value of 15 minutes. To prevent misuse of inactive sessions, we recommend setting a short disconnect timeout. For more information, see [Create a Fleet in Amazon WorkSpaces Applications](set-up-stacks-fleets-create.md).
+ **Limit access to stream WorkSpaces Applications applications to your IP ranges**: We recommend that you implement IP-based IAM policies. This ensures that WorkSpaces Applications sessions can only be accessed from clients whose IP address belongs to an authorized IP range. All connection attempts initiated by a user whose client's IP address is outside an authorized range will be denied, even if they are presenting an otherwise valid authentication cookie (potentially stolen from a user). For more information, see [Limit access to stream Amazon AppStream 2.0 applications to your IP ranges](https://aws.amazon.com/blogs/desktop-and-application-streaming/limit-access-to-stream-amazon-appstream-2-0-applications-to-your-ip-ranges/).
+ **Add additional authentication**: To launch domain-joined streaming instances, you can join your WorkSpaces Applications Always-On and On-Demand Windows fleets and image builders to domains in Microsoft Active Directory, and use your existing Active Directory domains, either cloud-based or on-premises. After the initial SAML-based authentication, your users will be prompted to provide their domain credentials for additional authentication against the organizational domain. For more information, see [Using Active Directory with WorkSpaces Applications](active-directory.md).

 If you have any concerns or need help, contact [AWS Support Center](https://console.aws.amazon.com/support/home#/). 

# Logging and Monitoring in Amazon WorkSpaces Applications
<a name="logging-monitoring-alerting"></a>

Monitoring is an important part of maintaining the reliability, availability, and performance of Amazon WorkSpaces Applications. This topic describes the services and tools that AWS provides for monitoring your WorkSpaces Applications resources and responding to potential incidents.

**Amazon CloudWatch Alarms**  
Amazon CloudWatch alarms let you watch a single metric over a time period that you specify. If the metric exceeds a given threshold, a notification is sent to an Amazon Simple Notification Service topic or AWS Auto Scaling policy. CloudWatch alarms do not invoke actions that are in a particular state. Instead, the state must have changed and been maintained for a specified number of periods. For more information, see [Monitoring Amazon WorkSpaces Applications Resources](monitoring.md).  
WorkSpaces Applications currently can't be configured as a target for CloudWatch Events. For a list of services that you can configure as targets for CloudWatch events, see [What Is Amazon CloudWatch Events](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html).

**AWS CloudTrail**  
AWS CloudTrail provides a record of actions taken by a user, role, or an AWS service in WorkSpaces Applications. This record lets you determine the request that was made to WorkSpaces Applications, the IP address from which the request was made, who made the request, when it was made, and additional details. For more information, see [Logging Amazon WorkSpaces Applications API Calls with AWS CloudTrail](logging-using-cloudtrail.md). 

**AWS Trusted Advisor**  
AWS Trusted Advisor inspects your AWS environment and then recommends ways to save money, improve system availability and performance, or help close security gaps. Trusted Advisor uses best practices collected from a wide variety of AWS customers. All AWS customers have access to five Trusted Advisor checks. If you have a Business or Enterprise support plan, you can view all Trusted Advisor checks.  
When you enable [application settings persistence](how-it-works-app-settings-persistence.md) or [home folders](home-folders-admin.md) for your users, the data that is generated by your users is stored in Amazon S3 buckets. Trusted Advisor contains the following checks related to Amazon S3:  
+ Logging configuration of Amazon S3 buckets.
+ Security checks for Amazon S3 buckets that have open access permissions.
+ Fault tolerance checks for Amazon S3 buckets that don't have versioning enabled, or have versioning suspended. 
For more information, see [AWS Trusted Advisor](https://docs.aws.amazon.com/awssupport/latest/user/trusted-advisor.html) in the *AWS Support User Guide*.

**Amazon S3 Access Logs**  
If your users have application settings data or home folders data stored in Amazon S3 buckets, consider viewing Amazon S3 server access logs to monitor access. These logs provide detailed records about requests that are made to a bucket. Server access logs are useful for many applications. For example, access log information can be useful in security and access audits. For more information, see [Amazon S3 Server Access Logging](https://docs.aws.amazon.com/AmazonS3/latest/dev/ServerLogs.html) in the *Amazon Simple Storage Service User Guide*.

**WorkSpaces Applications Usage Reports**  
You can subscribe to WorkSpaces Applications usage reports to receive detailed reports about how your users are using the service. The reports include how long users stream and which applications they launch. For more information, see [WorkSpaces Applications Usage Reports](configure-usage-reports.md). 

# Compliance Validation for Amazon WorkSpaces Applications
<a name="compliance-validation"></a>

Third-party auditors assess the security and compliance of Amazon WorkSpaces Applications as part of multiple AWS compliance programs. These include the following: [SOC](https://aws.amazon.com/compliance/soc-faqs/), [PCI](https://aws.amazon.com/compliance/pci-dss-level-1-faqs), [ISO](https://aws.amazon.com/compliance/iso-certified/), [FedRAMP](https://aws.amazon.com/compliance/fedramp/), [HIPAA](https://aws.amazon.com/compliance/hipaa-compliance/), [MTCS](https://aws.amazon.com/compliance/aws-multitiered-cloud-security-standard-certification/), [ENS High](https://aws.amazon.com/compliance/esquema-nacional-de-seguridad/), [HITRUST CSF](https://aws.amazon.com/compliance/hitrust/), [VPAT](https://aws.amazon.com/compliance/vpat/), and others.

**Note**  
WorkSpaces Applications supports [FIPS 140-2](https://aws.amazon.com/compliance/fips/). For information about how to use WorkSpaces Applications FIPS endpoints for administrative use or streaming, see [Protecting Data in Transit with FIPS Endpoints](protecting-data-in-transit-FIPS-endpoints.md).  
WorkSpaces Applications is also undergoing assessment for the [Department of Defense (DoD) Cloud Computing Security Requirements Guide (SRG)](https://aws.amazon.com/compliance/dod/).

For a list of AWS services in scope of specific compliance programs, see [AWS Services in Scope by Compliance Program](https://aws.amazon.com/compliance/services-in-scope/). For general information, see [AWS Compliance Programs](https://aws.amazon.com/compliance/programs/).

You can download third-party audit reports using AWS Artifact. For more information, see [Downloading Reports in AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html).

Your compliance responsibility when using WorkSpaces Applications is determined by the sensitivity of your data, your company's compliance objectives, and applicable laws and regulations. AWS provides the following resources to help with compliance:
+ [Security and Compliance Quick Start Guides](https://aws.amazon.com/quickstart/?awsf.quickstart-homepage-filter=categories%23security-identity-compliance) – These deployment guides discuss architectural considerations and provide steps for deploying security- and compliance-focused baseline environments on AWS.
+ [Architecting for HIPAA Security and Compliance Whitepaper ](https://d0.awsstatic.com/whitepapers/compliance/AWS_HIPAA_Compliance_Whitepaper.pdf) – This whitepaper describes how companies can use AWS to create HIPAA-compliant applications.
+ [AWS Compliance Resources](https://aws.amazon.com/compliance/resources/) – This collection of workbooks and guides might apply to your industry and location.
+ [Evaluating Resources with Rules](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) in the *AWS Config Developer Guide* – The AWS Config service assesses how well your resource configurations comply with internal practices, industry guidelines, and regulations.
+ [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) – This AWS service provides a comprehensive view of your security state within AWS that helps you check your compliance with security industry standards and best practices.

# Resilience in Amazon WorkSpaces Applications
<a name="disaster-recovery-resiliency"></a>

The AWS global infrastructure is built around AWS Regions and Availability Zones. Regions provide multiple physically separated and isolated Availability Zones, which are connected through low-latency, high-throughput, and highly redundant networking. With Availability Zones, you can design and operate applications and databases that automatically fail over between zones without interruption. Availability Zones are more highly available, fault tolerant, and scalable than traditional single or multiple data center infrastructures.

For more information about AWS Regions and Availability Zones, see [AWS Global Infrastructure](https://aws.amazon.com/about-aws/global-infrastructure/).

# Infrastructure Security in Amazon WorkSpaces Applications
<a name="infrastructure-security"></a>

As a managed service, Amazon WorkSpaces Applications is protected by AWS global network security. For information about AWS security services and how AWS protects infrastructure, see [AWS Cloud Security](https://aws.amazon.com/security/). To design your AWS environment using the best practices for infrastructure security, see [Infrastructure Protection](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html) in *Security Pillar AWS Well‐Architected Framework*.

You use AWS published API calls to access WorkSpaces Applications through the network. Clients must support the following:
+ Transport Layer Security (TLS). We require TLS 1.2 and recommend TLS 1.3.
+ Cipher suites with perfect forward secrecy (PFS) such as DHE (Ephemeral Diffie-Hellman) or ECDHE (Elliptic Curve Ephemeral Diffie-Hellman). Most modern systems such as Java 7 and later support these modes.

The following topics provide additional information about WorkSpaces Applications infrastructure security.

**Topics**
+ [

# Network Isolation
](network-isolation.md)
+ [

# Isolation on Physical Hosts
](physical-isolation.md)
+ [

# Controlling Network Traffic
](control-network-traffic.md)
+ [

# WorkSpaces Applications Interface VPC Endpoints
](interface-vpc-endpoints.md)
+ [

# Protecting Data in Transit with FIPS Endpoints
](protecting-data-in-transit-FIPS-endpoints.md)

# Network Isolation
<a name="network-isolation"></a>

A virtual private cloud (VPC) is a virtual network in your own logically isolated area in the Amazon Web Services Cloud. Use separate VPCs to isolate infrastructure by workload or organizational entity.

A subnet is a range of IP addresses in a VPC. When you launch an instance, you launch it into a subnet in your VPC. Use subnets to isolate the tiers of your application (for example, web, application, and database) within a single VPC. Use private subnets for your instances if they should not be accessed directly from the internet.

You can stream from WorkSpaces Applications streaming instances in your VPC without going through the public internet. To do so, use an interface VPC endpoint (interface endpoint). For more information, see [Tutorial: Creating and Streaming from Interface VPC Endpoints](creating-streaming-from-interface-vpc-endpoints.md).

You can also call WorkSpaces Applications API operations from your VPC without sending traffic over the public internet by using an interface endpoint. For information, see [Access WorkSpaces Applications API Operations and CLI Commands Through an Interface VPC Endpoint](access-api-cli-through-interface-vpc-endpoint.md).

# Isolation on Physical Hosts
<a name="physical-isolation"></a>

Different streaming instances on the same physical host are isolated from each other as though they are on separate physical hosts. The hypervisor isolates CPU and memory, and the instances are provided virtualized disks instead of access to the raw disk devices.

When you stop or terminate a streaming instance, the memory allocated to it is scrubbed (meaning, it's set to zero) by the hypervisor before it is allocated to a new instance, and every block of storage is reset. This ensures that your data is not exposed to another instance. 

# Controlling Network Traffic
<a name="control-network-traffic"></a>

To help control network traffic to your WorkSpaces Applications streaming instances, consider these options:
+ When you launch an Amazon AppStream streaming instance, you launch it into a subnet in your VPC. You can deploy streaming instances in a private subnet if they should not be accessible from the internet.
+ To provide internet access to your streaming instances in a private subnet, use a NAT gateway. For more information, see [Configure a VPC with Private Subnets and a NAT Gateway](managing-network-internet-NAT-gateway.md).
+ Security groups that belong to your VPC let you control the network traffic between WorkSpaces Applications streaming instances and VPC resources such as license servers, file servers, and database servers. Security groups also isolate traffic between your streaming instances and WorkSpaces Applications management services. 

  Use security groups to restrict access to your streaming instances. For example, you can allow traffic only from the address ranges for your corporate network. For more information, see [Security Groups in Amazon WorkSpaces Applications](managing-network-security-groups.md). 
+ You can stream from WorkSpaces Applications streaming instances in your VPC without going through the public internet. To do so, use an interface VPC endpoint (interface endpoint). For more information, see [Tutorial: Creating and Streaming from Interface VPC Endpoints](creating-streaming-from-interface-vpc-endpoints.md).

  You can also call WorkSpaces Applications API operations from your VPC without sending traffic over the public internet by using an interface endpoint. For more information, see [Access WorkSpaces Applications API Operations and CLI Commands Through an Interface VPC Endpoint](access-api-cli-through-interface-vpc-endpoint.md).
+ Use IAM roles and policies to manage administrator access to WorkSpaces Applications, Application Auto Scaling, and Amazon S3 buckets. For more information, see the following topics:
  + [Using AWS Managed Policies and Linked Roles to Manage Administrator Access to WorkSpaces Applications Resources](controlling-administrator-access-with-policies-roles.md)
  + [Using IAM Policies to Manage Administrator Access to Application Auto Scaling](autoscaling-iam-policy.md)
  + [Restricting Administrator Access to the Amazon S3 Bucket for Home Folders and Application Settings Persistence](s3-iam-policy-restricted-access.md)
+ You can use SAML 2.0 to federate authentication to WorkSpaces Applications. For more information, see [Amazon WorkSpaces Applications Service Quotas](limits.md).
**Note**  
For smaller WorkSpaces Applications deployments, you can use WorkSpaces Applications user pools. By default, user pools support a maximum of 50 users. For more information about WorkSpaces Applications quotas (also referred to as limits), see [Amazon WorkSpaces Applications Service Quotas](limits.md). For deployments that must support 100 or more WorkSpaces Applications users, we recommend using SAML 2.0.

# WorkSpaces Applications Interface VPC Endpoints
<a name="interface-vpc-endpoints"></a>

A virtual private cloud (VPC) is a virtual network in your own logically isolated area in the Amazon Web Services Cloud. If you use Amazon Virtual Private Cloud to host your AWS resources, you can establish a private connection between your VPC and WorkSpaces Applications. You can use this connection to enable WorkSpaces Applications to communicate with your resources on your VPC without going through the public internet.

Interface endpoints are powered by AWS PrivateLink, a technology that lets you keep streaming traffic within a VPC that you specify by using private IP addresses. When you use the VPC with an Direct Connect or AWS Virtual Private Network tunnel, you can keep the streaming traffic within your network. 

The following topics provide information about WorkSpaces Applications interface endpoints.

**Topics**
+ [

# Tutorial: Creating and Streaming from Interface VPC Endpoints
](creating-streaming-from-interface-vpc-endpoints.md)
+ [

# Access WorkSpaces Applications API Operations and CLI Commands Through an Interface VPC Endpoint
](access-api-cli-through-interface-vpc-endpoint.md)

# Tutorial: Creating and Streaming from Interface VPC Endpoints
<a name="creating-streaming-from-interface-vpc-endpoints"></a>

You can use an interface VPC endpoint in your Amazon Web Services account to restrict all network traffic between your Amazon VPC and WorkSpaces Applications to the Amazon network. After you create this endpoint, you configure your WorkSpaces Applications stack or image builder to use it. 

**Prerequisites**

Before you set up interface VPC endpoints for WorkSpaces Applications, be aware of the following prerequisites:
+ Internet connectivity is required to authenticate users and deliver the web assets that WorkSpaces Applications requires to function. The streaming interface endpoint maintains the streaming traffic within your VPC. Streaming traffic includes pixel, USB, user input, audio, clipboard, file upload and download, and printer traffic. To allow this traffic, you must allow the domains listed in [Allowed Domains](allowed-domains.md). After creating the VPC endpoint, you must allow the WorkSpaces Applications user authentication domains. However, for the streaming gateways, you can restrict access to just <vpc-endpoint-id>.streaming.appstream.<aws-region>.vpce.amazonaws.com. Allow listing to \$1.amazonappstream.com is not required. The VPC endpoint fully qualified domain name replaces that dependency.
+ The network to which your users' devices are connected must be able to route traffic to the interface endpoint.
+ The security groups that are associated with the interface endpoint must allow inbound access to port 443 (TCP) and ports 1400-1499 (TCP) from the IP address range from which your users connect.
+ The network access control list for the subnets must allow outbound traffic from ephemeral network ports 1024-65535 (TCP) to the IP address range from which your users connect.
+ You must have an IAM permissions policy in your AWS account that provides permissions to perform the `ec2:DescribeVpcEndpoints` API action. By default, this permission is defined in the IAM policy that is attached to the AmazonAppStreamServiceAccess role. If you have the required permissions, this service role is automatically created by WorkSpaces Applications, with the required IAM policies attached, when you get started with the WorkSpaces Applications service in an AWS Region. For more information, see [Identity and Access Management for Amazon WorkSpaces Applications](controlling-access.md).

**To create an interface endpoint**

1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).

1. In the navigation pane, choose **Endpoints**, **Create Endpoint**.

1. Choose **Create Endpoint**.

1. For **Service category**, ensure that** AWS services** is selected. 

1. For **Service Name**, choose **com.amazonaws.***<AWS Region>***.appstream.streaming**.

1. Specify the following information. When you're done, choose **Create endpoint**. 
   + For **VPC**, choose a VPC in which to create the interface endpoint. You can choose a different VPC than the VPC with WorkSpaces Applications resources.
   + For **Subnets**, choose the subnets (Availability Zones) in which to create the endpoint network interfaces. We recommend that you choose subnets in at least two Availability Zones.
   + For **IP address type**, choose either IPV6 or IPV4.
   + Ensure that the **Enable Private DNS Name** check box is selected. 
**Note**  
If your users use a network proxy to access streaming instances, disable any proxy caching on the domain and DNS names that are associated with the private endpoint. The VPC endpoint DNS name should be allowed through the proxy.
   + For **Security group**, choose the security groups to associate with the endpoint network interfaces. 
**Note**  
The security groups must provide inbound access to the ports from the IP address range from which your users connect.

While your interface endpoint is being created, the status of the endpoint in the console appears as **Pending**. After your endpoint is created, the status changes to **Available.** 

 To update a stack to use the interface endpoint that you created for streaming sessions, perform the following steps.

**To update a stack to use a new interface endpoint**

1. Open the WorkSpaces Applications console at [https://console.aws.amazon.com/appstream2/home](https://console.aws.amazon.com/appstream2/home).

   Ensure that you open the console in the same AWS Region as the interface endpoint that you want to use.

1. In the navigation pane, choose **Stacks**, and then choose the stack that you want.

1. Choose the **VPC Endpoints** tab, and then choose **Edit**.

1. In the **Edit VPC Endpoint** dialog box, for **Streaming Endpoint**, choose the endpoint through which to stream traffic.

1. Choose **Update**.

Traffic for new streaming sessions will be routed through this endpoint. However, traffic for current streaming sessions continues to be routed through the previously specified endpoint.

**Note**  
Users cannot stream using the internet endpoint when an interface endpoint is specified.

# Access WorkSpaces Applications API Operations and CLI Commands Through an Interface VPC Endpoint
<a name="access-api-cli-through-interface-vpc-endpoint"></a>

If you use Amazon Virtual Private Cloud to host your AWS resources, you can connect directly to WorkSpaces Applications API operations or command line interface (CLI) commands through an [interface VPC endpoint](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html) (interface endpoint) in your virtual private cloud (VPC) instead of connecting over the internet. Interface endpoints are powered by AWS PrivateLink, a technology that lets you keep streaming traffic within a VPC that you specify by using private IP addresses. When you use an interface endpoint, communication between your VPC and WorkSpaces Applications is conducted entirely and securely within the AWS network.

**Note**  
This topic describes how to access the WorkSpaces Applications API operations and CLI commands through an interface endpoint. For information about how to create and stream from WorkSpaces Applications interface endpoints, see [Tutorial: Creating and Streaming from Interface VPC Endpoints](creating-streaming-from-interface-vpc-endpoints.md).

**Prerequisites**

To use interface endpoints, you must meet the following prerequisites:
+ The security groups that are associated with the interface endpoint must allow inbound access to port 443 (TCP) from the IP address range from which your users connect.
+ The network access control list for the subnets must allow outbound traffic from ephemeral network ports 1024-65535 (TCP) to the IP address range from which your users connect.

**Topics**
+ [

# Create an Interface Endpoint to Access WorkSpaces Applications API Operations and CLI Commands
](access-api-cli-through-interface-vpc-endpoint-create-interface-endpoint.md)
+ [

# Use an Interface Endpoint to Access WorkSpaces Applications API Operations and CLI Commands
](how-to-access-api-cli-through-interface-vpc-endpoint.md)

# Create an Interface Endpoint to Access WorkSpaces Applications API Operations and CLI Commands
<a name="access-api-cli-through-interface-vpc-endpoint-create-interface-endpoint"></a>

Perform the following steps to create an interface endpoint.

1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).

1. In the navigation pane, choose **Endpoints**, **Create Endpoint**.

1. Choose **Create Endpoint**.

1. For **Service category**, ensure that** AWS services** is selected. 

1. For **Service Name**, choose **com.amazonaws.***<AWS Region>***.appstream.api**.

1. Specify the following information. When you're done, choose **Create endpoint**. 
   + For **VPC**, select a VPC in which to create the interface endpoint. 
   + For **Subnets**, select the subnets (Availability Zones) in which to create the endpoint network interfaces. We recommend that you choose subnets in at least two Availability Zones.
   + Optionally, you can select the **Enable Private DNS Name** check box.
**Note**  
If you select this option, ensure that you configure VPC and DNS as needed to support private DNS. For more information, see [Private DNS](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html#vpce-private-dns) in the *Amazon VPC User Guide*.
   + For **Security group**, select the security groups to associate with the endpoint network interfaces. 
**Note**  
The security groups must provide inbound access to the ports from the IP address range from which your users connect.

While your interface endpoint is being created, the status of the endpoint in the console appears as **Pending**. After your endpoint is created, the status changes to **Available.**

# Use an Interface Endpoint to Access WorkSpaces Applications API Operations and CLI Commands
<a name="how-to-access-api-cli-through-interface-vpc-endpoint"></a>

After the status of the interface VPC endpoint that you create changes to **Available**, you can use the endpoint to access WorkSpaces Applications API operations and CLI commands. To do so, specify the `endpoint-url` parameter with the DNS name of the interface endpoint when you use these operations and commands. The DNS name is publicly resolvable, but it only successfully routes traffic in your VPC. 

The following example shows how to specify the DNS name of the interface endpoint when you use the **describe-fleets** CLI command:

```
aws appstream describe-fleets --endpoint-url <vpc-endpoint-id>.api.appstream.<aws-region>.vpce.amazonaws.com
```

The following example shows how to specify the DNS name of the interface endpoint when you instantiate the WorkSpaces Applications Boto3 Python client:

```
appstream2client = boto3.client('appstream',region_name='<aws-region>',endpoint_url='<vpc-endpoint-id>.api.appstream.<aws-region>.vpce.amazonaws.com'
```

Subsequent commands using the `appstream2client` object automatically use the interface endpoint that you specified.

If you enabled the private DNS host names on the interface endpoint, you don’t need to specify the endpoint URL. The WorkSpaces Applications API DNS host name that the API and CLI use by default resolves within your VPC. For more information about private DNS host names, see [Private DNS](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html#vpce-private-dns) in the *Amazon VPC User Guide*.

# Protecting Data in Transit with FIPS Endpoints
<a name="protecting-data-in-transit-FIPS-endpoints"></a>

By default, when you communicate with the WorkSpaces Applications service, whether as an administrator using the WorkSpaces Applications console, the AWS Command Line Interface (AWS CLI), or an AWS SDK, or as a user streaming from an image builder or a fleet instance, all data in transit is encrypted using TLS 1.2.

If you require FIPS 140-2 validated cryptographic modules when accessing AWS through a command line interface or an API, use a FIPS endpoint. WorkSpaces Applications offers FIPS endpoints in all United States AWS Regions where WorkSpaces Applications is available. When you use a FIPS endpoint, all data in transit is encrypted using cryptographic standards that comply with Federal Information Processing Standard (FIPS) 140-2. For information about FIPS endpoints, including a list of WorkSpaces Applications endpoints, see [Federal Information Processing Standard (FIPS) 140-2](https://aws.amazon.com/compliance/fips).

**Topics**
+ [

# FIPS Endpoints for Administrative Use
](FIPS-for-administrative-use.md)
+ [

# FIPS Endpoints for User Streaming Sessions
](FIPS-for-user-streaming-sessions.md)
+ [

# Exceptions
](FIPS-exceptions.md)

# FIPS Endpoints for Administrative Use
<a name="FIPS-for-administrative-use"></a>

To specify a FIPS endpoint when you run an AWS CLI command for WorkSpaces Applications, use the `endpoint-url` parameter. The following example uses the WorkSpaces Applications FIPS endpoint in the US West (Oregon) Region to retrieve a list of all stacks in the Region:

```
aws appstream describe-stacks --endpoint-url https://appstream2-fips.us-west-2.amazonaws.com
```

To specify a FIPS endpoint for WorkSpaces Applications API operations, use the procedure in your AWS SDK for specifying a custom endpoint.

# FIPS Endpoints for User Streaming Sessions
<a name="FIPS-for-user-streaming-sessions"></a>

If you use SAML 2.0 or a streaming URL to authenticate users, you can configure FIPS-compliant connections for your users' streaming sessions.

To use a FIPS-compliant connection for users who authenticate using SAML 2.0, specify an WorkSpaces Applications FIPS endpoint when you configure the relay state of your federation. For more information about constructing a relay state URL for identity federation using SAML 2.0, see [Setting Up SAML](external-identity-providers-setting-up-saml.md).

To configure a FIPS-compliant connection for users who authenticate through a streaming URL, specify an WorkSpaces Applications FIPS endpoint when you call the [CreateStreamingURL](https://docs.aws.amazon.com/appstream2/latest/APIReference/API_CreateStreamingURL.html) or [CreateImageBuilderStreamingURL](https://docs.aws.amazon.com/appstream2/latest/APIReference/API_CreateImageBuilderStreamingURL.html) operation from the AWS CLI or an AWS SDK. A user who connects to a streaming instance using the resulting URL is connected through a FIPS-compliant connection. The following example uses the WorkSpaces Applications FIPS endpoint in the US East (Virginia) Region to generate a FIPS-compliant streaming URL:

```
aws appstream create-streaming-url --stack-name stack-name --fleet-name fleet-name --user-id user-id --endpoint-url https://appstream2-fips.us-east-1.amazonaws.com
```

# Exceptions
<a name="FIPS-exceptions"></a>

FIPS-compliant connections are not supported in the following scenarios:
+ Administration of WorkSpaces Applications through the WorkSpaces Applications console
+ Streaming sessions for users who authenticate using the WorkSpaces Applications user pool feature
+ Streaming using an interface VPC endpoint
+ Generating FIPS-compliant streaming URLs through the WorkSpaces Applications console
+ Connections to your Google Drive or OneDrive storage accounts where your storage provider does not provide a FIPS endpoint

# Security Groups in Amazon WorkSpaces Applications
<a name="managing-network-security-groups"></a>

You can provide additional access control to your VPC from streaming instances in a fleet or an image builder in Amazon WorkSpaces Applications by associating them with VPC security groups. Security groups that belong to your VPC allow you to control the network traffic between WorkSpaces Applications streaming instances and VPC resources such as license servers, file servers, and database servers. For more information, see [Security Groups for your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) in the *Amazon VPC User Guide*.

The rules that you define for your VPC security group are applied when the security group is associated with a fleet or image builder. The security group rules determine what network traffic is allowed from your streaming instances. For more information, see [Security Group Rules](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#SecurityGroupRules) in the *Amazon VPC User Guide*.

You can associate up to five security groups while launching a new image builder or while creating a new fleet. You can also associate security groups with an existing fleet or change the security groups for a fleet (to change security groups for a fleet, you must first stop the fleet). For more information, see [Working with Security Groups](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#WorkingWithSecurityGroups) in the *Amazon VPC User Guide*.

If you don't select a security group, your image builder or fleet is associated with the default security group for your VPC. For more information, see [Default Security Group for Your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#DefaultSecurityGroup) in the *Amazon VPC User Guide*.

Use these additional considerations when using security groups with WorkSpaces Applications.
+ All end user data, such as internet traffic, home folder data, or application communication with VPC resources, are affected by the security groups associated with the streaming instance.
+ Streaming pixel data is not affected by security groups.
+ If you have enabled default internet access for your fleet or image builder, the rules of the associated security groups must allow internet access.

You can create or edit rules for your security groups or create new security groups using the Amazon VPC console. 
+ **To associate security groups with an image builder** — Follow the instructions at [Launch an Image Builder to Install and Configure Streaming Applications](tutorial-image-builder-create.md).
+ **To associate security groups with a fleet**
  + *While creating the fleet* — Follow the instructions at [Create a Fleet in Amazon WorkSpaces Applications](set-up-stacks-fleets-create.md).
  + *For an existing fleet* — Edit the fleet settings using the AWS Management Console.

You can also associate security groups to your fleets using the AWS CLI and SDKs.
+ **AWS CLI** — Use the [create-fleet](https://docs.aws.amazon.com/cli/latest/reference/appstream/create-fleet.html) and [update-fleet](https://docs.aws.amazon.com/cli/latest/reference/appstream/update-fleet.html) commands.
+ **AWS SDKs** — Use the [CreateFleet](https://docs.aws.amazon.com/appstream2/latest/APIReference/API_CreateFleet.html) and [UpdateFleet](https://docs.aws.amazon.com/appstream2/latest/APIReference/API_UpdateFleet.html) API operations.

For more information, see the [AWS Command Line Interface User Guide](https://docs.aws.amazon.com/cli/latest/userguide/) and [Tools for Amazon Web Services](https://aws.amazon.com/tools/).

# Update Management in Amazon WorkSpaces Applications
<a name="update-management"></a>

WorkSpaces Applications provides an automated way to update your image builder with newer WorkSpaces Applications software. When your images are configured to always use the latest WorkSpaces Applications agent version, your streaming instances are automatically updated with the latest features, performance improvements, and security updates that are available from AWS. For information about how to manage WorkSpaces Applications agent versions, see [Manage WorkSpaces Applications Agent Versions](base-images-agent.md). 

You are responsible for installing and maintaining the updates for the Windows operating system, your applications, and their dependencies. For more information, see [Keep Your Amazon WorkSpaces Applications Image Up-to-Date](keep-image-updated.md).

You can keep your WorkSpaces Applications image up-to-date by using managed WorkSpaces Applications image updates. This update method provides the latest Windows operating system updates and driver updates, and the latest WorkSpaces Applications agent software. For more information, see [Update an Image by Using Managed WorkSpaces Applications Image Updates](keep-image-updated-managed-image-updates.md).

To manage updates for applications on your streaming instances, you can use any automatic update services provided. You can also follow the recommendations for installing updates provided by the application vendor. 

# Amazon WorkSpaces Applications Cross-Service Confused Deputy Prevention
<a name="confused-deputy"></a>

The confused deputy problem is a security issue where an entity that doesn't have permission to perform an action coerces a more-privileged entity to perform the action. In AWS, cross-service impersonation can leave account resources vulnerable to the confused deputy problem. Cross-service impersonation occurs when one service (the *calling service*) calls another service (the *called service*). The calling service can manipulate the called service to use its permissions to act on a customer's resources in ways that the calling service doesn't have permission to perform for itself. To prevent this, AWS provides tools that helps you protect your data for all services with service principals that have access to resources in your account.

We recommend using the `aws:SourceArn` and `aws:SourceAccount` global condition context keys in resource policies to limit permissions when accessing these resources. The following guidelines detail recommendations and requirements when you use these keys to protect your resources:
+ Use `aws:SourceArn` if you want only one resource associated with cross-service access.
+ Use `aws:SourceAccount` if you want to allow any resource in the specified account associated with cross-service use.
+ If the `aws:SourceArn` key doesn't contain an account ID, you must use both global condition context keys (`aws:SourceArn` and `aws:SourceAccount`) to limit permissions.
+ If you use both global condition context keys and the `aws:SourceArn` value contains an account ID, the `aws:SourceAccount` key must use the same account ID when used in the same policy statement.

The most effective way to protect against the confused deputy problem is to use the exact Amazon Resource Name (ARN) of the resource you want to allow. If you don't know the full ARN of the resource, use the `aws:SourceArn` global context condition key with wildcards (such as \$1) for the unknown portions of the ARN. You can also use a wildcard in the ARN if you want to specify multiple resources. For example, you can format the ARN as `arn:aws:servicename::region-name::your AWS account ID:*`.

**Topics**
+ [

# Example: WorkSpaces Applications service role cross-service confused deputy prevention
](example-confused-deputy.md)
+ [

# Example: WorkSpaces Applications fleet machine role cross-service confused deputy prevention
](example-fleet-machine.md)
+ [

# Example: WorkSpaces Applications Elastic fleets session script Amazon S3 bucket policy cross-service confused deputy prevention
](example-elastic-fleets.md)
+ [

# Example: WorkSpaces Applications Application Amazon S3 bucket policy cross-service confused deputy prevention
](example-s3-bucket.md)

# Example: WorkSpaces Applications service role cross-service confused deputy prevention
<a name="example-confused-deputy"></a>

WorkSpaces Applications assumes a service role using a variety of resource ARNs, which leads to a complicated conditional statement. We recommend using a wildcard resource type to prevent any unexpected WorkSpaces Applications resources failures.

**Example `aws:SourceAccount` Conditional:**    
****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": [
                    "appstream.amazonaws.com"
                ]
            },
            "Action": "sts:AssumeRole",
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": "your AWS account ID"
                }
            }
        }
    ]
}
```

**Example `aws:SourceArn` Conditional:**    
****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": [
                    "appstream.amazonaws.com"
                ]
            },
            "Action": "sts:AssumeRole",
            "Condition": {
                "ArnLike": {                   
                "aws:SourceArn": "arn:aws:appstream:us-east-1:111122223333:*"
                }
            }
        }
    ]
}
```

# Example: WorkSpaces Applications fleet machine role cross-service confused deputy prevention
<a name="example-fleet-machine"></a>

**Example `aws:SourceAccount` Conditional:**    
****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": [
                    "appstream.amazonaws.com"
                ]
            },
            "Action": "sts:AssumeRole",
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": "your AWS account ID"
                }
            }
        }
    ]
}
```

**Example `aws:SourceArn` Conditional:**  
If you want to use one IAM role for multiple fleets, we recommend using the `aws:SourceArn` global context condition key with wildcards (\$1) to match multiple WorkSpaces Applications fleet resources.  
****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": [
                    "appstream.amazonaws.com"
                ]
            },
            "Action": "sts:AssumeRole",
            "Condition": {
                "ArnLike": {
                "aws:SourceArn": "arn:aws:appstream:us-east-1:111122223333:fleet/your-fleet-name"
                }
            }
        }
    ]
}
```

# Example: WorkSpaces Applications Elastic fleets session script Amazon S3 bucket policy cross-service confused deputy prevention
<a name="example-elastic-fleets"></a>

**Example `aws:SourceAccount` Conditional:**    
****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": [
                    "appstream.amazonaws.com"
                ]
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::your-bucket-name/your-session-script-path",
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": "your AWS account ID"
                } 
            }
        }
    ]
}
```

**Example `aws:SourceArn` Conditional:**    
****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": [
                    "appstream.amazonaws.com"
                ]
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::bucket/AppStream2/*",
            "Condition": {
                "ArnLike": {
                "aws:SourceArn": "arn:aws:appstream:us-east-1:111122223333:fleet/yourFleetName"
                }
            }
        }
    ]
}
```

# Example: WorkSpaces Applications Application Amazon S3 bucket policy cross-service confused deputy prevention
<a name="example-s3-bucket"></a>

When you store data in an Amazon S3 bucket, the bucket might be exposed to confused deputy issues. This can leave data such as Elastic fleets, app blocks, setup scripts, application icons, and session scripts vulnerable to malicious actors.

To prevent confused deputy issues, you can specify the `aws:SourceAccount` condition or the `aws:SourceArn` condition in the Amazon S3 bucket policy for `ELASTIC-FLEET-EXAMPLE-BUCKET`.

The resource policies below show how to prevent the confused deputy problem with either of the following:
+ The `aws:SourceAccount` with your AWS account ID
+ The global condition context key `aws:SourceArn`

WorkSpaces Applications currently doesn't support confused deputy prevention for application icons. The service only supports VHD files and setup scripts. If you try to add additional conditions for application icons, the icons won't be displayed to end users.

In the following example, the bucket policy only allows WorkSpaces Applications Elastic fleet resources in the owner's account to access `ELASTIC_FLEET_EXAMPLE_BUCKET`.

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "ConfusedDeputyPreventionExamplePolicy",
            "Effect": "Allow",
            "Principal": {
                "Service": "appstream.amazonaws.com"
            },
            "Action": "s3:GetObject",
            "Resource": [
                "arn:aws:s3:::ELASTIC-FLEET-EXAMPLE-BUCKET/vhd-folder/*",
                "arn:aws:s3:::ELASTIC-FLEET-EXAMPLE-BUCKET/scripts/*"
            ],
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": "your AWS account ID"
                }
            }
        },
        {
            "Sid": "AllowRetrievalPermissionsToS3AppIconsForAppStream",
            "Effect": "Allow",
            "Principal": {
                "Service": "appstream.amazonaws.com"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::ELASTIC-FLEET-EXAMPLE-BUCKET/app-icons/*"
        }
    ]
}
```

------

You can also use the `aws:SourceArn` condition to limit resource access for specific resources. 

**Note**  
If you don’t know the full ARN of a resource, or you want to specify multiple resources, use the `aws:SourceArn` global context condition key with wildcards (\$1) for the unknown portions of the ARN.

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "ConfusedDeputyPreventionExamplePolicy",
            "Effect": "Allow",
            "Principal": {
                "Service": "appstream.amazonaws.com"
            },
            "Action": "s3:GetObject",
            "Resource": [
                "arn:aws:s3:::ELASTIC-FLEET-EXAMPLE-BUCKET/vhd-folder/*",
                "arn:aws:s3:::ELASTIC-FLEET-EXAMPLE-BUCKET/scripts/*"
            ],
            "Condition": {
                "ArnLike": {
                    "aws:SourceArn": "arn:aws:appstream:us-east-1:111122223333:app-block/*"
                }
            }
        },
        {
            "Sid": "AllowRetrievalPermissionsToS3AppIconsForAppStream",
            "Effect": "Allow",
            "Principal": {
                "Service": "appstream.amazonaws.com"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::ELASTIC-FLEET-EXAMPLE-BUCKET/app-icons/*"
        }
    ]
}
```

------

You can use the `aws:SourceArn` and `aws:SourceAccount` conditions to limit the resource access for specific resources and accounts. 

**Note**  
If you don’t know the full ARN of a resources, or if you want to specify multiple resources, use the `aws:SourceArn` global context condition key with wildcards (\$1) for the unknown portions of the ARN.

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "ConfusedDeputyPreventionExamplePolicy",
            "Effect": "Allow",
            "Principal": {
                "Service": "appstream.amazonaws.com"
            },
            "Action": "s3:GetObject",
            "Resource": [
                "arn:aws:s3:::ELASTIC-FLEET-EXAMPLE-BUCKET/vhd-folder/*",
                "arn:aws:s3:::ELASTIC-FLEET-EXAMPLE-BUCKET/scripts/*"
            ],
            "Condition": {
                "ArnLike": {
                "aws:SourceArn": "arn:aws:appstream:us-east-1:111122223333:app-block/*"
                },
                "StringEquals": {
                    "aws:SourceAccount": "your AWS account ID"
                }
            }
        },
        {
            "Sid": "AllowRetrievalPermissionsToS3AppIconsForAppStream",
            "Effect": "Allow",
            "Principal": {
                "Service": "appstream.amazonaws.com"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::ELASTIC-FLEET-EXAMPLE-BUCKET/app-icons/*"
        }
    ]
}
```

------

# Security Best Practices in Amazon WorkSpaces Applications
<a name="security-best-practices"></a>

 Cloud security at Amazon Web Services (AWS) is the highest priority. Security and compliance is a shared responsibility between AWS and the customer. For more information, refer to the [https://aws.amazon.com/compliance/shared-responsibility-model/](https://aws.amazon.com/compliance/shared-responsibility-model/). As an AWS and WorkSpaces Applications customer, it is important to implement security measures on different layers such as stack, fleet, image, and networking. 

 Due to its ephemeral nature, WorkSpaces Applications is often preferred as a secure solution to application and desktop delivery. Consider whether antivirus solutions that are commonplace in Windows deployments are relevant in your use cases for an environment that is predefined and purged at the end of a user session. Antivirus adds overhead to virtualized instances, making it is a best practice to mitigate unnecessary activities. For example, scanning the system volume (which is ephemeral) at boot, for instance, does not add to the overall security of WorkSpaces Applications. 

 The two key questions for security WorkSpaces Applications are centered on: 
+  Is persisting user state beyond the session a requirement? 
+  How much access should a user have within a session? 

**Topics**
+ [

# Securing Persistent Data
](securing-persistent-data.md)
+ [

# Endpoint Security and Antivirus
](endpoint-security-antivirus.md)
+ [

# Network Exclusions
](network-exclusions.md)
+ [

# Securing an WorkSpaces Applications Session
](securing-session.md)
+ [

# Firewalls and Routing
](firewalls-routing.md)
+ [

# Data Loss Prevention
](data-loss-prevention.md)
+ [

# Controlling egress traffic
](controlling-egress-traffic.md)
+ [

# Using AWS services
](using-services.md)

# Securing Persistent Data
<a name="securing-persistent-data"></a>

 Deployments of WorkSpaces Applications can require the user state to persist in some form. It might be to persist data for individual users, or to persist data for collaboration using a shared folder. AppStream 2.0 instance storage is ephemeral and has no encryption option. 

 WorkSpaces Applications provides user state persistence through home folders and application settings in Amazon S3. Some use cases require greater control over user state persistence. For these use cases, AWS recommends using a Server Message Block (SMB) file share. 

## User state and data
<a name="user-state-and-data"></a>

Because most Windows applications perform best and most securely when co-located with application data created by the user, it is a best practice to keep this data in the same AWS Region as WorkSpaces Applications fleets. Encrypting this data is a best practice. The default behavior of the user home folder is to encrypt files and folders at rest using Amazon S3-managed encryption keys from the AWS key management services (AWS KMS). It is important to note that AWS Administrative Users with access to the AWS Console or Amazon S3 bucket will be able to access those files directly.

In designs that require a Server Message Block (SMB) target from a Windows File Share to store user files and folders, the process is either automatic or requires configuration.

 *Table 5 — Options for securing user data* 


|   **SMB target**   |  **Encryption-at-rest**  |  **Encryption-in-transit**  |   **Antivirus (AV)**   | 
| --- | --- | --- | --- | 
|  FSx for Windows File Server  |  [https://docs.aws.amazon.com/fsx/latest/WindowsGuide/encryption-at-rest.html](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/encryption-at-rest.html)  |  [https://docs.aws.amazon.com/fsx/latest/WindowsGuide/encryption-in-transit.html](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/encryption-in-transit.html)  |   AV installed on a remote instance performs scan on mapped drive   | 
|   **File Gateway, AWS Storage Gateway**   |  By default, all data stored by AWS Storage Gateway in S3 is encrypted server-side with Amazon S3-Managed Encryption Keys (SSE-S3). You can optionally configure different gateway types to encrypt stored data with AWS Key Management Service (KMS)  |  All data transferred between any type of gateway appliance and AWS storage is encrypted using SSL.  |   AV installed on a remote instance performs scan on mapped drive   | 
|  EC2-based Windows File Servers  |  [Enable EBS encryption](https://docs.aws.amazon.com/kms/latest/developerguide/services-ebs.html)  |  PowerShell; Set- SmbServerConfiguration – EncryptData \$1True  |   AV installed on server performs scan on local drives   | 

# Endpoint Security and Antivirus
<a name="endpoint-security-antivirus"></a>

The brief ephemeral nature of WorkSpaces Applications instances and the lack of persistency of data means a different approach is required to ensure user experience and performance is not compromised by activities that would be required on a persistent desktop. Endpoint Security agents are installed in WorkSpaces Applications images when there is an organizational policy or when used with external data ingress e.g. e-mail, files ingress, external web browsing.

## Removing unique identifiers
<a name="removing-unique-iidentifiers"></a>

Endpoint Security agents may have a globally unique identifier (GUID) which must be reset during the fleet instance creation process. Vendors have instructions on installing their products in images which will ensure a new GUID is generated for each instance generated from an image.

To ensure the GUID is not generated, install the Endpoint Security agent as the last action before running the WorkSpaces Applications Assistant to generate the image.

## Performance optimization
<a name="performance-optimization"></a>

Endpoint Security Vendors provide switches and setting that optimize the performance of WorkSpaces Applications. The settings vary between vendors and can be found in their documentation, typically in a section on VDI. Some common settings include but are not limited to are:
+ Turn off boot up scans to ensure instance creation, startup and login times are minimized
+ Turn off scheduled scans to prevent unnecessary scans
+ Turn off signature caches to prevent file enumeration
+ Enable VDI optimized IO settings
+ Exclusions required by applications to ensure performance

Endpoint security vendors provide instructions for use with virtual desktop environments which optimize performance.
+ Trend Micro Office Scan [Support for Virtual Desktop Infrastructure - Apex One/OfficeScan (trendmicro.com)](https://success.trendmicro.com/solution/1055260-best-practice-for-setting-up-virtual-desktop-infrastructure-vdi-in-officescan)
+ CrowdStrike and [How to Install the CrowdStrike Falcon in the Data Center](https://www.crowdstrike.com/blog/tech-center/install-falcon-datacenter/)
+ Sophos and [Sophos Central Endpoint: How to install on a gold image to avoid duplicate identities](https://support.sophos.com/support/s/article/KB-000035040?language=en_US) and [Sophos Central: Best practices when installing Windows Endpoints in Virtual Desktop Environments](https://support.sophos.com/support/s/article/KB-000039009?language=en_US)
+ McAfee and [McAfee Agent provisioning and deployment on Virtual Desktop Infrastructure systems](https://kc.mcafee.com/corporate/index?page=content&id=KB87654)
+ Microsoft Endpoint Security and [Configuring Microsoft Defender Antivirus for non-persistent VDI machines - Microsoft Tech Community](https://techcommunity.microsoft.com/t5/microsoft-defender-for-endpoint/configuring-microsoft-defender-antivirus-for-non-persistent-vdi/ba-p/1489633)

## Scanning exclusions
<a name="scanning-exclusions"></a>

 If security software is installed in WorkSpaces Applications instances, the security software must not interfere with the following processes. 

 *Table 6 — Security software must not interfere with the following processes. This may impact the service availability and performance.* 


|  **Service**  |  **Processes**  | 
| --- | --- | 
|  AmazonCloudWatchAgent  |  "C:\$1Program Files\$1Amazon\$1AmazonCloudWatchAgent\$1start-amazon- cloudwatch-agent.exe"  | 
|  AmazonSSMAgent  |  "C:\$1Program Files\$1Amazon\$1SSM\$1amazon-ssm-agent.exe"  | 
|  Amazon DCV  |  "C:\$1Program Files\$1NICE\$1DCV\$1Server\$1bin\$1dcvserver.exe" "C:\$1Program Files\$1NICE\$1DCV\$1Server\$1bin\$1dcvagent.exe" "C:\$1Program Files\$1NICE\$1DCV\$1Server\$1bin\$1dcvdrivehelper.exe" "C:\$1Program Files\$1NICE\$1DCV\$1Server\$1bin\$1dcvprinterhelper.exe" "C:\$1Program Files\$1NICE\$1DCV\$1Server\$1bin\$1dcvwebauthnnativemsghost.exe" "C:\$1Program Files\$1NICE\$1DCV\$1Server\$1bin\$1dcvwebrtcnativemsghost.exe" "C:\$1Program Files\$1NICE\$1DCV\$1Server\$1bin\$1dcvlogonhelper.exe" "C:\$1Program Files\$1NICE\$1DCV\$1Server\$1bin\$1xpstopdf.exe"  | 
|  WorkSpaces Applications  |   "C:\$1Program Files\$1Amazon\$1AppStream2\$1StorageConnector\$1StorageConnector.exe"   In the folder "C:\$1Program Files\$1Amazon\$1Photon\$1"   ".\$1Agent\$1PhotonAgent.exe"  ".\$1Agent\$1s5cmd.exe"  ".\$1WebServer\$1PhotonAgentWebServer.exe"  ".\$1CustomShell\$1PhotonWindowsAppSwitcher.exe"  ".\$1CustomShell\$1PhotonWindowsCustomShell.exe"  ".\$1CustomShell\$1PhotonWindowsCustomShellBackground.exe"   | 
|  Windows Driver Foundation  |  "C:\$1Windows\$1System32\$1WUDFHost.exe"  | 

## Folders
<a name="folders"></a>

 If security software is installed in WorkSpaces Applications instances, the software must not interfere with the following folders: 

**Example**  

```
    C:\Program Files\Amazon\* 
    C:\ProgramData\Amazon\* 
    C:\Program Files (x86)\AWS Tools\* 
    C:\Program Files (x86)\AWS SDK for .NET\* 
    C:\Program Files\NICE\* 
    C:\ProgramData\NICE\* 
    C:\AppStream\* 
    C:\Program Files\WindowsPowerShell\Modules\AWSPowerShell\*
```

## Endpoint security console hygiene
<a name="endpoint-security-console-hygiene"></a>

WorkSpaces Applications will create new unique instances each time a user connects beyond the idle and disconnect timeouts. The instances will have a unique name and will build up in endpoint security management condoles. Setting unused aged machines over 4 or more days old (or lower depending on WorkSpaces Applications session timeouts) to be deleted will minimize the number of expired instances in the console.

# Network Exclusions
<a name="network-exclusions"></a>

 The WorkSpaces Applications management network range (`198.19.0.0/16`) and following ports and addresses should not be blocked by any security / firewall or antivirus solutions within WorkSpaces Applications instances. 

 *Table 7 — Ports in WorkSpaces Applications streaming instances security software must not interfere with* 


|  **Port**  |   **Usage**   | 
| --- | --- | 
|  8300  |   This is used for establishing the streaming connection   | 
|  3128  |  This is used for managing the streaming instance by WorkSpaces Applications  | 
|  8000  |   This is used for managing the streaming instance by WorkSpaces Applications   | 
|  8443  |   This is used for managing the streaming instance by WorkSpaces Applications   | 
|  53  |   DNS   | 

 *Table 8 — WorkSpaces Applications managed service addresses security software must not interfere with* 


|  **Port**  |  **Usage**  | 
| --- | --- | 
|  169.254.169.123  |  NTP  | 
|  169.254.169.249  |  NVIDIA GRID License Service  | 
|  169.254.169.250  |  KMS  | 
|  169.254.169.251  |  KMS  | 
|  169.254.169.253  |  DNS  | 
|  169.254.169.254  |  Metadata  | 

# Securing an WorkSpaces Applications Session
<a name="securing-session"></a>

## Limiting application and operating system controls
<a name="limiting-application-and-operating-system-controls"></a>

 WorkSpaces Applications gives the administrator the ability to specify exactly which applications can be launched from the web page in application streaming mode. This does not, however, guarantee that only those applications specified can be run. 

 Windows utilities and applications can be launched through the operating system through additional means. AWS recommends using [https://aws.amazon.com/blogs/desktop-and-application-streaming/using-microsoft-applocker-to-manage-application-experience-on-amazon-appstream-2-0/](https://aws.amazon.com/blogs/desktop-and-application-streaming/using-microsoft-applocker-to-manage-application-experience-on-amazon-appstream-2-0/) to ensure that only the applications that your organization requires can be run. The default rules must be modified, as they grant everyone path access to critical system directories. 

**Note**  
 Windows Server 2016 and 2019 require the Windows Application Identity service to be running to enforce AppLocker rules. Application access from WorkSpaces Applications using Microsoft AppLocker is detailed in the [AppStream Admin Guide.](https://docs.aws.amazon.com/appstream2/latest/developerguide/data-protection.html#application-access) 

 For fleet instances joined to an Active Directory domain, use Group Policy Objects (GPOs) to deliver user and system settings to secure the users application and resource access. 

# Firewalls and Routing
<a name="firewalls-routing"></a>

 When creating an WorkSpaces Applications fleet, subnets and a Security Group must be assigned. Subnets have existing assignments of Network Access Control Lists (NACLs) and route table(s). You can associate [up to five security groups](https://docs.aws.amazon.com/appstream2/latest/developerguide/managing-network-security-groups.html) while launching a new image builder or while creating a new fleet Security Groups can have up to [five assignments from the existing Security Groups](https://docs.aws.amazon.com/appstream2/latest/developerguide/managing-network-security-groups.html). For each security group, you add rules that control the outbound and inbound network traffic from and to your instances

A NACL is an optional layer of security for your VPC that acts as a stateless firewall for controlling traffic in and out of one or more subnets. You might set up network ACLs with rules similar to your security groups in order to add an additional layer of security to your VPC. For more information about the differences between security groups and network ACLs, see [the compare security groups and NACLs page](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Security.html#VPC_Security_Comparison).

When designing and applying Security Group and NACL rules, consider the AWS Well-Architected best practices for least privilege. *Least privilege* is a principle of granting only the permissions required to complete a task.

For customers who have a high-speed private network connecting their on premise environment to AWS (via an AWS Direct Connect), you may consider using the VPC Endpoints for AppStream, which will mean the streaming traffic will be routed via your private network connectivity rather than going across the public internet. For more information on this topic, see the WorkSpaces Applications streaming interface VPC endpoint section of this document.

# Data Loss Prevention
<a name="data-loss-prevention"></a>

We'll look at two kinds of data loss prevention.

## Client to AppStream 2.0 Instance Data Transfer Controls
<a name="client-to-AppStream-instance-data-transfer-controls"></a>

 *Table 9 — Guidance for controlling data ingress and egress* 


|  **Setting**  |  **Options**  |  **Guidance**  | 
| --- | --- | --- | 
|  Clipboard  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/appstream2/latest/developerguide/data-loss-prevention.html)  |  Disabling this setting does not disable copy and paste within the session. If copying data into the session is required, choose Paste to remote session only to minimize the potential for data leakage.  | 
|  File transfer  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/appstream2/latest/developerguide/data-loss-prevention.html)  |  Avoid enabling this setting to prevent data leakage.  | 
|  Print to local device  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/appstream2/latest/developerguide/data-loss-prevention.html)  |  If printing is required, use network mapped printers that are controlled and monitored by your organization.  | 

 Consider the advantages of the existing organizational data transfer solution over the stack settings. These configurations are not designed to replace a comprehensive secure data transfer solution. 

# Controlling egress traffic
<a name="controlling-egress-traffic"></a>

Where data loss is a concern, it’s important to cover off what a User can access once they are inside of their WorkSpaces Applications instance. What does the network exit (or egress) path look like? It is a common requirement to have public internet access available to the end user inside their WorkSpaces Applications instance, so placing a WebProxy or Content Filtering Solution in the network path needs to be considered. Other considerations include a local Antivirus application and other endpoint security measures inside the AppStream instance (see the section “Endpoint Security and Antivirus” for more information).

# Using AWS services
<a name="using-services"></a>

## AWS Identity and Access Management
<a name="aws-identity-and-access-management"></a>

 Using an IAM role to access AWS services, and being specific in the IAM policy attached to it, is a best practice that provides only the users in WorkSpaces Applications sessions have access without managing additional credentials. Follow the [https://docs.aws.amazon.com/appstream2/latest/developerguide/using-iam-roles-to-grant-permissions-to-applications-scripts-streaming-instances.html#best-practices-for-using-iam-role-with-streaming-instances](https://docs.aws.amazon.com/appstream2/latest/developerguide/using-iam-roles-to-grant-permissions-to-applications-scripts-streaming-instances.html#best-practices-for-using-iam-role-with-streaming-instances). 

 Create [https://docs.aws.amazon.com/appstream2/latest/developerguide/s3-iam-policy.html](https://docs.aws.amazon.com/appstream2/latest/developerguide/s3-iam-policy.html) that are created to persist user data in both home folders and application settings persistence. This [https://docs.aws.amazon.com/appstream2/latest/developerguide/s3-iam-policy.html#s3-iam-policy-restricted-access](https://docs.aws.amazon.com/appstream2/latest/developerguide/s3-iam-policy.html#s3-iam-policy-restricted-access) from access. 

## VPC endpoints
<a name="vpc-endpoints-1"></a>

 A VPC endpoint enables private connections between your VPC and supported AWS services and VPC endpoint services powered by AWS PrivateLink. AWS PrivateLink is a technology that enables you to privately access services by using private IP addresses. Traffic between your VPC and the other service does not leave the Amazon network. If public internet access is required only for AWS services, VPC endpoints remove the requirement for NAT gateways and internet gateways altogether. 

 In environments where automation routines or developers require making API calls for WorkSpaces Applications, [https://docs.aws.amazon.com/appstream2/latest/developerguide/access-api-cli-through-interface-vpc-endpoint.html](https://docs.aws.amazon.com/appstream2/latest/developerguide/access-api-cli-through-interface-vpc-endpoint.html). For example, if there are EC2 instances in private subnets without public internet access, a VPC endpoint for WorkSpaces Applications API can be used to call AppStream 2.0 API operations such as [https://docs.aws.amazon.com/appstream2/latest/APIReference/API_CreateStreamingURL.html](https://docs.aws.amazon.com/appstream2/latest/APIReference/API_CreateStreamingURL.html). The following diagram shows an example setup where WorkSpaces Applications API and streaming VPC endpoints are consumed by Lambda functions and EC2 instances. 

![\[A reference architecture diagram for VPC endpoint\]](http://docs.aws.amazon.com/appstream2/latest/developerguide/images/vpc-endpoint.jpeg)


 *VPC endpoint* 

 The streaming VPC endpoint allows you to stream sessions through a VPC endpoint. The streaming interface endpoint maintains the streaming traffic within your VPC. Streaming traffic includes pixel, USB, user input, audio, clipboard, file upload and download, and printer traffic. To use the VPC endpoint, the VPC endpoint setting must be enabled at the WorkSpaces Applications stack. This serves as an alternative to streaming user sessions over the public internet from locations that have limited internet access and would benefit from accessing through a Direct Connect instance. Streaming user sessions through a VPC endpoint require the following: 
+  The Security Groups that are associated with the interface endpoint must allow inbound access to port `443` (TCP) and ports `1400–1499` (TCP) from the IP address range from which your users connect. 
+  The Network Access Control List for the subnets must allow outbound traffic from ephemeral network ports `1024-65535` (TCP) to the IP address range from which your users connect. 
+  Internet connectivity is required to authenticate users and deliver the web assets that WorkSpaces Applications requires to function. 

 To learn more about restricting traffic to AWS services with WorkSpaces Applications, see the administration guide for [https://docs.aws.amazon.com/appstream2/latest/developerguide/creating-streaming-from-interface-vpc-endpoints.html](https://docs.aws.amazon.com/appstream2/latest/developerguide/creating-streaming-from-interface-vpc-endpoints.html). 

 When full public internet access is required, it’s a best practice to disable Internet Explorer Enhanced Security Configuration (ESC) on the Image Builder. For more information, see the WorkSpaces Applications administration guide to [https://docs.aws.amazon.com/appstream2/latest/developerguide/customize-fleets.html#customize-fleets-disable-ie-esc](https://docs.aws.amazon.com/appstream2/latest/developerguide/customize-fleets.html#customize-fleets-disable-ie-esc). 

## Configuring the Instance Metadata Service (IMDS) on your instances
<a name="configuring-imds"></a>

This topic describes the Instance Metadata Service (IMDS).

*Instance metadata* is data that's related to an Amazon Elastic Compute Cloud (Amazon EC2) instance that applications can use to configure or manage the running instance. The instance metadata service (IMDS) is an on-instance component that code on the instance uses to securely access instance metadata. For more information, see [Instance metadata and user data](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html) in the *Amazon EC2 User Guide*.

Code can access instance metadata from a running instance using one of two methods: Instance Metadata Service Version 1 (IMDSv1) or Instance Metadata Service Version 2 (IMDSv2). IMDSv2 uses session-oriented requests and mitigates several types of vulnerabilities that could be used to try to access the IMDS. For information about these two methods, see [Configuring the instance metadata service](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html) in the *Amazon EC2 User Guide*.

### Resource support for IMDS
<a name="imds-resource-support"></a>

Always-On, On-Demand, Single-Session, and Multi-Session Fleets, and all Image Builders support both IMDSv1 and IMDSv2 when running WorkSpaces Applications images with the agent version or managed image update released on or after January 16, 2024.

Elastic Fleets and AppBlock Builders instances also support both IMDSv1 and IMDSv2.

### Example of IMDS attribute settings
<a name="imds-examples"></a>

Below are two examples of choosing the IMDS method:

#### Java v2 SDK example
<a name="java-sdk-example"></a>

Below example request disable IMDSv1 using `disableIMDSV1` attributes

```
CreateFleetRequest request = CreateFleetRequest.builder()
 .name("TestFleet")
 .imageArn("arn:aws:appstream:us-east-1::image/TestImage")
 .instanceType("stream.standard.large")
 .fleetType(FleetType.ALWAYS_ON)
 .computeCapacity(ComputeCapacity.builder()
 .desiredInstances(5)
 .build())
 .description("Test fleet description")
 .displayName("Test Fleet Display Name")
 .enableDefaultInternetAccess(true)
 .maxUserDurationInSeconds(3600)
 .disconnectTimeoutInSeconds(900)
 .idleDisconnectTimeoutInSeconds(600)
 .iamRoleArn("arn:aws:iam::123456789012:role/TestRole")
 .streamView(StreamView.APP)
 .platform(PlatformType.WINDOWS)
 .maxConcurrentSessions(10)
 .maxSessionsPerInstance(2)
 .tags(tags)
 .disableIMDSV1(true)
 .build();
```

Set **disableIMDSV1** to true to disable IMDSv1 and enforce IMDSv2.

Set **disableIMDSV1** to false to enable both IMDSv1 and IMDSv2.

#### CLI Example
<a name="cli-example"></a>

Below example request disable IMDSv1 using `--disable-imdsv1` attributes

```
aws appstream create-fleet --name test-fleet --image-arn "arn:aws:appstream:us-east-1::image/test-image" --disable-imdsv1 --instance-type stream.standard.small --compute-capacity DesiredInstances=2 --max-user-duration-in-seconds 57600 --disconnect-timeout-in-seconds 57600 --region us-east-1
```

Set `--disable-imdsv1` to true to disable IMDSv1 and enforce IMDSv2.

Set `--no-disable-imdsv1` to false to enable both IMDSv1 and IMDSv2.