AWS WorkSpaces - Desktops Test

Amazon WorkSpaces enables you to provision virtual, cloud-based Microsoft Windows, Amazon Linux, or Ubuntu Linux desktops for your users, known as WorkSpaces. WorkSpaces eliminates the need to procure and deploy hardware or install complex software. You can quickly add or remove users as your needs change. Users can access their virtual desktops from multiple devices or web browsers.

Figure 1 shows how a Workspace works.

Figure 1 : How an AWS WorkSpace works?

For Windows and Linux WorkSpaces, each WorkSpace is associated with a virtual private cloud (VPC), and a directory to store and manage information for your WorkSpaces and users.

WorkSpaces uses Simple AD, AD Connector, or AWS Managed Microsoft AD directory to authenticate users. Users access their WorkSpaces by using a client application from a supported device or, for Windows WorkSpaces, a web browser, and they log in by using their directory credentials. The login information is sent to an authentication gateway, which forwards the traffic to the directory for the WorkSpace. After the user is authenticated, streaming traffic is initiated through the streaming gateway.

Each WorkSpace has two elastic network interfaces associated with it: a network interface for management and streaming (eth0) and a primary network interface (eth1). The primary network interface has an IP address provided by your VPC, from the same subnets used by the directory. This ensures that traffic from your WorkSpace can easily reach the directory. Access to resources in the VPC is controlled by the security groups assigned to the primary network interface.

If a user is unable to connect to a WorkSpace or is experiencing considerable slowness when attempting to do so, that user will not be able to use the cloud resources effectively; this in turn will impact user productivity, deflate revenues, and escalate support costs and penalties.

To avoid this, administrators should be able to detect and resolve the unavailability/inaccessibility of WorkSpaces, and latencies in connecting to WorkSpaces, well before users complain. This is where the AWS WorkSpaces - Desktops test helps!

This test automatically discovers AWS WorkSpaces, and for each WorkSpace, the test then reports the following:

Is the WorkSpace available?
Is the WorkSpace reachable? Did any connection attempts to the WorkSpace fail recently? If so, which WorkSpace is it?
Is the WorkSpace running? Or is it in maintenance?
Are user sessions launching too slowly on any WorkSpace? If so, which WorkSpace is it?
Are latencies observed when connecting to any WorkSpace?
Have too many session disconnects been noticed on any WorkSpace?

This way, the test rapidly leads administrators to unavailable, inaccessible, and latent WorkSpaces, so that they can swiftly troubleshoot the anomalies, quickly restore normalcy, and thus assure users of a superlative WorkSpace experience!

Target of the test: Amazon Cloud

Agent deploying the test: A remote agent

Output of the test: One set of results for each AWS WorkSpace

