WorkSpace Disk Not Encrypted: Securing Amazon WorkSpaces at Rest

Amazon WorkSpaces gives your users a managed virtual desktop in the cloud. Each WorkSpace is backed by EBS volumes: a root volume that holds the operating system and a user volume that holds the user's files and profile. When those volumes are not encrypted, anything written to disk sits in plaintext on AWS-managed storage. The workspaces_diskencryption check looks for WorkSpaces where either volume has encryption disabled and flags them.

It sounds like a small box to tick, but virtual desktops are where people actually do work: they download spreadsheets, cache credentials, save email attachments, and sometimes paste secrets into text files. Encryption at rest is the baseline control that makes all of that data unreadable to anyone who gets at the underlying storage without your keys.

---

What this check detects

The check inspects every WorkSpace in a region and reads the volume encryption state reported by the WorkSpaces API. A WorkSpace passes only when both volumes are encrypted:

• RootVolumeEncryptionEnabled is true
• UserVolumeEncryptionEnabled is true

If either is false, the WorkSpace is marked as failing. You can see the same data yourself with the AWS CLI:

aws workspaces describe-workspaces \
  --query 'Workspaces[].{Id:WorkspaceId,User:UserName,Root:RootVolumeEncryptionEnabled,UserVol:UserVolumeEncryptionEnabled}' \
  --output table

---

Why it matters

An unencrypted WorkSpace volume is plaintext data sitting on storage you do not fully control. The risks are concrete:

• Data at rest exposure. Encryption at rest protects against access to the physical or virtual storage layer. Without it, you are relying entirely on access controls with no cryptographic backstop.
• Sensitive working data. WorkSpaces frequently hold the most sensitive material in an organization: financial models, customer PII, source code, and downloaded reports. That data lands on the user volume in plaintext if encryption is off.
• Cached credentials and tokens. Browsers, CLI tools, and corporate apps cache session tokens, API keys, and saved passwords on disk. An unencrypted volume makes these recoverable.
• Compliance gaps. Frameworks like PCI DSS, HIPAA, SOC 2, and ISO 27001 expect encryption at rest for systems handling regulated data. An unencrypted virtual desktop fleet is a common audit finding.

---

How to fix it

Because encryption can only be set when a WorkSpace is created, remediation means recreating the affected WorkSpaces with encryption enabled. The clean path is: back up user data, terminate the unencrypted WorkSpace, and provision a new encrypted one.

Step 1: Preserve the user's data

Terminating a WorkSpace deletes its volumes. Make sure anything on the user volume is backed up first, ideally to a location your users already rely on (network drive, S3, OneDrive, etc.). If you use a custom bundle or image, capture it before you terminate.

Step 2: Pick a KMS key

You can use the default AWS-managed key or a customer-managed key (CMK) for tighter control over key policy and rotation. List your keys:

aws kms list-aliases \
  --query "Aliases[?contains(AliasName, 'workspaces') || contains(AliasName, 'workspace')]"

If you want a CMK, create one and note its key ID or ARN for the next step.

Step 3: Create an encrypted WorkSpace

Provision the replacement with both volumes encrypted. Pass the same directory, bundle, and username so the user lands back in a familiar setup:

aws workspaces create-workspaces --workspaces '[
  {
    "DirectoryId": "d-0123456789",
    "UserName": "jdoe",
    "BundleId": "wsb-0123456789",
    "RootVolumeEncryptionEnabled": true,
    "UserVolumeEncryptionEnabled": true,
    "VolumeEncryptionKey": "arn:aws:kms:us-east-1:111122223333:key/abcd1234-...",
    "WorkspaceProperties": {
      "RunningMode": "AUTO_STOP"
    }
  }
]'

If you are happy with the AWS-managed key, you can omit VolumeEncryptionKey and AWS will use the aws/workspaces key.

Step 4: Terminate the unencrypted WorkSpace

Once the user is confirmed working on the new encrypted WorkSpace, remove the old one:

aws workspaces terminate-workspaces \
  --terminate-workspace-requests WorkspaceId=ws-0123456789

Doing it in the console

1. Open the WorkSpaces console and choose Launch WorkSpaces.
2. Select the directory, then the user, then the bundle.
3. On the configuration step, check both Encrypt root volume and Encrypt user volume.
4. Choose the KMS key (default or your CMK), review, and launch.
5. After the user migrates, select the old WorkSpace and choose Actions → Remove WorkSpaces.

---

How to prevent it from happening again

The reliable fix is to make encryption the default at provisioning time, then verify continuously. Manual launches are where unencrypted WorkSpaces sneak in, so codify the configuration.

Define WorkSpaces in Terraform with encryption on

resource "aws_workspaces_workspace" "jdoe" {
  directory_id = aws_workspaces_directory.main.id
  bundle_id    = data.aws_workspaces_bundle.standard.id
  user_name    = "jdoe"

  root_volume_encryption_enabled = true
  user_volume_encryption_enabled = true
  volume_encryption_key          = aws_kms_key.workspaces.arn

  workspace_properties {
    running_mode = "AUTO_STOP"
  }
}

With this in your module, a WorkSpace cannot be created without encryption unless someone deliberately edits the code, which shows up in a pull request review.

Gate it in CI with policy-as-code

Add an Open Policy Agent (Conftest) rule that rejects any plan where WorkSpaces encryption is not enabled:

package main

deny[msg] {
  resource := input.resource_changes[_]
  resource.type == "aws_workspaces_workspace"
  not resource.change.after.root_volume_encryption_enabled
  msg := sprintf("WorkSpace %s has root volume encryption disabled", [resource.address])
}

deny[msg] {
  resource := input.resource_changes[_]
  resource.type == "aws_workspaces_workspace"
  not resource.change.after.user_volume_encryption_enabled
  msg := sprintf("WorkSpace %s has user volume encryption disabled", [resource.address])
}

Run it against your plan output in the pipeline:

terraform plan -out=tfplan.binary
terraform show -json tfplan.binary > tfplan.json
conftest test tfplan.json

Catch drift continuously

IaC stops new mistakes, but it does not catch WorkSpaces created by hand through the console or older ones that predate your policy. Run the workspaces_diskencryption check on a schedule with Lensix so any unencrypted WorkSpace is surfaced shortly after it appears, regardless of how it was created.

---

Best practices

• Encrypt both volumes, always. Do not encrypt only the user volume. The root volume can hold logs, temp files, swap, and cached data that is just as sensitive.
• Use a customer-managed KMS key for regulated workloads. A CMK lets you control the key policy, enable automatic rotation, and produce an audit trail of key usage in CloudTrail.
• Restrict who can launch WorkSpaces. Limit workspaces:CreateWorkspaces to your provisioning role or pipeline so engineers cannot spin up ad hoc unencrypted desktops.
• Standardize on a vetted bundle. Maintain a custom bundle that bakes in your security agent and configuration, and provision every WorkSpace from it with encryption enabled.
• Keep user data off the WorkSpace where you can. Redirecting profiles and documents to a managed file service reduces the blast radius and makes encrypted rebuilds far less disruptive.
• Document the rebuild process. Since you cannot encrypt in place, have a runbook ready so remediating a flagged WorkSpace is a known, low-friction task rather than an emergency.

Encryption at rest on WorkSpaces is cheap, transparent to users, and expected by every major compliance framework. The only real cost is that you have to decide on it at launch time, so the winning move is to make encryption the default in your tooling and let a recurring check catch anything that slips through.