Amazon WorkSpaces are invisible to SSM and CloudWatch (and how to fix it)

I spent an afternoon arguing with Windows about whether I was allowed to be root on a machine I created. Six hours and six layers of undocumented workarounds later, I got CMMC-compliant audit logging on a desktop that doesn’t know it exists.

The problem

WorkSpaces don’t show up in AWS Systems Manager. They’re not EC2 instances — no instance profile, no metadata endpoint, no identity. SSM Agent is pre-installed but thinks it’s nobody. CloudWatch Agent has no credentials and doesn’t know what region it’s in.

Attempt 1: AD logon script

My plan: AD logon script bootstraps everything on first login. Zero user interaction.

Upload a PowerShell script to NETLOGON and set scriptPath on the AD user. User logs in. Notepad opens. Just… Notepad. My script displayed as a text file.

Windows scriptPath only executes .bat, .cmd, .vbs, .exe. A .ps1 opens in the default text editor. This is documented nowhere obvious.

Attempt 2: Wrap it in a .bat

@echo off
powershell -ExecutionPolicy Bypass -File \\domain\NETLOGON\bootstrap.ps1

Script fires. “Access is denied.” Logon scripts run with a UAC split token — even local admins get a filtered, non-elevated token. Can’t register SSM, can’t install anything.

Four things that didn’t work

1. Self-elevating .bat — triggers a random UAC prompt. Bad habit for unattended bootstrapping.
2. schtasks /rl HIGHEST — access denied. The split token can’t create elevated scheduled tasks.
3. WinRM/impacket — zero inbound SG rules on WorkSpaces. No remote access.
4. Opening the SG — Windows Firewall blocks everything anyway, even after the SG allows it.

What worked

Start-Process -Credential with the domain admin. Creates a full unfiltered admin token, no UAC prompt:

$cred = New-Object System.Management.Automation.PSCredential(
    "DOMAIN\Administrator",
    (ConvertTo-SecureString "password" -AsPlainText -Force)
)
Start-Process powershell -Credential $cred -ArgumentList "-File \\domain\NETLOGON\bootstrap.ps1"

But only with DOMAIN\Administrator — the UPN format (Administrator@domain.local) silently fails with “invalid credentials.” SimpleAD quirk. Cost me an hour.

SSM hybrid registration

SSM registers the WorkSpace as a hybrid instance (mi-* prefix instead of i-*). Now I have Run Command.

Push CloudWatch Agent, but hybrid instances have no EC2 metadata. The config-downloader runs as Administrator not SYSTEM, so it can’t find credentials.

Fix: common-config.toml pointing to the right credential file, plus AWS_DEFAULT_REGION as a machine environment variable because hybrids don’t know what region they’re in:

[credentials]
shared_credential_profile = "AmazonCloudWatchAgent"
shared_credential_file = "C:\\path\\to\\credentials"

Result

Windows Security, Application, and System logs now flow to CloudWatch. 365-day retention, KMS encrypted. AU-2, AU-3, AU-11 compliance controls satisfied.

Best detail: log stream names show EC2 instance IDs that don’t exist. Ghost IDs baked into the WorkSpaces base AMI.

The advisor logged in, installed Chrome, opened Word. No idea any of this happened.

Humility check

At every enterprise I’ve worked at, Windows sysadmins had this solved. GPOs pushing scripts at boot. SCCM deploying agents fleet-wide. Golden images with everything pre-baked. Twenty years of knowledge passed down like oral tradition.

I was reinventing all of it because WorkSpaces sits in this uncanny valley — not EC2, not on-prem, none of those tools included. Those sysadmins were wizards under my nose for years and I never appreciated it until I had to do it myself.

Infrastructure should be invisible. Compliance should be automatic. The number of monkeys you had to stack to get there is nobody’s business but yours.