Amazon WorkSpaces FAQs

• Apple iPadOS based iPad, iPad Pro, iPad Mini, iPad Air

• Android-compatible ChromeOS devices 

• Android phones and tablets

No. Your custom WorkSpaces or WorkSpaces Pools that support BYOL for Windows 10 or Windows 11 Desktops are launched on physically dedicated hardware to meet license compliance requirements with Microsoft. WorkSpaces launched in a directory marked for dedicated hardware can only be from the custom bundle you created that has your Windows 10 or Windows 11 Desktop image.

If you wish to launch WorkSpaces from public bundles to users in the same domain, you can create a new AWS AD Connector directory that points to the same Microsoft Active Directory as your Windows 10 or Windows 11 Desktop WorkSpaces or Pools, and launch WorkSpaces or Pools in that directory as you normally would through the AWS Management Console or the WorkSpaces SDK and CLI.

• Keyboard, mouse, and touch input (touch input is only supported on tablet clients). Amazon WorkSpaces do not currently support 3D mice.

• Audio output to client device

• Analog and USB headsets

• The number of screens it has to stream to.

• The amount of pixel changes taking place in each screen.

• The resolution of each monitor being used.

• Windows WorkSpaces Personal: Use Group Policy. Refer to our documentation on Managing Windows WorkSpaces for more information.

• Amazon Linux 2 WorkSpaces Personal: Modify the configuration files on your WorkSpaces. Refer to our documentation on Managing Amazon Linux WorkSpaces for more information.

• Ubuntu WorkSpaces Personal: Modify the configuration files on your WorkSpaces. Refer to our documentation on Managing Ubuntu WorkSpaces for more information. 

• Red Hat Enterprise Linux WorkSpaces Personal: Modify the configuration files on your WorkSpaces. Refer to our documentation on Managing Red Hat Enterprise Linux WorkSpaces for more information.

• Rocky Linux WorkSpaces Personal: Modify the configuration files on your WorkSpaces. Refer to our documentation on Managing Rocky Linux WorkSpaces for more information.

• WorkSpaces Pool: Change the settings on your WorkSpaces Pool Directory, which will alter the settings for the entire pool at once. Refer to our documentation on WorkSpaces Pools Directory configurations for more information.

WorkSpaces Personal supports the following operating systems:

• Provided by AWS: Windows Server 2016, Windows Server 2019, Windows Server 2022, Amazon Linux 2, Ubuntu 22.04, Rocky Linux 8, and Red Hat Enterprise Linux 8

• Bring Your Own License: Windows 10 and Windows 11. See our BYOL documentation to see the current supported versions information.

WorkSpaces Personal offers two pricing options, which can be changed at any time. AlwaysOn virtual desktops are billed at a predictable, flat monthly rate for unlimited usage and provide instant access for users who use the service as their primary desktop. AutoStop hourly metering stops billing when a virtual desktop is not in use, preserving the state of apps and data, and resumes automatically when users sign on. Billing for AutoStop virtual desktops includes a low monthly base fee and an hourly fee when the instance is in use. See the WorkSpaces Pricing page for more detail.

Amazon WorkSpaces Personal offers a variety of hardware options, including GPU options. For more information on the options and the workloads they are appropriate for, see our bundle documentation.

Yes, you can alter the compute type configuration of a WorkSpace after it is deployed. See our Modify a WorkSpace documentation for more information.

Yes. You can increase the size of the root and user volumes attached to your WorkSpaces Personal at any time. For more information, see our documentation on Modifying WorkSpaces.

No. To ensure that your data is preserved, the volume sizes of either volume cannot be reduced after a WorkSpace is launched.

For either change, you get charged the monthly price for AlwaysOn or the monthly fee for AutoStop WorkSpaces prorated on a per-day basis.

For example, if you increase the volume on the 10th of a month on an AlwaysOn Power WorkSpace with 175 GB, and 100 GB for root and user volumes respectively, you are charged $78.00 for the Power WorkSpace and $11.60 for 20 days of additional 175 GB at $0.10/GB-month (in us-east-1). Similarly, switching a bundle—for example, from Value to Standard—on the 15th of a month results in 15 days of Value WorkSpaces charge ($12.50 in US-East-1) and 15 days of Standard WorkSpaces charge ($17.50 in US-East-1).

You can increase volume sizes or change a WorkSpace to a larger hardware bundle once in a 6-hour period. You can also change to a smaller hardware bundle once in a 30-day period. For a newly launched WorkSpace, you must wait 6 hours before requesting a larger bundle.

