A conversation at work a few weeks ago reminded me that a lot of folk don’t have AWS CloudShell on their radar, which surprised me a little.
I thought about it though for a few days, and came to the conclusion that there’s a fundamental difference between the habits and mindset of someone who began using multi-user systems back in the late ’70s to someone who comes to it now (yes, I know, I’m handwaving a cloud environment as a multi-user system).
Back in the day, working with serious computing resources almost always meant logging into a server via a dumb terminal.
Quite definitely, we perceived the operating shell to be “over there in that other machine”.
This persisted well into the 80’s, as our terminals morphed into Terminal apps in a GUI, but somewhere in the last few decades, the habit has shifted to running things locally that operated on remote assets, instead of the older habit of operating remotely. The whole world of infrastructure-as-code and command line interfaces to cloud providers leads to a world view of the code being local to the operator desktop.
As a result, while I find the idea of launching a CloudShell for some operations very natural and comfortable, some of my younger co-workers don’t even think of it as an option.
Let’s unpack what CloudShell is for a little bit, because I’m guessing that it may not be familiar to the reader either.
Basically, CloudShell is a terminal window displayed in the AWS web console (or Mobile app, as I talk about below) that you can use to operate against the AWS account with everything running remotely rather than on your desktop.
Launching a CloudShell session is very fast – seconds at most – and once launched the first time, comes up almost instantly on future invocations. What you get is a command line virtual machine with 2GB of RAM, 1 vCPU, and 1Gb of persistent storage in your home directory (caveat, this only persists for up 120 days since the last time you used the virtual machine, after which it is lost).
The machine is running one of the flavours of Amazon Linux, and comes pre-installed with all the tools you need for bashing (ah-ha!) around on the command line, including Python, git, the AWS CLI tools, node.js, Docker, kubectl and a ton of other goodies. Installing other tools, like Terraform, is possible if you can install them in your home directory.
The command line session inherits the role (and thus permissions) of whoever you logged into the console as, but of course you can easily assume another role (that you have permission to assume…) or use some other method to operate using a different IAM identity inside the terminal session.
The only trick is that the principal that logged into the AWS console needs permission to launch CloudShell. You can either craft a policy for specific permissions, or just use the AWSCloudShellFullAccess managed policy.
The key question is – why use CloudShell instead of just opening a terminal window? It’s a fair question. For most real life purposes, the credential you have for accessing the AWS account from the web console is the same credential you use from your local terminal window (or to be precise, the same principal with the same permissions).
In answer, some of the reasons I’ve used it in the past:
- The computer I’m working of is not my normal machine, and I don’t want to download things onto it or install tools just to get the work done;
- I may not want to have access credentials on my local machine;
- I want to run something that takes a while to execute, without needing to keep the local machine logged in, but without the hassle of creating a temporary EC2 instance;
- I want to move data around, but don’t want to copy it from the AWS cloud to my laptop, and then back up again;
- I want to experiment with different versions of standard tools, without the hassle of either setting up a temporary EC2 instance of some sort of temporary working environment on my laptop
Launching CloudShell is trivial (assuming you have the permission to do so). There are widgets on the console to use a shortcuts, or you can find the service through the service selector:
Using the widgets launches the terminal in a pop-over window, and you can use the drag widget at the top of it to resize it
Launching the service opens the terminal full sized in your browser window
Notice also the “+” control – you can add additional tabs for additional shells.
Poking around in the shell, it’s about as standard as you can get. You’ve got a user, a filesystem, and an IP address
From here, I can do a Git clone to pull in whatever tool(s) or code I’m working with, and just go from there.
Now for the fun part. Did you know that AWS have a mobile app? A lot of folk don’t. I’ve got it on my phone, and on my iPad… which means I can be hyper mobile while still being able to operate my AWS accounts. That’s pretty cool.
Launching CloudShell (notice the widget in the top right corner) takes you through the “are you really happy to do this?” prompt
Once I’ve launched it, I’m back inside the same (somewhat) persistent virtual machine, and can operate the command line on the remote service from my phone.
To be honest, I rarely do this off my phone. My eyes are getting old, and reading this is not comfortable, plus typing with my thumbs is a slow.
But this is very comfortable off my iPad, given it has a screen comparable to most laptops, and an… adequate… keyboard.
I have some cautions to add about operating this way off a mobile device.
In my case, the principal I use for accessing my AWS accounts from mobile only has read permissions – I can’t update anything.
It’s also important to have strong login protections on your mobile device. Fortunately current model Apple mobile devices have good biometric access control, so the risks of someone misusing the AWS account can be minimised. Despite that, I do have additional MFA controls to login to the AWS account. Just in case.
Watch this space – I want to do a similar write up for Google Cloud Platform. GCP and Azure also have work-alike virtual terminals, but I’m can’t be bothered to re-enable my Azure account just to write it up.