Are you using a docker image to run AWS CLI or something? It shouldn’t have anything to do with docker at all if you’re just running the bare ‘aws’ command.

It spins up docker containers to create an ssh connection?!

aws ec2-instance-connect doesn't use docker, it just sets up a short lived ssh key in the instance metadata that you can use to connect. You can connect either via a public ipv4, ipv6, or a vpc private endpoint.

I don't really know any details, but all I can tell you is that this is the output of running it in a fresh environment (masked out the instance details and snipped some output..):

  $ docker rmi amazon/aws-cli
  <snip>
  $ cd /tmp
  $ python3 -m venv venv
  <snip>
  $ . venv/bin/activate
  $ pip install awscliv2
  <snip>
  $ ssh -i mykey.pem ec2-user@i-masked     -o ProxyCommand='awsv2 ec2-instance-connect open-tunnel --instance-id i-masked'
  Unable to find image 'amazon/aws-cli:latest' locally
  latest: Pulling from amazon/aws-cli
  6ebddf7084e9: Pull complete 
  eb7d160dbc3b: Pull complete 
  af71d24e41d0: Pull complete 
  cf26adf9ea98: Pull complete 
  2491adb1df28: Pull complete 
  Digest: sha256:a8c8edb4641672d9ef61873594aa02d1c493341ca30f96e257fdc4d3da17ef9c
  Status: Downloaded newer image for amazon/aws-cli:latest
  
  A newer release of "Amazon Linux" is available.
  <snip>

And now I am logged into the machine. You can clearly see that it downloaded an AWS docker image. Exit from ssh, back to local terminal, and now there is an image on my machine:

  $ docker images | grep aws-cli

amazon/aws-cli latest 817d1061df76 3 hours ago 384MB

So I don't know if I agree that aws ec2-instance-connect doesn't use docker. And also, I don't necessarily have a problem that it does, it just surprised me a bit.

You're confusing `awscliv2`[1], a third-party Python wrapper around AWS CLI v2[2], with instance connect. From its package page:

- This is not an official AWS CLI v2 application

- By default this app uses amazon/aws-cli Docker image

The only official macOS distribution of AWS CLI v2 is via a macOS installer package:

https://docs.aws.amazon.com/cli/latest/userguide/getting-sta...

It's also available in Homebrew[3] but the packaging is maintained by a third-party, not Amazon.

[1] https://pypi.org/project/awscliv2/

[2] https://awscli.amazonaws.com/v2/documentation/api/latest/ind...

[3] https://formulae.brew.sh/formula/awscli

Oh I see. I installed awscliv2 after discovering that awscli did not have the ec2-instance-connect command, so I could not follow the documentation and went searching to see if there was an updated package and discovered that one. So I guess you are not supposed to install it using pip anymore. Good to know.

Update: and now I've read through the github issue, oh my I've missed quite some drama.

I agree it's confusing and I think Amazon's reasons for dropping PyPI support are pretty lame:

https://github.com/aws/aws-cli/issues/4947#issuecomment-5860...

They also have't provided a reason for why they don't distribute via Homebrew:

https://github.com/aws/aws-cli/issues/727

Don't overlook SSM <https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/session-...> which doesn't require sshd nor public access to get onto a machine and one can opt in to a bunch of audit logging if that's your jam. They also have some "ansible-y" behavior about running playbooks against groups of instances, but I haven't had good experiences with that process in order to recommend it. It's just a small bonus that one can also hop onto an instance from the AWS Console when using SSM, since it is websocket based and not "ssh from the browser"

The agent is Apache 2 if one wanted to build, enhance, or audit what it does: https://github.com/aws/amazon-ssm-agent#readme as is the local binary that awscli uses for the websocket handshaking: https://github.com/aws/session-manager-plugin#readme

I really like SSM, and for specifically for Windows RDP, the port forwarding feature. When combined with SSO, proper policies and tagging, you can do away with SSH keys, bastion hosts and VPNs.

SSM is powerful and convenient but very dangerous due to its huge surface area... I personally remove it by default.

The traditional method to achieve this is a ssh bastion. You have one tiny server running that has a publicly reachable IP, and can also reach the other servers (usually via the private network). You ssh into the bastion, then ssh from there into your actual server (or use port forwarding to make an ssh connection via the bastion, which some tooling supports out-of-the-box).

Considering the cheapest ec2 instance type is now cheaper than an ipv4 address this is easy to justify if the AWS specific options don't fit your usecase

Bastions are a good option. sshd supports jumping through them by default using the -J flag (jump) or automatically by adding the 'ProxyJump' statement to your .ssh/config.

Newer versions of ssh have the -J option which lets you enter the bastion host and it does everything else automatically.

See, you’re already acting as if you’re being selfish.

You’re not.

Having an IP per endpoint that is conveniently globally routable from any other endpoint is the entire purpose of the Internet!

It’s not some sort of greed or abuse of privilege! It’s the reason for the thing to exist!

This is like going to a shopping centre that has been growing along with the local population exponentially but refuses to buy more shopping carts. You can’t feel guilty for using a shopping cart “just” for your quick snack shopping as-if that’s a greedy move taking it away from more deserving people with “real” grocery shopping to do.

Stop thinking like this. Seriously, STOP!

You’re the victim here.

You’re the victim of Amazon’s greed and lock-in.

You’re the victim of the lack of foresight for the most predictable resource exhaustion in the history of the world.

You’re the victim of a problem that has had a solution for two decades that is now included for free(!) in every network device being made but is being turned off by lazy administrators that can’t be bothered averting slow-moving catastrophies.