For example, if you increase the root and user volume of a Standard WorkSpace on 5th Dec at 11:00 AM and change it to Performance WorkSpace at the same time, on 5th Dec at 4:00 PM, you can again increase the root and user volume, and change the hardware bundle. If you change the Performance WorkSpace to a Standard WorkSpace on 6th Dec at 12:00 and want to go to a further smaller bundle (Value), you would be able to make this change on 6th Jan at 12:00.

WorkSpaces Migration allows you to move WorkSpaces Personal end users to a new operating system or baseline custom image without losing user profile data. For more information, see our documentation on migration.

All data in the latest snapshot of the original user volume will be retained. For a Windows WorkSpace, the D drive data captured by the latest snapshot will be retained after migration and the C drive will be newly created from the target bundle image. In addition, migrate attempts to move data from the old user profile to the new one. Data that cannot be moved to the new profile will be preserved in a .notMigrated folder. For more information, refer to the documentation.

Yes. The WorkSpaces migrate function allows you to replace your WorkSpaces instance root volume with a base image from another bundle. Migrate will recreate the WorkSpace using a new root volume from the target bundle image, and the user volume from the latest original user volume snapshot. For detailed information about migrate, refer to the documentation.

Migrate associates your WorkSpace with a new bundle. A rebuild after migration will use the newly associated bundle to generate the root volume.

An image contains only the OS, software and settings. A bundle is a combination of both that image and the hardware from which a WorkSpace can be launched. See our documentation for more an overview on images and bundles. Bundles are only used with WorkSpaces Personal and do not apply to WorkSpaces Pools.

Yes. You can update an existing bundle with a new image that contains the same tier of software (for example, containing the Plus software) as the original image. See our documentation for more information.

Yes. Amazon WorkSpaces enables maintenance windows for both AlwaysOn and AutoStop WorkSpaces by default. For AlwaysOn (monthly) WorkSpaces, the maintenance schedule is controlled by the OS settings on the WorkSpace. The default maintenance window is a four-hour period from 00h00 – 04h00 (this time window is based on the time zone settings you have set for your Amazon WorkSpaces) each Sunday morning. During this time your WorkSpaces may not be available. For AutoStop (hourly) WorkSpaces, the default maintenance window is typically from 00h00 to 05h00 everyday starting on the 3rd Monday of the month in the time zone of the WorkSpaces AWS region. The Maintenance window might take up to two weeks. WorkSpaces can be maintained on any day in the maintenance window. You can set the Maintenance mode for AutoStop WorkSpaces in the WorkSpaces management console. For more information see Manage the WorkSpace Running Mode. The maintenance window for AutoStop WorkSpaces is currently not configurable.

It is highly recommended to keep your WorkSpaces maintained regularly. If you want to run your own WorkSpaces maintenance schedule, it is possible to opt out of the service default maintenance windows for Windows WorkSpaces. For AutoStop (hourly) WorkSpaces, you can disable the Maintenance mode on the console. For AlwaysOn Windows WorkSpaces, the maintenance window is controlled by the system settings and can be configured via Automatic Updates GPO settings. Currently, you cannot opt out of the maintenance windows for AlwaysOn Amazon Linux Ubuntu, Rocky Linux, and Red Hat Enterprise Linux WorkSpaces.

WorkSpaces Personal provides users with Linux and Windows cloud desktops. The underlying OS, and any applications installed in the WorkSpace may need updates.

By default, your Amazon WorkSpaces are configured to install software updates. Amazon Linux, Ubuntu, Rocky Linux, and Red Hat Enterprise Linux WorkSpaces will be updated to install the latest security and software patches, and Amazon WorkSpaces with Windows have Windows Updates turned on. Updates to Applications installed via Manage applications are included as part of your regular Windows Updates. You can customize these settings, or use an alternative patch management approach. Updates are installed at 2am each Sunday. You are responsible to update any 3rd party application that you have installed on your WorkSpaces.

No action is needed on your part. Updates are delivered automatically to your WorkSpaces during the maintenance window. During the maintenance window, your WorkSpaces may not be available.

No. The Amazon WorkSpaces service requires these updates to be provided to ensure normal operation of your users’ WorkSpaces.

You have full control over the Windows update configuration in your WorkSpaces, and can use Active Directory Group Policy to configure this to meet your exact requirements. If you would like to have advance notice of patches so you can plan appropriately we recommend you refer to Microsoft Security Bulletin Advance Notification for more information.

