[bgs113]

> CloudShell is intended to be used from the AWS Management Console and does not currently support programmatic interaction

Which unfortunately means I can only access this from a browser window and can't start up a session from my own terminal. Sure would be nice to be able to launch a secure, remote CLI without all the limitations of a web client.

[alFReD-NSH]

The point of CloudShell is to easy use AWS CLI without setting it up and setting the credentials, however to use this from your own terminal, it means you have to install software and then configure credentials, well then that would exactly same as installing AWS CLI and configuring it.

[yjftsjthsd-h]

On the flip side: How is installing a browser and authenticating in it any better than installing openssh and/or awscli and authenticating through them?

[Thorrez]

I think it's assumed that everyone already has a browser installed. Also to authenticate through openssh and/or awscli it will likely require some browser interaction, so that would require installing a browser if one isn't installed.

[acdha]

MFA and persistence — especially if you use SSO. If you have credentials sitting around in your home directory they can be harvested from a standard location by malware and people are often very slow to rotate them. In contrast, if you're following Amazon's guidelines your console login will already have MFA and be using short-term credentials.

[yjftsjthsd-h]

awscli directly supports 2fa (https://aws.amazon.com/premiumsupport/knowledge-center/authe... ); I guess having to harvest cookies out of a browser profile is more work, but it seems like a small difference

[acdha]

It supports some MFA (e.g. not U2F / FIDO) and not if you use SSO.

The browser profile is harder to exfiltrate, in part because modern OSes have ways to restrict access to particular processes, but that was also only part of the benefit: the main thing is the duration of the session. Tons of people leave AWS keys sitting around in ~/.aws for ages.

You can setup schemes with STS but not everyone remembers that and with this approach you have a very simple answer: it always uses STS, there's never a file sitting around for someone to accidentally save somewhere they shouldn't, etc.

Nothing here is something you couldn't do on your own — it's just a very easy option with safe defaults.

[joseph]

I think the issue is that web based terminals aren't very usable, as they mess with keybindings and line wrapping, for example. At least that is the case with GCP Cloud Shell. It makes it pretty difficult to use for even basic things like running vi or emacs.

[isaveyou]

Doesnt save link as a PWA make it behave like yet another electron app with regards to key capture?

[ohyeshedid]

You can connect via ssh to a GCP cloudshell instance, you just need to spin it up first.

[the8472]

The problem is that AWS CLI without access to your custom workflows in the form of aliases, scripts and what-not is far less useful.

Or perhaps even entirely useless if you'd normally use it as part of a local build and test process.

[staticassertion]

You can SSH via AWS Systems Manager.

https://docs.aws.amazon.com/systems-manager/latest/userguide...

[hrez]

to cloudshell?

[Kiro]

What would the difference be? Isn't CloudShell just a shell that you can easily access from the browser?

[hrez]

managed vs self-managed among other things

[gizmodo59]

I think something like this: $gcloud alpha cloud-shell ssh

I love to be able to use my terminal client than browser. This is neat because I don't want to maintain another ec2 myself even if its in the free tier.

[bdcravens]

I think this is meant as an alternative to having the cli installed locally. What is the advantage to you of running a remote AWS cli session from your terminal?

[derefr]

The same thing you get from AWS WorkSpaces, but in CLI form: a machine that's running within/adjacent to your corporate VPC, with fast high-bandwidth access to all your internal infrastructure, especially things like storage buckets. As opposed to your own machine, running half-way across the country where you might only be able to achieve 10Mbps between you and the AWS datacenter.

Think "I'll run this arbitrary script to batch-process input-bucket X to output-bucket Y, enriching the data by calling out to internal service Foo and external service Bar." The kind of thing Google's Cloud Dataflow is for, but one-off and freeform.

—also, for a lot of people, just the fact that things are running in the cloud, means they're running more reliably. If you want to run something that's going to take four days to finish, you don't want to do it on your own workstation. What if the power cuts out in your house? (Just the fact that you can restart/OS-update your local computer and "keep your place" in the remote is nice, too.) You want a remote VM somewhere (preferably with live migration in case of host maintenance) running screen(1) or tmux(1), with your job inside it. Of course, you can just create a regular VM in your VPC, and do it on top of that; but a cloud shell abstracts that away, and "garbage collects" after itself if you leave it idle.

[hrez]

Except it doesn't run in any of your VPC's.

[_alex_]

Not yet

[RKearney]

You mean like Cloud9?

https://aws.amazon.com/cloud9/

[NeutronStar]

"AWS Cloud9 is a cloud-based integrated development environment (IDE) that lets you write, run, and debug your code with just a browser."

I would say no.

[RKearney]

You can easily SSH to a Cloud9 instance, so it would satisfy the criteria given.

Alternatively, one can launch a custom AMI in EC2 to do whatever they want.

Multiple solutions already exist for the given problem, therefore yet another AWS service seems unnecessary.

[bgs113]

Except that Cloud9 requires an EC2 instance and associated spend, whereas CloudShell is free.

[_alex_]

I think you just described ssh