What you need to know about the new AWS CloudShell service (A Cloud Guru)
Originally posted on acloud.guru
So, a new way to use a command line might not be one of re:Invent 2020's sector-shattering announcements, but my goodness, it’s long-awaited — and very welcome.
During the final week of re:Invent 2020, Amazon released the new AWS CloudShell, a browser-based shell that makes managing your AWS environment through the command line an absolute breeze. Why should you care? Read on!
Why is a fancy command line cool?
The command line has the flexibility that the AWS Management Console just can’t match. Needing to make repetitive changes? Extract information for a report? Just need to make a quick config change? CLI will often be the most powerful tool to accomplish this.
But we’ve had other options. Instance Connect, Cloud9, and jump servers have helped us manage our systems anywhere we’ve needed them. But all of those require an EC2 instance to be running, and that incurs a cost. If you’re using federated identities, that’s an even bigger headache with no personal API keys.
You could just use shared IAM roles or API keys between all of your admins. But you also lose all integrity of your ability to attribute changes to an individual. (Also, your CISO’s ears just started burning even from reading that idea.)
AWS CloudShell is different in that you can use it anywhere you have a browser. It’s free and requires no setup. The best part though? It automatically assumes a role based on your IAM identity — even with federated identities. No fuffing about with credentials! You even have a 1GB /home drive for persistent storage.
What is AWS CloudShell? What are the Benefits?
Okay, so a lot of this is stuff you could read on a news site or AWS’s own blog. Let’s dig into four interesting technical bits.
1. Regional service
Despite being present at the heart of the console, AWS CloudShell is very much a regional service. At time of publishing, it is available in five regions around the world:
- US East (Ohio)
- US East (N. Virginia)
- US West (Oregon)
- Asia Pacific (Tokyo)
- Europe (Ireland)
Fortunately, you can still use the AWS CLI across any region around the world, just as you would from a local machine. So even if all of your AWS Resources are located in Melbourne, Australia, you can still easily use the CloudShell from a U.S. region to manage your resources.
One thing to be aware of is that your persistent home drive storage is local to the region, not global, much as you’d expect from a service probably backed by EBS. Persistent storage is also not permanent, and after 120 days of not using CloudShell in a region, the storage is purged. Something to be aware of with those handy admin scripts!
2. More repositories
Running on Amazon Linux 2, the initial range of applications available on your CloudShell can be a little underwhelming. But just as with any other Amazon Linux 2 machine, you can add additional repositories to your yum configuration.
As an example, you can add the Extended Packages for Enterprise Linux with some very simple commands:
sudo yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
sudo yum updateinfoThis gives you so many options for flexibility in your CloudShell. Indeed, you can even install the CLI tools for Azure or GCP, if you choose!
3. Persisting beyond files
While CloudShell does have a persistent home directory, that’s all that persists. Applications do not. But wait, there’s a solution! If the home directory persists, why not install the applications we need there?
You can also use the .bashrc file in the home directory to amend the local $PATH attribute when launching the shell, making it easy to seamlessly use those applications. You can even take that further and use .bashrc to customize your CloudShell extensively!
Okay, but what if we need more than 1GB of persistent storage? Well, you’re probably using the CloudShell for more than it was designed. But if you needed to, you could also store files in an S3 bucket, and pull them down to the CloudShell on another local directory on launch. Now, you will incur data transfer costs, but it does give you some options.
4. AWS CloudShell VS. Google Cloud Shell VS. Azure Cloud Shell
And you’d be right. Not only are Amazon not first to this game, they’re comparatively late. Other cloud providers have already beaten them to this feature, with Google Cloud Shell (released October 2015), and Azure Cloud Shell (May 2017).
In fact, users of those platforms might find accessing AWS CloudShell to be very familiar . . .
This is actually a really positive thing in giving some feeling of consistency between the cloud providers. And there’s a reason Google developed the Cloud Shell in the first place — and why Microsoft eventually copied them. It’s a fantastically versatile feature, and I suspect it’ll be one of the most widely used features announced at re:Invent 2020.
Fun fact: This is the first service I can think of that has the same name across all three major cloud providers.