Amazon WorkSpaces running Amazon Linux 2, Ubuntu, Rocky Linux, and Red Hat Enterprise Linux are updated via pre-configured software repositories repositories hosted in each WorkSpaces region. Updates are automatically installed. Patches and updates requiring a reboot are installed during our weekly maintenance window. For all other applications, updates can be delivered via the automatic update service for each application if one is available. For applications without an automatic update service, you will need to evaluate the software vendor’s recommended updating approach and follow that if necessary.

The AWS Console lets you provision, restart, rebuild, restore, and delete WorkSpaces. To manage the underlying OS for the WorkSpaces, you can use standard Microsoft Active Directory tools such as Group Policy or your choice of Linux orchestration tools to manage the WorkSpaces. In the case when you have integrated WorkSpaces with an existing Active Directory domain, you can manage your WorkSpaces using the same tools and techniques you are using for your existing on-premises desktops. If you have not integrated with an existing Active Directory, you can set up a Directory Administration WorkSpace to perform management tasks. See the documentation for more information. You can also give WorkSpaces users the ability to perform common tasks on their own by enabling self-service management. Once enabled, WorkSpaces users can do things like restart, rebuild, restore, increase volume size, change compute type, and change running mode directly from the WorkSpaces client with no IT or helpdesk intervention.

Yes, you can assign tags to existing WorkSpaces resources including WorkSpaces, directories registered with WorkSpaces, images, custom bundles, and IP Access Control Groups. You can also assign tags during the creation of new WorkSpaces and new IP Access Control Groups. You can assign up to 50 tags (key/value pairs) to each WorkSpaces resource using the AWS Management Console, the AWS Command Line Interface, or the Amazon WorkSpaces API. To learn more about assigning tags to your Amazon WorkSpaces resources, follow the steps listed on this web page: Tag WorkSpaces Resources.

Yes. You can use the AWS Console to control whether Amazon WorkSpaces in your directory can be accessed using Web Access, by visit the directory details page. Note: this setting can only be applied to all WorkSpaces in a directory, not at an individual Amazon WorkSpace level.

A restart is just the same as a regular operating system (OS) reboot. A rebuild will retain the user volume on the WorkSpace but will return the WorkSpace to its original state (any changes made to the system drive will not be retained).

A rebuild will retain the user volume on the WorkSpace but will return the WorkSpace to its original state (any changes made to the system drive will not be retained). A restore will retain both the root and user volumes on the WorkSpace but will return the WorkSpace to the last healthy state as detected by the service.

To remove a WorkSpace you no longer require, you can “delete” the Workspace. This will remove the underlying instance supporting the WorkSpace and it will no longer exist. Deleting a WorkSpace will also remove any data stored on the volumes attached to the WorkSpace, so confirm you have saved any data you must keep prior to deleting a WorkSpace.

No. You can currently only provide one WorkSpace for each user.

You can launch as many WorkSpaces as you need. WorkSpaces sets default limits, but you can request an increase in these limits here. To see the default limits for WorkSpaces, visit our documentation.

If either AD Connector or AWS Microsoft AD is used to integrate with an existing Active Directory domain, the user would follow your existing lost password process for your domain, such as contacting an internal helpdesk. If the user is using credentials stored in a directory managed by the WorkSpaces service, they can reset their password by clicking on the “Forgot Password” link in the Amazon WorkSpaces client application.

To remove a user’s access to their WorkSpace, you can disable their account either in the directory managed by the WorkSpaces service, or in an existing Active Directory that you have integrated the WorkSpaces service with.

Yes. WorkSpaces Personal supports AD and non-AD domain joined virtual desktops. To use Entra ID for identity management, AWS IAM Identity Center (IdC) acts as an identity broker to ensure user identity data automatically remains synchronized between AWS and cloud-based identity providers like Entra ID. WorkSpaces Personal also natively supports Intune. Leveraging Windows Autopilot, Windows 10 and 11 virtual desktops are automatically enrolled to Intune during provisioning and later joined to Entra ID.

An IP Access Control Group is a feature that lets you specify trusted IP addresses that are permitted to access your WorkSpaces. An Access Control group is made up of a set of rules, each rule specifies a specific permitted IP address or range of addresses. you can create up to 25 IP Access Control groups with up to 10 rules per group specifying the IP addresses or IP ranges accessible to your Amazon WorkSpaces.

Yes. With this feature you can create up to 25 IP Access Control groups with up to 10 rules per group specifying the IP addresses or IP ranges accessible to your Amazon WorkSpaces.

See IP Access Control Groups for details.