Configurable parameters for the test
Parameter	Description
Test Period	How often should the test be executed.
Host	The host for which the test is to be configured.
Access Type	eG Enterprise monitors the AWS cloud using AWS API. By default, the eG agent accesses the AWS API using a valid AWS account ID, which is assigned a special role that is specifically created for monitoring purposes. Accordingly, the Access Type parameter is set to Role by default. Furthermore, to enable the eG agent to use this default access approach, you will have to configure the eG tests with a valid AWS Account ID to Monitor and the special AWS Role Name you created for monitoring purposes. Some AWS cloud environments however, may not support the role-based approach. Instead, they may allow cloud API requests only if such requests are signed by a valid Access Key and Secret Key. When monitoring such a cloud environment therefore, you should change the Access Type to Secret. Then, you should configure the eG tests with a valid AWS Access Key and AWS Secret Key. Note that the Secret option may not be ideal when monitoring high-security cloud environments. This is because, such environments may issue a security mandate, which would require administrators to change the Access Key and Secret Key, often. Because of the dynamicity of the key-based approach, Amazon recommends the Role-based approach for accessing the AWS API.
AWS Account ID to Monitor	This parameter appears only when the Access Type parameter is set to Role. Specify the AWS Account ID that the eG agent should use for connecting and making requests to the AWS API. To determine your AWS Account ID, follow the steps below: Login to the AWS management console. with your credentials. Click on your IAM user/role on the top right corner of the AWS Console. You will see a drop-down menu containing the Account ID (see Figure 2). Figure 2 : Identifying the AWS Account ID
AWS Role Name	This parameter appears when the Access Type parameter is set to Role. Specify the name of the role that you have specifically created on the AWS cloud for monitoring purposes. The eG agent uses this role and the configured Account ID to connect to the AWS Cloud and pull the required metrics. To know how to create such a role, refer to Creating a New Role.
AWS Access Key, AWS Secret Key, Confirm AWS Access Key, Confirm AWS Secret Key	These parameters appear only when the Access Type parameter is set to Secret.To monitor an Amazon instance, the eG agent has to be configured with the access key and secret key of a user with a valid AWS account. For this purpose, we recommend that you create a special user on the AWS cloud, obtain the access and secret keys of this user, and configure this test with these keys. The procedure for this has been detailed in the Obtaining an Access key and Secret key topic. Make sure you reconfirm the access and secret keys you provide here by retyping it in the corresponding Confirm text boxes.
Proxy Host and Proxy Port	In some environments, all communication with the AWS cloud and its regions could be routed through a proxy server. In such environments, you should make sure that the eG agent connects to the cloud via the proxy server and collects metrics. To enable metrics collection via a proxy, specify the IP address of the proxy server and the port at which the server listens against the Proxy Host and Proxy Port parameters. By default, these parameters are set to none , indicating that the eG agent is not configured to communicate via a proxy, by default.
Proxy User Name, Proxy Password, and Confirm Password	If the proxy server requires authentication, then, specify a valid proxy user name and password in the proxy user name and proxy password parameters, respectively. Then, confirm the password by retyping it in the CONFIRM PASSWORD text box. By default, these parameters are set to none, indicating that the proxy sever does not require authentication by default.
Proxy Domain and Proxy Workstation	If a Windows NTLM proxy is to be configured for use, then additionally, you will have to configure the Windows domain name and the Windows workstation name required for the same against the proxy domain and proxy workstation parameters. If the environment does not support a Windows NTLM proxy, set these parameters to none.
Exclude Region	Here, you can provide a comma-separated list of region names or patterns of region names that you do not want to monitor. For instance, to exclude regions with names that contain 'east' and 'west' from monitoring, your specification should be: east,west
Detailed Diagnosis	To make diagnosis more efficient and accurate, the eG Enterprise embeds an optional detailed diagnostic capability. With this capability, the eG agents can be configured to run detailed, more elaborate tests as and when specific problems are detected. To enable the detailed diagnosis capability of this test for a particular server, choose the On option. To disable the capability, click on the Off option. The option to selectively enable/disable the detailed diagnosis capability will be available only if the following conditions are fulfilled: The eG manager license should allow the detailed diagnosis capability Both the normal and abnormal frequencies configured for the detailed diagnosis measures should not be 0.

Measures reported by the test:

Measurement

Description

Measurement Unit

Interpretation

Is available?

Indicates whether/not this WorkSpace is available.

The values reported by this measure and their corresponding numeric values have been described in the table below:

Measure Value	Numeric Value
Yes	1
No	0

Note:

By default, this measure reports the Measure Values listed in the table above to indicate whether/not a WorkSpace is available. In the graph of this measure however, the same is indicated using the numeric equivalents only.

If this measure reports the value No for any WorkSpace, then you can use the detailed diagnosis of this measure to identify the IP address, the Computer name, and the Directory used by that WorkSpace. This will help in swiftly troubleshooting the unavailability.

Is healthy?

Indicates whether/not this WorkSpace is healthy.

Amazon WorkSpaces periodically sends status requests to a WorkSpace. The WorkSpace is marked as Unhealthy if a response isn’t received from the WorkSpace in a timely manner.

If the target WorkSpace is marked as Unhealthy, then this measure will report the value No. If it is marked as Healthy, then this measure will report the value Yes.

The numeric values that correspond to these measure values are detailed below:

Measure Value	Numeric Value
Yes	1
No	0

