As a developer I have tended to prefer the "standalone instance" route, and I almost certainly installed Steam that way: Follow the standalone instance instructions [1] and then log in to it as a remote desktop, installing whatever you need.
If the Steam install process needs GPU acceleration, then you'll also need to set up a VNC server on the instance and connect that way. Windows' "Remote Desktop Connection" can't use the GPU, where a VNC connection can.
BUT beware: Make sure your VNC password is as strong as possible; maybe even turn off VNC when you're not actively using it.
Good luck!
[1] http://docs.aws.amazon.com/appstream/latest/developerguide/a...
Steam games seem to fail whenever something needs to be admin, most likely installing directX on first - run. I'm going to try running them once first before packaging the appstream and then see how it goes.
OpenVPN offers UDP mode, and I believe Hamachi (the VPN software mentioned in the article) uses UDP by default as well.
I mean, why would it? You're not likely to have a high ping time inside your LAN.
The VPN solution might have worse performance than an appstream app, but it works with the existing catalog of steam games.
We periodically install random Windows apps (including games) to test the stack. Games work well. Too well, you might say. ;)
And considering how much work we've done to cut down on latency, I wouldn't expect the Steam streaming app running over a generic VPN connection to even come close in performance -- the VPN is almost certainly going to run over TCP, while AppStream will run over UDP, meaning in any but the best network environments AppStream will clobber a VPN connection for latency.
[1] https://aws.amazon.com/appstream/
[2] Disclaimer: I work on AppStream for Amazon, but my opinions are my own and don't represent Amazon. I'm just commenting as someone who has a lot of experience playing with the product.