Monitor Amazon Workspaces with Splunk

Amazon Workspaces is a “Desktop-as-a-Service” or Virtual Desktop Infrastructure (VDI) capability from the AWS cloud. VDI provides a secure way to enable home working, ensuring that staff are working from secure and compliant desktop machines, accessed via a remote connection from whatever physical machine they have at home.

Splunk is brilliant at ingesting data from AWS. There are various routes that can be used to bring the data in. The “Splunk Add-on for AWS” allows you to pull data in various ways from AWS. For monitoring use cases CloudWatch Metrics provide a great way to pull the AWS resource-specific metrics into Splunk. Out of the box, the Add-on provides templated support for a number of common AWS CloudWatch metric namespaces such as AWS/EC2, AWS/RDS, AWS/Billing, AWS/ApiGateway and more. Amazon WorkSpaces (AWS/Workspaces) is not set up by default, but it can be added as we show here.

Building the POC environment

Setting up Amazon Workspaces

AWS are currently offering up to 50 free users on Amazon WorkSpaces.

• Login to your AWS Console and navigate to Amazon WorkSpaces
  • Click ‘Get Started Now’
  • Set up Directory: AWS Managed Microsoft AD: Standard Edition
    • Orgname = acmevdi
    • Directory DNS name = vdi.acmevdi.com
    • Set an admin password
  • Choose VPC and subnets
    • stick with the default or use a suitable VPC/subnet if appropriate
  • Review – note that there are 30 days of trial usage, remember to delete resources after the test to avoid charges
  • Create Directory – took around 20 mins to get to the ready state
• Click on the WorkSpaces option then “Launch WorkSpaces”
  • Select a Directory – defaults should be fine
  • Create some test users
  • Select Bundle – here you can match your users to OS and connection protocols, for testing I chose:
    • 1 x Windows 10 (Standard/PCoIP)
    • 1 x Amazon Linux 2 (Standard/PCoIP)
    • 1 x Windows 10 (Standard/WSP)
  • WorkSpaces Configuration
    • AutoStop was chosen as it is Free Tier eligible
    • Add encryption and tags if required
      • I added a tag project=splunk. (to see if it shows up in the data later)
  • Launch Workspaces

Emails will be sent to the test users explaining how to connect. They will need to download the client appropriate for the OS they are using on their physical machine.

AWS User and Permissions

The Splunk Add-on for AWS will poll the AWS APIs to collect CloudWatch metric data. It does this as a user, using a Access and Secret Key to authenticate. Briefly, here are the steps:

• From the AWS Console access IAM
• Add User (splunk) with programmatic access
• Create a group – SplunkCloudWatchMetrics
  • Create Policy: CloudWatchMetrics (use the policy below to grant access to all CloudWatch metrics)
• The user now has access to hit the AWS API and retrieve CloudWatch metrics
• Access the user and click on the Security credentials tab – from here you can create an access key and secret that you will use when setting up the connect in the Splunk Add-on for AWS

{
    "Statement": [
        {
            "Action": [
                "cloudwatch:List*",
                "cloudwatch:Get*",
                "autoscaling:Describe*",
                "ec2:Describe*",
                "s3:List*",
                "sqs:List*",
                "sns:List*",
                "lambda:List*",
                "elasticloadbalancing:Describe*"
            ],
            "Effect": "Allow",
            "Resource": "*"
        }
    ],
    "Version": "2012-10-17"
}

Setup the Splunk Add-on for AWS

Pre-requisites:

• Splunk v8 installed
• Splunk Add-on for AWS installed

Setup the Account to connect to AWS

Setup the account from the Configuration tab in the add-on:

• Click ‘Add’
• Name = a name for this connection
• Key ID = the AWS Access Key ID
• Secret = the AWS Secret Key ID
• Region Category = Global

Setup the Input to ingest Amazon WorkSpaces CloudWatch Metrics

From the Inputs tab:

• Click ‘Create New Input’
  • Select CloudWatch
• Name = Amazon_WorkSpaces
• AWS Account = <name of account you specified previously>
• AWS Regions = the region(s) your WorkSpaces run in
• Metrics Configuration – click Edit in Advanced Mode

The default Metrics Configuration is set up to ingest from various namespaces. For this test, remove all of the namespaces from the left-hand side by clicking on the ‘x’. Also, remove any Dimensions in the right-hand section.

As AWS/WorkSpaces is not one of the listed namespaces you need to add it manually:

• Click “+ Add Namespace”
  • Namespace = AWS/WorkSpaces (select from list and hit Enter)
  • The Splunk Add-on populates the Dimension settings as shown below:

Warning: The default settings result in no data being ingested

Most of the AWS CloudWatch Metrics are available at the DirectoryId or the WorkspaceId dimension level but not both. For example, the “Available” metric will return the details on all of the virtual workstations if the WorkspaceId dimension is used, or a summary of the entire estate if DirectoryId is used. The table below shows this scenario for an environment with three virtual desktops:

As we can see above, decisions need to be made on each metric in terms of at which level to ingest the data (per WorkspaceId or per DirectoryId), and then also which aggregate function works best for that metric.

The table below suggests a metric setup that will allow for a comprehensive view across the estate. If you want to be able to identify issues at the workstation level (for instance, which workstations are experiencing high latency) then consider ingesting the data at the WorkstationId level. You can choose to do this alongside the DirectoryId level metrics or use Splunk to aggregate the values across the virtual workstations to get the big picture. The forest and the trees.

Metric	Description	DirectoryId Aggregation
Available	The number of WorkSpaces that returned a healthy status.	Sum
ConnectionAttempt	The number of connection attempts.	Sum
ConnectionFailure	The number of failed connections.	Sum
ConnectionSuccess	The number of successful connections.	Sum
InSessionLatency	The round trip time between the WorkSpaces client and the WorkSpace.	Average Maximum
Maintenance	The number of WorkSpaces that are under maintenance.	Sum
SessionDisconnect	The number of connections that were closed, including user-initiated and failed connections.	Sum
SessionLaunchTime	The amount of time it takes to initiate a WorkSpaces session.	Average Maximum
Stopped	The number of WorkSpaces that are stopped.	Sum
Unhealthy	The number of WorkSpaces that returned an unhealthy status.	Sum
UserConnected	The number of WorkSpaces that have a user connected.	Sum

• To Implement the settings above remove the default dimension setup from the metrics configuration screen then add each of the rows above using the following Dimension Value: [{“DirectoryId”:[“.*”]}]
• The screenshot below shows this setup in the Add-on

To finish the setup complete these steps:

• Click OK
• Change the index name as required (or leave to default)
• The Period can be changed to 60s (or kept at a higher value)
• Click Save

For further information on the CloudWatch Metrics available for Amazon WorkSpaces check this AWS documentation page: https://docs.aws.amazon.com/workspaces/latest/adminguide/cloudwatch-metrics.html

Checking the data

We can quickly check the data with the following search:

index=aws_workspaces sourcetype="aws:cloudwatch" 
|stats count values(Sum) as sum avg(Average) as average max(Maximum) as maximum by metric_name

Within our test environment this currently produces the following stats table:

Conclusion

With Amazon Workspaces, as with many AWS technologies, there are CloudWatch Metrics available that can help monitor the service. As we have shown above, careful configuration of the metrics is required in order for them to be successfully ingested into Splunk.

In a future post we’ll look at building dashboards to help visualise the VDI estate.