Yes. This feature can be used with the macOS, iPad, Windows desktop, Android tablet, and Web Access. This feature also supports zero clients using MFA.

Yes. The initial connection would require an IP address on the allowed list. If Web Access is enabled when accessing WorkSpaces through the Web Access client, if the approved IP address changes to an unapproved IP address, after the user’s credentials are validated and before the WorkSpaces session begins to launch, that unapproved IP address would be able to access a WorkSpace.

Zero Clients using MFA can be used with IP Based Access Controls, along with any compatible Zero Clients which do not use PCoIP Connection Manager to connect to WorkSpaces. Any connections through PCoIP Connection Manager will not be able to access WorkSpaces if IP Based Access Controls are enabled.

WorkSpaces supports the use of the URI (uniform resource identifier) WorkSpaces:// to open the WorkSpaces client and optionally enter the registration code, user name, and/or multi-factor authentication (MFA) code (if MFA is used by your organization).

You can create your unique URI links by following the WorkSpaces URI formatting documented in Customize How Users Log in to their WorkSpaces in the Amazon WorkSpaces Administration Guide. By providing these links to users, you enable them to use the URI on any device that has the WorkSpaces client installed. URI links can contain human-readable sensitive information if you choose to include the registration code, user name, and/or MFA information, so take precautions with how and whom you share URI information.

Yes. You can restrict access to WorkSpaces based on the client OS type, and using digital certificates. You can choose to block or allow macOS, Microsoft Windows, Linux, iPadOS, Android, ChromeOS, zero client, and the WorkSpaces Web Access client.

Yes. WorkSpaces supports root volume and user volume encryption. WorkSpaces uses EBS volumes that can be encrypted on creation of a WorkSpace, providing encryption for data stored at rest, disk I/O to the volume, and snapshots created from the volume. WorkSpaces integrates with the AWS KMS service to allow you to specify the keys you want to use to encrypt the volumes. For more information, see our documentation on encrypted WorkSpaces.

There is no additional charge for encrypting volumes on WorkSpaces, however you will have to pay standard AWS KMS charges for KMS API requests and any custom CMKs that are used to encrypt WorkSpaces. see AWS KMS pricing here. Note that the Amazon WorkSpaces services makes a maximum of five API calls to the KMS service upon launching, restarting or rebuilding a single WorkSpace.

You will be able to see if a WorkSpace is encrypted or not from the AWS Management Console or using the Amazon WorkSpaces API. In addition to that, you will also be able to tell which volume(s) on the WorkSpace were encrypted, and the key ARN that was used to encrypt the WorkSpace. For example, the DescribeWorkSpaces API call will return information about which volumes (user and/or root) are encrypted and the key ARN that was used to encrypt the WorkSpace.

Encryption of WorkSpaces is only supported during the creation and launch of a WorkSpace.

WorkSpaces does not support disabling encryption for a running WorkSpace. Once a WorkSpace is launched with encryption enabled, it will always remain encrypted.

A PC-over-IP (PCoIP) Zero Client is a single-purpose hardware device that can enable access to WorkSpaces. Zero Clients include hardware optimization specifically for the PCoIP protocol, and are designed to require very little administration.

You can use Amazon WorkSpaces Personal with PCoIP Zero Clients. PCoIP Zero Clients will only work with PCoIP WorkSpaces, they will not work with DCV WorkSpaces. For more information reference Teradici's website.

Zero Clients should be updated to firmware version 4.6.0 (or newer). The WorkSpace will need to be using the PCoIP protocol, as the Amazon DCV protocol does not support PCoIP Zero Clients. You will need to run the PCoIP Connection Manager to enable the clients to successfully connect to Amazon WorkSpaces. Consult the Amazon WorkSpaces documentation for a step by step guide on how to properly setup the PCoIP Connection Manager, and for help on how to find and install the necessary firmware required for your Zero Clients.

WorkSpaces Personal preserves the data and state of your applications when stopped. On reconnect, your WorkSpace will resume with all open documents and running programs intact. AutoStop Graphics.g4dn, GraphicsPro.g4dn, Graphics, and GraphicsPro WorkSpaces do not preserve the state of data and programs when they stop. For these Autostop WorkSpaces, we recommend saving your work when you’re done using them each time.

By logging into WorkSpaces from the Amazon WorkSpaces client application, the service will automatically restart your WorkSpace. When you first attempt to log in, the client application will notify you that your WorkSpace was previously stopped, and that your new session will start once your WorkSpace has resumed.