Note:

By default, this measure reports the Measure Values listed in the table above to indicate whether/not a WorkSpace is healthy. In the graph of this measure however, the same is indicated using the numeric equivalents only.

Common causes for the Unhealthy status of a WorkSpace are as follows:

An application on the WorkSpace is blocking network connection between the Amazon WorkSpaces service and the WorkSpace.
High CPU utilization on the WorkSpace.
The computer name of the WorkSpace is changed.
The agent or service that responds to the Amazon WorkSpaces service isn't in running state.

The following troubleshooting steps can return the WorkSpace to a healthy state:

First, reboot the WorkSpace from the Amazon WorkSpaces console. If rebooting the WorkSpace doesn't resolve the issue, either use RDP, or connect to an Amazon Linux WorkSpace using SSH.
If the WorkSpace is unreachable by a different protocol, rebuild the WorkSpace from the Amazon WorkSpaces console.
If a WorkSpaces connection cannot be established, verify the following:
- Verify CPU utilization. If it is abnormally high, then resize the WorkSpace to resolve the CPU bottleneck.
- Verify the computer name of the WorkSpace. If it was changed recently, then change it back to the original name.
- Verify firewall rules and confirm that the Windows and third-party firewalls have rules to allow the ports required for establishing streaming connections, for streaming user input, for managing and configuring the WorkSpace, and for PCoIP streaming.

Connection attempt

Indicates the number of connection attempts made to this WorkSpace.

Number

Connection success

Indicates the number of connection attempts to this WorkSpace that was successful.

Number

A high value is desired for this measure.

Connection failure

Indicates the number of connections attempts to this WorkSpace that failed.

Number

Ideally, the value of this measure should be 0. A non-zero value for any WorkSpace is a cause for concern as it implies that connection attempts to that WorkSpace have failed.

Compare the value of this measure across WorkSpaces to know which WorkSpace recorded the maximum number of failed connection attempts. You may want to investigate such frequent connection failures.

Session launch time

Indicates the time it takes to initiate a WorkSpace session.

Seconds

A high value for this measure indicates that WorkSpace sessions are consistently taking a long time to be initiated. This is a problem condition that warrants an investigation. Some common reasons for a slow session launch are as follows:

Group Policy settings that are set by your system administrator can cause a delay on login after your Windows WorkSpace has been launched or rebooted.
You may be using an outdated version of WorkSpace Windows client application

Session latency

Indicates the round trip time (RTT) between the WorkSpace client and this WorkSpace.

Seconds

Ideally, the value of this measure should be low.

If the round-trip time from your client to your WorkSpace is longer than 100ms, you can still use your WorkSpace, but this might result in a poor experience. A slow round-trip time can be caused by many factors, but the following are the most common causes:

You are too far from the AWS Region that your WorkSpace resides in. For the best WorkSpace experience, you should be within 2,000 miles of the AWS Region that your WorkSpace is in.
Your network connection is inconsistent or slow. For the best experience, your network connection should provide at least 300 kbps, with capability to provide over 1 Mbps when viewing video or using graphics-intensive applications on your WorkSpace.

Is session disconnected?

Indicates whether any user-initiated connection to this WorkSpace is currently disconnected.

The values reported by this measure and their corresponding numeric values have been described in the table below:

Measure Value	Numeric Value
Yes	1
No	0

Note:

By default, this measure reports the Measure Values listed in the table above to indicate whether/not a WorkSpace session is disconnected. In the graph of this measure however, the same is indicated using the numeric equivalents only.

If this measure reports the value Yes for any WorkSpace, it is a matter of distress for an administrator, as it implies that a user/client is currently disconnected from a WorkSpace. If this situation persists, it can adversely impact user experience with AWS WorkSpaces. To avoid this, administrators should rapidly investigate the disconnect, identify why it occurred, and resolve it quickly. Some of the reasons for frequent disconnects are as follows:

