A new hire on my team once spent half a day trying to get Azure CLI and PowerShell modules installed correctly on a locked-down corporate laptop before she could run a single command against our subscription.
IT policies blocked package installs, antivirus flagged the CLI installer, and by lunchtime she still hadn’t managed a single resource. That kind of friction is common in enterprise environments where endpoint restrictions, VPN requirements, and software approval processes turn a five-minute task into a multi-day ordeal.
Azure Cloud Shell solves exactly this problem. It’s a browser-based, authenticated shell environment that Microsoft hosts for you, preloaded with Azure CLI, Azure PowerShell, and a handful of other common tools — no local install, no corporate laptop restrictions, no “wrong version of the module” errors. You open a browser tab, sign in, and you’re running commands against your subscription in under a minute.
This guide covers what Cloud Shell actually is under the hood, how its storage and authentication model works, when to use it versus a local terminal, and the security and cost details you need to know before relying on it for day-to-day Azure administration.
What Cloud Shell Actually Is
Azure Cloud Shell is a browser-accessible, Microsoft-managed command-line environment that runs on temporary, auto-provisioned compute in Azure. You access it directly through the Azure portal, through shell.azure.com, or through the Azure mobile app, and it authenticates using your existing Azure sign-in — no separate credential setup required.
Under the hood, Cloud Shell spins up a lightweight container on demand, mounts a persistent file share from your storage account, and gives you a choice between a Bash environment or a PowerShell environment. Both come with Azure CLI, Azure PowerShell’s Az module, Git, Terraform, Ansible, kubectl, Docker CLI, and several other tools already installed and kept current by Microsoft.
That last point matters more than it sounds — if you’ve ever hit an error because your locally installed Az PowerShell module was three versions behind and missing a cmdlet, you know how much time Cloud Shell saves by removing that variability entirely.
The container itself is ephemeral. Once you close the session or it times out from inactivity (typically after 20 minutes), the compute is torn down. Nothing about your work is lost, though, because Cloud Shell separates compute from storage — which is the next thing worth understanding clearly.
Pro Tip: In my experience, Cloud Shell is the fastest way to hand off “please run this one command” tasks to a teammate who doesn’t have Azure CLI installed locally — I just send them the command and tell them to open Cloud Shell from the portal. No setup conversation needed.
How Cloud Shell’s Storage Model Works
The first time you launch Cloud Shell, Azure prompts you to create or select a storage account to back it. This is a real, billable Azure Storage resource in your subscription, and it’s what makes Cloud Shell persistent rather than a totally throwaway session.
Cloud Shell creates a File Share inside that storage account and mounts it as your $HOME directory (technically your clouddrive mount plus an .img file that holds your home directory contents). Anything you save there — scripts, downloaded files, SSH keys, .bashrc customizations — survives across sessions because it lives in persistent storage, not in the throwaway container.
If you’ve worked with Azure Files before, this is exactly that service doing the heavy lifting behind Cloud Shell’s “remember my stuff” behavior.
This design has real implications worth understanding:
- Storage costs apply. The file share consumes a small amount of storage (usually a 5 GB minimum allocation), which shows up as a normal charge on your Azure storage account bill. It’s inexpensive, but it’s not free, and it’s easy to forget it’s there if you set it up once and never think about it again.
- One storage account can serve multiple regions, but Cloud Shell ties your home directory to a specific file share, so if you delete that storage account, you lose your saved scripts and configuration.
- You can bring your own storage account instead of letting Cloud Shell auto-create one, which matters if your organization has naming conventions or resource group placement rules that a wizard-created resource would violate.
If your team already has strict tagging and naming standards, I’d strongly recommend creating the storage account yourself ahead of time following your resource group naming convention rather than letting the first-run wizard name it for you — cleaning up an oddly named “cloud-shell-storage-eastus” resource group later is a hassle nobody enjoys.
Pro Tip: I always create the Cloud Shell storage account inside a dedicated, clearly tagged resource group before a new team’s first login. It avoids the auto-provisioned defaults from scattering unmanaged storage accounts across random resource groups that show up months later during a cost review with nobody able to explain what they’re for.
Bash vs. PowerShell: Choosing Your Environment
Cloud Shell gives you a toggle between Bash and PowerShell environments, and you can switch between them at any time without losing your mounted file share. The underlying container changes, but your $HOME directory persists either way.
Choose Bash if your daily work leans toward Azure CLI, Linux-based scripting, Terraform, or you’re more comfortable in a POSIX shell generally. Azure CLI’s az commands work identically here as they would on a local Linux machine, and our Azure CLI tutorial and list of top Azure CLI commands you must know apply directly.
Choose PowerShell if your background is Windows administration, Microsoft Entra ID scripting, or you’re managing hybrid environments where PowerShell is already your team’s standard. The Az PowerShell module comes preloaded and current, meaning you skip the installing Azure PowerShell and importing the Azure module in PowerShell steps entirely — Cloud Shell has already done that work for you.
Realistically, most administrators end up using both depending on the task. I use Bash for quick resource inspection and Terraform runs, and I switch to PowerShell when I’m scripting Microsoft Entra ID group membership changes or working with cmdlets that don’t have a clean Azure CLI equivalent yet.
Here’s a basic example of listing resource groups from Cloud Shell using Azure CLI:
az group list --output tableThis command lists every resource group in your currently active subscription and formats the output as a readable table instead of raw JSON — useful for a quick visual scan when you’re troubleshooting or documenting an environment.
And the PowerShell equivalent:
powershellGet-AzResourceGroup | Select-Object ResourceGroupName, LocationGet-AzResourceGroup retrieves all resou