If your WorkSpace has not yet stopped, your connection is almost instantaneous. If you WorkSpace has already stopped, in most cases it will be available within two minutes. For BYOL AutoStop WorkSpaces, a large number of concurrent logins could result in significantly increased time for a WorkSpace to be available. If you expect many users to log into your BYOL AutoStop WorkSpaces at the same time, please consult your account manager for advice.

Audio optimization with Connect is available on the WorkSpaces directory level. The feature enables customers to offload the CCP (Contact Control Panel) audio traffic from WorkSpaces streaming to local endpoint processing, which addresses audio quality issues related to suboptimal network conditions.

To launch a WorkSpace to be billed hourly, simply select a user, choose an WorkSpaces bundle (a configuration of compute resources and storage space), and specify the AutoStop running mode. When your Amazon WorkSpace is created, it will be billed hourly.

With monthly billing, you pay a fixed monthly fee for unlimited usage and instant access to a running Amazon WorkSpace at all times. Hourly pricing allows you to pay for your Amazon WorkSpaces by the hour and save money on your AWS bill when your users only need part-time access to their Amazon WorkSpaces. When WorkSpaces being billed hourly are not being used, they automatically stop after a specified period of inactivity, and hourly usage metering is suspended.

Amazon WorkSpaces operates in two running modes – AutoStop and AlwaysOn. The AlwaysOn running mode is used when paying a fixed monthly fee for unlimited usage of your Amazon WorkSpaces. This is best when your users need high availability and instant access to their desktops, especially when many users need to log into WorkSpaces around the same time. The AutoStop running mode allows you to pay for your Amazon WorkSpaces by the hour. This running mode is best when your users can wait for around 2 minutes to start streaming desktops that have sporadic use. Consult AWS representative for more information about login concurrency and running modes. You can easily choose between monthly and hourly billing by selecting the running mode when you launch Amazon WorkSpaces through the AWS Management Console, the Amazon WorkSpaces APIs, or the Amazon WorkSpaces Command Line Interface. You can also switch between running modes for your Amazon WorkSpaces at any time.

Hourly usage fees start accruing as soon as WorkSpace is running. Your Amazon WorkSpace may resume in response to a login request from a user, or to perform routine maintenance.

Hourly usage charges are suspended when your WorkSpaces stop. AutoStop automatically stops your WorkSpaces for a specified period of time after users disconnect, or when scheduled maintenance is completed. The specified time period is configurable and is set to 60 minutes by default. Note that partial hours are billed as a full hour, and the monthly portion of hourly pricing does not suspend when your Amazon WorkSpaces stop.

You can manually stop WorkSpaces from the AWS Management Console, or by using the WorkSpaces APIs. To stop the monthly fee associated with hourly WorkSpaces, you need to remove the Amazon WorkSpaces from your account (note: this also deletes all data stored in those Amazon WorkSpaces).

Yes, you can switch from hourly to monthly billing for WorkSpaces Personal at any time by switching the running mode to AlwaysOn in the AWS Management Console, or through the WorkSpaces APIs. When you switch, billing immediately changes from hourly to monthly, and you are charged a prorated amount at the monthly rate for the remainder of the month for AlwaysON, along with the base monthly fee and hourly usage fees of AutoStop that have been already billed for the month. Your Amazon WorkSpaces will continue to be charged monthly unless you switch the running mode back to AutoStop. You can switch from monthly to hourly billing by setting the running mode to AutoStop in the AWS Management Console or through the WorkSpaces APIs. Switching from monthly to hourly billing will take effect the following month as you will have already paid for WorkSpaces for that month. Your Amazon WorkSpaces will continue to be charged hourly unless you switch the running mode back to AlwaysOn. Note that billing renewals happen at 00:00 UTC Time on the first of each month. WorkSpaces users can also switch between monthly and hourly billing directly from the WorkSpaces client if this self-service management capability is enabled by their WorkSpaces administrator.

Yes. Amazon provides the Cost Optimizer for Amazon WorkSpaces, which analyzes usage data to determine the most cost-effective billing option. It outputs a daily report, and can optionally convert WorkSpaces to the most cost-effective billing option.

If you’re paying for WorkSpaces monthly, your WorkSpaces are charged for the full month’s usage. If you’re paying hourly (AutoStop running mode), you are charged for the hours during which your Amazon WorkSpaces are running or undergoing maintenance, plus a monthly fee for fixed infrastructure costs. In both cases, the monthly fee is prorated in the first month only.

