Checking further, it looks like AWS WorkSpaces doesn't actually support any protocol other than "Teradici PC-over-IP"—I'm guessing that whether or not you enable RDP on the remote, the AWS firewall policy won't expose the port. (This is apparently on purpose; WorkSpaces advertises "keeping your data on-premise by never exporting it to the client; the client only gets pixels.")

I guess plain EC2 Windows instances will still work, though. The setup is simple enough:

1. on the instance, select a base image of any edition of Windows 7/8/10 that supports receiving Remote Desktop Connections;

2. enable receiving Remote Desktop Connections on the instance's System prefs (might already be enabled if that's how they expect people to connect to manage their instances);

3. install this thing on the instance: http://www.kimknight.net/remoteapptool (since Windows doesn't come with any sort of GUI for this†);

4. use the tool to generate an RDP connection profile on the instance—naming the session and browsing for an EXE path is usually enough;

5. in the same tool, generate an .rdp file for that session, and get it back to your computer;

6. import the .rdp file into Microsoft Remote Desktop;

7. edit the new RDP connection to supply the correct server address (from the client's perspective) and prepopulated authentication credentials.

Now launching that RDP session should give you e.g. a Notepad window on your desktop.

Note one restriction: if the EC2 instance you're running isn't a Server edition of Windows, you'll be restricted to one RDP session at a time. There are things you can do to get around this, though I'm not sure they're compliant with the Windows EULA.

---

† The actual, official thing you're supposed to do is to have a Server-edition instance running the "Remote Desktop Connection Broker" service; the Server Manager app, pointed at that machine, then lets you manage "RemoteApp and Desktop Connection Resources" (i.e. an RDP session directory).

Interestingly, the "session host" instances that the Connection Broker, well, brokers for, can be any edition of Windows (but are usually Enterprise); productivity apps aren't written for, or tested with, Server-edition Windows, after all, so it wouldn't make sense for the instance the users actually connect to to be a Server.

The tool above basically skips the Broker by giving you the same .rdp profile the Broker would answer with after you negotiate with it. This is why the process feels so manual: if you had a Connection Broker server in-between, it'd be the thing transparently plugging in all those details for you, basically taking the .rdp "template" you get from the tool and filling out the client-side creds from the client step of the negotiation, and the server-side address by picking one of its load-balanced pool members.