I keep getting more and more powerful laptops, and then offloading more and more processing to the cloud. SOMETHING’S GOTTA GIVE! My local machine doesn’t just run web browsers and chat apps. No, my laptop is still loaded up with dev tools, while all my virtual machines and container clusters now live in the cloud. That helps. But we’re seeing more and more of the dev tools sneak into the cloud, too.

One of those dev tools is the shell experience. If you’re like me—actually, you’re probably much more advanced than me—you invest in a loaded terminal on your machine. On my Mac, I directly install a few tools (e.g. git, gcloud CLI) but use Homebrew to keep most of my favorite tools close by.

It’s no small effort to maintain a local terminal environment that’s up to date, and authenticated to various endpoints. To make all this easier, each of three hyperscalers now has a “cloud shell” experience that offers developers a hosted, pre-loaded terminal for working with that cloud.

In this blog post, I’m going to look at the cloud shells from AWS, Microsoft Azure, and Google Cloud, and see what they really have to offer. Specifically, I’m going to assess:

• Shell access. How exactly do you reach and use the shell?
• Shells offered. Bash? Powershell?
• Amount of storage provided. How much can you stash in your environment?
• Durability period. How long does each cloud hold onto your compute environment? Storage?
• Platform integrations. What ways does the shell integrate with the cloud experience?
• Embedded tools. What comes pre-loaded in the shell?
• Code editing options. Is there a way to edit files or build apps?
• Compute environment configuration/extensibility. Can you change the shell environment temporarily or permanently?
• UX and usability controls. What can you do to tweak the appearance or behavior?

Let’s take a look.

Disclaimer: I work for Google Cloud, so obviously I’ll have some biases. That said, I’ve used AWS for over a decade, was an Azure MVP for years, and can be mostly fair when comparing products and services. Please call out any mistakes I make!

Google Cloud Platform

GCP offers a Cloud Shell that runs within a Docker container on a dedicated Google Compute Engine virtual machine. Not that you see any of that. You just see a blinking cursor.

How do you reach that cursor? From within the GCP Console, there’s an ever-present button in the top navigation. Of note, you can also access it via a dedicated link at shell.cloud.google.com.

Once you launch the Cloud Shell—and if it’s the first time, you’ll see a brief message about provisioning your infrastructure—you see a new frame on your screen. Note that this is a globally distributed service, and you’re automatically assigned to the closest geographic region.

Each user gets 5GB of persistent storage that’s mounted into this underlying virtual machine. This VM terminates after 20 minutes of inactivity. If you don’t use Cloud Shell at all for 120 days, the home disk goes away too.

You have two default shell interpreters (Bash and sh) at your disposal here. Google Cloud Shell lets you create unique sessions via tabs, and see below that I’m using one tab to list all the shells. I was able to switch between shells, including PowerShell too!

Cloud Shell comes with lots of pre-loaded tools including gcloud, vim, emacs, gradle, helm, maven, npm, pip, git, docker, MySQL client, TensorFlow, and Terraform. It also has built-in language support for Java, Go, Python, Node.js, Ruby, PHP, and .NET Core.

If you want tools that aren’t pre-loaded by Google Cloud, you’ve got a few options. You can manually install tools during your session, or, create a customer_environment script that runs whenever your instance boots up.

What about platform integrations? If you call a Google Cloud API that requires credentials, there’s a prompt for authorization. There’s also an “Open in Cloud Shell” feature that makes it simple to create links that trigger opinionated Cloud Shell instances. If you’re writing tutorials or want people to try the code in your git repo, you can generate a link. There’s also a baked-in cloudshell CLI to launch tutorials, download files, and more. You can also use the gcloud CLI on your local workstation to tunnel into the Cloud Shell, thanks to the gcloud beta cloud-shell operation.

The Google Cloud Shell also has a full-fledged code editor built in. This editor—also available directly via ide.cloud.google.com—gets launched right from the Cloud Shell, either through the button on the Cloud Shell navigation or by invoking the cloudshell edit . command.