Yes, you will be charged a small monthly fee for the Amazon WorkSpaces bundle you selected. If you’ve chosen an Amazon WorkSpaces Plus bundle, you will be charged for the software subscription as well. You can find the monthly fees for all Amazon WorkSpaces on the pricing page here.

Plus bundles are always charged monthly, even if you’re paying forWorkSpaces by the hour. If you selected a Plus bundle when you launched your WorkSpaces, you will incur the listed fee for the Plus software bundle even if you do not use those Amazon WorkSpaces in a particular month.

Yes, you will be able to monitor the total number of hours WorkSpaces has been running in a given period of time through the CloudWatch “UserConnected” metric.

Yes. You can use AD Connector to proxy Active Directory authentication requests to your existing Active Directory. For more information, see the AD Connector documentation. When you use the Small size of AD Connector, it is free when at least 1 WorkSpace is associated to it in a given billing cycle. When you use the Large size of AD Connector, it is free with at least 100 WorkSpaces associated to in a given billing cycle. For more information on this, see the note about Amazon WorkSpaces on the Other Directories pricing page for AWS Directory Services. You can also use AWS Managed Microsoft AD to integrate with your existing on-premises Active Directory with a forest trust relationship. For more information, see our trust documentation for Microsoft Managed AD.

Each user you provision a WorkSpace Personal for needs to exist in a directory, but you do not have to provision a directory yourself. You can either have the WorkSpaces service create and manage a directory for you and have users in that directory created when you provision a WorkSpace. Alternatively, you can integrate WorkSpaces with an existing, on-premises Active Directory so that users can continue to use their existing credentials meaning that they can get seamless applications to existing applications.

Yes. See our documentation for more details.

You may keep your AWS directory in the cloud and use it to domain join EC2 instances or provide directory users access to the AWS Management Console. You may also delete your directory. If there are no WorkSpaces being used with your Simple AD or AD Connector for 30 consecutive days, this directory will be automatically deregistered for use with Amazon WorkSpaces, and you will be charged for this directory as per the AWS Directory Service pricing terms. If you delete your Simple AD or AD Connector you can always create a new one when you want to start using WorkSpaces again.

Amazon WorkSpaces is integrated with both CloudWatch Metrics and CloudWatch Events.
You can use Amazon CloudWatch Metrics to review health and connection metrics for individual WorkSpaces and all WorkSpaces belonging to a directory. You can set up CloudWatch Alarms on these metrics to be alerted about changes to WorkSpaces health, or about issues your users may have connecting to their WorkSpaces.
You can use CloudWatch Events to view, search, download, archive, analyze, and respond to successful WorkSpace logins. Amazon WorkSpaces client applications send WorkSpaces Access events to CloudWatch Events when a user successfully logs in to a WorkSpace. All Amazon WorkSpaces client applications send these events.

Yes, you will be able to monitor the total number hours your WorkSpaces have been running in a given period of time through CloudWatch “UserConnected” metric.

CloudWatch Metrics are available with WorkSpaces in all AWS regions where WorkSpaces is available.

There is no additional cost for using CloudWatch Metrics with WorkSpaces via the CloudWatch console. There may be additional charges for setting up CloudWatch Alarms and retrieving CloudWatch Metrics via APIs. See CloudWatch pricing for more information.

CloudWatch Metrics are enabled by default for all your WorkSpaces. Visit the AWS Management Console to review the metrics and set up alarms.

See the documentation for more information on CloudWatch metrics with WorkSpaces.

• The following metrics are currently supported for reporting on Amazon WorkSpaces usage:

• Available 

• Unhealthy 

• ConnectionAttempt 

• ConnectionSuccess 

• ConnectionFailure 

• SessionLaunchTime 

• InSessionLatency 

• SessionDisconnect 

• UserConnected 

• Stopped

• Maintenance 

• TrustedDeviceValidationAttempt 

• TrustedDeviceValidationSuccess 

• TrustedDeviceValidationFailure 

• TrustedDeviceCertificateDaysBeforeExpiration 

• CPUUsage 

• MemoryUsage 

• RootVolumeDiskUsage 

• UserVolumeDiskUsage 

• UDPPacketLossRate 

• UpTime

See Monitor your WorkSpaces using CloudWatch metrics for more information.

Yes. WorkSpaces sends metrics to CloudWatch every 5 minutes, with at least a delay of 15 minutes for Always On instances. If an Auto Stop WorkSpaces instance stops before this time, the generated metrics will be sent to CloudWatch as soon as that instance comes back on. So, Auto Stop WorkSpaces instances may take more time to be delivered.

