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.

50 free users on AWS 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 =
      • 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
Workspaces are launching

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": [
            "Effect": "Allow",
            "Resource": "*"
    "Version": "2012-10-17"

Setup the Splunk Add-on for AWS


  • 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:
AWS/WorkSpaces Input – Default Metrics Configuration

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:

CloudWatch “Available” metric with both WorkspaceId and DirectoryId dimensions

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.

MetricDescriptionDirectoryId Aggregation
AvailableThe number of WorkSpaces that returned a healthy status.Sum
ConnectionAttemptThe number of connection attempts.Sum
ConnectionFailureThe number of failed connections.Sum
ConnectionSuccessThe number of successful connections.Sum
InSessionLatencyThe round trip time between the WorkSpaces client and the WorkSpace.Average
MaintenanceThe number of WorkSpaces that are under maintenance.Sum
SessionDisconnectThe number of connections that were closed, including user-initiated and failed connections.Sum
SessionLaunchTimeThe amount of time it takes to initiate a WorkSpaces session.Average
StoppedThe number of WorkSpaces that are stopped.Sum
UnhealthyThe number of WorkSpaces that returned an unhealthy status.Sum
UserConnectedThe number of WorkSpaces that have a user connected.Sum
Suggested Metric Setup
  • 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
Add-on Setup for DirectoryId level metric ingestion

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:

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:

Stats table of metrics and values


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.

For 2021 we’ve committed to posting a new Splunk tip every week!

If you want to keep up to date on tips like the one above then sign up below:

Subscribe to our newsletter to receive regular updates from iDelta, including news and updates, information on upcoming events, and Splunk tips and tricks from our team of experts. You can also find us on Twitter and LinkedIn.


* indicates required
Posted by:Stuart Robertson

Stuart Robertson is the Consulting Director at iDelta. He is one of the initial founders of iDelta and has worked there since formation in 2001. Stuart holds various certifications in Core Splunk and ITSI. Stuart also holds a Bsc(Hons) in Computing Science from the University of Glasgow.