This editor is based on Eclipse Theia and has the Cloud Code extensions built in. This means I can create apps, use source control, link to GCP services, run tests, and more. Because Cloud Shell supports Web Preview, you can also start up web applications and hit a local endpoint.

Let’s look at the overall user experience. In the Cloud Shell navigation menu, I have options to send key combinations (e.g. Ctrl+V), change the look and feel (e.g. color, font), upload or download files, run in safe mode, restart the Cloud Shell instance, minimize the frame itself, break it out into its own window, or close the terminal entirely.

With this mix of free storage, a wide set of tools, a fully functional code editor, and easily extendible environments, the Google Cloud Shell feels like a very complete experience.

Microsoft Azure

Azure provides a Cloud Shell that runs on a temporary virtual machine. Like with GCP, all the infrastructure details are invisible, and users just get a virtual terminal.

You have a few ways to reach Azure’s Cloud Shell. There’s an always-there button in the Portal and a direct link available at shell.azure.com.

Once you trigger the Cloud Shell, you quickly get a new resizable frame holding your terminal instance.

The compute instance is available at no charge. These instances use a 5GB persistent storage image in your file share, and it appears that you pay for that. Like the Google Cloud Shell, the Azure one uses non-durable compute nodes that time out after 20 minutes of inactivity.

You have two shell experiences: bash or PowerShell. Storage is shared between each.

The Azure Cloud Shell comes absolutely loaded with tools. You have all the standard Azure tools (Azure CLI, azcopy, etc) along with things like vim, emacs, git, maven, npm, Docker, kubectl, Helm, MySQL client, PostgreSQL client, Cloud Foundry CLI, Terraform, Ansible, Packer, and more. There’s also built-in language support for Go, Ruby. .NET Core, Java, Node.js, PowerShell, and Python. I didn’t see any obvious way to customize the experience that lasts beyond a given session.

As far as integrations, it appears there is SSO with Azure Active Directory. There’s also a special PowerShell commandlet for managing Exchange Online. Try to control yourselves. Similar to GCP, the Azure Cloud Shell supports a URL format that lets tutorial creators launch the Cloud Shell from anywhere. Visual Studio Code users can also integrate the Azure Cloud Shell into their local dev experience.

Azure also provides a handy code editor within their Cloud Shell experience. Based on the open source Monaco editor, has a basic file explorer, command palette, and language highlighting.

Let’s look at the user experience. In the Cloud Shell navigation bar, you have buttons to restart the shell, configure font style and size, download files, upload files, open the code editor, trigger a local web server, minimize the frame, or shut it down.

All in all, it’s a solid experience. Not as rich as what GCP has, but entirely functional with nice touches like the code editor, and easy switching between bash and PowerShell.

AWS

AWS is the newest entrant to the cloud-based terminal with their AWS CloudShell. AWS seems careful to call the host a “computing environment” versus ever saying “virtual machine.” It’s possible that you get a container in a shared environment.

It looks like you have one way to reach the CloudShell. There’s a button in the AWS Console navigation bar.

Clicking that button pops up a new browser instance holding your terminal.

There’s no cost for AWS CloudShell and you get 1GB of persistent storage (also for free). The service is available in a handful of AWS regions (3 in the US, 1 in Ireland, 1 in Tokyo). Sessions expire after 20-30 minutes, and data is held for 120 days.

AWS CloudShell has three shell experiences including bash, PowerShell, and z shell.

The AWS CloudShell comes with a handful of useful pre-loaded tools. You get the AWS tools (e.g. AWS CLI, AWS SAM), as well as git, make, ssh, and vim. You can modify the default environment by creating a .bashrc script that runs whenever the bash shell fires up. There’s native language support for Node.js and Python.

There’s one platform integration I noticed, which helps you push and pull code from AWS CodeCommit.

There are some nice touches in the AWS CloudShell user experience. I like that you can stack tabs (session) or put them side by side. You can also download and upload files. AWS also offers settings to change the font size or switch from dark mode to light mode.

AWS offers a functional experience that’s basic, but useful for those living in an AWS world.

It’s great to see all the major clouds offering this functionality. GCP objectively has the most feature-rich experience, but each one is useful. Try them out, and see if they can make your dev environment simpler.