Successful WorkSpace logins. Amazon WorkSpaces sends access event information to CloudWatch Events when a user successfully logs in to a WorkSpace from any WorkSpaces client application.

You can use CloudWatch Events to view, search, download, archive, analyze, and respond based on rules that you configure. You can either use the AWS Console under CloudWatch to view and interact with CloudWatch Events or use services such as Lambda, ElasticSearch, Splunk and other partner solutions using Kinesis Streams or Firehose to take actions based on your event data. For storage, CloudWatch Events recommends using Kinesis to push data to S3. For more information on how to use CloudWatch Events, see the Amazon CloudWatch Events User Guide.

Events are represented as JSON objects which include WAN IP address, WorkSpaces ID, Directory ID, Action Type (ex. Login), OS platform, Timestamp and a Success/Failure indicator for each successful login to WorkSpaces. See our documentation for more details here.

There is no additional cost for using CloudWatch Events withWorkSpaces. You will be charged for any other services you use that take action based on CloudWatch Events, such as Amazon ElasticSearch, and AWS Lambda. This also includes other CloudWatch services such as CloudWatch Metrics, CloudWatch Logs, and CloudWatch Alarms if your usage surpasses the CloudWatch Free Tier limits. All of these services are integrated with and can be triggered from CloudWatch Events.

You can choose to let users accomplish typical management tasks for their own WorkSpace, including restart, rebuild, change compute type, and change disk size. You can also let users switch from monthly to hourly billing (and back). You can choose to enable specific self-service management capabilities that suit your needs directly in the WorkSpaces Admin Console. For more information, see Enable self-service WorkSpace management capabilities for your users.

Self-service management capabilities are enabled by default when you register a directory with WorkSpaces. You can choose to not enable them when you register a directory. You can modify specific self-service management capabilities from the WorkSpaces console. On the Directories page, select the directory you want to modify for self-service management. Next, select “Update Details” under the “Actions” menu. You can find all self-service management capabilities options under the “User Self Service Permissions” section. You can also use WorkSpaces APIs to modify self-service management capabilities.

Self-service management capabilities are available to users through the WorkSpaces client on Windows, Mac, Android, and ChromeOS devices supporting Android apps.

Yes, you must authenticate to use any self-service management capabilities.

You can continue to use your WorkSpace while disk size or running mode is being changed. Restarting, rebuilding, restoring, and changing compute type requires disconnecting from your WorkSpaces session.

Self-service management capabilities are available at no additional cost. You can enable self-service management for tasks such as changing the WorkSpace bundle type, or increasing the volume size. When end users perform these tasks, the billing rate for those WorkSpaces may change.

To reduce downtime from maintenance and disruptive events, deploy WorkSpaces Personal in multiple Regions, making sure that regional WorkSpaces maintenance schedules do not overlap. Use cross-Region redirection, so that you can direct users to WorkSpaces Regions not under maintenance. For more information on WorkSpaces cross-Region redirection, refer to Amazon WorkSpaces documentation.

Amazon WorkSpaces Multi-Region Resilience provides automated, redundant virtual desktop infrastructure in a secondary WorkSpaces Region and streamlines the process of redirecting users to the secondary Region when the primary Region is unreachable due to outages.

Use WorkSpaces Multi-Region Resilience with cross-Region redirection to deploy redundant virtual desktop infrastructure in a secondary WorkSpaces Region and design a cross-Region failover strategy in preparation for disruptive events. Leveraging Domain Name System(DNS) failover and health-check capabilities, WorkSpaces cross-Region redirection points your users to log into WorkSpaces in a disaster recovery Region when the primary WorkSpaces Region is not reachable. To learn more, refer Amazon WorkSpaces documentation on WorkSpaces Multi-Region Resilience and cross-Region redirection.

WorkSpaces standby configuration for Multi-Region Resilience automates the creation and maintenance of standby deployments. After setting up a user directory in your preferred secondary Region, simply select the WorkSpaces in your primary Region that you want to create standby WorkSpaces for, either through the AWS management console or the AWS SDK. The system will automatically provision standby WorkSpaces in your secondary Region, using the latest bundle of your primary WorkSpaces. By default, the system does not replicate the user volume (D drive) or the root volume (C drive) to the standby WorkSpaces. To do so, you need to enable data replication.

Yes. After you set up your standby WorkSpaces in the secondary Region, you can enable data replication to copy both the root volume (C drive) and the user volume (D drive) from your primary WorkSpaces to your standby WorkSpaces. The data replication is one-way. Once it is enabled, the system will replicate data from your primary AWS Region to the secondary AWS Region. To learn more, refer to Amazon WorkSpaces Multi-Region Resilience.