A WorkSpace that frequently disconnects and reconnects usually indicates high round-trip time (RTT) or an unstable internet connection. For a healthy connection from your network to the AWS Region that your WorkSpace is in, the RTT should be less than 100 ms.
If your local network has trouble maintaining connections, the WorkSpaces client drops the connection and tries to reconnect.

To resolve issues with your WorkSpace frequently disconnecting and reconnecting, follow these broad steps:

Verify RTT - Use Connection Health Check to verify that your internet connection is suitable for Amazon WorkSpaces. If not, then choose an appropriate connection.
Verify the client version - Check if you are using the latest WorkSpaces client version. If not, upgrade to the latest version and then proceed.
Reboot the WorkSpace - There might also be an issue with the PCoIP Agent on the WorkSpace's side. In this case therefore, reboot the WorkSpace. This runs through a WorkSpace initialization to make sure that all WorkSpace components are healthy.

Is user connected?

Indicates whether any user is connected to this WorkSpace presently.

The values reported by this measure and their corresponding numeric values have been described in the table below:

Measure Value	Numeric Value
Yes	1
No	0

Note:

By default, this measure reports the Measure Values listed in the table above to indicate whether/not any user is connected to a WorkSpace. In the graph of this measure however, the same is indicated using the numeric equivalents only.

If this measure reports the value Yes, then you can use the detailed diagnosis of the measure to know which user is connected to the WorkSpace.

Is stopped?

Indicates whether/not the WorkSpace has stopped.

Number

The values reported by this measure and their corresponding numeric values have been described in the table below:

Measure Value	Numeric Value
Yes	1
No	0

Note:

By default, this measure reports the Measure Values listed in the table above to indicate whether/not a WorkSpace has stopped. In the graph of this measure however, the same is indicated using the numeric equivalents only.

Is maintenance?

Indicates whether this WorkSpace is under maintenance currently.

Number

The values reported by this measure and their corresponding numeric values have been described in the table below:

Measure Value	Numeric Value
Yes	1
No	0

Note:

By default, this measure reports the Measure Values listed in the table above to indicate whether/not a WorkSpace is under maintenance. In the graph of this measure however, the same is indicated using the numeric equivalents only.

This metric applies to WorkSpaces that are configured with an AutoStop running mode. With this mode, your WorkSpaces stop after a specified period of inactivity and the state of apps and data is saved.

Amazon WorkSpaces schedules maintenance for your WorkSpaces. During the maintenance window, important updates are downloaded and installed. If you enable maintenance mode for your AutoStop WorkSpaces, they are started automatically once a month in order to download and install important service, security, and Windows updates.

Running mode

Indicates the running mode of this WorkSpace.

The running mode of a WorkSpace determines its immediate availability and how you pay for it (monthly or hourly). You can choose between 2 running modes when you create the WorkSpace. This measure reports one of these 2 modes as its value. These modes are as follows:

AlwaysOn — Use when paying a fixed monthly fee for unlimited usage of your WorkSpaces. This mode is best for users who use their WorkSpace full time as their primary desktop.
AutoStop — Use when paying for your WorkSpaces by the hour. With this mode, your WorkSpaces stop after a specified period of disconnection, and the state of apps and data is saved.

The numeric values that correspond to the above measure values are described in the table below:

Measure Value	Numeric Value
AlwaysOn	1
AutoStop	2

Note:

By default, this measure reports the Measure Values listed in the table above to indicate the running mode of a WorkSpace. In the graph of this measure however, the same is indicated using the numeric equivalents only.

Root volume size

Indicates the current size of the root volume of this WorkSpace.

The root volume is where the OS and applications normally live. The user volume is meant for your users to store their data in. In the case of a rebuild of the WorkSpace the root volume gets reverted back to default whereas the users data is persistent, at least as much as its last snapshot, normally every 12 hours.

Root and user volumes must be sized as per the following combinations:

Root Volume in GB	User Volume in GB
80	10
80	50
80	100
175-1000	100-1000

Volume sizes can be increased once in a 24-hour period. For a newly launched Workspace, you must wait 24 hours before requesting a larger bundle. You can never decrease volume sizes.

User volume size

Indicates the current size of the user volume of this WorkSpace.