Haha I'm not sure if you were being serious, but the workflow you just outlined is the clunky part of SSM. The pre-requisites are getting all the IAM roles and permissions setup (no mean feat), installing the agent, configuring it with keys generated by another user, and getting the connection information back from the aws console. This promises to be a lot easier to setup and authenticate, install tailscale, login.

Installing the agent client side is no more or less tedious than installing the Tailscale client, IMO anyway.

I made two scripts, one in .Net with a GUI for non-devs to grep a server hostname or tag:name in AWS that resolves to an instance ID for SSH or RDP. And another python script doing the same but without the GUI for the dev team. Works a treat.

But you've already explained why it's a little tedious and now I've documented and understood why. Tailscale MagicDNS does all this nonsense for you. Yeah ok thanks for rubber ducking me I see your point now. :)

I think I see what you're saying. Usually though, a lot of that stuff is single-setup. E.g., all OS's that we have deployed have the agent installed and running by default.

Additionally, the instance roles are already pre-configured.

There's almost zero overhead in ensuring SSM gets installed on new instances.

One small benefit over TailScale here, I would think, is that I don't have to rely on another tool to gain shell access. Probably a minor win, if you're running a TailScale deployment. In either case, I'd probably want to go with a single tool just to minimize the attack surface area.

It really seems to depend on the point of view. If you're already using AWS seriously, your hosts will have the default agent anyway, IAM is already managed in a reasonable way (iamy, tf or similar), etc. so the setup is not that hard. I'm not sure what you mean by information from the AWS console - it's usable in the terminal.