Yes. Amazon WorkSpaces Multi-Region Resilience leverages the existing cross-Region redirection capabilities and streamlines the process of redirecting users to a secondary Region when their primary WorkSpaces Region is unreachable due to disruptive events. It does this without requiring users to switch the registration code when logging in to their standby WorkSpaces. You can use fully qualified domain name (FQDN) as Amazon WorkSpaces registration codes for your users. When an outage occurs in your primary Region, you can redirect users to the standby WorkSpaces in the secondary Region based on your Domain Name System (DNS) failover policies for the FQDN.

You can define the Region priority by configuring routing policies for your FQDN on DNS. For more information, refer to Amazon WorkSpaces documentation.

Yes. Old registration codes will keep working. Users can register with either old registration codes or fully qualified domain names (FQDN). Cross-Region redirection only works when end users register with FQDNs.

Yes. WorkSpaces cross-Region redirection works with both public domain names and domain names in private DNS zones. If your end users use private FQDNs from the public internet, the WorkSpaces clients will return errors reporting invalid registration codes.

WorkSpaces cross-Region redirection works in all AWS Regions where Amazon WorkSpaces is available except AWS GovCloud and China Regions.

Windows, macOS, and Linux WorkSpaces clients support cross-Region redirection.

Use WorkSpaces Multi-Region Resilience ** with cross-Region redirection to deploy redundant virtual desktop infrastructure in a secondary WorkSpaces Region and design a cross-Region failover strategy in preparation for disruptive events. Leveraging Domain Name System (DNS) failover and health-check capabilities, WorkSpaces cross-Region redirection could point your users to log into WorkSpaces in a disaster recovery Region when the primary WorkSpaces Region is not reachable. To learn more, refer to Amazon WorkSpaces documentation on WorkSpaces Multi-Region Resilience and cross-Region redirection.

We strive to offer our customers the flexibility to meet a wide variety of technical and business requirements.

Yes. When you provision a new WorkSpaces user in the directory, you can enable either Amazon DCV or PCoIP, as long as the WorkSpaces user is not already listed in that directory.

Yes. One streaming protocol is selected when a WorkSpace is provisioned for a given user. To switch to a different streaming protocol after a WorkSpace has been provisioned, you can use the WorkSpaces migrate API to update the Workspace’s protocol.

Yes, as long as separate directories are created for each type of WorkSpace. A single user cannot run both PCoIP and Amazon DCV on WorkSpaces from the same directory. However, a single directory can include a mix of both PCoIP and DCV-based WorkSpaces users.

If you encounter any issues or want to provide feedback about Amazon DCV, contact AWS Support.

WorkSpaces Pools supports Windows Server 2019 and Windows Server 2022.

WorkSpaces Pools is billed on a hourly basis that combines a low base monthly fee with an hourly usage fee when virtual desktops in the pool are provisioned to users. This allows for predictable costs for regular use and efficient billing for variable or sporadic needs. See the WorkSpaces Pricing page for more detail.

When configuring WorkSpaces Pools, you will be prompted with the bundle type for the pool. We offer Value, Standard, Performance, Power, PowerPro, GeneralPurpose and accelerated graphics bundles that range in from 1 vCPU / 2 GB Memory up to 8 vCPU / 32 GB Memory. Recommendations are provided for each bundle on the types of workloads that are generally optimized for each. Customers are encouraged to monitor performance on initial setup to ensure they have selected the appropriate bundle for their specific set of applications.

Yes, WorkSpaces Pools supports SAML 2.0 Identity Provider services, such as Entra ID, Okta, and more. For more information, please see our documentation.

WorkSpaces Pools supports authentication via SAML 2.0.

Uses receive a provisioning email from their admin with the URL for their WorkSpace Pool. Once they click on the link for their WorkSpace, they provide a registration code, then the user can authenticate with their domain credentials. Once logged in, the users will be connected to the desktop.

The Amazon DCV streaming protocol is the underlying streaming technology.

Administrators control the networking configuration, and can remove internet access if it is not required.

Administrators can configure a wide variety of options for user data storage, such as Amazon S3 or Amazon FSx.

Yes, you can use the same images for WorkSpaces Personal and WorkSpaces Pools.

Refer to our peripherals documentation for information on the supported devices.

Yes. Amazon WorkSpaces Thin Client works with both WorkSpaces Personal and WorkSpaces Pools.