Add ec2-sandbox.sh for throwaway Windows and Linux dev sandboxes

[peter-smith-phd]

Adds scripts/ec2-sandbox.sh, which stands up a disposable EC2 instance to do manual testing against, and tears it down again when you're finished testing. You get a fresh Windows or Linux machine, reachable over RDP, with a fresh install of VS Code ready to use. One sandbox per OS per region, so a Windows and a Linux sandbox can run side by side.

Usage

ec2-sandbox.sh <create|delete|info> <windows|linux> [options]

Command	Description
create <os>	Launch the sandbox and print the RDP connection details
delete <os>	Terminate it and clean up
info <os>	Re-print the connection details for a running sandbox

Options:

--region <r>          AWS region (defaults to your configured region)
--instance-type <t>   Override the instance type
--as <admin|user>     Which account --open connects as (default: user)
--open                Launch the RDP client afterwards
-y, --yes             Skip the delete confirmation
-h, --help            Full help

Each sandbox has two logins: an admin account, and an unprivileged User (Windows) / user (Linux). You probably want to use the User account for your manual testing.

Examples

./scripts/ec2-sandbox.sh create linux
./scripts/ec2-sandbox.sh create windows --region us-east-1 --open
./scripts/ec2-sandbox.sh info linux --as admin
./scripts/ec2-sandbox.sh delete windows -y

Notes

• Requires AWS credentials in your shell; run --help for the full option list.
• RDP and SSH are opened only to your current public IP address, but are inaccessible to every other IP address.
• You'll need to install the "Windows App" if you're a Mac user, and this will allow you to RDP to the Windows / Linux instances.
• Note that Windows uses Podman (not Docker), since Docker Desktop is not available for Windows Server, and EC2 doesn't allow us to create Windows Desktop instances (it's a licensing issue).
• Instances bill by the hour, so run delete when you are finished.

[anisaoshafi]

Thanks a lot, Peter 🙌🏼
Tested with a windows instance, worked like a charm 👏🏼
Connecting was easy, this helps a lot.

[dominikschubert]

Nice! Was working on something similar the last two days, but kept hitting the same limitation.
I do have a few concerns, but as this is just a script, nothing here is blocking a potential merge.
While it's still useful to be able to spin up a quick instance we can RDP into I'm mostly worried it might lead us to a sense of false of "security" (or rather correctness).

1. Server vs. Client image

Note that Windows uses Podman (not Docker), since Docker Desktop is not available for Windows Server, and EC2 doesn't allow us to create Windows Desktop instances (it's a licensing issue).

I've been running into the same problem and from my point of view, the intention was to test a realistic customer environment (someone using Windows on e.g. their Laptop). AFAIK we'd need to create a VM on Azure for a proper Client image or bring our own license with a standard client image loaded on EC2, but there's no pre-baked client images available on AWS as you said. I'm not versed well enough in the Windows ecosystem to say how much of an is sue that is in terms of faithful reproduction of a typical user environment. Not being able to use Docker Desktop seems to be very limiting when I assume that's what the majority is using right now.

2. Docker setup
   We're not at a point where we are able to treat podman as a first-class alternative to Docker for Localstack workloads, which is why it also won't be able to surface the customer issues we'd expect on Windows with Docker (Desktop). I'd highly recommend against using podman here. As an alternative we can install docker-engine instead but even that is not a faithful representation as most will still be using Docker Desktop [intuition - don't have data right now at hand to back that up].
   That said, we should definitely ramp up our E2E testing for all of these Docker alternatives, which is where this will come in handy!

3. What do we actually need to test?
   Trying to enumerate with the help of Claude the cases we're trying to cover for with explicit testing on Windows:

Legend: ✓ covered · ~ partial · ✗ not covered

Dimension	Weight	1. Win11 + Docker Desktop	2. Server + Engine (WSL2)	3. Server + Podman
Layer 1: Windows OS / Go binary (paths, keyring, signals, update, shells, TUI)	high	✓	✓	✓
Docker Desktop plumbing (//./pipe/docker_engine, context, engine-starting state, file sharing)	high	✓	✗	✗
Lambda / networking with attributable results (real Docker socket, bridge)	high	✓	✓	✗ (Podman noise)
host.docker.internal	med	✓	✗	✗
Podman detection branch	low (Linux CI can cover)	✗	✗	✓
Matches real user segment	—	majority	WSL2-Engine minority	Podman minority
Hosting	—	Azure / Windows 365 / local VM (no EC2)	EC2	EC2
Setup effort	—	high, manual	medium (WSL2 + dockerd + DOCKER_HOST)	done (PR #480)
Cost	—	highest	low, hourly	low, hourly
Role in matrix		Release smoke tests	Daily Windows bug hunting	Cheap Layer 1 checks; Podman segment

[peter-smith-phd]

Nice! Was working on something similar the last two days, but kept hitting the same limitation. I do have a few concerns, but as this is just a script, nothing here is blocking a potential merge. While it's still useful to be able to spin up a quick instance we can RDP into I'm mostly worried it might lead us to a sense of false of "security" (or rather correctness).

I totally agree - I think this will give us 80% confidence that it runs on Windows, but the remaining 20% of possible problems will be related to not using Docker Desktop. We should treat this script as a nice to have, but we still need to have Docker Desktop running on Windows Desktop to get that 100% confidence.

What this solution does buy us:

1. Easy access to a Linux system.
2. Easy access to make Podman-on-Windows work (something we need, as a secondary solution).

Maybe we need a similar script that creates something on Azure?