I didn't realize AWS didn't have this already! I've been working exclusively in GCP for the past few years, and I assumed the two platforms were at parity. Is AWS starting to lag behind in new features?
It seems inevitable that remote dev environments will become ubiquitous.<p>With increased distribution of systems, increased use of cloud proprietary infra software that you can't run locally and now these custom SOCs. Companies are just going to give up on local dev environments and force everyone to write code in a browser.
Had to get feature parity with GCP, huh. Is this similar to SSH via SSM in that it could be a security improvement? Can I disable port 22 and remove the SSH client altogether and still use AWS CloudShell on an instance?
One of the nicest features for me in this is the webpage widget to upload and download files into the CloudShell instance.<p>I have zero problem doing this with the normal remote instance I use for this sort of thing in the past, but for whatever reason, walking junior engineers through this process is always one of the most painful things I deal with. Having a GUI way of doing this will make walking them through it easy.<p>That said, this environment doesn't deal with flaky connections well. A few toggles of my wifi, and now I have multiple bash orphans on my ECS container. I shouldn't be too surprised, looks like they've repurposed the SSH client from Cloud 9. It'd be nice if they brought in something like a Mosh client.
> CloudShell is intended to be used from the AWS Management Console and does not currently support programmatic interaction<p>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.
I am glad to see this as I hate using a web console to try to get actual work done.<p>But I have to confess I opened this article half hoping it would be about Lambda support for bare bash scripts. Horrifying, yes, but at the same time...
Really glad to see this directly integrated into the AWS console.<p>I ran workshops when I was at AWS, and using the Cloud 9 shell saved us a ton of time getting a room full of people set up with a functioning AWS CLI. Being able to just click a button to pull up a shell and then paste in a command is so much lower friction.
> Sessions cannot currently connect to resources inside of private VPC subnets, but that’s also on the near-term roadmap.<p>That should probably have been on the launch roadmap.
This would have been great to have last week. I was walking a client through deploying a project I wrote over a video call.<p>But before we could get started he had to:<p>- install the AWS CLI<p>- stop screen sharing while I walked him through creating an access key/secret key from the web console<p>- walk him through aws configure<p>start the screen share back<p>- install the SAM CLI<p>- install jq<p>If he had used this. He could have just run<p><pre><code> git clone
aws s3 mb $artifactBucket
sam package....
sam deploy
</code></pre>
And all of the resources would have been created.
How to install Ruby on AWS CloudShell: <a href="https://dev.to/peterc/how-to-install-ruby-on-aws-cloudshell-3n8c" rel="nofollow">https://dev.to/peterc/how-to-install-ruby-on-aws-cloudshell-...</a>
Nice to see AWS using ECS front and center! The containers might be floating around in fargate me thinks.<p>Started a CloudShell session and ran:<p>ps aux<p>cat /proc/1/cgroup<p>echo cool :)<p>Also feels like now an EIP IPv4 has been assigned to my IAM user. Pros and Cons seem to equal right now in my head. Mmmmm
Hmm, I suppose this is useful for super large orgs? I feel managing the IAM policies around this is pretty much the same level of complexity as managing access to a bastion host to open a ssh tunnel through.
I'm glad AWS is working on this. It's a big problem and companies are not facing it. Wrote about it here: <a href="https://andrios.co/articles/oneoffs" rel="nofollow">https://andrios.co/articles/oneoffs</a><p>But CloudShell is yet too narrow of a solution, I'm sure they will improve it over time, but a few problems with todays' release:<p>1) It only tracks bash commands. What if I write a quick Python one-off script and run it from a file? CloudTrail will never get the content of such script. This is script will get lost at the end of my session. What about Git for storing code?<p>2) Only works in the browser. The browser has it's good parts, but during incident resolution speed is critical. Getting a prompt without my local shell history, aliases, binaries, and many others, will make it slower to resolve incidents. One might say it's for a good reason, but we can do better.<p>3) Only works with AWS. This is a big problem as many companies are in the process of migrating to AWS, with services running within their own servers. Companies will use CloudShell to investigate edge cases, most of the time during incidents, engineers need fast access to all resources. Using a different solution for each type of resource won't help.<p>4) Hard to audit. If you ever tried using CloudTrail, you know what I'm talking about. And again, companies will need different solutions if they don't run only in AWS.<p>5) No review workflow support. If you only allow platform and SRE to access infrastructure, this is fine. But if you really want to bring ownership of problems to developers (DevOps), they need a way to get this level of access without risking production. This comes in the form of experts reviewing (instead of running) commands and scripts faster that the regular Github Pull Request workflow.<p>There are more, but I'm still happy with the product. AWS saying that you need one-off solutions no matter how much automation you have will help us move to a future where companies treat one-off scripts as first class citizens.<p>If you are interested in a solution that solves the problems I pointed out and many more, check out RunOps: <a href="https://www.loom.com/share/ea25027e73c94aa395f3e0ab70b71f0e" rel="nofollow">https://www.loom.com/share/ea25027e73c94aa395f3e0ab70b71f0e</a>
This is unrelated, but currently, I'm doing my own basic web development projects and pushing them to the cloud using netlify. What should be my next step to learn about AWS, devops, and these things in general?
Interesting that AWS went with the "pet vs cattle" terminology in their blog post. I thought it was not very cool to use in 2020, as evidenced by debates on naming convention in K8S.
Makes me wonder if I can install Terraform and Terragrunt on this...<p>LOL, or run a remote VSCode session on it :D (I know that's not gonna happen, but would be kinda cool nonetheless)
Prior: <a href="https://news.ycombinator.com/item?id=25431697" rel="nofollow">https://news.ycombinator.com/item?id=25431697</a><p>Not quite logged in yet - had a "AWS CloudShell is temporarily unavailable because it's being activated" screen for a while now. Fingers crossed!
I find that AWS chose the same name as GCP for this tool hilarious.<p>Nonetheless, excited to see it -- it's something that I've complained about with AWS since using Google's CloudShell. It also continues us down the path to easy Ops-type work on an iPad (even though you can already have an EC2 instance and use Prompt to access it, being able to have a shell without needing to provision and EC2 instance is <i>chefs kiss</i>).